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. 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. 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. 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. 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. 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. 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. 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. 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. -Ken Marq Kole wrote: > > All, > > I've just asked Geoffrey Coram to upload a new version of the Multiple > Analog Blocks discussion document to the Verilog-AMS website. I've tried > to collect some of the discussions on the reflector since the appearance > and subsequent (but limited) review in the telecons. It still is a > lengthy document (25 pages) but I do hope you find some time to review > it before tomorrow's conference call. > > Best regards, > Marq > > > Marq Kole > Competence Leader Robust Design > > Research > NXP Semiconductors > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Thu Apr 05 2007 - 18:22:35 PDT