RE: gEDA: design decisions: PCB<->schematic (long)

["Keith Outwater" <Keith_Outwater-at-NOSPAMmvis_dot_com>]

Hi Andras - 
First let me say that Lasagne looks really neat! The 3-d view appears to be a novel approach to viewing layers.  Wouldn't surprise me if a commercial PCB package picked up on that concept.

Regarding PCB and schematic tool communication:

First a little about my background:
I'm a digital electronics designer who spent over 15 years working with high-end EDA tools, primarily from mentor Graphics.  I used Mentor's Design Architect (schematic capture) and Boardstation (PCB) in large projects involving up to 30 design engineers.  Designers worked concurrently on schematics and PCB layout was also performed concurrently.  My designs ranged from simple to complex.  One design used a hierarchical schematic that flatted to 133 pages.  The PCB was a 12Ux400mm eurocard with 8200 component instances, 15000 nets, 30000 pins and 29000 vias.

Now I'm at a company that uses point tools to do PCBs.  We use a schematic editor (orcad) to do schematics and a separate tool to do PCB layout.  The tools communicate via netlist and a back annotation file ant the end of the design cycle.  I dislike this flow intensely and I'm serious looking a gschem (and maybe Lasagne!) s an alternative.

I mention all of this since it affects my perception of what a schematic capture and PCB layout tools should do.  Of course if all you want to do are small simple boards then none of the points below will be too relevant.

Here are some points in no particular order. I apologize in advance if I seem to ramble a bit!

1. My first suggestion for your PCB tool is __solve the general case__  By that I mean don't place arbitrary limits on things like the number of layers.  By all means allow extensions to the tool via scripting.  By all means DO NOT enforce a particular design paradigm on the user.  An example of what no to do (for a schematic editor at least) is the orcad capture tool.  Please support strokes!

2. Yes, I have successfully made use of two-way communication between schematic and layout. This was supported by the Mentor toolset and was essential for rapidly and efficiently laying out complex boards that worked correctly the first time.  The Mentor tools do this by using a unified design database in which schematic data and layout data reside in the same database.  Designs look like objects and object data is manipulated by various tools.  Personally, I regard any toolset which does not support this as crippled. Think of it this way:  a schematic should describe electrical connectivity between LOGICAL symbols.  In PCB layout, logical symbols are mapped to PHYSICAL packages.  So, for example, when drawing a schematic you generally don't care about what particular reference designators are used on symbols as long as they are unique.  In the PCB layout you might want to have the reference designators numbered in an X-Y fashion when you have finished placement and routing so you can rapidly identify components when debugging the board.  The best place to change the reference designators is in PCB layout, not the schematic because PCB layout is where working with ref des data is most useful and efficient.  Annotation capability between tools (forward and backward) makes this scheme possible.  This can be generalized to ANY property, not just reference designator.  For example component orientation, placement on top or bottom side, component height, etc...

Here's an example:
Suppose I am designing a high speed board in which signal rise and fall time are so fast that many traces will act as transmission lines.  Furthermore, suppose the combination of rise/fall times and clock frequencies require that traces have identical routed lengths in order for the design to function.  
The electrical constraints on signals would be specified on the schematic using properties (i.e. matched_length_group=mlg1 on nets in a particular matched length group) and then passed the PCB tool where physical constraints could be added.  For example you could set the allowable length mismatch on matched length groups or constrain nets with certain properties (i.e. netclass=critical) to only route on certain layers.  That's the forward annotation aspect of things.  What you'd also like to be able to do is assign these types of properties in the PCB layout tool and then be able to back annotate them to the schematic.  That allows you to modify constraints in either tool as appropriate and synchronize the changes.

3. I think that your tool should support forward and back annotation and could do so relatively easily.  You could define a format for annotations and then if the user pushes the "generate back annotation button" just dump every property (property name and new value) that the user has edited.  Forward annotations would simply override properties in the PCB design.  Use a scalable, flexible file format for annotations so users can work with the data easily.
What is so useful about that?  Here's an example that ties in with your desire to handle large BGAs:

Xilinx makes FPGA devices that come in large packages (for example an 1152 pin BGA).  During FPGA design, I/O pin assignments must be made.  For an FPGA, optimal I/O pin assignments are a function of internal FPGA routing considerations and package-level (i.e. PCB) routing considerations.  For a high pin count device, it is difficult to manually assign I/O pins to the FPGA before board layout and get something that is anywhere close to optimal.  Yes you can floor plan your board and FPGA (been there, done that) but this is a manual process that takes the same amount of effort on every iteration.  The large effort required virtually guarantees that iterations == 1.  EDA tools can help.  Here's a flow I've used with great success (using Mentor tools).

  a. FPGA designer constrains critical pins (clocks, etc...) and then allows FPGA place and route tool to pick I/O pins without regard to PCB layout.
  b. A script parses the FPGA router output to allow schematic tool to automatically assign nets to pins on the FPGA schematic symbol via scripting.
  c. Schematic data is passed to PCB layout tool where FPGA pins are marked "swappable" and FPGA pins are swapped by the PCB designer as necessary to achieve good routing.
  d. "was-is" file or other suitable back annotation file) is generated by PCB tool and used by script to modify FPGA place and route tool I/O pin assignment file.
  e. FPGA designer re-routes FPGA with new I/O pin assignments to verify that an FPGA route that meets performance requirements is achievable.  
  f. Step "b" above is performed to update schematic.
  g. Schematic data is passed to PCB layout tool to verify that everything is consistent (the loop is closed at this point).

The steps above can be performed very quickly with little human intervention and used to achieve very high quality results but the technique requires core capabilities like scripting and annotation in the tools.

OK, that's probably enough to get the discussion really cooking.
I would summarize by saying:
1. Solve the general case problem - avoid special cases.
2. Strive for scalability and configurability.
3. Allow users to adapt the tool to their work flow and requirements NOT the other way around.


> Hi, 
> 
> I have thought out some of the details of the upcoming rewrite of
> Lasagne, and this time, I am going to try not just to make a good tool
> for myself, but a really good PCB design program. The one thing I have
> not been able to work out yet is how strongly the schematic editor
> (gschem I suppose) and the PCB editor should be tied together. In many
> commercial packages they are basically part of one big program --
> Eagle has this "forward-backward annotation", for example.
> 
> Now the question: has anyone ever successfully made use of two-way
> communication between the layout editor and the schematic editor? Does
> it really make sense to make changes to the schematic diagram when
> someone rearranges connections on the PCB?
> 
> Doing one-way communication is rather easy to implement, I think I
> have a good plan for that, but I'm quite sure the other way
> (PCB->schematic) would be very hard to add. Is there any need for it
> at all?
> 
> I'm the last person to know the answer, having built all my projects
> so far on the PCB directly without any schematic diagram.
>