[Xcircuit-dev] xcircuit, PCB, and hierarchy

[R. Timothy Edwards]

Dear Eric,

> I do agree that hierarchical
> PCB layout processes are important, from the standpoint of simplicity.
> But, on the other hand, hierarchical layout is often avoided unless it
> is imposed by machine constraints.

   XCircuit has no problem flattening designs;  it's really an issue of
naming conventions.  What xcircuit ends up with (and "magic", and other
hierarchically-based layout tools) is a flat representation with
hierarchical names such as rectifier1/diode3.1 and so forth.  To give
that diode a unique name from the top level, so that the diode is just
"D7", say, is a great idea, but xcircuit can't handle passing parameters
through several levels of hierarchy.  I come back to this issue every
now and then, as it is an extraordinarily useful concept that is
extraordinarily difficult to implement.

   On top of that, the tutorials, and probably the xcircuit interface
overall, have a clear VLSI bias, because that's what I do.  Occasionally
I build PCBs but I have yet to get into the habit of doing LVS on them.
Usually, that's not especially useful, as most of my errors stem from
misreading datasheets, where LVS won't do any good anyway.  It's only
when you get into 4+ layers on a PCB, or when you get into big
production runs, that you get into situations where it becomes
prohibitively expensive to fix errors on the board.

> I redid the tutorial without the hierarchical
> grouping, and it worked just fine.

The reason I haven't worked too much on the hierarchy-to-PCB concept
is that it works just fine if you start with a flat design in
xcircuit.  I should probably separate out the VLSI and PCB parts of
the tutorial so that I can properly stress the use of hierarchy for
VLSI but de-stress it for PCB layout.

> Probably, pcb's are not all that hierarchical because if they were,
> it might be less expensive to do the arrays in VLSI, gals or FPGA's.
> If digital logic is used, it might just be easier to use one of
> Lattices new ISP's.  They even have a downloadable tool chain.

Funny you should mention that.  My "counterexample", the 34-channel
biosonar frontend board, has more Lattice ISP chips on it than
probably any other board ever built (104, to be exact. . . these are
the ispPAC programmable analog chips, which is why there are so many
of them).  I made a subcell of 3 ispPAC chips, capacitors, and wiring,
and copied it 34 times.  In PCB, I had to be absolutely sure that
subcell was correct before copying it, because further changes would
have to be done to each part individually instead of once, to the
subcell.

Lattice's downloadable tool chain has been an annoyance from the start.
For the analog chips, I wrote my own software so I could program all
102 chips at once, feeding them high-level parameters such as filter
frequency and Q.  I used one of their digital chips, the 6192FF, as an
interface chip, but I can only compile the schematic on their Windows-
only tool.  I do the schematics in Windows, too.  It nearly drove me
to write an EDIF output style for xcircuit, but I just didn't have
the time.

Generally speaking, though, most people use FPGAs to implement great
gobs of logic like state machines and glue logic, which isn't
hierarchical at all.  The benefit of the FPGA is that 1) you can fix
it if it's wrong, and 2) you know all the timing delays for simulation
without having to lay out the board.

> Somehow, it seems that there should be a way to insure that the
> parts correspond between the two tools.

My feeling is that the problem lies in the LVS tools.  It should not
be necessary to ensure a perfect correspondence between part numbers;
if two parts are 74HCT244s, then it should not make a difference that
the one on the PCB is labeled #1 and the one on the schematic is
labeled #2.  Or for that matter, that the one on the schematic has
a hierarchical name and the one on the PCB has a flat name.  From
this standpoint, I'd like to get into "pcb" sometime and fix the
way it handles netlists.

I've also been thinking about writing an inherently hierarchical
LVS tool.  For highly arrayed designs, it would be orders of magnitude
faster, take less memory, and produce more meaningful results.  Just
another thing I'll get around to if I have the time.

						Regards,
						Tim

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Xcircuit-dev mailing list
Xcircuit-dev at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcircuit-dev