Hi Peter, On Date:Fri, 2 Jan 2009 12:48 pm, Peter Clinton wrote: [snip] .. disallowing net->bus pinconnections etc..
Normally, I would not voice any concern, but the above causes me to inform you of the consequences of doing what you suggested. The Gschem code can treat BUS exactly the same as net execpt for its visual effect. Bus bin of a symbol is just a thick line laying on top of part of the non-red portion of a pin. The user can just put it there for visual effect. The bus-tap acts as a no-connect (as currently implemented), so to make sure that the BUS trunk's net name is separated from other bus/net net names tapping the trunk. The bus trunk/s net names are just a place holder for net names processing, just as what is already done in "gnet-verilog.scm". How net names and pins are treated, IMHO should be upto the backend Scheme code, so that any backends can be supported including Verilog-AMS, SystemC, CASE tools, etc, thru attribute processing. Many advance schematic tools use the same symbol for bus/non-bus application in parameterized attribute form, current Gschem Gnetlist can already do them too. Best Regards, Paul Tan -----Original Message----- From: Peter Clifton <[email protected]> To: gEDA user mailing list <[email protected]> Sent: Fri, 2 Jan 2009 8:25 pm Subject: Re: gEDA-user: Is gnetman available for download anywhere? 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. 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. If you have any technical comments, lets take them on geda-dev. That is not an invitation to nit-pick every design decision made by me or any other of the gEDA developers. Might I suggest that checking out git HEAD and giving it a try should alleviate any fears. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
