I am describing IP-XACT definition for a DUT. The DUT has several registers that clear on read (example, interrupt status).
I see that IP-XACT does not provide any option to capture this type of register.
How is this to be handled?
In reply to chr_sue:
In reply to verif_learner:
Which tool you are using? IP-XACT is only a data format.
chr_sue, IP-XACT schema standardizes many attributes of a register, among many other things like bus interface etc. One of the element in the IP-XACT register definition is “access”.
From IP-XACT user guide -
Finally, an addressBlock can have an access element and multiple register
and registerFile elements. An access element can take the values read-write, read-only, write-only, readwriteOnce, and writeOnce
As you can see, IP-XACT does not support clear on read type. I posted this to check if there is something in IP-XACT I am missing, example some additional attribute, because clear on read is such a common register property I have come across.
In reply to verif_learner:
The IP-XACT Standard under preparation does not have readwriteOnce etc.
But it is still only a data format and it does not itself create a UVM register model.
Cadence uses this format for the register description for the UVM RAL. And for sure they do not only support the 3 access tpes defined in the IP-XACT spec.
In reply to chr_sue:
In reply to verif_learner:
The IP-XACT Standard under preparation does not have readwriteOnce etc.
But it is still only a data format and it does not itself create a UVM register model.
Cadence uses this format for the register description for the UVM RAL. And for sure they do not only support the 3 access tpes defined in the IP-XACT spec.
ok. some confusion here. let me try to clarify.
RTL is already available and it is not based on IP-XACT. It does support features like clear on read. I cant do the same thing because IP-XACT has no way to specify this. So, my RAL model will be out of sync with RTL register model.
Please note that, IP-XACT is not just a data format. It is a specification.
So, unless it has a way to specify a feature, the downstream vendors cannot implement it.
I hope I have clarified my point …
In reply to verif_learner:
Who forces you to employ the IP-XACT while having RAL code generators provided by the big 3 EDA providers?
In reply to chr_sue:
In reply to verif_learner:
Who forces you to employ the IP-XACT while having RAL code generators provided by the big 3 EDA providers?
No one is forcing. I want to use it because it is an accepted industry standard. What vendors provide additionally (they accept IP-XACT too) is not industry standard and is proprietary. So, it is unlikely I can share it to a wider audience that may or may not use the vendor specific format I use.
In reply to verif_learner:
In reply to chr_sue:
No one is forcing. I want to use it because it is an accepted industry standard. What vendors provide additionally (they accept IP-XACT too) is not industry standard and is proprietary. So, it is unlikely I can share it to a wider audience that may or may not use the vendor specific format I use.
Normally vendors support their extensions (you can look for vendor extensions on the IP-XACT standard), these extensions can be used to define whatever is required for creating such registers, so probably you can check on your vendor to see if they support such feature (if you are using any automated tool), additionally, if you cannot have such extensions you could add register field callbacks to model the desired behaviour you can have a look to the following paper and several forum entries in this site.
HTH,
-R