Re: Elaboration algorithm proposal

Marq Kole wrote:

>
> Geoffrey, Kev,
>
> When we wanted to allow multiple analog blocks in the analog context 
> the only way to handle this in a consistent way that would not 
> overburden the implementation was by concatenating them into a single 
> larger analog block.

I disagree with that premise. Note: I built a working compiled code 
Verilog-A[MS] simulator back in ~ 1996, and I saw no problems with  
allowing multiple analog blocks in a module.

> That is definitely different than the @always block in digital Verilog 
> which as far as I can tell should be considered to operate concurrently. 

True, but if anything analog blocks are intrinsically more concurrent 
than digital since they are evaluated by solving a joint matrix, digital 
evaluation is not usually parallel.

> One of the problems with concurrent execution of separate analog 
> blocks is that you will immediately open up the possibility of race 
> conditions in the handling of the statements that work with 
> module-level variables in the sequential blocks, and hence ambiguity.

Doesn't matter if the blocks are in the same module or different 
modules, if they share data that is outside the matrix you will get 
"race" conditions, but that is just an issue of (bad) programming style.

>
> By *defining* that multiple analog blocks will be concatenated the 
> race conditions and therefore the ambiguity will not be present 
> anymore. The way analog contributions are handled is essentially 
> concurrent, because the continuous-time solver is handling all 
> contributions together. But analog blocks also contain code that is 
> needed for setting up these analog contributions and this code is not 
> necessarily concurrent. Apart from that: multiple contributions to a 
> branch are principally sequential in nature either by value retention 
> or through switch branches. Analog blocks are not @always blocks and 
> they probably never will be.

Basically you are advocating that there should only be (semantically) 
one analog block in a module because people write bad code.

> In my opinion the advantage of multiple analog blocks will mainly be 
> in combination with generate constructs. If a modeller creates 
> multiple analog blocks that contribute to the same branch he will need 
> take the same amount of care as when he made them in a single block.

OK

>
> If you need a stronger level of concurrency then instead of multiple 
> analog blocks you should use separate analog modules, this given 
> concurrency even to the point that reordering the instantiations of 
> these modules does not influence the simulation results. However, they 
> will no longer be able to do collective bookkeeping on the same set of 
>  module-level variables. You can't have both without significant 
> effort in implementation and probably restrictions in how to model to 
> prevent ambiguity. In the end, analog is very different from digital.

Once again I disagree with the premise, analog is not actually that much 
different from digital when it comes to building a simulator. The main 
difference is that the analog processes are sensitive to changes in 
derivatives rather than levels, and you usually (but not always) need a 
matrix solver to evaluate the derivatives and levels, but like digital 
you just step through the analog blocks evaluating them as necessary to 
work out new contributions etc.

As I said elsewhere, concatenating otherwise disjoint analog processes 
will have a negative effect on performance, and is likely to create more 
problems than it solves.

Kev.

>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors
>
>
>
>
>
>
>
>
> *"Geoffrey.Coram" <Geoffrey.Coram@analog.com>*
>
> Sent by:
> geoffrey.coram@analog.com
>
> 15-12-2006 14:38
>
> 	
> To
> 	edaorg@v-ms.com
> cc
> 	verilog-ams@verilog.org
> Marq Kole <marq.kole@nxp.com>
> Subject
> 	Re: Elaboration algorithm proposal
> Classification
> 	
>
>
>
> 	
>
>
>
>
>
> edaorg@v-ms.com wrote:
> >
> > This sounds bad to me. As a user I would expect to get the
> > same behavior if I put the analog blocks in the same module
> > or in separate modules if their connectivity is the same -
> > I don't see that being the case if the blocks get concatenated.
> > Reodering always blocks in Verilog doesn't change the behavior,
> > the same should be true for analog blocks.
> >
> > I think there should be an explicit statement to the effect
> > that: the reordering of analog blocks within a module or
> > declaring them in seperate modules should not change the
> > results of simulation for pure analog (to exclude A/D issues
> > at ports).
>
> Kevin brings up an interesting point: what about value
> retention?  If I do:
>  analog begin: block 1
>    V(out) <+ 5;
>  end
>  
>  analog begin: block 2
>    I(out) <+ 5;
>  end
>
> Then reordering the blocks before concatenation will
> alter the results.
>
> Also, if you have
>  analog begin: block 1
>    V(out) <+ 5;
>  end
>  
>  analog begin: block 2
>    V(out) <+ 500;
>  end
> then you will get a singular matrix error if these
> are in separate modules connecting to the same node.
> If they are concatenated, the values will add and
> you'll get a 505-volt independent source driving
> the node.
>
> -Geoffrey
>