[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: gEDA-dev: some suggestions



Adding in a comment to Stuart's and Peter's buss discussion and the auto
routing thread from earlier in the week...



Isn't fully functional bus support in gEDA/gschem a true requirement for the
next generation of auto router in PCB?  If not, you would need to bundle
your data lines together in PCB before routing (in order to implement a
serpentine feature to ensure identical trace lengths -OR- if to ensure good
placement if you were running signal sized ground traces between signal
lines).  

Also towards the same future auto routing goal would be the ability to
support decoupling capacitor protection, so that the trace running between a
capacitor and a chip's power pin would not be used as a connection point to
feed other components on that net.



These are currently beyond my ability to implement, but I am trying to
figure out what preparation needs to be done in gEDA to support a good auto
router.  


Andrew Miner




/*

-----Original Message-----
>> Better to add hierarchy to gschem and gnetlist, IMO!
>
> I'm currently using heirachy in gschem and gnetlist in the design of a 
> rather complex circuit board... so I'd describe that as a fait accompli.
>
> Unless you meant something different, of course.

I'll bet you don't use any busses, and your netnames are all global.

Hierarchical busses remain a problem for gEDA.  That is, I can't just
connect a bus called foo[7:0] to a pin on a block, and have all the nets in
foo[7:0] show up at the lower level.  Pins are strictly single-net
constructions as gEDA currently stands.

As for other types of hierarchy, a big problem arises if you have one
top-level block, and in it you want to instantiate multiple identical copies
of a lower-level block.  This is common in IC design, but I have also done
such a thing in a 4 port IO PCB I did once.  Each lower-level block is
identical, but must have different refdeses and different netnames on the
lower level so that the different nets aren't all shorted out in the
resulting netlist.  Acceptable netnames can be of the type
foo1_upper:bar_lower, foo2_upper:bar_lower, etc.
Acceptable refdeses might be U1:U5, U2:U5 and so on [1].  Doing this is a
problem for both gschem and for gnetlist.

Unless things have changed in the last few months, gEDA can't handle these
issues.  If I'm wrong, please tell me!

Stuart


[1]  Then these refdeses are changed at layout time to something more
sensible like U5, U6, etc, and backannoed into the schematic.
(Good -- actually any -- backanno is the other important missing piece in
gEDA.)  Doing this in a hierarchical design in not trivial, and is prone to
error. ViewLogic does something they call OATS, which is some scheme to
overwrite lower-level refdeses from the top level.  It always broke for me,
but I probably didn't understand it.

*/



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev