Jump to content

weber

Members
  • Content count

    11
  • Joined

  • Last visited

About weber

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Palo Alto, CA, USA

Recent Profile Visitors

260 profile views
  1. Purpose of modifiedWriteValue = oneToSet?

    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.
  2. IP-XACT : "testable" and "testConstraint"

    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
  3. I would recommend using nested "registerfile" objects within an addressBlock to contain your registers since these can be multi-dimensional arrays. We added the registerfile object in IEEE 1685-2009. You can use "bank" objects to group addressBlock objects but arrays are not supported.
  4. validating xml files

    Hello iperryman, First, Annex I is informative and not normative. The schema namespace and location in the example should use 1685-2014 instead of 2.0. Consider this a bug in the document. I don't think the committee intended to release the 2.0 version of the schema. Regardless, 2.0 schema location doesn't work. Second, the schema location attribute itself is incorrect. Third, copying text out of a PDF file is not reliable. I had to fix the file I copying output document to get it to pass. Parsing and generating IP-XACT files is quite complex. Please consider commercially available solutions.
  5. Capturing register implementation information in IP-XACT XML

    Hello Balasubramanian, I am a contributing member of both the IP-XACT and SystemRDL committees. The committees are going in different directions with regard to the data model. IP-XACT documents the interfaces of a design, avoids behavior, and is a communication interchange format for EDA tools. SystemRDL is all about register hardware and software behavior, and, it is meant as a human design capture format. The currently active SystemRDL committee is in the process of attempting to add those features of IP-XACT 2009 which are not in SystemRDL 1.0 and other additional features. The IP-XACT committee is currently dormant waiting for the publication of the next standard by the IEEE. Also, the SystemRDL file would be encapsulated by a IP-XACT component. The IP-XACT meta data would only include the software interface description and the hardware behavior would be captured in the encapsulated SystemRDL file and the corresponding RTL implementation could also be in encapsulated Verilog or VHDL files. There is no need to duplicate the SystemRDL behavior information in IP-XACT meta data. The IP-XACT committee certainly does not have the resources to duplicate the efforts of other standards.
  6. Capturing register array information inside IPXACT XML

    Hello Balasubramanian, Many languages support multi-dimensional arrays of objects including System Verilog and IP-XACT. However, I was hoping that you would provide a reference to a standard or a programming language which specifies the offset layout of the array in memory and includes the multiple stride feature you are requesting. Our concern is that this multiple stride feature would not translate to the expected derived outputs of IP-XACT especially those for the software community. Also, IP-XACT is not an authoring format. You should be using a tool to generate the IP-XACT to resolve this issue. Using SystemRDL to generate IP-XACT is one such path, but, there are other richer formats and platforms commercially available.
  7. Capturing register array information inside IPXACT XML

    Hello Chris, IP-XACT is actually two committees. First, there is the Accellera IP-XACT committee. I believe participation is limited to Accellera members, but, check with the chair of the committee. Second, there is the IEEE P1685 committee which is entity based. Participation is limited to entity (company, university, government) members of the IEEE Standards Association. The next version of IP-XACT is worked on by the Accellera committee first and then the result is contributed to the IEEE P1685 committee for refinement and eventual publication. Once published by the IEEE P1685 committee, IP-XACT becomes an international standard. The next opportunity for technical participation will be when the Accellera IP-XACT schema subcommittee reconvenes, and, this will probably be at least year from when the standard is published depending on industry participation.
  8. Complex register description

    Hello Balasubramamian, The industry supports SystemRDL. The Semifore CSRCompiler is the reference platform for the Accellera SystemRDL 1.0 standard and has been supporting the various versions of SystemRDL since 2007. Semifore is a contributing member of the current active Accellera SystemRDL standards committee. FULL DISCLOSURE: I work for Semifore, Inc.
  9. Capturing register array information inside IPXACT XML

    Hello Balasubramanian, The word you are looking for is "stride". Stride is the offset distance between elements of an array. IP-XACT 1685-2009 does not have a stride feature. Due lack of participation and resources for the forthcoming IP-XACT version (hopefully 2014) the stride feature has been deferred until the committee reconvenes for the subsequent version. We look forward to your participation. In general an array is an indexed sequential collection of identical elements. Stride is one property which is assumed identical between array elements. The second example violates this assumption of consistent stride between elements. Which standards or programming languages inspire the second example? Best Regards Richard Weber Semifore, Inc.
  10. Complex register description

    I am a member of both the IP-XACT and SystemRDL committees. The committees are going in different directions with regard to the data model. IP-XACT documents the interfaces of a design, avoids behavior, and is a communication format for tools. SystemRDL is all about register hardware and software behavior, and, it is meant as a human design capture format. The SystemRDL committee is in the process of attempting to add those features of IP-XACT 2009 which are not in SystemRDL 1.0.
  11. Complex register description

    Hello Christian, The feature you are describing is register aliasing. The is not supported by IEEE 1685-2009. It is supported by Accellera SystemRDL 1.0 2009. I would recommend that you have the four registers containing the fields with the appropriate access and modifiedWriteValue. The fact that there is only one physical register is currently beyond IP-XACT. You can either make a note of this in the description or add vendor extensions to document the relationship.
×