RE: 4 State Logic Proposals

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
>Of Per Bojsen
>Sent: Sunday, October 16, 2005 7:50 PM
>To: itc@eda.org
>Subject: RE: 4 State Logic Proposals
>
>
>Hi Russ,
>
>> So you see where a fatal error generated from every 4-state write to 
>> the HDL side would get in the way of getting this case up 
>and running?
>
>Yes, you do have some good and valid points.  I am still 
>worried about the portability issues.  I see two conflicting 
>concerns here:
>
>  1) Your pragmatic concern about allowing the implementation to be
>     lenient regarding X and Z to ease porting of 4-state-full models
>     and environments.
>
>  2) My concern about having the implementation detect non-portable
>     models by flagging X and Z usage as errors.

Yep, these are conflicting concerns. My inclination is to lean towards
forcing portability over other factors, so this is an exception to
these inclinations.

>
>It seems reasonable to find a way to accommodate both 
>concerns.  But first, I'd like to understand one key point in 
>your example.  Your example assumes the model is sending and 
>receiving X and Z.  The receiving part we can ignore as the 
>implementation will either run on a 2-state engine in which 
>case X and Z will never be sent by the HDL side and thus never 
>received by the C side.  So that leaves sending X and Z.  My 
>question is, how common do you think such models are (models 
>that actually send X and/or Z to the HDL side)?

I don't know. Within our (BRCM) verification environment, we do have
simulation-only transactors that do communicate 4-state values with
their C proxies. I think the most common usage is to set 'Z' values
to some transactor that interfaces to a bus. Of course, this could
easily be done by some 2-state command that causes the hw transactor
to drive the 'Z' value.

>
>Let me now address the question of accommodating both concerns 
>above from a couple of different angles.  First one might 
>argue that the relaxing of X and Z usage considered errors to 
>warnings could be something an implementation could add as an 
>enhancement to the standard somewhat akin to how GCC has 
>defined a number of non-standard improvements to C.  GCC has 
>options that enable/disable the various language extensions.  
>Similarly, a SCE-MI implementation could provide non-standard 
>extensions such as treating certain errors more leniently.
>
>Next, still assuming the standard says sending X and Z is an 
>error, the application could modify this behavior by 
>installing an error handler that would see this error and 
>instead of aborting would allow the simulation/emulation to 
>continue.  This probably makes more 
>sense if we define sending X and Z as a non-fatal error rather 
>than a fatal error.  The reason is that we have currently 
>defined fatal errors as non-recoverable.  Non-fatal errors are 
>recoverable and we could define the coercion of X and Z to 0 
>and 1 as the recovery. All this assumes that we are continuing 
>to use the SCE-MI error and warning infrastructure for 
>errors/warnings related to the DPI subset of SCE-MI 2.0.  I do 
>not remember if this topic has been brought up before.  I will 
>send a separate email to raise this issue.
>
>Anyway, I still believe it is important that the standard 
>specifies some mandatory diagnostic upon sending X and Z.  
>Whether it needs to be a fatal error, non-fatal error, or a 
>warning, I do not care much.

Me too. I'm just concerned about getting a consensus for requiring
the generation of warnings/errors. This seems to be a sticking point
and I don't think it's worth spending a lot of time on it. Any product
that didn't issue these warnings/errors would probably be barraged with
customer complaints and it would be a "bug report"/"feature request" in
short order.

In an ideal world, a product would have settable levels: coercion, warning
issuance, error generation could be controlled by the user. Default would
be coercion and a warning issuance.

  I want to be able to detect 
>non-portable constructs at compile time and/or run time as 
>much as possible and sending X and Z is easy to check for, so 
>we should do it.  Perhaps we need to define two operating 
>modes: Strict compliance where portability is guaranteed if 
>the models run without errors/warnings and relaxed compliance 
>where the models can take advantage of optional extensions 
>such as sending X and Z.
>
>Per
>
>
>

---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------