RE: 4 State support proposal

All,

BRCM has not submitted a detailed proposal regarding 4-state support though
we raised the issue several weeks ago. Our expressed desire is simple: to be
able to use models written for 4-state simulation in a 2-state only SCEMI
environment without having to rewrite lots of code.

I think that that is as simple as saying we'd like the SCEMI (C side) data
types svLogic and svLogicVecVal and the (SV side) data types integer and reg
at least to pass through a SCEMI preprocessor or IFLC (or whatever you want
to call it) without triggering some kind of abort or error.

There is no issue with coercion or mapping of 4state to 2state going from
HDL -> C, because the HDL side doesn't generate 4state when represented in
an emulator. If a present or future hardware accelerator does generate
4state, then that particular technology could claim support for this beyond
SCEMI but I don't believe the spec should indicate that's a SCEMI compliant
mode of operation.

Going from C-> HDL is dicier. There probably needs to be a simple mapping of
'X' and 'Z' to '0' and '1' and an option to generate a warning message (not
a requirement). The simulation/emulation mismatch issues, in my opinion,
would be more than offset by no need to go through models and change all the
svLogic types to svBit. But it's a tradeoff, and I'm not 100% convinced
about it.

I agree with John that we should support P1800 DPI only.

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



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of John Stickley
> Sent: Wednesday, October 05, 2005 6:19 AM
> To: ramesh@tharas.com
> Cc: brian_bailey@acm.org; itc@eda.org
> Subject: Re: 4 State support proposal
> 
> 
> Ramesh,
> 
> One minor point of clarification just so I understand
> fully what you are saying. When you say support
> both svLogicVec32 and svLogicPackedArrRef are you
> referring to both the old deprecated "DPI" and
> the newer "DPI-C" usage respectively ?
> 
> These are redundant functionalities and I would strongly 
> recommend against saying SCE-MI 2 should support the old 
> deprecated usage. This would impact 2 state support as well, 
> i.e. svBitVec32 vs. svBitPackedArrRef and I really don't 
> think we want to go down that road.
> 
> As for your 4-state recommendations I think I'm hearing
> you say that if an acceleration vendor supports 4 state,
> that SCE-MI 2 should not prevent it right ?
> 
> As you know 4-state was not supported in SCE-MI 1.
> Do you see this as a major limitation to SCE-MI 1 ?
> 
> Can you you modify your proposal to suggest how SCE-MI 2
> should handle the case when an acceleration vendor does not 
> support 4 state, i.e., gracefully accommodate both
> scenarios:
> 
> 1. The accel vendor supports it
> 2. The accel vendor does not support it
> 
> -- johnS
> 
> Brian,
> 
> As far as I can see, we don't yet have an IM for this issue.
> I think it would be good to add one at this point.
> 
> -- johnS
> 
> Ramesh Narayanaswamy wrote:
> > Dear Colleagues:
> > 
> > We would propose that 4 state be supported in the SCE-MI 2.0 
> > Interface.
> > 
> > Four valued System Verilog data types, reg, logic, and 
> integer should 
> > be treated as four valued at the DPI interface.
> > 
> > The C side mapping would be to svLogic, svLogicVec32, 
> > svLogicPackedArrRef.
> > 
> > e.g.,
> > 
> > /* (a chunk of) packed logic array */
> > 
> > typedef struct { unsigned int c; unsigned int d;} svLogicVec32;
> > 
> > The encoding would follow the SV definition:
> > 
> > c       d       Value
> > 
> > 0       0       0
> > 0       1       1
> > 1       0       z
> > 1       1       x
> > 
> > [the above is the same as "old" Verilog's aval/bval encoding]
> > 
> > The implementor has the choice of
> >         a) coercing to two state by dropping 'c'
> >         b) warning and coercing
> >         c) generate error and stop; the error can be at compile time
> >            if an implementation disallows reg, logic, and integer in
> >            the relevant function interface.
> > 
> > Most synthesis and emulation platforms accept reg, integer 
> and coerce 
> > to two state. The proposed approach for SCE-MI is 
> consistent with that 
> > approach.
> > 
> > If desired VHDL subtype X01Z can be supported with the same 
> encoding 
> > as SV logic/reg.
> > 
> > --
> > regards,
> > Ramesh
> > 
> 
> -- 
> 
> This email may contain material that is confidential, 
> privileged and/or attorney work product for the sole use of 
> the intended recipient.  Any review, reliance or distribution 
> by others or
> forwarding without express permission        /\
> is strictly prohibited. If you are     /\   |  \
> not the intended recipient please     |  \ /   |
> contact the sender and delete        /    \     \
> all copies.                      /\_/  K2  \_    \_
> ______________________________/\/            \     \
> John Stickley                   \             \     \
> Mgr., Acceleration Methodologies \             \________________
> Mentor Graphics - MED             \_
> 17 E. Cedar Place                   \   john_stickley@mentor.com
> Ramsey, NJ  07446                    \     Phone: (201) 818-2585
> ________________________________________________________________
>