4 state issue

Brian, ITC peers,

 

When I made my recommendation for supporting only 2 states, I did not
take into consideration that some emulation vendors would choose to
offer 4 state emulators/accelerators. But given Ramesh's (From Tharas)
feedback, I suggest modifying our original proposal to accommodate
Ramesh (and others) as follows.

 

1.       SCE-MI 2.0 would support conveying 4 state values from the HW
side to the SW side. This will allow the SW side to monitor X and Z (if
the HW side is capable of producing the X and Z values of course). 2
state emulators/accelerators will only produce 2 state values.

 

2.       SCE-MI 2.0 would support conveying only 2 state values from the
SW side to the HW side. Passing other values such as X and Z will be
considered 'undefined' meaning it is up to the implementation to
determine what to do in this case. Passing X and Z will thus NOT be
considered an error.

 

The value that we see with this revised proposal over what I have
proposed originally at the meeting is:

 

a.       Supports 4 state value emulators/accelerators.

b.       Runs in compatible (congruent) mode on standard SystemVerilog
simulators that support DPI. Allows conveying 4 state values to 4 state
hw/SW engines that support 4 state values according to DPI data type
mapping.

c.       Allows vendors to offer users any option they wish for handling
transfer of X and Z from the SW side to the HW side in acceleration
mode. For example, 2 sates vendors can support coercion of X and Z
values to 0 and 1 w/o breaking congruency as congruency is only defined
within the definition of SCE-MI 2.0 spec (above). Vendors could also
provide the user a 'configuration switch' that defines how the
infrastructure would treat X and Z (coercion; to what values, error,
support it, etc).

d.       Portability of SCE-MI 2.0 transactors is guaranteed and the
results in simulation mode and acceleration mode will be the same within
the scope of the SCE-MI 2.0 spec.

 

I will not attend the next meeting this Thursday, so I hope you all will
have an enjoyable discussion. 

 

Regards,

 

Shabtay

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Brian

>Bailey

>Sent: Tuesday, October 11, 2005 10:16 AM

>To: itc@eda.org

>Subject: Meeting Minutes and Plan for Thursday

> 

>Hi Guys,

>    Please find attached the minutes from the meeting. For Thursday we
will

>go back to the Mentor call in details, but at the 10:00 Pacific time
slot.

> 

>From the US 888 742 8686

>International 303 928 2600

>Conference ID 6249294

> 

>Given that Shabtay will not be with us, I think we should use the
meeting

>as

>a planning meeting rather than a technical session. How do we want to
make

>sure that we have the real issues on the table? Do we understand the
flow

>(Assume for a moment just SV, as the others are still being questioned
in

>terms of Macro vs Function call). Which calls from 1.1 need to remain
in

>place for 2.0, which new ones need to be added?

> 

>Sorry, I have not been able to keep the IM's updated over the past 2
weeks.

>I intend to work on them today.

> 

>Best regards

>Brian