[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] another assertion 'bug'
From: |
al davis |
Subject: |
Re: [Gnucap-devel] another assertion 'bug' |
Date: |
Thu, 13 Dec 2012 19:41:10 -0500 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) |
On Thursday 13 December 2012, Felix Salfelder wrote:
> On Thu, Dec 13, 2012 at 06:43:15AM -0500, al davis wrote:
> > It is correct, in parsing, to set_dev_type to the 'device'
> > attribute, but incorrect to make them all subcircuits.
>
> i've worked this out some more. i think the following is
> desirable: - if there is a device attribute and
> (some_dispatcher[device] || find_looking_out(device)), use
> that device
> - else, instanciate a fake sckt that collects the parameters.
> this wont simulate, but set_dev_type makes the list command
> happy.
>
> unfortunately savant's find_type_in_string has no access to
> the body of the device. for example find_type_in_string on
>
> C 1 2 3 4 some-symbol.sym
> {
> device=some-other
> }
>
> will not know about some-other.
That's a problem. The best way to deal with this is to read
that whole block into memory so it can be scanned. Actually,
this is the only way I would consider. With anything else you
will be fighting it all the way through.
I have considered a mod to the CS class to be able to redefine
what a "line" is. There are many places where that would help.
> so (my approach, not changing the parser much) looks a bit
> more involved:
>
> - instanciate a fake-sckt
> - if the symbol has a device attribute the device_dispatcher
> knows (and it matches the pincount whatsoever) use that
> device as type - otherwise instanciate that fake-sckt and
> set-dev-type
>
> the first case is simple, but doesnt allow the user override
> the device attribute (*). in the second case, a device is
> instanciated and potentially set_type to some-other. this
> way the user may override the device attribute if a subckt
> matching the pins is present.
That won't work .. wrong type for simulation. .. wrong data
structures, wrong virtuals ...
A variant would be to make a subckt/module with one device
inside. That adds a lot of overhead.
Another variant would be to do that, then deflate it later, like
what is done in bm_ expressions.
It is simpler to just read the whole object first, so you can
scan for the type.
It's no accident that Verilog put the type first. Compare the
parsing of verilog format vs spectre format, which puts the type
in the middle.