Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


kock last won the day on September 29 2015

kock had the most liked content!

About kock

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

638 profile views
  1. Hello, Sorry for replying this late. The rational is that the global memory map is computed from the design connectivity. The components should be reusable. For instance, if you swap bus components with different addressing, then the cpu component should not be affected. Hence, the global memory map is not described in the cpu component. De cpu component only describe its addressable space and not what is all mapped into this space. Furthermore, the global memory map is independent of IP-XACT design configurations (unless the design configurations configure different hierarchical views). The design connectivity is described in IP-XACT designs. What you can describe, is that you have multiple hierarchical views in a component. These hierarchical views can reference different designs. However, the IP-XACT semantic consistency rules (SCR 11.3) state that the global memory maps for each bus interface in an hierarchy of bus interfaces must be equal. So you can describe the scenario mentioned in your email as long as the bus interfaces of the top component adhere to this rule. Best regards, Erwin
  2. Validating IPXact

    Hello Sunil, Perhaps you can have a look at the tool list at https://en.wikipedia.org/wiki/IP-XACT. Personally I do not have experience with open source tools supporting IP-XACT. Best regards, Erwin
  3. inclusion of busDefinition in Component

    Hello Ritu, You cannot specify paths in IP-XACT XML files. The referencing is done through VLNV identifiers. The VLNV reference in a busType in a component bus interface must match with the VLNV identifier of a bus definition. How you load these two XML files in a tool is outside of the standard and is tool specific. I do not know which tool you are using but it should not matter where the IP-XACT XML files are located on your file system. Best regards, Erwin
  4. buildCommand for c/c++ object file

    Hi Justin, It is not possible to describe multiple build commands to support cmd1 and cmd1. Command cmd1 will probably generate an intermediate file that is used for command cmd2. I think you have add this intermediate file to the file set and move cmd2 to the build command for that file. For the 2nd question, all header files should be listed explicitly in the file set with isIncludeFile set to true. The dependency must be added to the files that include those files or to the whole file set. Best regards, Erwin
  5. buildCommand for c/c++ object file

    Hello Justin, The flags element should not contain the whole command; it should contain the flags only. Also you miss a dependency on hello.cpp for hello.o. I would suggest to describe it like this: <ipxact:fileSet> <ipxact:name>fs-sw</ipxact:name> <ipxact:file> <ipxact:name>hello.cpp</ipxact:name> <ipxact:fileType>cppSource</ipxact:fileType> </ipxact:file> <ipxact:file> <ipxact:name>hello.o</ipxact:name> <ipxact:fileType>swObject</ipxact:fileType> <ipxact:buildCommand> <ipxact:command>g++</ipxact:command> <ipxact:targetName>hello.o</ipxact:targetName> </ipxact:buildCommand> <ipxact:dependency>hello.cpp</ipxact:dependency> </ipxact:file> <ipxact:file> <ipxact:name>hello.so</ipxact:name> <ipxact:fileType>swObjectLibrary</ipxact:fileType> <ipxact:buildCommand> <ipxact:command>g++</ipxact:command> <ipxact:flags>-shared -fPIC</ipxact:flags> <ipxact:targetName>hello.so</ipxact:targetName> </ipxact:buildCommand> <ipxact:dependency>hello.o</ipxact:dependency> </ipxact:file> </ipxact:fileSet> Best regards, Erwin
  6. Purpose of modifiedWriteValue = oneToSet?

    Hi Michael, My understand is that oneToSet also means that writing a 0 has no effect. Best regards, Erwin
  7. IP-XACT : "testable" and "testConstraint"

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

    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
  9. Hello Justin, Yes, this is the way it should be done. Best regards, Erwin
  10. Duplicated schema tags

    Hello, In case of viewRef, it may be that the different definitions can be factored out into a single definition. I agree with you that it would have been cleaner to have a single definition rather than duplicating the same definition multiple times. However, for accessHandles and ports there are really different definitions. A port in an abstractionDefinition is different from a port in a component. Hence, your translation to Python classes should include some use of scopes or namespaces. Best regards, Erwin
  11. Hi Justin, Sorry for my delayed response. The IP-XACT IEEE 1685-2014 contains Semantic Consistency Rule 1.2 (anyVLNVRefMustExist): Any VLNV in an IP-XACT document used to reference another IP-XACT document shall precisely match the identifying VLNV of an existing IP-XACT document. In the schema, such references always use the attribute group versionedIdentifier. So the standard defines that the component XML files of your sub-modules must exist if your instantiate them in a design. If you are only interested in managing the VLNVs, you can also consider using an IP-XACT catalog (new in IEEE 1685-2014). Best regards, Erwin
  12. Hello Justin, I do not know of freely available TGI implementations. There are commercial implementations available from IP-XACT EDA vendors. Best regards, Erwin
  13. Hi Justin, A design describes the instances and configuration of the sub-IPs and their interconnect. As you mention, these sub-IPs need to be described in IP-XACT. So this is not an appropriate way to handle sub-IPs not described in IP-XACT. I think the answer to your question depends on what you mean with "track". If you just want to track files of sub-IPs you can describe them in file sets of IP_A. Or you can describe sub-IPs in XML containing file sets only. So you can explain your goal a bit more? Thanks, Erwin
  14. Hi Ashwin, The Accellera standardization committee does not have a published guideline for this. Please check with your IP-XACT EDA vendor for a dedicated solution. Best regards, Erwin
  15. Hello Kenny, Indeed you found an inconsistency. The clockInterfaceRef and resetInterfaceRef are not part of the schema. The text should also be removed from the specification document. If you do not want to connect clock and reset ports using the addressable bus interface you can use the isInformative element in the portMap element. This allows you to make clock and reset ports part of the portMaps to get a reference for the other ports without physically connecting them through this interface. The clock and reset port itself can be mapped again in other dedicated clock and reset bus interface in order to create the physical connections. Best regards, Erwin