Hi Steve,
I remember we had the conversation about this before,
e.g., bus = address[0-23],data[0-16],r/wn.
And I hope you remember the part that I suggested
to you that all these can already be implemented
with the existing gnetlist C/SCM support, without
changing any C/SCM code. And thay you can study
the gnet-verilog.scm as an example of how-to.
All you need to do is to implement them in your
gnet-xxx.scm.
If people want the "visual bus" look, just add
the "visual" code to make "visual BUS" to behave
the same as the net. The same behavior applies,
netname to pinnumber mapping info is already
provided by the gnetlist C/SCM to any gnet-xxx.scm,
how the mapping is interpreted should be upto
the specific backends.
IF you want netname=abc,abus{0:21} map to
pinnumber=[1,5,2,4 ...], its all upto you. You can
easily implement them in your gnet-xxx.scm. If
foo wants netname=abus<n+1,0,abc> maps to
pinnumber=<foo_kitchen_sink_pin_list>, foo
can do them too in gnet-foo.scm.
Is it necessary that Gschem and/or Gnetlist
C/SCM has to changed to accomodates your way
of implementation? (except the visual BUS part)
Do you really want to impose your specific mapping
to every backends? Isn't it better to let the
backend gnet-xxx.scm to handle them application
specifically?
Best Regards,
Paul Tan
-----Original Message-----
From: Steve Meier <[email protected]>
To: gEDA developer mailing list <[email protected]>
Sent: Thu, 8 Jan 2009 6:46 pm
Subject: Re: gEDA-dev: Google Summer of Code 2009
I was keeping quiet on this subject as I am in the process of writing an
explanation of how gnetlist & libgeda and libakeda & mra_netlist
generate netlists. But, now I will say a couple of things.
1) I use a lot more complex of a bus structure
bus=add[0-23],data[0-16],r/wn
2) I am able to re-netname (this is a new verb) a bus at a bus to
symbol interface or a bus to bus ripper interface (my bus rippers can be
either bus to net or bus to bus) as long as I keep the same names. This
means that by symbols don't have to be forced to a standard.
bus=add[0-23],data[0-16],r/wn
is the same as
bus = address[0-23],data[0-16],r/wn
3) I am able at a bus ripper to split off or join a sub bus
big bus
bus=add[0-23],data[0-16],r/wn
sub bus
bus=data[0-8]
4) For hierarchy the bus name closest to the root of the tree dominates
the name.
so:
bus=main_bus_addr[0-23],main_bus_data[0-16],main_bus_r/wn
if it is closer to the top level wins over if the above is closer then
the bellow which has the hierarchically corrected net names.
bus=s10/add[0-23],s10/data[0-16],s10/r/wn
5) all these convolutions of bus structures can happen at every
hierarchical branch. so that a bus can be limited to only a portion of
the design or can start deep in one branch and traverse all20the way to
the top level and then go deep down another branch. In doing so two
buses that aren't connected but have the same net names should not be
reconnected during netlisting
Peter, sorry for my slowness to provide you the examples I promise to
get them out to you shorty. They actually belong in my how to use my
netlister document.
Steve Meier
On Fri, 2009-01-09 at 01:55 +0000, Peter Clifton wrote:
> On Thu, 2009-01-08 at 10:52 -0500, DJ Delorie wrote:
> > > Anybody else!?!?
> >
> > I'm willing, but I've already got the LF work to do. My pet
projects
> > for GSoC'09:
> >
> > * "bus nets" in gaf - the ability to use pin numbers like
> > "[1-4,6,8,10-15]" and net names like "D[0-15]" and have them
> > demultiplex into individual signals when you run the netlister.
>
> libgeda + gschem now support bus pins (graphical only) - new this
> development cycle.
>
> I just crippled gnetlist to avoid it helpfully netlisting them into
the
> standard netlist as if they were nets, and taught it some better
> type-checking rules between the various objects. I did this to stop
the
> "buses as nets" miss-feature being used by anyone. We don't want to
> encourage any usage we may intend to break later!
>
> It is a 2-line edit to turn on netlisting of buses, but it may be
rather
> more complex to ensure that in every appropriate place which reads the0D
> pin/connectivity list, the code checks to see if its looking at a
> net-pin or a bus-pin connectivity list.
>
> For the 1.8 cycle, I was thinking we might expose connectivity of
buses
> to backend APIs, and introduce a shared scheme file which some
possible
> ways of interpreting attributes defining the bus, then spitting a
> flattened bus into the resulting net-list.
>
> Teaching PCB to grok buses natively would be really cool.
>
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
