Re: 4 State support proposal

John, and ITC Colleagues:

Please see comments below.

I have added the corrections/comments to the proposal as well; the updated proposal is attached.


John Stickley wrote:
> 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.

I agree with your suggestion. We should limit SCE-MI 2 usage to DPI-C usage, and so i should be 
precise and say

The C side mapping would be to svLogic, svLogicVecVal, svLogicVecVal* .

> 
> 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 ?

Yes. Here is my general comment on 4 state support:

4 state support in SCE-MI 2 allows more flexibility;

a user doesn't have to use it if he doesn't want to;

if a user does use it, his usage is explicit and visible to the tool;

it is straight forward for the tool to coerce 2 state behavior.

> 
> As you know 4-state was not supported in SCE-MI 1.
> Do you see this as a major limitation to SCE-MI 1 ?

SCE-MI 1 was perhaps viewed as very emulator centric and 4 state was not particularly relevant.

SCE-MI 2 perhaps has an oppurtunity to be used as a standard way of interfacing C/C++ testbench 
artifacts to simulation, acceleration, and emulation. So, allowing for 4 state would enable the 
standard to be used more widely.

> 
> 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

The assumption is a user who cares to represent the interface in 4 state will use the 4 state types 
of reg/integer/logic.

Say the user has a reg [31:0] mybus, that is mapped to svLogicVecVal mybus on the C side.

Scenario 1: Vendor supports 4 state

If the vendor supports 4 state mybus.c may be populated with non zero values; i.e., z/x encoding has 
'c' bit at '1'. This works in either direction.

Scenario 2: Vendor does not support 4 state

Going from HDL to C:

mybus.c would be zero all the time; the HDL will populate mybus.d with the 2 state value.

Going from C to HDL:

mybus.c and mybus.d would be populated; the HDL will consume mybus.d only.

The above implicitly means, z will be coerced to 0, and x will be coerced to 1.

It is recommended that the tool produce nothing OR warnings OR errors when non-zero mybus.c values 
are present; the user can pick what he wants to see.

> 
> -- 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
>>
> 


-- 
regards,
Ramesh

[10/5/05 update]

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, svLogicVecval, svLogicVecval* .

e.g.,

[From unapproved IEEE P1800_D6 draft]

/* (a chunk of) packed logic array */

typedef struct vpi_vecval { 
	uint32_t a; 
	uint32_t b; } s_vpi_vecval, *p_vpi_vecval;

/* (a chunk of) packed logic array */ 

typedef s_vpi_vecval svLogicVecVal;

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.

Discussion of 4 state usage and implementation:

The assumption is a user who cares to represent the interface in 4
state will use the 4 state types of reg/integer/logic.

Say the user has a reg [31:0] mybus, that is mapped to svLogicVecVal
mybus on the C side.

Scenario 1: Vendor supports 4 state

If the vendor supports 4 state mybus.c may be populated with non zero
values; i.e., z/x encoding has 'c' bit at '1'. This works in either
direction.

Scenario 2: Vendor does not support 4 state

Going from HDL to C:

mybus.c would be zero all the time; the HDL will populate mybus.d with
the 2 state value.

Going from C to HDL:

mybus.c and mybus.d would be populated; the HDL will consume mybus.d
only.

The above implicitly means, z will be coerced to 0, and x will be
coerced to 1.

It is recommended that the tool produce nothing OR warnings OR errors
when non-zero mybus.c values are present; the user can pick what he
wants to see.