kock

Members
  • Content count

    33
  • Joined

  • Last visited

Everything posted by kock

  1. 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
  2. Hi Eirik, Please send me an email (erwin.de.kock at nxp.com). Best regards, Erwin
  3. Hello Harsh, This is not a tool forum, but it seems that the IP-XACT XML file that you provide as argument is not valid because it does not contain a memoryMaps element. I cannot see the details because the attached XLSX file does not contain the XML file details. Best regards, Erwin
  4. Hi Tudor, The errata have been updated and your comments posted in this forum have been added. The new version is available at http://www.accellera.org/images/downloads/standards/ip-xact/IPXACT-2014-errata-2.pdf Thanks for your contributions, Erwin
  5. Hi Kenny, Yes, IEEE 1685-2014 supports RTL and TLM views in a single file. Please read this topic http://forums.accellera.org/topic/5070-views-in-a-componentmodel/ were the question was asked before. Best regards, Erwin
  6. Yes, indeed. People in the IP-XACT technical committee have noticed this too. We will add it to the errata: http://www.accellera.org/images/downloads/standards/ip-xact/IPXACT-2014-errata.pdf Thanks, Erwin
  7. Hello Gregoire, Thanks for addressing this topic. I think it is better to discuss it over the phone in a special interest meeting of the IP-XACT Technical Committee rather than have discussion in this forum. I will propose this in the next TC meeting. If we come to agreement then we can post the outcome here. Best regards, Erwin
  8. Hi, I am not sure to understand the problem but it seems that you need 4 views to describe all possible componentInstantiation/designConfigurationInstantiation pairs. Does that make sense? Erwin
  9. Hello Jorge, Yes it is possible to describe RTL and TLM within the same component using two different views. The motivation to have more than one view is that you can describe multiple implementations of an IP in the same IP-XACT component. The way to indicate if a port is present is a particular view is to use the wireTypeDefs (for wire ports) and transTypeDefs (for transactional ports). Each wireTypeDef and each transTypeDef contains zero or more viewRef elements. If there are zero viewRef elements then the type applies to all views (implying that the port is present is all views). If there are one or more viewRef elements then the type applies only to the views specified by the viewRef elements (implying that the port is not present in the views that are not specified). If a port does not have wireTypeDefs or transTypeDefs then the default type applies to all views (implying that the port is present in all views). I must admit that this is not very well described in the IEEE 1685-2014 document in Sections 6.12.9 and 6.12.19. Best regards, Erwin
  10. Hello Fred, Unfortunately there is no such document. Best regards, Erwin
  11. Hello Sachin, A designInstanceID is a handle to an instance of a design. As you mentioned, a designInstantiation has a designRef with configurable elements. The designRef and its configurable element values define an instance of the referenced design. You can get a handle to this design instance by apply the function getDesignInstantiationDesignInstanceID to the designInstantiation. You can apply the TGI function getUnconfiguredID on the retrieved designInstanceID to get the designID that matches with the designRef VLNV. Best regards, Erwin
  12. Hi Emna, I am not sure that I understand you. You speak of c++ objects. In IP-XACT you cannot make references to c++ objects. You can only reference files. Furthermore, you can specify the sc_module name in a view. You can also make multiple views. So in the example above, you can make two views: <spirit:views> <spirit:view> <spirit:name>TLM</spirit:name> <spirit:envIdentifier>*:*:*</spirit:envIdentifier> <spirit:language>systemc</spirit:language> <spirit:modelName>tlmip</spirit:modelName> <spirit:fileSetRef> <spirit:localName>TLM</spirit:localName> </spirit:fileSetRef> </spirit:view> <spirit:view> <spirit:name>TLM-AT</spirit:name> <spirit:envIdentifier>*:*:*</spirit:envIdentifier> <spirit:language>systemc</spirit:language> <spirit:modelName>tlmip_at</spirit:modelName> <spirit:fileSetRef> <spirit:localName>TLM-AT</spirit:localName> </spirit:fileSetRef> </spirit:view> </spirit:views> The view named TLM contains modelName tlmip meaning that the sc_module is named tlmip (defined in the file tlmip.cpp). The view named TLM-AT contains modelName tlmip_at meaning that the sc_module is named tlmip_at (for instance defined in another file tlmipat.cpp in an additional fileSet TLM-AT. When you have two instances of this component, let's say u0 and u1, you can choose the view for each instance in the IP-XACT design configuration XML file. E.g.: <spirit:viewConfiguration> <spirit:instanceName>u0</spirit:instanceName> <spirit:viewName>TLM</spirit:viewName> </spirit:viewConfiguration> <spirit:viewConfiguration> <spirit:instanceName>u1</spirit:instanceName> <spirit:viewName>TLM-AT</spirit:viewName> </spirit:viewConfiguration> This will tell your SystemC netlister that it needs to instantiate u0 as tlmip and u1 as tlmip_at. Also you can derive that you will need to compile both files tlmip.cpp and tlmipat.cpp. Best regards, Erwin
  13. Hi, In IP-XACT, you can reference a file that contains the c++ code. The XML file below defines a component tlmip which contains a view named TLM. That view references a fileSet named TLM. The two files in that fileSet are supposed to implement the TLM view. If you instantiate this component tlmip and you set the TLM view for that instance, then you can derive that you need to compile the tlmip.cpp file and that you need the include file tlmip.h for that. Best regards, Erwin <?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>nxp.com</spirit:vendor> <spirit:library>dp</spirit:library> <spirit:name>tlmip</spirit:name> <spirit:version>1.0</spirit:version> <spirit:busInterfaces> <spirit:busInterface> <spirit:name>TLM_Slave</spirit:name> <spirit:busType spirit:version="2011-1.0" spirit:name="TLM2GP" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:abstractionType spirit:version="2011-1.0" spirit:name="TLM2GP_tlm" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:slave> <spirit:memoryMapRef spirit:memoryMapRef="RegisterMap"/> </spirit:slave> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>socket</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> </spirit:busInterfaces> <spirit:memoryMaps> <spirit:memoryMap> <spirit:name>RegisterMap</spirit:name> <spirit:addressBlock> <spirit:name>Registers</spirit:name> <spirit:baseAddress spirit:resolve="immediate">0x0</spirit:baseAddress> <spirit:range spirit:resolve="immediate">0x400</spirit:range> <spirit:width spirit:resolve="immediate">32</spirit:width> <spirit:usage>register</spirit:usage> <spirit:access>read-write</spirit:access> </spirit:addressBlock> <spirit:addressUnitBits>8</spirit:addressUnitBits> </spirit:memoryMap> </spirit:memoryMaps> <spirit:model> <spirit:views> <spirit:view> <spirit:name>TLM</spirit:name> <spirit:envIdentifier>*:*:*</spirit:envIdentifier> <spirit:language>systemc</spirit:language> <spirit:modelName>tlmip</spirit:modelName> <spirit:fileSetRef> <spirit:localName>TLM</spirit:localName> </spirit:fileSetRef> </spirit:view> </spirit:views> <spirit:ports> <spirit:port> <spirit:name>socket</spirit:name> <spirit:transactional> <spirit:transTypeDef> <spirit:typeName>tlm::tlm_target_socket<32></spirit:typeName> <spirit:typeDefinition>tlm.h</spirit:typeDefinition> </spirit:transTypeDef> <spirit:service> <spirit:initiative>provides</spirit:initiative> <spirit:serviceTypeDefs> <spirit:serviceTypeDef> <spirit:typeName spirit:implicit="true">tlm_fw_transport_if</spirit:typeName> </spirit:serviceTypeDef> </spirit:serviceTypeDefs> </spirit:service> </spirit:transactional> </spirit:port> </spirit:ports> </spirit:model> <spirit:fileSets> <spirit:fileSet> <spirit:name>TLM</spirit:name> <spirit:file> <spirit:name>../SLMODEL/inc/tlmip.h</spirit:name> <spirit:fileType>systemCSource</spirit:fileType> <spirit:isIncludeFile spirit:externalDeclarations="true">true</spirit:isIncludeFile> <spirit:logicalName>tlmiplib</spirit:logicalName> </spirit:file> <spirit:file> <spirit:name>../SLMODEL/src/tlmip.cpp</spirit:name> <spirit:fileType>systemCSource</spirit:fileType> <spirit:logicalName>tlmiplib</spirit:logicalName> <spirit:dependency>../SLMODEL/inc</spirit:dependency> </spirit:file> </spirit:fileSet> </spirit:fileSets> </spirit:component>
  14. Hi Sachin, The directory structure in this document is as follows: data/<library>/<cell>/<view> where data is the root of your tree, <library> is placeholder for a collection of IPs (for instance matching with the library field in the IP-XACT VLNV), <cell> is the name of your IP (this name must be unique in your company), <view> is the name of a view (directory) of that IP that contains the implementation of that view An example for a soft IP named my_ip: data/my_lib/my_ip/RTL/my_ip.v /DOCUMENTS/my_ip.pdf /METADATA/my_ip.xml The METADATA view is the location for an IP-XACT XML file. The file my_ip.xml can contain a view named RTL referencing a fileSet named RTL. The fileSet RTL can contain a file named ../RTL/my_ip.v. This verilog file would implement the module my_ip. You can think of many other views such as NETLIST for gate-level netlist and LAYOUT for gdsii. If you would replace the prefix "my" by a unique prefix for each team in your organization, then all IP would be unique and in a unique location. Best regards, Erwin
  15. Hi Sachin, There is no way to define environment variables locally to components. You need to organize that yourself outside of IP-XACT. You may derive the names of your environment variables from the IP-XACT VLNV identifier. For instance, rather than using MY_VAR you could use <Vendor>_<Library>_<Name>_<Version>. Since the VLNV is unique, also your environment variables are unique. However, I think a better approach is to organize your directory structure such that each team in your organization works in its own sub-tree of this directory structure. Also the common files should have one location in this directory structure. An example of such a structure is the CoReUse directory structure. In this way all your paths can be relative. Best regards, Erwin
  16. Hello Sachin, In an IP-XACT file element you can use either a relative path or a path using an environment variable. For instance ${MY_VAR}/my_common_lib/my_common_file.v. In this way, the file path is independent of the location of the IP-XACT component xml file containing this file element. Best regards, Erwin
  17. Hello Olof, Let me comment on your issues. Ad 1) There is no central registery for bus definitions. The idea is that protocol owner publish there own bus definitions. The Accellera IP-XACT Working Group has created some bus definitions that will be published shortly on the Accellera web page. These bus definitions are promoted as best practices. They include SPI, I2C, TLMGP, and JTAG. SDRAM is not part of it yet. Ad 2) You can use the bus and abstraction definition extends mechanism to make variants of buses. This makes sense for adding signals if it is allowed to connect different versions of bus interfaces (e.g. if it is possible to connect a b2 bus interface to a b3 bus interface. If that is not allowed then I suggest to make different bus definitions (i.e. in which the version element value differs). In order to handle different numbers of bits in a bus, you can also leave out the width of the logical port in the onMaster and onSlave element in an abstraction definition. If you do not specify a width, then you can map any number of bits on that logical port in a bus interface port map. Ad 3) In IP-XACT IEEE 1685-2009 the bus definitions are not parameterizable. In the new revision IEEE 1685-2014, they are parameterizable. To handle address width and data width in 1685-2009, I advice you to omit the width elements in the abstraction definitions. Best regards, Erwin
  18. Hi Steven, In addition to alternateRegisters, you may also use memoryRemap and remapStates. Each remapState corresponds to a mode. For each remapState, you can define a memoryRemap. Best regards, Erwin
  19. Hi Venkatesh, Sorry for my late reply. I recommend to avoid mirrored interfaces such that you can use bridges rather than channels. Please use slave instead of mirrored master and master instead of mirrored slave. Below are some fragments for a TLM bus. Here is slave interface (target socket). In this case it bridges to all master interfaces but in general it does not have to be connected fully. You can have multiple slave interfaces of course. <spirit:busInterface> <spirit:name>target_socket_0</spirit:name> <spirit:busType spirit:version="2011-1.0" spirit:name="TLM2GP" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:abstractionType spirit:version="2011-1.0" spirit:name="TLM2GP_tlm" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:slave> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_0"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_1"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_2"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_3"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_4"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_5"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_6"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_7"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_8"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_9"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_10"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_11"/> <spirit:bridge spirit:opaque="false" spirit:masterRef="initiator_socket_12"/> </spirit:slave> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>target_socket_0</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> Here are the first two master interfaces (initiator sockets). Each master interfaces references to an address space. For each address space you provide the base address (which is an offset to the lowest incoming address). <spirit:busInterface> <spirit:name>initiator_socket_0</spirit:name> <spirit:busType spirit:version="2011-1.0" spirit:name="TLM2GP" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:abstractionType spirit:version="2011-1.0" spirit:name="TLM2GP_tlm" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:master> <spirit:addressSpaceRef spirit:addressSpaceRef="AS_0"> <spirit:baseAddress>0x0</spirit:baseAddress> </spirit:addressSpaceRef> </spirit:master> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>initiator_socket_0</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> <spirit:busInterface> <spirit:name>initiator_socket_1</spirit:name> <spirit:busType spirit:version="2011-1.0" spirit:name="TLM2GP" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:abstractionType spirit:version="2011-1.0" spirit:name="TLM2GP_tlm" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:master> <spirit:addressSpaceRef spirit:addressSpaceRef="AS_1"> <spirit:baseAddress>0x20000000</spirit:baseAddress> </spirit:addressSpaceRef> </spirit:master> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>initiator_socket_1</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> Here are the two referenced address spaces. They can have different ranges of course. <spirit:addressSpace> <spirit:name>AS_0</spirit:name> <spirit:range>0x20000000</spirit:range> <spirit:width>32</spirit:width> </spirit:addressSpace> <spirit:addressSpace> <spirit:name>AS_1</spirit:name> <spirit:range>0x20000000</spirit:range> <spirit:width>32</spirit:width> </spirit:addressSpace> You can now connect slaves (memories, peripherals) to the master interfaces of the bus. Here is an example of a ROM. <spirit:busInterfaces> <spirit:busInterface> <spirit:name>target_socket</spirit:name> <spirit:busType spirit:library="ieee1666" spirit:name="TLM2GP" spirit:vendor="accellera.org" spirit:version="2011-1.0"/> <spirit:abstractionType spirit:library="ieee1666" spirit:name="TLM2GP_tlm" spirit:vendor="accellera.org" spirit:version="2011-1.0"/> <spirit:slave> <spirit:memoryMapRef spirit:memoryMapRef="MemoryMap"/> </spirit:slave> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>socket</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> </spirit:busInterfaces> <spirit:memoryMaps> <spirit:memoryMap> <spirit:name>MemoryMap</spirit:name> <spirit:addressBlock> <spirit:name>ROM</spirit:name> <spirit:baseAddress>0x0</spirit:baseAddress> <spirit:range spirit:dependency="id('Size')" spirit:resolve="dependent">0x20000000</spirit:range> <spirit:width>32</spirit:width> <spirit:usage>memory</spirit:usage> <spirit:access>read-only</spirit:access> </spirit:addressBlock> </spirit:memoryMap> </spirit:memoryMaps> Similary, you can connect masters to the slave interfaces of the bus. Here is an example of a master. <spirit:busInterfaces> <spirit:busInterface> <spirit:name>initiator_socket</spirit:name> <spirit:busType spirit:library="ieee1666" spirit:name="TLM2GP" spirit:vendor="accellera.org" spirit:version="2011-1.0"/> <spirit:abstractionType spirit:library="ieee1666" spirit:name="TLM2GP_tlm" spirit:vendor="accellera.org" spirit:version="2011-1.0"/> <spirit:master> <spirit:addressSpaceRef spirit:addressSpaceRef="AS"> <spirit:baseAddress>0x0</spirit:baseAddress> </spirit:addressSpaceRef> </spirit:master> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>socket</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> </spirit:busInterfaces> <spirit:addressSpaces> <spirit:addressSpace> <spirit:name>AS</spirit:name> <spirit:range>0xE0000000</spirit:range> <spirit:width>32</spirit:width> </spirit:addressSpace> </spirit:addressSpaces> Best regards, Erwin
  20. Hello Venkatesh, Ad 1). The base address in an address block inside a memory map is an offset that is relative to the incoming address of the slave bus interface that references that memory map. So if you instantiate the slave module multiple times and connect the instances to a bus, then all slave instances will a different offset automatically depending on the addressing of that bus. There is no need to specify an (absolute) offset in a design. Having said that, it is not impossible since you can make the base address user resolved and set the configurable element value in the design. Ad 2). It is not possible to describe a parameterized number of bus interfaces. Hence, you need to make a different IP-XACT component for each bus configuration allowing you to connect N masters and M slaves. Of course, you can instantiate such a component multiple times. There is no need for separate busdef and absdef. Each of the master bus interfaces on your IP-XACT bus requires a reference to an address space in that component and a base address. These base addresses and address spaces links to ad 1) because they specify the bus addressing, i.e., the address space for each connected slave. Again the bus addressing is relative. Best regards, Erwin
  21. Hello RahuIJn. In IP-XACT there are wire ports and transactional ports. The element direction with values in, out, inout, and phantom is used for wire ports. The element initiative with values provides, requires, both, and phantom is used for transactional ports. A transactional port has initiative provides if the transactional port provides (implements) a service (method) that can be called by another port. A transactional port has initiative requires if the transactional ports requires (calls) a service (method) that is implemented by another port. Initiative both means that the transactional port implements and calls methods. If your bidirectional port is a standard TLM2 socket then you do not need to model this as a bidirectional port. We have the following style for that (for a target socket): <spirit:busInterface> <spirit:name>RegisterIF</spirit:name> <spirit:busType spirit:version="2011-1.0" spirit:name="TLM2GP" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:abstractionType spirit:version="2011-1.0" spirit:name="TLM2GP_tlm" spirit:library="ieee1666" spirit:vendor="accellera.org"/> <spirit:slave> <spirit:memoryMapRef spirit:memoryMapRef="RegisterMap"/> </spirit:slave> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>TLMSOCKET</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>socket</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> </spirit:busInterface> <spirit:port> <spirit:name>socket</spirit:name> <spirit:transactional> <spirit:transTypeDef> <spirit:typeName>tlm::tlm_target_socket<32></spirit:typeName> <spirit:typeDefinition>tlm.h</spirit:typeDefinition> </spirit:transTypeDef> <spirit:service> <spirit:initiative>provides</spirit:initiative> <spirit:serviceTypeDefs> <spirit:serviceTypeDef> <spirit:typeName spirit:implicit="true">tlm_fw_transport_if</spirit:typeName> </spirit:serviceTypeDef> </spirit:serviceTypeDefs> </spirit:service> </spirit:transactional> <spirit:access/> </spirit:port> An initiator socket is similar with initiative requires. Best regards, Erwin
  22. Hello Steven, The term "System Mode" in relation to register is not an IP-XACT term. Rather System Mode is a bus interface mode in IP-XACT. So this is a little bit confusing. I believe the IP-XACT mechanism that you are looking for is alternate registers. This allows you to define multiple registers at the same address, each with its own properties. I must admit that I have no experience in using it. Best regards, Erwin
  23. Hello Bernd, Thank you. We will update the link with the new download. Meanwhile you can download the 2014 revision via http://www.accellera.org/downloads/ieee/ Best regards, Erwin
  24. Hi Brahim, Yes, the hierarchicalRef can reference a design configuration. Best regards, Erwin
  25. Hello Norbert, I will take an action point in the Accellera IP-XACT Working Group to see if we can post the XSL transforms on the Accellera website. Also I already upconverted the busdefs that you mentioned to 1685-2009. I will also see if we can make those available on the website. Best regards, Erwin