Re: 4 State support proposal

ITC Techies,

I just realized after reading Russ's response that my
earlier e-mail was using the wrong data type names
so this may have been confusing to readers.

What I meant to say is that "DPI" deprecated usage uses:

svBitVec32
svBitPackedArrRef
svLogicVec32
svLogicPackedArrRef

Compare this the preferred "DPI-C" usage which uses
svBitVecVal
svBitVecVal *
svLogicVecVal
svLogicVecVal*

My point was that SCE-MI I should only support the
latter not the former regardless of what decisions
we make regarding 2-state vs. 4-state handling.

-- johnS

Russell Vreeland wrote:
> 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
>  > ________________________________________________________________
>  >
> 
> 

-- 

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
________________________________________________________________