Re: multiple analog blocks

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
In the syntax I suggested previously the  "continue" is optional on the 
first block so the following would work (standalone):

 for (i = 1; i < N; i = i + 1)
  analog begin :
    continue  loop
      I(out[i]) <+ (V(in)-V(out[i]))/res;
    end

However it may be useful to use a block before the generate to declare 
variables etc. only used in the following "continue" blocks so that 
their scope is limited to the concatenated blocks.
> 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?
I don't think it's a good idea to have concatenation for unnamed analog 
blocks.
> - 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)?
I would say outer block only.
> - 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?
I think you would need to work through some examples to show that won't 
make life difficult, but it's the kind of restriction you can relax 
later, however, as mentioned above I think it may be useful to declare 
things in at least the first block of the set.
>
> - possible concurrency issues with multiple concurrent analog 
> procedural blocks:
>   * switch branches: signal/disallow contributing to a switch branch 
> in concurrent analog procedural blocks ?
There isn't much difference between the concurrent analog blocks in the 
same module and those in separate modules, so I see no need for any 
restrictions.
>   * 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?
I think (once again) that if you want to limit scope on items then it 
should be explicit, i.e. add keywords like "private" or "local".

Kev.
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors