[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] Re: [Iverilog-devel] Verilog AMS Road map?

From: al davis
Subject: [Gnucap-devel] Re: [Iverilog-devel] Verilog AMS Road map?
Date: Sat, 25 Jul 2009 01:40:43 -0400
User-agent: KMail/1.11.2 (Linux/2.6.26-1-amd64; KDE/4.2.2; x86_64; ; )

Sitting in my "drafts" since November --- how's that for slow.

also .. copy  to gnucap-devel

On Monday 24 November 2008, Stephen Williams wrote:
> But with A/MS, the idea I have is that analog circuits can be
> collected into islands of analog in a sea of digital. At any
> given time step, all the islands that need processing can be
> processed in their own threads to their convergences, then
> their results (in the form of events) puts into the even
> queue and digital time scheduling resumes. The Verilog A/MS
> execution model practical insists on this kind of threading.
> In fact, I consider it a viable possibility that the analog
> processing is farmed off to gnucap instances, fed, watered
> and herded by the vvp process.

I have been swamped on something else, which has really been 
screwing things up.

I see two tracks.  Both are needed.

One is small analog blocks in a primarily digital system.  (Call 
this #1). Inside this one, there are two variants.  One is 
little pieces with limited analog behavior. (Call this #1a.) The 
other is *real* analog blocks in your digital system.  (Call 
this #1b.)

The other track is to take an analog approach, with digital 
pieces inside.  (Call this #2.)

#1 uses Icarus Verilog as king.  #2 uses Gnucap as king.

Inside #1, limited analog behavior (#1a) could be used to 
describe single node blocks, and simple blocks with analog-like 
behavior, like a logic gate with timing.  You really don't want 
to think analog, but need to model some analog to make the 
digital work.  The analog part could be solved with a simple 
relaxation based solver, easily.  This can (and should) be done 
entirely within Icarus Verilog, with the acknowledgement that it 
is limited and won't do real analog circuits like RF and op-

Inside #1, real analog blocks inside your digital system (#1b) 
is harder.  To do this entirely within Icarus, if you think all 
you need to do is completely re-implement Spice, you are grossly 
underestimating what is needed.  This leads to the idea "analog 
processing is farmed off to gnucap instances....".

But perhaps #1b should really be #2.

Now, what is #2?

Consider having the Icarus compiler generate C++ code that can 
be linked with gnucap as a plugin, for everything, even the 
digital part.  Is this a vvp process?  Well, almost.  It's not a 
separate process, but has an interface that can be called.  
Gnucap has an event queue, and an assortment of other features 
to support digital concepts like latency and temporal sparsity.

In #1b, where you say to spawn gnucap instances, perhaps you 
want something that can be dynamically linked and called.

Suppose you have digital calling analog calling digital calling 
analog calling ...

or is that analog calling digital calling analog calling ...

The only difference is who goes first.  There's another 
difference, not seen so far, in the expected user interface.

But really what it leads to is that #1b and #2 are really the 
same, and #1a is needed by #2 also, as a speedup technique.

reply via email to

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