Paul, I am doing much more then just flat net listing hierarchical designs.
I don't the time or energy to get into every thin that I am up to. I still don't find the stock libgeda, gnetlist and backends capable of all my interests. Steve Meier On Sat, 2009-01-03 at 10:57 -0500, Paul Tan wrote: > Hi Peter Clinton, > > Thank you very much for you response, I really > appreciate it. > > I am a bit confused, after reading about Steve > Meier's "hierarchical bus". > > Peter Clinton wrote, On Sat, 03 Jan 2009 12:22:27 +0000 > >Since gnetlist doesn't understand buses or bus pins, > >you will have to continue using it this way. Steve Meier > >has a customised netlister which_does_ allow interconnection > >between hierarchical blocks using native bus objects > >and bus pins, and that is why I added support in gschem. > >(Because he asked nicely). > > Many months ago, after some technical discussion > with Steve Meirer thru private emails exchange > (we had to discussed those off the forum, because > Ales would like us to take it offline), I understood > what Steve Meier's "hierarchical bus" was meant > for flat-hierarchy netlist such as PAD/PCB format > only. > > Steve Meier, please correct me if I am wrong: > Is the "hierarchical bus" you asked Peter Clinton > to implement is for flat-hierachy netlister > format such as PADs/PCB ? > > I bring this up because flat-hiearchy netlists > are different than non-flat herarchy netlists. > Mike Jarabak already implemented the non-flat > hiearchy verilog netlist with BUS for 1 hiearchy level. > The stocked "gnet_hier_verilog.sh" added the > support for multi-level deep hierachy (with > limitation of 1 page per hierachy). > > Currently, I already modified the > "gnet_hier_verilog.sh" to support multi-page > multi_level full hiearchy with BUS, using > existing Gschem/gnetlist, Mike's gnet-verilog.scm. > I can release it once I make a good example > test case for you to run. > > Well, I hope Steve is reading this and can > clarify this. > > Thanks again. > > Best Regards, > Paul Tan > > > -----Original Message----- > From: Peter Clifton <pc...@cam.ac.uk> > To: gEDA developer mailing list <geda-dev@moria.seul.org> > Sent: Sat, 3 Jan 2009 4:22 am > Subject: Re: gEDA-dev: gEDA-user: Is gnetman available for download > anywhere? > > > > On Sat, 2009-01-03 at 00:15 -0500, Paul Tan wrote: > > 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. > > Ok, nothing has changed in the legality of connecting objects which > gschem / gnetlist already understood. Perhaps I wasn't clear when I > suggested some change in the logic: > > To summarise the old logic: > > Net-Net connections OK > Net-Pin connections OK (but we only supported NET pins) > Bus-Pin connections NOT OK (but we only supported NET pins) > Pin-Pin connections OK (indiscriminate of type, but we only supported > NET pins) > Bus-Bus connections OK (although we didn't do anything with them) > Bus-Net end-point connections not OK > Bus-Net mid-point connections not OK > Net-Bus mid-point connections OK (and usually replaced with bus-rippers) > > Changed behaviour: > > Allow - Bus-BusPin connections > Disallow - NetPin-BusPin connections > > (This is "allow" as in, the objects are registered as connected > internally, and the red cue goes away). > > If you still think there would be any negative comments from the new > behaviours, please let me know. > > I'll just quote the commit messages: > > commit f37c893edfeb016e57aae5e92f48093608e5cdfb > Author: Peter Clifton <pc...@cam.ac.uk> > Date: Sat Jan 3 02:38:29 2009 +0000 > > gschem: Add interface to toggle a pin between net pin and bus pin > types. > > This allows schematic diagrams of hierarchical connections to > include > buses. Since gnetlist does not currently support buses, this > feature is > useful only for diagrams, or when used with a custom netlister. > > Since we don't want to mislead users into thinking bus pins netlist, > the option to set pin type is only present on the page's popup menu, > and is marked "(graphical)". > > > commit 7d01d4ae87fd329ffa3e93df9e286dd6e56e225c > Author: Peter Clifton <pc...@cam.ac.uk> > Date: Fri Jan 2 23:14:53 2009 +0000 > > libgeda: Fix bus/net to bus/net pin connectivity checking rules > > Previously, the type of pin was not checked when computing > connections, > and buses were disallowed from connecting to any type of pin. > > Refactor s_conn_update_line_object() to concicely check the > following: > > Allow connections between matching pin types only. > Allow connections between nets, other nets and net pins. > Allow connections between nets and the mid-points of a bus. > Allow connections between buses, other buses and bus pins. > > > commit 998e8546754fe2ab41a57ce112c3966190c501df > Author: Peter Clifton <pc...@cam.ac.uk> > Date: Fri Jan 2 23:14:52 2009 +0000 > > gschem: Add support for rendering and adding pins with type > PIN_TYPE_BUS > > Bus pins are rendered thicker, and with a bigger cue than standard > pins > of PIN_TYPE_NET. > > This commit also fixes a bug where the wrong sized cue circle was > drawn > for net-net interconnections. > > > > The Gschem code can treat BUS exactly the > > same as net execpt for its visual effect. > > Can, but doesn't. In the code-base as is, OBJ_BUS is a separate object > type. > > > 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. > > gEDA has (since I don't know when) defined in its file format > specification that a pin object has type "PIN_TYPE_NET" or > "PIN_TYPE_BUS". Its just that we never used the latter before. > > It now supports setting the bus pin type, and rendering it thicker - > without any hacks to overlay a thicker line. > > > 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". > > None of this has changed. > > Since gnetlist doesn't understand buses or bus pins, you will have to > continue using it this way. Steve Meier has a customised netlister which > _does_ allow interconnection between hierarchical blocks using native > bus objects and bus pins, and that is why I added support in gschem. > (Because he asked nicely). > > For complex designs, it is useful to be able to connect hierarchy blocks > via non-graphical buses, and as Peter B suggests, we'll be looking at > teaching gnetlist to expose the wiring of bus objects to the gnetlist > backends in a similar way to how we expose net wiring as a netlist. > > > 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. > > I agree with you that the interpretation of those, and their underlying > type needs to end up in the netlist back-ends. If the existing back-ends > wish to continue allowing buses to be inferred from nets, that is fine. > > Perhaps what wasn't immediately clear, was that we have no plans to > remove, or change the behaviour of bus rippers and the existing > graphical only interpretation of buses in gEDA. > > To be honest, I can't think of any instances in gEDA where we've broken > a behaviour or feature, and we're not about to start now. > > If you suspect that gnetlist's test-suite isn't exercising a particular > feature (e.g. verilog buses), please contribute a test-case we can add > to the regression test suite. We take changes in that output very > seriously. > > PS.. Amusing slightly unrelated story: > > gnetlist code unfortunately misuses GLib hash tables to produce a unique > list of components. I say mis-uses, because out output depends on the > sequence that we enumerate all items in the hash table (which isn't > guaranteed), and we don't apply any sorting for ourselves. > > In the latest version of GLib, they changed the hash table > implementation to a faster one, and the enumeration ordering behaviour > changed. (Perfectly legitimate). Almost all our test-suite fails. > > Before the next release, we need to change to our own implementation, or > apply a sort to the results of the hash table step. Since we may not be > able to easily reproduce the sorting behaviour of the old hash-table > implementation, we may now have to add an arbitrary sort order, then > pour over many thousand lines of diff in the test-suite output, checking > the output re-ordering is acceptable. > > Not fun, but yes.. we take test-suite failures seriously. > > Best wishes, > > -- > 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-dev mailing list > geda-dev@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > > > > _______________________________________________ > geda-dev mailing list > geda-dev@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
