RE: 4 State Logic Proposals

Hi Per,

Since Shabtay is out, let me make some clarifications about the most
recent Cadence proposal on 4-state:

> 2) Shabtay's recently updated proposal allows 4 state values
> to be transported from the emulator/simulator side to the
> software side if the emulator/simulator is 4 state capable.
> However, only 2 state values are supported in the other
> direction.  It is not clear if this means that the 4 state
> logic types can be used in this direction or not.  In any event,
> attempting to pass 4 state values X and Z leads to undefined
> behavior.

This proposal assumes the following two things:
1) The purpose of having a hardware platform that supports 4-States is
to monitor X's or Z's in the DUT coming from the hardware side.
2) A transactor developer or modeler would not need the ability to send
X's or Z's from a BFM proxy to a BFM.

The revised proposal from Cadence is to allow 4-state TYPES in one
direction, from HW->SW, and 2-state TYPES from SW->HW.  Therefore, if a
vendor supports 4-state values in HW, these values are allowed to be
monitored by the SW side.  If the vendor does not support 4-state
values, the SW side monitors the 2-state value that is in HW.  

Allowing only 2-state types to be passed from HW->SW removes the need
for coercing 4-state values into 2-state values, and promotes a better
modeling style. 

This approach would be fairly simple to enforce: 

	export "DPI-C" function callme;
 	function void callme;
		input  logic [31:0]  badarg;   // This would be an error
		input  bit   [31:0]  goodarg;  // This would be OK
		output logic [31:0]  goodarg1; // This would be OK
		output bit   [31:0]  goodarg2: // This would be OK
		begin
		end
	endfunction

With this proposal, there is no "undefined" case, since 'logic' data
types are only supported as outputs in exported DPI functions, and as
inputs in imported DPI functions.

Regards,
Jason