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
