On Saturday 03 January 2009 04:25:03 Peter Clifton wrote: > On Fri, 2009-01-02 at 22:17 -0500, Paul Tan wrote: > > Hi, > > > > Virtuoso implemented that which ease them in > > dealing with parameterized BUSS net/pin, easier to > > deal with situation interfacing to many backend > > tools, some of which even need varialbe pin such as > > BUSA[0:N] (n=0) which connects to a single wire net. > > > > The current gnetlist already allows all sort of > > flexibilities to deal with similar situations. > > My hope is that this flexibility should not > > be reduced or restricted without Ales approval > > and other developers concensus. > > Paul, > > gschem supports a bus primitive already, has done for ages, but it is > graphical only. Steve was asking for a way to hook those up to a pin > with pin_type == PIN_TYPE_BUS (which gEDA already supported, just did > nothing with). > > This is what I've implemented.. an ability to set that type code, to > render pins of that type as appropriate and some logic to check what > objects should be depicted as connected. This doesn't break, or > otherwise affect the verilog backend. In the future it may be possible > to use gschem's buses and bus pins more explicitly for that though.
IMHO, having visual distinction between bus connections and wire connections
on printed schematics is invaluable. Having a GUI that understands that wires
and buses have to be handled slightly differently is likewise very useful. A
sensible way to do this is to make them separate schematic object types. In
the future it is likely that gnetlist will be taught to create a "buslist" of
bus connections as well as net connections, and backends will be taught to use
it. Until that time, gnetlist and gnetlist backends will do as they've always
done: ignore buses completely.
[ Peter: we could consider letting the backends define a function which takes
a bus object and returns a list of netnames encapsulated by the bus? ]
If in the future you have any concerns about whether gnetlist behaviour has
changed, I recommend running the test suite which is *designed to* detect
changes in behaviour. All of the developers, including Peter Clifton and I,
work hard to ensure that gnetlist's behaviour changes only when absolutely
necessary, and that such changes are communicated to the user base.
> I share your great respect for Ales and the other developers, but I'm
> getting fed up with you resisting change for no good reason, and your
> continual suggestions that every decision taken by the developers should
> go through an approval process.
I'm afraid that I'm starting to get fed up with it too.
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
