Jump to content

IP-XACT : "testable" and "testConstraint"


jamal elhaitout

Recommended Posts

Hi Jamal,
The IEEE 1685-2014 standard says:

testable (optional; type: boolean) defines if the field is testable by a simple automated register test. If this is not present, testable is presumed to be true.

testConstraint (optional; type: string; default: unConstrained) attribute defines the constraint for the field during a simple automated register test. unConstrained indicates there are no restrictions on the data that may be written or read from the field. restore indicates the field’s value shall be restored to the original value before accessing another register. writeAsRead indicates the field shall be written only to a alue just previously read from the field. readOnly indicates the field shall be only read.

Not sure if this is what you are looking for. You can download the standard through the Accellera website.
best regards,
Erwin

Link to comment
Share on other sites

Hello Jamal,

The term simple automated register test is not defined in the standard. I agree with you that it should have been defined. Currently, it is open for different interpretations but in the context of IP-XACT I would say that a field is testable if and only if its IP-XACT metadata contains sufficient information to automatically generate tests for it that prove or disprove the correctness of that field metadata if you would apply those tests on a register implementation. However, this is just my own interpretation. I do not know to what extend the UVM built-in register test adhere to this interpretation assuming you generate the UVM register model from the IP-XACT register description.

Best regards,
Erwin

 

Link to comment
Share on other sites

Hi Erwin ,

Thanks a lot for your answer.

This is exactly the ambiguity I have : Me as a developer I don't know what to generate(in UVM model) exactly when this field is true/false.

Actually UVM provides some built-in tests (register access, reset test , bit bash test, ...), and provides some variables (i.e NO_REG_TESTS) to disable these tests for a given register.

So my interpretation was to use "testable" field to disable these UVM tests, but I still have some doubts it is not the good interpretation.

I am wondering if this ipxact field is related also to other things like coverage, backdoor , ...

 

 

Best regards

Jamal

 

Link to comment
Share on other sites

Hello Jamal,

First, IP-XACT 1685-2009 was published before the UVM register abstraction layer was created and published by the UVM committee. There was no effort to bring the concepts into alignment, and, the IP-XACT testable and test constraint are independent from the UVM register abstraction layer. There are many kinds of tests and testing environments, and, the IP-XACT committee has left the interpretation of these properties undefined. I voted to not include these properties because of this ambiguity. Perhaps the next version of IP-XACT can incorporate the UVM resources for controlling the UVM built-in tests so that at least these two IEEE standards can work together better.  Be sure to have your company's representative add your specific requirements to the list when the committee is gathering requirements for the next standard.

 

           Best regards,

                        Rich

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...