Jump to content


  • Content Count

  • Joined

  • Last visited

About weber

  • Rank

Profile Information

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

Recent Profile Visitors

832 profile views
  1. Hello Ankit, The active alternate register in the component implementation is selected by an alternateGroup. An alternateGroup is considered actively selecting an alternateRegisters due to an unspecified combination of port values, register values, memory values, or other component internal state values which can change value while the component implementation is running. An alternateGroup does not change the component implementation. Both scenarios you mention could be supported by the IP-XACT alternateRegister feature. Some examples: 1. The alternateGroup activation combination includes a component port value which can be tied to a constant in the component instantiation. 2. The alternateGroup activation combination includes a field value.
  2. Hello UshaKumi, It would be better to describe the register bit positions without a field specification to be "unspecified" instead of "reserved". The word "reserved" does not have a specific agreed meaning in the industry, and, the register bit positions without a field specification could have many different software behaviors or hardware implementations. Also, these bit position could be actual fields which the IP provider has chosen exclude from the IP-XACT file. If your tool flow requires that every bit in a register be associated with a field you can always ask the IP file provider if they could generate an IP-XACT file with all the register bits associated with fields. The IP provider probably has more information about the design to fill in the register with appropriate field specifications.
  3. Hello hbhatia, The first line is the XML declaration and not the IP-XACT declaration. The file is XML version 1.0 and encoded with the ISO-8859-1 character encoding. The version of IP-XACT would be in the namespace declaration on the first XML tag which may be preceded by comments. The following example has the namespace declaration corresponding to IEEE 1685-2014 IP-XACT on the ipxact:component tag on the last line: <?xml version="1.0" encoding="UTF-8" ?> <!-- --> <!-- Generated by Semifore, Inc. csrCompile --> <!-- Version: 2017.09 Build: 336 Windows 64-bit --> <!-- IEEE 1685-2014 IP-XACT XML output --> <!-- --> <ipxact:component xmlns:ipxact="http://www.accellera.org/XMLSchema/IPXACT/1685-2014"> IP-XACT files for register information would contain XML tags like "<ipxact:component>" or "<spirit:memoryMap>". However, the first XML tag in your file is "<map>". This tag is not in the IP-XACT schema. It is unlikely that your file is an IP-XACT file. Perhaps the file name gives a clue to what schema the file is using. Otherwise, request an IP-XACT file for the register information.
  4. 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.
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  • Create New...