Mail Archives: geda-user/2015/05/02/18:37:27
I'm not likely to lose my job over this, and my employers haven't been
and aren't going to be paying me for doing this. We're a small shop
filled with type A personalities who are all highly opinionated. This
is essentially a side-project I've been working on - mostly because
without it, I end up wasting my doing things that are painfully
tedious. The rationale that over time, the time I save by using this
will compensate for the time spent setting it up is something that I
can justify without any trouble. The bottom line for this decision is
that the consequences of releasing it more publicly - and committing
to maintaining it personally - is a considerably bigger commitment for
me given the time I have available. I can deal with rickety scripts
for most of what I need to do. But if it has to be generally usable,
the requirements on code quality and documentation begin to shoot up,
so I'm in two minds.
I've not yet had the time or the resources to try out anything with
FPGAs and ASICs, so I don't know if socgen is something I will be able
to understand. I will take a look over the week though.
Encoding information in the schematic is a conscious design decision
on my part. That way, I only have to maintain the schematic and a
limited set of files around this. This reduces the cascading effect
that making a small change in an old design typically has. I see your
point about being completely independent of the EDA suite used. I did
start off by trying to contain gEDA specific code to a specific python
module, leaving the possibility of reimplementing it to interact with
other EDA suites open. Admittedly, it isn't something I've done
religiously, but I think it should be mostly isolated. My gedaif
folder currently has about 10% of the total LOC.
I should perhaps clarify, though. I'm a person who's worked with both
gEDA and Eagle on 4 layer boards who has never even tried out an
autorouter on either. The goal was originally to streamline
engineering communications with other 'groups' - marketing, inventory,
support, etc, and to keep it out of the way of the engineering folk
doing their things. I did look at some project-like tools over the
years, but nothing really fit the workflow that we were used to. This
happened in almost every context I was working in - The tools define
the workflow instead of the workflow defining the tools. I admit that
I'm at risk of doing exactly the same thing for people who are not me
- workflows being relatively subjective and such - but my intent was
to stay out of it entirely, and create a core framework that defines
how information is encoded, not how the information is generated or
what happens to it eventually.
I will try to spend some time over the next week or two and write up
some of the documentation. I'll also create some small gEDA project
which demonstrates the essential capabilities of the scripts.
Shashank
On Sun, May 3, 2015 at 3:26 AM, Ouabache Designworks <z3qmtr45 AT gmail DOT com> wrote:
> 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
>
>
--
Chintalagiri Shashank
Indian Institute of Technology, Kanpur
http://blog.chintal.in
- Raw text -