Re: gEDA-user: Hierarchy question

[Mike Jarabek <mjarabek@istop.com>]

Hi.

Bill Cox wrote:

> Mike Jarabek wrote:
>
> > Hi,
> >
> >    I ran into a similar issue with the Verilog netlister.  I skirted 
> > the issue by adding a symbol with a special attribute attached, 
> > 'device', where the value was `IPAD', `OPAD' or `IOPAD'.  When the 
> > netlister enumerates the instances on the schematic, it builds lists 
> > of the ports, based on the type attribute, and then ignores those 
> > special symbols when the actual netlist instances are written out.  
> > The VHDL netlister uses a similar scheme. (Literally.. ;-) You can 
> > look in gnetlist/scheme/gnet-verilog.scm for info.
> >
> >    AFAIK, no `standard' symbol was created to convey this 
> > information. Perhaps the time has come for this?
> >
> > Mike
>
> I think we need to settle on some attributes for hierarchy connection...
>
> I like your scheme, but it has some duplication in attribute info.  
> The direction (in, out, inout) info is encoded on the pintype 
> attribute of the pin.  I'd rather have a single device attributes for 
> all flags, like "FLAG" or "IO".  That makes it simpler to search for 
> flags.
At the time when I wrote the Verilog netlister, we did not have access 
to attached attributes on the pin itself.  So I attached the information 
at the symbol level, where it was visible to the netlister back end. 
Using the attribute on the Pin directly is a better idea, with an 
appropriate device class attribute.  I suppose you could then have the 
`symbol' for the schematic appear on the schematic with the hierarchy 
connections on it, then use the same symbol on the next level up to 
actually instantiate the sub-block... Well maybe, if the ins and outs 
matched up right...

> Either way, the current IO library has no consistent use of the device 
> attribute. 
This can probably be partially solved with an addition to the symbol 
creation guide, and some small modifications to existing back-ends.

Mike