Mail Archives: geda-user/2015/05/02/17:57:09
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f
|
| X-Recipient: | geda-user AT delorie DOT com
|
| DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed;
|
| d=gmail.com; s=20120113;
|
| h=mime-version:in-reply-to:references:date:message-id:subject:from:to
|
| :content-type;
|
| bh=iPWNKbEmbtstlUj58LkEqugzh/BfZ5QtZI4IG1KAI7g=;
|
| b=lp1wwhDX+0QhT7WjvMQah+RbHaHWRQDfN9DbSaCfDRdao1smHK/BsOHSI2A2sQf7j9
|
| tetYali1kii0/YfU14kemYHYBWJbW1j5Rvd57tNMgpAdFfPVFiuaTGW6f85MWTlbOUNi
|
| MvajYA7+xKOkC6E85EuAJWcVqU0wEatkOxrrD2o6jEGQ1u1XDjAsYH0dss8UhJ7ko0ZB
|
| uMsKXBBaD8Ns4jyK2FJs5ZaIHeJMMlAdmAQ3o/ncmw+ZEpZR+vj2mL2jGQySv5EiJ4j7
|
| Gkh3DKhIilTjHGmrq8NQEk4iGh/BDfqcfIgW7t8dzQtpcTt/WcuCm0cUHDk15ub1D7ox
|
| E53Q==
|
| MIME-Version: | 1.0
|
| X-Received: | by 10.107.128.149 with SMTP id k21mr19681259ioi.7.1430603773237;
|
| Sat, 02 May 2015 14:56:13 -0700 (PDT)
|
| In-Reply-To: | <CAOFvGD5grmj5Hy415HWisHKa2YKuF04Vf=JdUado48qMnzwMow@mail.gmail.com>
|
| References: | <CALT8Ef51_5-G-w6W1_1q7-XaOQU0UV1wFME9--xwVx=H3bBUjA AT mail DOT gmail DOT com>
|
| <CAOFvGD5grmj5Hy415HWisHKa2YKuF04Vf=JdUado48qMnzwMow AT mail DOT gmail DOT com>
|
| Date: | Sat, 2 May 2015 14:56:13 -0700
|
| Message-ID: | <CAOP4iL3c_sD_95+MgA+L8=e5WujSPObYtG22WcaKWFiGcOccEw@mail.gmail.com>
|
| Subject: | Re: [geda-user] Automation of non-EDA processes around gEDA
|
| From: | Ouabache Designworks <z3qmtr45 AT gmail DOT com>
|
| To: | geda-user AT delorie DOT com
|
| Reply-To: | geda-user AT delorie DOT com
|
| Errors-To: | nobody AT delorie DOT com
|
| X-Mailing-List: | geda-user AT delorie DOT com
|
| X-Unsubscribes-To: | listserv AT delorie DOT com
|
--001a113f9224b7df7705152065a4
Content-Type: text/plain; charset=UTF-8
My first question would be what does management know or thinks it knows
about about open source? You are suggesting that you will be paid to
essentially work on an open source project so they must understand that
they will not own anything that you contribute under an opensource license.
The upside for them is that they get to use and influence a tool that was
written and tested by a much larger team than just you by yourself. If
you do this as your own project then check your employment contract for any
of those "We own you and all your thoughts 24 hrs a day, 7 days a week"
clauses. Keep the root on github or sourceforge . Paranoid types would
even have an owner account that wasn't traceable back to them. Screw this
up and you could lose your job.
I am doing a project like this for Asic and Fpga design but it could and
should be extended into the PC board realm. The project is called socgen
and is available on both opencores.org and sourceforge.com.
It currently uses geda for output documentation but is modular and could be
extended.
My design philosophy is that our IC's have grown past the point where
traditional hand crafted R+D techniques can do the job in a ever shrinking
amount of time. We need to design our tools the same way that we design a
high volume production line if you want big working designs in a very
short time.
Socgen uses a IP-Xact(IEEE-1685)ish standard as its main backbone. I say
"ish" because it is a standard that should have never been released. The
committee that created it had a lot of smart people on it but they were
toolmakers,silicon vendors and IP houses. Correct me if I am wrong but I do
not think that the spirit committee had anyone on it who's day job involved
actually designing IC's. It has floundered since its release because any
real designer trying to use it quickly finds that it really can't do what
they need to accomplish. Its a shame because a lot of it is really good
with an occasional clunker thrown in to mess you up. I deviant from the
standard whenever this happens.
I use perl for all of the socgen tools. You can do system calls to anything
that executes and return data via output files. I currently do this with
icarus, verilator, covered and Xilinx ise. Perl has a large support
community and I have found CPAN to be a life saver at times.
My suggestion would not be to embed anything in a schematic since that
means you have to follow its file format rules but to come up with your own
project specific format with tools to import/export between geda. You do
your work in your project tools that are very flexible and they keep track
of all these other design objects. The key is a robust tool set that is
flexible enough for unexpected changes.
You could check out my socgen project and try it out. It supports verilog
rtl entry and can create a bitfile for a Xilinx fpga. I could use some
feedback on any system administration issues. I develop on a ubuntu 14.04
machine only.
The other thing that you could do is send me a breakdown of all the steps
that your koala tool preforms. Describe the design objects and what
happens to them. Describe your output deliverables. When a product goes
into production then what do you do with all of the design docs. How do
future engineers find stuff that you did in the past that could be reused.
You can email me direct z3qmtr45 AT gmail DOT com if you want to discuss anything
offline
John Eaton
On Fri, May 1, 2015 at 6:48 PM, Jason White <
whitewaterssoftwareinfo AT gmail DOT com> wrote:
> That is interesting,
>
> Item number 5 on the list (automaticly generate gerbers, schematic,
> bom configurations, and documentation) is of most interest to me. All
> of the component sourcing features, while necessary in every design,
> are a much more complicated to use.
>
> I look forward to seeing what some of your scripts can do.
>
> On Fri, May 1, 2015 at 8:02 PM, Shashank Chintalagiri
> <shashank DOT chintalagiri AT gmail DOT com> wrote:
> > Hello,
> >
> > I'm working on a tool (presently called Koala) which I'm hoping to use
> > to streamline the various non-EDA processes involved with maintaining
> > gEDA projects, helping with manufacturing, planning, etc. It's
> > presently just reaching some form of critical mass where I'm fairly
> > confident it'll serve the purposes I had in mind for it originally.
> > It's essentially in the form of a rickety collection of python
> > scripts. At best, some of these are at alpha quality. At worst, some
> > elements are downright ugly hacks.
> >
> > At this point in the development, I'd like to gauge the interest in
> > the community for having such a tool available. Releasing the code
> > will mean having to scrub all company specific information from the
> > core, and have ways to inject that information separately on a
> > per-instance basis. It'll also mean having to revisit the many
> > instances where I've had to diverge from gEDA standards and norms.
> > While I will probably have some convincing to do to develop a revenue
> > model to justify the time and effort of maintaining a 'public' version
> > at my workplace, I think I may be able to eventually release a
> > significant portion of the core functionality with a GPL/AGPL or
> > similar license - if there is enough interest in using it within the
> > community. I would also like to hear about the approaches typically
> > used by people to deal with the annoyances I'm trying to rid myself
> > of. Much thanks for your time.
> >
> > The following is the broad outline of the functionality and approach I
> > was looking to implement when I started working on Koala :
> >
> > * The Fundamental Information sources are various gEDA (and
> > eventually other, such as FreeCAD) projects. As far as possible, the
> > source files should follow the formats and norms we were using before,
> > i.e., standard gEDA files. Additional functionality is introduced by
> > an external scaffold erected around the standard projects. The gEDA
> > binaries are untouched.
> >
> > * The information content of the gEDA schematics I was using
> > previously was insufficient. The closest analogue to the dilemma and
> > the solution that I found to be the subjectively 'cleanest' way is a
> > wild tangent to the standard heavy-vs-light standards argument.
> >
> > * I work at a company where we build instrumentation in low volume.
> > BOMs are constantly in flux, even when the base PCB doesn't change.
> > Additionally, we have a few PCBs which can be populated in a wide
> > variety of ways by a combination of DNP/DNI and component value
> > changes. Manually maintaining these BOMs off-schematic was getting too
> > cumbersome.
> >
> > * The idea is to encode as much of this information within the
> > schematic as possible, and use this new tool to generate a variety of
> > BOMs from a single gEDA project. This has been done by adding extra
> > attributes to affected components in the gschem files.
> >
> > * The low volume production we do also means that our input costs can
> > be significantly affected by optimising upstream orders and exploting
> > cross-PCB and even cross-Product Line overlaps in BOMs to increase our
> > order quantities and reduce order cost. A way to collate various BOMs
> > together was necessary.
> >
> > * Much of this work was and is still done by hand - by myself and
> > other people at my company - resulting in significant wastage of
> > skilled resources and delays in procurement and production.
> >
> > * Koala was supposed to collapse the many steps requiring human
> > intervention in the (Schematic Capture -> BOM -> Order Planning ->
> > Order Execution -> Production Control -> Product Pricing) chain into
> > the following main steps :
> > - Encoding relevant information directly into gschem files
> > - Adding a human editable config file alongside the gEDA
> > project file which contains the appropriate rules for transforming the
> > BOM (and hopefully schematic, eventually) as per the requirements.
> >
> > * Executing the scripts koala provides are used to produce one or more
> > of the following sets of information or documentation :
> > 1. Cost of the PCB, fully soldered, for each configuration at a
> > specified volume.
> > 2. Shortages in Inventory that need to be fulfilled to complete a
> > specified production cycle.
> > 3. Select sources for each of the components necessary and
> > minimize order cost (at present supporting only the vendors we use
> > most commonly, possibly only Digikey being relevant to anyone on this
> > list)
> > 4. Estimate financial outlay for a specified production cycle.
> > 5. Generate various documentation, including schematic PDFs,
> > reference BOMs per configuration, Assembly Manifests, Purchase Orders,
> > Gerber Zips, etc.
> >
> > * The cost of using Koala, though, is that the rules for supported
> > schematic become much more rigid than gEDA standards. These
> > restrictive naming conventions can be irritating and time consuming to
> > move to. In essence, I would imagine every Koala implementation could
> > eventually have it's own naming conventions. Additional features need
> > extra attributes to be added to gEDA schematics. I've never gotten the
> > hang of hierarchial schematics, so those aren't in any way supported.
> > (Perhaps they provide this sort of functionality by themselves?).
> > SPICE and friends won't like the way names are transformed, and so at
> > present will not work. Eventually an exporter for SPICE-friendly
> > schematics could be implemented in principle.
> >
> >
> >
> >
> > --
> >
> > Chintalagiri Shashank
>
>
>
> --
> Jason White
>
--001a113f9224b7df7705152065a4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>My first question would be w=
hat does management know or thinks it knows about about open source?=C2=A0 =
You are suggesting that you will be paid to essentially work on an open sou=
rce project so they must understand that they will not own anything that yo=
u contribute under an opensource license. The upside for them is that they =
get to use and influence a tool that was written and tested by a much large=
r team than just you by yourself. =C2=A0 If you do this as your own project=
then check your employment contract for any of those "We own you and =
all your thoughts 24 hrs a day, 7 days a week" clauses. Keep the root =
on github=C2=A0 or sourceforge . Paranoid types would even have an owner ac=
count that wasn't traceable back to them.=C2=A0 Screw this up and you c=
ould lose your job.<br><br><br></div>I am doing a project like this for Asi=
c and Fpga design but it could and should be extended into the PC board rea=
lm.=C2=A0 The project is called socgen and is available on both <a href=3D"=
http://opencores.org">opencores.org</a> and <a href=3D"http://sourceforge.c=
om">sourceforge.com</a>.<br></div>It currently uses geda for output documen=
tation but is modular and could be extended.<br><br></div>My design philoso=
phy is that our IC's have grown past the point where traditional hand c=
rafted R+D techniques can do the job in a ever shrinking amount of time. We=
need to design our tools the same way that we design a high volume product=
ion line if you want=C2=A0 big working designs in a very short time.<br><br=
></div>Socgen uses a IP-Xact(IEEE-1685)ish standard as its main backbone. I=
say "ish" because it is a standard that should have never been r=
eleased. The committee that created it had a lot of smart people on it but =
they were toolmakers,silicon vendors and IP houses. Correct me if I am wron=
g but I do not think that the spirit committee had anyone on it who's d=
ay job involved actually designing IC's. It has floundered since its re=
lease because any real designer trying to use it quickly finds that it real=
ly can't do what they need to accomplish. Its a shame because a lot of =
it is really good with an occasional clunker thrown in to mess you up. I de=
viant from the standard whenever this happens.<br><br></div>I use perl for =
all of the socgen tools. You can do system calls to anything that executes =
and return data via output files. I currently do this with icarus, verilato=
r, covered and Xilinx ise.=C2=A0 Perl has a large support community and I h=
ave found CPAN to be a life saver at times.<br><br></div>My suggestion woul=
d not be to embed anything=C2=A0 in a schematic since that means you have t=
o follow its file format rules but to come up with your own project specifi=
c format with tools to import/export between geda. You do your work in your=
project tools that are very flexible and they keep track of all these othe=
r design objects. The key is a robust tool set that is flexible enough for =
unexpected changes.<br><div><div><br></div><div>=C2=A0You could check out m=
y socgen project and try it out. It supports verilog rtl entry and can crea=
te a bitfile for a Xilinx fpga.=C2=A0 I could use some feedback on any syst=
em administration issues. I develop on a ubuntu 14.04 machine only.<br><br>=
<br></div><div>The other thing that you could do is send me a breakdown of =
all the steps that your koala tool preforms.=C2=A0 Describe the design obje=
cts and what happens to them. Describe your output deliverables.=C2=A0 When=
a product goes into production then what do you do with all of the design =
docs. How do future engineers find stuff that you did in the past that coul=
d be reused.<br><br></div><div>You can email me direct <a href=3D"mailto:z3=
qmtr45 AT gmail DOT com">z3qmtr45 AT gmail DOT com</a> if you want to discuss anything of=
fline<br><br><br></div><div>John Eaton<br><br><br></div><div><div><br><br><=
br><br><br><div><div><div><br><br><br><br><br></div></div></div></div></div=
></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, May 1, 2015 at 6:48 PM, Jason White <span dir=3D"ltr"><<a href=3D"ma=
ilto:whitewaterssoftwareinfo AT gmail DOT com" target=3D"_blank">whitewaterssoftwa=
reinfo AT gmail DOT com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Th=
at is interesting,<br>
<br>
Item number 5 on the list (automaticly generate gerbers, schematic,<br>
bom configurations, and documentation) is of most interest to me. All<br>
of the component sourcing features, while necessary in every design,<br>
are a much more complicated to use.<br>
<br>
I look forward to seeing what some of your scripts can do.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Fri, May 1, 2015 at 8:02 PM, Shashank Chintalagiri<br>
<<a href=3D"mailto:shashank DOT chintalagiri AT gmail DOT com">shashank.chintalagir=
i AT gmail DOT com</a>> wrote:<br>
> Hello,<br>
><br>
> I'm working on a tool (presently called Koala) which I'm hopin=
g to use<br>
> to streamline the various non-EDA processes involved with maintaining<=
br>
> gEDA projects, helping with manufacturing, planning, etc. It's<br>
> presently just reaching some form of critical mass where I'm fairl=
y<br>
> confident it'll serve the purposes I had in mind for it originally=
.<br>
> It's essentially in the form of a rickety collection of python<br>
> scripts. At best, some of these are at alpha quality. At worst, some<b=
r>
> elements are downright ugly hacks.<br>
><br>
> At this point in the development, I'd like to gauge the interest i=
n<br>
> the community for having such a tool available. Releasing the code<br>
> will mean having to scrub all company specific information from the<br=
>
> core, and have ways to inject that information separately on a<br>
> per-instance basis. It'll also mean having to revisit the many<br>
> instances where I've had to diverge from gEDA standards and norms.=
<br>
> While I will probably have some convincing to do to develop a revenue<=
br>
> model to justify the time and effort of maintaining a 'public'=
version<br>
> at my workplace, I think I may be able to eventually release a<br>
> significant portion of the core functionality with a GPL/AGPL or<br>
> similar license - if there is enough interest in using it within the<b=
r>
> community. I would also like to hear about the approaches typically<br=
>
> used by people to deal with the annoyances I'm trying to rid mysel=
f<br>
> of. Much thanks for your time.<br>
><br>
> The following is the broad outline of the functionality and approach I=
<br>
> was looking to implement when I started working on Koala :<br>
><br>
>=C2=A0 * The Fundamental Information sources are various gEDA (and<br>
> eventually other, such as FreeCAD) projects. As far as possible, the<b=
r>
> source files should follow the formats and norms we were using before,=
<br>
> i.e., standard gEDA files. Additional functionality is introduced by<b=
r>
> an external scaffold erected around the standard projects. The gEDA<br=
>
> binaries are untouched.<br>
><br>
>=C2=A0 * The information content of the gEDA schematics I was using<br>
> previously was insufficient. The closest analogue to the dilemma and<b=
r>
> the solution that I found to be the subjectively 'cleanest' wa=
y is a<br>
> wild tangent to the standard heavy-vs-light standards argument.<br>
><br>
>=C2=A0 * I work at a company where we build instrumentation in low volu=
me.<br>
> BOMs are constantly in flux, even when the base PCB doesn't change=
.<br>
> Additionally, we have a few PCBs which can be populated in a wide<br>
> variety of ways by a combination of DNP/DNI and component value<br>
> changes. Manually maintaining these BOMs off-schematic was getting too=
<br>
> cumbersome.<br>
><br>
>=C2=A0 * The idea is to encode as much of this information within the<b=
r>
> schematic as possible, and use this new tool to generate a variety of<=
br>
> BOMs from a single gEDA project. This has been done by adding extra<br=
>
> attributes to affected components in the gschem files.<br>
><br>
>=C2=A0 * The low volume production we do also means that our input cost=
s can<br>
> be significantly affected by optimising upstream orders and exploting<=
br>
> cross-PCB and even cross-Product Line overlaps in BOMs to increase our=
<br>
> order quantities and reduce order cost. A way to collate various BOMs<=
br>
> together was necessary.<br>
><br>
>=C2=A0 * Much of this work was and is still done by hand - by myself an=
d<br>
> other people at my company - resulting in significant wastage of<br>
> skilled resources and delays in procurement and production.<br>
><br>
>=C2=A0 * Koala was supposed to collapse the many steps requiring human<=
br>
> intervention in the (Schematic Capture -> BOM -> Order Planning =
-><br>
> Order Execution -> Production Control -> Product Pricing) chain =
into<br>
> the following main steps :<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Encoding relevant information directly in=
to gschem files<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Adding a human editable config file along=
side the gEDA<br>
> project file which contains the appropriate rules for transforming the=
<br>
> BOM (and hopefully schematic, eventually) as per the requirements.<br>
><br>
> * Executing the scripts koala provides are used to produce one or more=
<br>
> of the following sets of information or documentation :<br>
>=C2=A0 =C2=A0 =C2=A0 1. Cost of the PCB, fully soldered, for each confi=
guration at a<br>
> specified volume.<br>
>=C2=A0 =C2=A0 =C2=A0 2. Shortages in Inventory that need to be fulfille=
d to complete a<br>
> specified production cycle.<br>
>=C2=A0 =C2=A0 =C2=A0 3. Select sources for each of the components neces=
sary and<br>
> minimize order cost (at present supporting only the vendors we use<br>
> most commonly, possibly only Digikey being relevant to anyone on this<=
br>
> list)<br>
>=C2=A0 =C2=A0 =C2=A0 4. Estimate financial outlay for a specified produ=
ction cycle.<br>
>=C2=A0 =C2=A0 =C2=A0 5. Generate various documentation, including schem=
atic PDFs,<br>
> reference BOMs per configuration, Assembly Manifests, Purchase Orders,=
<br>
> Gerber Zips, etc.<br>
><br>
> * The cost of using Koala, though, is that the rules for supported<br>
> schematic become much more rigid than gEDA standards. These<br>
> restrictive naming conventions can be irritating and time consuming to=
<br>
> move to. In essence, I would imagine every Koala implementation could<=
br>
> eventually have it's own naming conventions. Additional features n=
eed<br>
> extra attributes to be added to gEDA schematics. I've never gotten=
the<br>
> hang of hierarchial schematics, so those aren't in any way support=
ed.<br>
> (Perhaps they provide this sort of functionality by themselves?).<br>
> SPICE and friends won't like the way names are transformed, and so=
at<br>
> present will not work. Eventually an exporter for SPICE-friendly<br>
> schematics could be implemented in principle.<br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Chintalagiri Shashank<br>
<br>
<br>
<br>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Jason White<br>
</font></span></blockquote></div><br></div>
--001a113f9224b7df7705152065a4--
- Raw text -