jamal elhaitout Posted August 28, 2017 Report Share Posted August 28, 2017 Hi All , I am wondering what is the exact meaning of "testable" and "testConstraint" ip-xact fields ? how should UVM register model be generated for these fields? What we mean by an automated register test ? UVM built-in tests ? Thanks in advance! Best regards, Jamal Quote Link to comment Share on other sites More sharing options...
kock Posted August 28, 2017 Report Share Posted August 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
jamal elhaitout Posted August 28, 2017 Author Report Share Posted August 28, 2017 Hi Erwin , Many Thanks for your reply! Yes , I read this on IPXACT standard, but still not clear for me. What we mean by an automated register test exactly ? the UVM built-in register tests ? Or something like ipxact2test flow ? Best regards, Jamal Quote Link to comment Share on other sites More sharing options...
kock Posted August 28, 2017 Report Share Posted August 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
jamal elhaitout Posted August 28, 2017 Author Report Share Posted August 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
Richard Weber Posted August 28, 2017 Report Share Posted August 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
jamal elhaitout Posted August 29, 2017 Author Report Share Posted August 29, 2017 Hi Richard, Thanks a lot for your answer. This makes the subject a bit clear. Sure we will contribute to this requirement (we have some people involved in this standard). Best regards, Jamal Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.