[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]