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

884 profile views
  1. kock

    IPXACT for Registers alone for UVM RAL

    Hello Saravan, There are two options. 1. You create a single IP-XACT component that contains a memory map describing your whole system. So the address block base address + register offset represents the absolute base address of the register in your memory map. There is no need to describe bus interfaces is this approach. However, your IP-XACT component is not re-usable; it is a dedicated description of your current system. 2. Your create an IP-XACT component for each individual IP describing the registers for that IP. These IP-XACT components also need a bus interface referencing the component memory map. In these descriptions, the address block base address + register offset represents the base address offset of the register relative to the base address of an instance of such a component. Next, you create an IP-XACT design in which you instantiate your IP-XACT components. In addition you need to create IP-XACT components for (possible dummy) CPU and bus. You encode the system memory map using address spaces and bridges in the bus. The CPU holds the global address space. You connect all bus interfaces like this: CPU instance master interface -> BUS instance slave interface BUS instance master interface 1 -> IPx instance slave interface BUS instance master interface 2 -> IPy instance slave interface BUS instance master interface 3 -> IPz instance slave interface ... Based on this design topology it is possible to compute the system memory map. This is typically supported by an IP-XACT Design Environment. All IP instance registers are mapped in the address space of the CPU using the addressing of the BUS. The result could be written out as a single IP-XACT component as described in Option 1. However, that result could also be written out as a UVM register model. The advantage of Option 2 is that your IP-XACT component register descriptions of your IPs are reusable. The only thing you need to change between your current system and your next system is the BUS component (different #number of slave interfaces and different addressing) and the IP-XACT design instantiating the relevant IPs. Please note that Option 2 is a simplistic representation of your system only for the purpose of describing the system memory map. However, you can refine this into an IP-XACT design hierarchy that represents the physical connectivity to capture the physical connectivity (wiring) as well as the logical connectivity (memory map) in a single IP-XACT design hierarchy (and hence single data model). Also note that you can apply Option 2 without creating the IP-XACT design and IP-XACT components CPU and BUS if you write the top-level UVM block manually which instantiates the generated IP UVM register models with the correct base addresses. Best regards, Erwin
  2. kock

    Portable Stimulus vs IP-XACT

    Hello Jamal, There is no compatibility or other relation between Portable Stimulus and IP-XACT. One could think of using IP-XACT register descriptions to describe register sequences. This would be a flow on top of both standards. Best regards, Erwin
  3. Hi, Here is an example: Verilog module: module my_module(my_port); parameter my_parameter = 12; input wire [my_parameter:0] my_port; endmodule And the a corresponding IP-XACT 2009 description: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <spirit:component xmlns:spirit="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009 http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009/index.xsd"> <spirit:vendor>Vendor</spirit:vendor> <spirit:library>Library</spirit:library> <spirit:name>my_module</spirit:name> <spirit:version>1.0</spirit:version> <spirit:model> <spirit:views> <spirit:view> <spirit:name>import</spirit:name> <spirit:envIdentifier>::</spirit:envIdentifier> <spirit:language>verilog</spirit:language> <spirit:modelName>my_module</spirit:modelName> <spirit:fileSetRef> <spirit:localName>VerilogSource</spirit:localName> </spirit:fileSetRef> </spirit:view> </spirit:views> <spirit:ports> <spirit:port> <spirit:name>my_port</spirit:name> <spirit:wire> <spirit:direction>in</spirit:direction> <spirit:vector> <spirit:left spirit:resolve="dependent" spirit:id="my_port_LEFT_id" spirit:dependency="id('my_parameter')">12</spirit:left> <spirit:right>0</spirit:right> </spirit:vector> </spirit:wire> </spirit:port> </spirit:ports> <spirit:modelParameters> <spirit:modelParameter> <spirit:name>my_parameter</spirit:name> <spirit:value spirit:format="long" spirit:resolve="user" spirit:id="my_parameter">12</spirit:value> </spirit:modelParameter> </spirit:modelParameters> </spirit:model> <spirit:fileSets> <spirit:fileSet> <spirit:name>VerilogSource</spirit:name> <spirit:file> <spirit:name>my_module.v</spirit:name> <spirit:fileType>verilogSource</spirit:fileType> </spirit:file> </spirit:fileSet> </spirit:fileSets> </spirit:component> The attribute value in spirit:dependency="id('my_parameter')" is an XPATH expression in terms of the modelParameter. The evaluated value of this expression determines the actual value of left value of the port. The given value 12 is a default value similar to the default value in the Verilog module. In this way, you can describe all your Verilog parameters as IP-XACT component parameters or modelParameters. You need to translate the Verilog expressions that calculate the port width to XPATH expressions in IP-XACT 2009. As mentioned, this is not needed anymore in IP-XACT 2014. Best regards, Erwin
  4. Hello, ad 1) The Verilog module parameters should be described as modelParameters in IP-XACT 2009. In IP-XACT 2014, modelParameters are renamed into moduleParameters located in componentInstantiation. ad 2) Variable width ports can be described in IP-XACT 2009 and 2014. In IP-XACT 2009, the left and right values of port vector are described in XPATH expressions. In IP-XACT 2014, the expression language has been changed to SystemVerilog. You can express left and right values as SystemVerilog expression in the component parameters. You should also make the Verilog moduleParameters in the componentInstantiations expressions in terms of component parameters because it is not allowed to use componentInstantiation specific parameters outside of the componentInstantiation scope (in this case left and right). If you apply the XST transform on an IP-XACT 2009 component with modelParameters to generate the IP-XACT 2014 version of that component, you will see how component parameters are used set moduleParameters. Best regards, Erwin
  5. Hello, A global system memory map can be computed. The component for which a global memory map is computed should have a master bus interface referencing an address space. The global memory map will then be computed in the address space by locating the peripheral component memory maps in that address space. The set of reachable peripherals is determined by interconnections between bus interfaces of component instances and the internal component bridges and channels. The addresses as seen by the master component are calculated along the paths from peripheral component instances to master component instances. Perhaps it helps to read the IP-XACT user guide available via http://www.accellera.org/images/downloads/standards/ip-xact/IP-XACT_User_Guide_2018-02-16.pdf The computed global memory map can be written out as a single IP-XACT component memory map. This is typically an automated process and not done manually indeed. Best regards, Erwin
  6. 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
  7. kock

    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
  8. kock

    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
  9. kock

    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
  10. kock

    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
  11. kock

    Purpose of modifiedWriteValue = oneToSet?

    Hi Michael, My understand is that oneToSet also means that writing a 0 has no effect. Best regards, Erwin
  12. kock

    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
  13. kock

    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
  14. Hello Justin, Yes, this is the way it should be done. Best regards, Erwin
  15. kock

    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