Re: multiple analog blocks

Hi all,
Maybe I'm mistaken, but isn't this over-complicating the issue?
We are now suggesting adding in a new construct that doesn't appear in 
Verilog-D and will clash with the "continue" statement in System-Verilog 
and I am not quite sure what problem we are trying to solve anymore.
I thought all we wanted to do for this section was give the user some 
indication of what results that could expect when using multiple analog 
blocks within the same instance. Something along the lines of:
"When using multiple analog blocks within the same module, the user can 
expect to see the same results as if multiple sequential blocks were 
used instead." or something like that.
As an implementor of a simulator, all I need to know is what is the 
expected result. If internally I treat them all as one large analog 
block, or maybe solve them in parallel is fine, as long as I get the 
result the user is expecting.

If I have digital:
    always #5  i = 1;
    always #5 $display("i = %b",i);
    always #5 i = 5;

These three blocks seem to be solved sequentially - I always get the 
value 1 printed. So can't multiple analog blocks also behave like this? 
Would there ever be a situation where a model developer would have 
expected to get the value 5 printed?
I hope I am not missing something.

Cheers...
Dave


Marq Kole wrote:
>
> Kev,
>
> I like your proposal, but I would suggest to construct it more like a 
> continued analog sequential block. By moving the continuation to the 
> analog sequential block level, you could say something like:
>
> integer i;
>
> analog
>   begin : init1
>     i = 1;
>   end
>
> analog
>   begin : init2
>     i = 2;
>   end
>
> analog
>   continue : init1
>     i = i + 1;
>     $strobe("i = %d", i); // continue named block init1
>   end
>
> Having a named continued analog sequential block without a named 
> sequential block may be allowed to support the use of continued analog 
> sequential blocks in loop generate statements. Alternatively, the user 
> is required to create a (possibly empty) named analog sequential block 
> before the generate construct.
>
> analog
>   begin : loop
>     // This shouldn't be needed for ease of use
>   end
>
> for (i = 1; i < N; i = i + 1)
>   analog
>     continue : loop
>       I(out[i]) <+ (V(in)-V(out[i]))/res;
>     end
>
> By allowing continued analog sequential blocks only within analog 
> procedural blocks spillage into the digital language space can be held 
> at bay. :-)
>
> The concatenation of analog procedural blocks is now shifted to the 
> concatenation of analog sequential blocks (even if they appear in 
> different analog procedural blocks). But the user is actually in 
> control of the concatenation -- it is no longer a hidden process. On 
> the other hand, separate analog procedural blocks still appear as 
> essentially concurrent, allowing activity-level optimization (as is 
> assumed in Geoffrey Coram's MOS11 example on the Designer's Guide 
> website) to be handled at the named analog sequential block level.
>
> There's still a few loose ends (no show stoppers, though):
> - do we allow unnamed continued analog sequential blocks? If so, what 
> do they continue?
> - allow continued analog sequential blocks wherever analog sequential 
> blocks are allowed to appear? Or restrict them to occur only in analog 
> procedural blocks (not inside another analog sequential block)?
> - disallow declaration of local variables in (named) continued analog 
> sequential blocks (no analog block item declaration)? What other 
> restrictions do continued analog sequential blocks need with respect 
> to (named) analog sequential blocks?
> - possible concurrency issues with multiple concurrent analog 
> procedural blocks:
>   * switch branches: signal/disallow contributing to a switch branch 
> in concurrent analog procedural blocks ?
>   * shared variables: should they be owned by particular blocks? does 
> that solve anything? all items in a vector variable, vector net, or 
> vector port to be owned by the same analog procedural block?
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors


-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================