[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-
amps.
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnucap-devel] Re: [Iverilog-devel] Verilog AMS Road map?,
al davis <=