RE: Verification unit bindings -- text change proposal

Johan,

Thanks for the clarification. I now understand that you are not suggesting a general rewrite rule that will work for all flavors, but rather a semantic description that is illustrated by a rewriting in one flavor. I understand that this semantic description can be applied even if the rewriting illustrated in one flavor is not legal in another.

I also understand your point about inheriting a vunit that is bound to a module at a different level.

I have no problem with the approach you are taking with this. I would like to be able to express the semantics by showing an equivalent example in every case (and flavor), and I think that would be possible if PSL were to define pathnames over a hierarchical design, independent of the underlying language - hence my question.

Regards,

Erich

| -----Original Message-----
| From: Johan Alfredsson [mailto:johan.alfredsson@safelogic.se]
| Sent: Tuesday, January 25, 2005 4:19 AM
| To: Erich Marschner
| Cc: ieee-1850-extensions@eda.org
| Subject: RE: Verification unit bindings -- text change proposal
|
|
| Erich,
|
| There is no approach -- there is only an example, which is
| perfectly valid. However, you are correct that the example
| cannot be written in a similar manner for VHDL. This boils
| down to the crucial fact that an instantiated verification
| unit IS NOT generally a verification unit.
| (At Safelogic, we have always referred to this as a
| "verification task".) Let me also point out that this is the
| case regardless of chosing my "approach" or other discussed
| "approaches".
| To answer your other questions in one go: No. It is not
| relevant what you can and cannot do in VHDL. If the example
| would have been written in VHDL, it would have looked like this:
|
| vunit ex2a (ent) {
| assert never (ena and enb);
| }
|
| If the entity "ent" is instantiated twice, once in
| top_block.i1 and once in top_block.i2 the result from
| instantiating vunit ex2a would be a collection of 2 assert
| directives, assert never (sig_a and sig_b) where, in the
| first directive, sig_a and sig_b respectively would refer to
| the signals instantiated in the port of ent bound to
| top_block.i1 and the second directive would be similar,
| except that sig_a and sig_b respectively would refer to the
| signals instantiated in the port of ent bound to top_block.i2.
|
| Note that the same thing is required for the approach you
| have been advocating, for instance in the following case (let
| ent2 be instantiated several times hierarchically below ent)
|
| vunit a (ent) {
| inherit b;
| }
|
| vunit b (ent2) {
| assert never sig_a;
| }
|
| You clearly cannot describe the instantiation of a as a vunit
| itself in VHDL.
|
| Cheers,
|
| Johan Alfredsson
| Jasper Design Automation
| www.jasper-da.com
|
| > Johan,
| >
| > This approach relies upon support for hierarchical pathnames that
| > refer to items in other modules ("out of module
| references", or OOMRs).
| > Although OOMRs are allowed in Verilog, they are not allowed
| in VHDL -
| > so how do you expect this to work in a VHDL context? Do
| you mean to
| > extend VHDL expressions used in the Boolean layer of a PSL
| directive
| > to allow such references? If so, how will you specify
| that, and where?
| >
| > Regards,
| >
| > Erich
| >
| > | -----Original Message-----
| > | From: owner-ieee-1850-extensions@eda.org
| > | [mailto:owner-ieee-1850-extensions@eda.org] On Behalf Of Johan
| > | Alfredsson
| > | Sent: Monday, January 24, 2005 10:16 AM
| > | To: ieee-1850-extensions@eda.org
| > | Subject: Verification unit bindings -- text change proposal
| > |
| > |
| > | Hi all,
| > |
| > | The following is a proposal how the LRM text ought to be
| > | changed/clarified concerning the semantics of verification unit
| > | bindings, specifically to take care of the ambiguity that 7.2.1
| > | talks about duplicating the contents of a verification unit while
| > | the second exampel (on p. 92) implies that not only the
| contents but
| > | also the verification unit itself is duplicated.
| > |
| > | Johan Alfredsson
| > | Jasper Design Automation
| > | www.jasper-da.com
| > |
| > | --------------------------------------------------------------
| > | ----------------
| > |
| > | Change proposal for 7.2.1
| > |
| > | p. 91
| > |
| > | Insert "Note that the verification unit itself is not
| duplicated."
| > | after "If the verification unit is explicitly bound to a module,
| > | then this is
| > | equivalent to duplicating the contents of the
| verification unit and
| > | binding each duplication to one instance."
| > |
| > |
| > | p. 92
| > |
| > | Change the second example (lines 4-20)into
| > |
| > | "As a second example consider
| > |
| > | vunit ex2a(mod1) {
| > | assert never (ena && enb);
| > | }
| > |
| > |
| > | The verification unit is bound to mod1. If this module is
| > | instantiated
| > | twice in the design, once as top_block.i1.i2 and once as
| > | top_block.i1.i3,
| > | then vunit ex2a is equivalent to the following vunit:
| > |
| > | vunit ex2b(top_block.i1) {
| > | assert never (i2.ena && i2.enb);
| > | assert never (i3.ena && i3.enb);
| > | }"
| > |
| > | --------------------------------------------------------------
| > | -----------------
| > |
| > |
| >
|
|
Received on Tue Jan 25 06:05:52 2005