Shabtay’s take 04/28 - Issues resolved. Needs explanation in the mixed usage section and only requires spec review.

Committee agrees

Mixed SCE-MI 1.1/2.0 usage

a) Firming up the seams between the new DPI-based features and the SCE-MI 1.1 features: restrictions on mixing etc.

b) Initialization and Creset in 1.1 -- how can 2.0 models be made compatible with 1.1 models utilizing these mechanisms?

Some of this already covered by other discussions.

When a 1.1 model is used in a 2.0 environment, this should work. A model may not mix 1.1 and 2.0 constructs. May use pure HDL constructs, i.e. no messaging mechanisms.

2.0 models have time frozen rather than clock frozen.

As soon as any 1.1 model exists in a run, all clocks must be sourced from SCE-MI clocks.

At highest level of hierarchy when there is an import/export construct, there can be no SCE-MI 1.1 construct below that (except clock port) and visa versa.

John to create a set of rules for this.

No SCE-MI 1.1 object should call any 2.0 feature and visa versa on the SW side.

JohnS> One of my AI's last week at the face to face was to write up a formal requirement for preventing mixes of SCE-MI 1.1 constructs with SCE-MI 2 constructs in the same transactor and C models.

For purposes of this description, the following definitions are given:

A SCE-MI 1.1 HDL model is defined as a hierarchy with the following properties:

1. At least one SCE-MI 1.1 message port or clock control macro (but not clock port macro) is instantiated at the highest level of the hierarchy within the model.

2. More SCE-MI 1.1 message ports or clock controls may be instantiated at lower sub-hierarchies of the model.

A SCE-MI 2.0 HDL model is defined as a hierarchy with the following properties:

1. At least one SCE-MI 2.0 DPI function call us declared at the highest level of the hierarchy within the model.

2. More SCE-MI 2.0 DPI function calls may be declared at lower sub-hierarchies of the model.

Requirements for SCE-MI 2:

1. No SCE-MI 1.1 models as defined above can contain any SCE-MI 2.0 function call declarations or calls anywhere in their hierarchy.

2. No SCE-MI 2.0 models as defined above can contain any SCE-MI 1.1 message port or clock control macros anywhere in their hierarchy.

3. No SCE-MI 1.1 callback functions can make direct calls to exported DPI calls.

4. No SCE-MI 2.0 imported function calls can make calls to the SCE-MI 1.1 service loop or to send on any of the input ports.

<End JohnS

>Per

So I noticed you used the convention proposed by Russ to use 2.0 to refer to the features that are new in 2.0 and 1.1/1.x to refer to the old features that are retained in SCE-MI 2.0 for backwards compatibility reasons, right? It would be nice to have a figure in the preamble to the standard (one of the introductory sections, that is) that shows the relationship between 1.1 and 2.0 . . .

<End Per

>Russ

I agree with this. We definitely need to talk about the SCEMI 1.1 clock macros and their relationship to SCEMI 2.0, whether it's possible to have a SCEMI 2.0 emulatable testbench without them, etc.

<End Russ

>Shabtay

Can you explain the why SCE-MI 1.1 message port must be instantiated only at the highest level of the hierarchy within the model and why DPI function call is declared at the highest level of the hierarchy within the model?

>>JohnS

The use of the term "model" is arbitrary but convenient.

The more precise definition is "some level of hierarchy containing macros in itself or below cannot have DPI functions anywhere in itself or below".

Similarly, "some level of hierarchy containing DPI functions in itself or below cannot have macros anywhere in itself or below.

This forces macros to only exist in disjoint hierarchies from functions.

I'm just conveniently labeling such hierarchies as "models" because that is how we think of them.

<<End JohnS

>>Per

John said `at least one SCE-MI 1.1 message port/clock control macro' must be instantiated at the highest level of the model. He did not say that *all* message ports/clock control macros must be instantiated at that level. Similarly for DPI. So you can definitely have macros at any level of hierarchy below the top level of the model. Again, similarly for a SCE-MI 2.0 DPI model.

<<End Per

Shabtay? John clarified my "highest level" question and I agree with him. The way I see it, I can create a single model (transactor) and instantiate one SCE-MI 1.1 message port 5 levels down the hierarchy. Independently of whether this makes much sense, it is still a legitimate SCE-MI 1.1 use model. Correct? If not, I'd like to learn why not.

I agree now with your more precise definition.

<End Shabtay