Jump to content
Michael Tsurikov

Purpose of modifiedWriteValue = oneToSet?

Recommended Posts

IEEE Std 1685-2014 includes this:
 

Quote

 

modifiedWriteValue (optional) element to describe the manipulation of data written to a field. The value shall be one of oneToClear, oneToSet, oneToToggle, zeroToClear, zeroToSet, zeroToToggle, clear, set, or modify. If the modifiedWriteValue element is not specified, the value written to the field is the value stored in the field.

...

oneToSet means in a bitwise fashion each write data bit of a one shall set (set to one) the corresponding bit in the field.

 

 

I don't understand the purpose of oneToSet. It seems to describe the basic functionality that any read/write field should have, without any modifications.

In other words, when I receive this code from an IP vendor of mine:

Quote

            <spirit:name>FIELD</spirit:name>
            <spirit:description>...</spirit:description>
            <spirit:access>read-write</spirit:access>
            <spirit:modifiedWriteValue>oneToSet</spirit:modifiedWriteValue>

 

I don't understand how that is any different from simply this:

Quote

            <spirit:name>FIELD</spirit:name>
            <spirit:description>...</spirit:description>
            <spirit:access>read-write</spirit:access>

 

In both cases, when I write a 1 to this field, the field becomes 1.

Can someone clarify what purpose the oneToSet modifiedWriteValue serves?

Thank you.

Share this post


Link to post
Share on other sites

For all of the bitwise modifiedWrite functions (oneToClear, oneToSet, oneToToggle, zeroToClear, zeroToSet, zeroToToggle) the specified bit write value changes the target bit and the opposite bit write value leaves the target bit unchanged. This provides atomic write access to modify a single bit within a field within a single write transaction.  For fields with normal write behavior the write replaces the target field value with the write value.  This feature was inherited and expanded from Accellera SystemRDL 1.0 standard which at least has equations for the few bitwise write behaviors it supports. The IEEE 1800.2-2017 UVM standard inherited this feature from IP-XACT and has a slightly better description. We'll make sure that the next version of the standard specifies more completely the behavior of modifiedWrite.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×