Re: Verilog-AMS Committee Meeting Reminder - 25 Jan 2007

David Miller wrote:
> Could I suggest that we please postpone discussing the multiple analog 
> blocks proposal till maybe next weeks call?
For me too, I don't think I'll make the call.

In the meantime...

1. Race conditions

    I don't think the problem is clear. I don't think there are really 
that many opportunities for race conditions. The code in a Verilog-AMS 
model is not C code, what actually gets executed in the simulator does 
not necessarily have variables that are shared during evaluation. No 
data is propagated until the matrix is solved. The race conditions are 
therefore no worse than in a digital simulation. Also, adding attributes 
is unlikely to be useful since the model writer probably wouldn't know 
that their model was going to be used that way, and the user may not be 
able to modify source.

2. Concatenation of analog blocks

I'll vote "no" on any new keywords - it always slows things down getting 
stuff through committees.  I still think labeling the blocks should be 
required so that you can have separate concatenated analog processes 
(and non-concatenated) in the same module. I think your upward 
hierarchical references are really more "lateral" and don't go outside 
the  module, so I don't  see any problems there, but maybe a shorthand 
syntax for referring to another instance of the same block in the same 
generate would be useful e.g. ".[<index>].<item>".

Kev.

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