Re: multiple analog blocks - discussion doc

Ken,

My answers in the text below

Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors


Ken Kundert <ken@designers-guide.com> wrote on 06-04-2007 03:21:59:

> Marq,
>     I have read through your document and have the following comments:
> 
> Guideline 5, Page 4, Line 87: I suggest you leave out any comments about
> single kernel versus cosimulation. I believe these distinctions are
> meaningless marketing babble. It is enough to say that it is
> implementation independent, though in my mind that basically means that
> the specification should be complete and clear enough so that there is
> little chance for ambiguity.

OK

> Example 3, Page 7, Line 221-330: This is not an example of multirate, it
> is an example more akin to latency. In other words it does not
> demonstrate several blocks running a different rates, it demonstrates
> some blocks as being latent and therefore not needing evaluation.

I'll rephrase all references to multirate to refer to latency instead.
 
> Example 3, Page 7, Line 221-330: I believe that this example is
> misguided. It breaks the behavioral description of a diode into three
> blocks and assumes that the simulator will only evaluate the blocks as
> needed. The simulator is given no cues to indicate when they should be
> evaluated, so it will need to do a careful dependency analysis to
> determine if and when each block should be evaluated. Once the
> dependency analysis is done, there is no need to honor the blocks at
> all. The simulator could (and should) decide on a statement by statement
> basis which statements should be evaluated. Thus, dividing the behavior
> into separate blocks really provides no benefit in this case.

Agreed. Apart from some intrinsic problem with the example that Geoffrey 
pointed out, I support the notion that latency exploitation is best left 
to the compiler instead of relying on model writer's hints by using either 
named blocks or multiple analog blocks.

> Section 3.1.1, Page 10, line 390: I completely agree with your
> conclusion that undeclared branches should be associated with the module
> rather than a particular analog block. However, I don't believe you can
> simply allow race conditions on variables. I believe that whenever there
> is a race condition on a variable that is being assigned a value
> continuously, the model will simply not work 50% of the time. Allow me
> to make an alternate proposal.
> 
>     1. If a variable is assigned a value continuously in an analog
>        block, it is owned by that block and its value cannot be
>        assigned in any other block.
>     2. A variable assigned a value within an @ statement that is
>        contained in an analog block is not said to be assigned a value
>        continuously.
>     3. A variable that is not assigned continuously, can be assigned
>        a value by any analog, always, or initial block.
> 
> In this way the chance of a continuous race condition is eliminated, but
> one has freedom to share variables more fully.

Hmm, I need to think about this some more. At first glance it seems to 
work OK, but what happens in case of cross-dependency? Also, writing is 
not the only problem: if a variable has different values before and after 
evaluation of the analog block in which it is assigned a value and another 
block uses this variable, how to determine which value it will actually 
see? What happens if there is a cross-dependency in case of two variables? 
This is why Kevin came up with the copy-in, copy-out behaviour.

> Section 3.1.3.1, page 14, line 617: I believe it adds little value to
> support multiple unnamed parallel branches within a module. Frankly it
> seems like it would cause more confusion than it is worth.

I tried to capture the back-annotation aspects here, but I might have done 
a bad job here.
 
> Section 3.1.3.1, page 15, line 651: I don't understand how you can have
> mismatched natures on branches that connect to the same node.

The wording may be wrong but I was trying to have the situation where an 
existing voltage contribution was given a current contribution for 
instance from a back annotation. In case of two unnamed branches this 
would come down to a switch branch, while if they were the same they would 
add up. Does this make sense? If not, we'll forget about this section...

> Section 3.2, page 15-19, lines 686-869: This section adds a lot of
> complexity and the justification for it seems very weak. Largely the
> justification consists of Example 1, and frankly that example can be
> trivially rewritten to eliminate the need for any of this. Is there a
> better explanation of why this is necessary? What happened to the idea
> of just evaluating the analog blocks in order? That is simple and seems
> to solve a lot of issues.

You mean example 4, right? Because the main reason for having concatenated 
analog blocks would be the situation where you have a succession of 
stages, each depending on a value determined in the previous one, creating 
a specific order of evaluation for the analog blocks. As this order was 
deemed to be absent because of the concurrent nature of the multiple 
analog blocks (in parallel to the initial and always blocks) it needed to 
be added explicitly.

> Example 7, page 20, line 901: The line has two problems. First, the
> argument of the transition function is the output of another transition
> function. This means that the argument will be continually varying,
> which is inappropriate. Second, when i==0, it tries to access stage[-1],
> which does not exist.

For the first problem: what is exactly the issue, besides inappropriate 
use of the transition function? For the second problem, I guess you 
overlooked the modulus operator which would turn it into stage[n-1].

> Example 7, page 20, line 911: This is a race condition. value is
> assigned continuously on line 900 and is assigned on the initial step to
> a different value on line 911. If the two analog blocks are evaluated
> concurrently there is a race condition and it is arbitrary which one
> dominates. Your explanation on line 930 about this not being an issue
> because line 900 includes a transition statement is incorrect. A
> transition function does not delay the assignment, nor could it.

Maybe I should reconsider the example, but if instead I created the 
ring-oscillator using inverter instances again using a transition 
operator, where would be the difference? On the initialization part, as 
far as I have understood an expression that has a transition assigned to 
it will clear the transition if it scheduled earlier, or add the 
transition in the queue if it is scheduled later - where I took the delay 
in the transition function into account.

> 
> -Ken
> 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.