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. _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
