Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by kock

  1. Hi Kushi, The additional system interfaces allow you to make (clock, reset, sideband) connections in addition to the master/slave connections. So you can separately handle your clock/reset/sideband connectivity. The system group names are not relevant for netlisting. They provide additional checking capabilities in IP-XACT. Best regards, Erwin
  2. Hi Kushi, As I mentioned earlier ( https://forums.accellera.org/topic/6446-interface-mode-mirroredmaster-mirroredslave/ ) my advice is to map clock and reset signals in interfaces. However, this is an advice. Other ways of working are to handle clock and reset with adhoc connections or dedicated clock and reset bus interfaces. The IP-XACT standard does not enforce a particular way of working. The official AMBA bus definitions contain clock and reset in master and slave interfaces. They are optional to allow people to decide for themselves whether they want to map clock and reset in those interfaces. In my environment, we choose to make those signals required because we want to enforce a certain way of working. Best regards, Erwin
  3. Hi Kushi, Clock and reset have direction in because that is the direction from the protocol point of view. Clock and reset signals are generated by clock and reset generators. If you map clock and reset in your master and slave bus interfaces, you need to drive the clock and reset signals. You can do this by inserting a so-called phantom component on the interconnection. A phantom component is a component that only has phantom ports (ports with direction phantom). Here is an example with clock only: Component A with input port clk mapped in AMBA master bus interface m Component B with input port clk mapped in AMBA slave bus interface s Design with instance a of component A and instance b of component B and interconnection from a.m to b.s If you netlist the design you will a get a net between a.clk and b.clk but this net is not driven since both ends of the net are inputs. Now lets assume you also have Component C (clock generator) with output port clk mapped in CLOCK master bus interface clock. As integrator, you can now make an integration specific phantom component and change the design as follows: Component I with phantom port clk that is mapped in three three bus interfaces CLOCK slave bus interface clock AMBA slave bus interface s AMBA master bus interface m Design as before with the interconnection and additional instance c of Component C and instance i of Component I and interconnections a.m to i.s i.m to b.s c.clock to i.clock If you now netlist this design you will get a net between c.clk (driver) and a.clk and b.clk. Instance i will not appear in the netlist as a module instance since it only has phantom ports. In my opinion, the use of a phantom component is the cleanest way to do this. Alternative ways are to connect c.clk via an adhoc connection to a.clk and/or b.clk, or to add additional clock slave interfaces to A or B such that you can connect c.clock to those interfaces. However, you then add additional interfaces only for integration purposes. There is an example in the user guide ( https://accellera.org/images/downloads/standards/ip-xact/IP-XACT_User_Guide_2018-02-16.pdf ) of a phantom component for I2S. You can make similar components for AMBA protocols and other Serial protocols. Best regards, Erwin
  4. Hi Kushi, A system bus interface must be connected to a mirrored system bus interface. Sometimes, system interfaces are used to connect clock and reset signals or side-band signals. An EDA tool behaves the same for system interfaces as for master/slave interfaces. It maps component ports onto logical ports, wires the logical port bits, and infers from that which ports from which component instances need to be wired in a generated netlist. There is no addressing associated with system interfaces. Personally, I do no use system interfaces. In my opinion, the better approach is to map clock and reset in master and slave interfaces. This allows the use of abstractors to bridge between RTL and TLM descriptions. Clock and reset are needed at the RTL side but they are abstracted at the TLM side. This is not possible with system interfaces. In general, to enable IP re-use, i.e. in IP-XACT terms to enable IP-XACT component reuse, an IP-XACT component shall not have bus interfaces specifically tailored to way the IP-XACT component is integrated in its context. I think this is a good way of thinking while creating IP-XACT components. Best regards, Erwin
  5. Hi Kushi, In an abstraction definition, you can describe the properties of logical ports for master, slave, and system interface. For wire ports, the properties are presence, width, and direction. In a bus interface, the component ports mapped onto the logical ports have to obey the semantic consistency rules concerning the directions (SCR 6.* in IEEE 1685-2014). For instance, SCR 6.5, a logical port with direction in can only be mapped onto a component port with direction in, inout, or phantom. For a mirrored bus interface, the direction of the logical port must be reversed. If an abstraction definition contains logical ports such that for each logical port the direction in a master is mirrored compared to the direction in a slave, and also presence and width are identical in a master and a slave, then from the netlisting point of view there is no difference between a master interface and a mirrored slave interface and also no difference between a slave interface and mirrored master interface. Such an abstraction definition is sometimes called symmetric. However, if an abstraction definition is asymmetric, then SCRs 6.* imposes different constraints for master/mirrored slave interfaces and slave/mirrored master interfaces. A typical example is a logical clock port (see all AMBA bus definitions). The logical ports PCLK, HCLK, and ACLK have direction in for master and slave interfaces. Another example is IEEE 1149.1 JTAG (see https://www.accellera.org/images/busdefs/busdef_SpiritCons_Accellera_1685-2009_final.zip) where logical ports TDI and TDO have a width of 1 in slave interfaces and no width in master interfaces. As a result you can mapped multiple TDI/TDO bits in a mirrored master interface but only 1 bit in a slave interface. The use of mirrored and non-mirrored interfaces is not only relevant for connectivity but also for internal addressing in a component. If you use mirrored interfaces then the internal addressing can only be expressed using channels (from mirrored master to mirrored slave). If you use non-mirrored interfaces then the internal addressing can only be expressed using bridges (from slave to master). It is not possible to describe internal addressing with a combination of mirrored and non-mirrored interfaces (e.g. addressing from a mirroredMaster to a master). As a result, it is not possible to cascade components that use channels for addressing. Hence, my advice is always to use bridges for addressing in combination with non-mirrored interfaces. In my opinion, the use of mirrored interfaces only makes sense in combination with non-addressable bus definitions that are asymmetric. Typically, these are serial protocols such as JTAG, but also I2C, I2S, SPI, and so on. Often they have an output enable logical port with direction out for master and slave interfaces. In that case, you functional IO muxing component needs mirrored master and slave interface to allow the output enable signal to be input. Please see the above referenced accellera.org bus definitions. Best regards, Erwin
  6. Hi Bhargav, Yes, this fragment is valid and it means what you indicated. You can perform a schema check using the schema hosted on the Accellera website: http://www.accellera.org/XMLSchema/ Best regards, Erwin
  7. Hi Bhargav, Glue logic is not covered by the IP-XACT standard. Perhaps your IP-XACT EDA vendor can offer a vendor-specific solution on top of the standard using vendor extensions or vendor-specific parameter conventions. Best regards, Erwin
  8. Yes, there are companies that leverage both IP-XACT and PSS. I cannot provide company names. Please talk to EDA vendors.
  9. Hi Bhargav, Your IP-XACT fragment translates to input [32:0] port [3:0][7:0][4:0] in SystemVerilog. So the part in ipxact:vector is packed (left of the port name) and the part in ipxact:array is unpacked (right of the port name). If you want to represent input [32:0][3:0][7:0][4:0] port then all dimensions must go into ipxact:vectors and each dimension is a separate ipxact:vector. Best regards, Erwin
  10. Hi Bhargav, The purpose of arrays is to describe arrays of ports. For instance, in SystemC you can write sc_out< sc_lv<32> > my_port[10]. Your IP-XACT fragment would translate to SystemC as sc_in< sc_lv< 33 > > TAR_PRI_RD[6]. Best regards, Erwin
  11. Hello Harshita, Please see the discussion in this topic: Best regards, Erwin
  12. Hi Bhargav, This is not allowed by SCR 6.25 on page 203 of the IEEE std. 1685-2014: "All ports referenced in an ad hoc connection shall reference the same number of bits. If no range is specified for a nonscalar port, then the full range from the port definition is presumed." Best regards, Erwin
  13. Hi Bhargav, In case of your example connecting A[2:0][2:0] to B[5:3][6:4] there is no need to describe the partSelect. If there is no partSelect then automatically the full range is connected. If you want to create connections different from A[x][y] -> B[x+3][y+4], let's say A[x[[y] -> B[y+3][x+4], then you can use two adhoc connections: <ipxact:adHocConnections> <ipxact:adHocConnection> <ipxact:name>adhoc1</ipxact:name> <ipxact:portReferences> <ipxact:internalPortReference componentRef="cA" portRef="A"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>0</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>2</ipxact:left> <ipxact:right>0</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> <ipxact:internalPortReference componentRef="cB" portRef="B"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>1</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>6</ipxact:left> <ipxact:right>4</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> </ipxact:portReferences> </ipxact:adHocConnection> <ipxact:adHocConnection> <ipxact:name>adhoc2</ipxact:name> <ipxact:portReferences> <ipxact:internalPortReference componentRef="cA" portRef="A"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>1</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>2</ipxact:left> <ipxact:right>0</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> <ipxact:internalPortReference componentRef="cB" portRef="B"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>0</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>5</ipxact:left> <ipxact:right>3</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> </ipxact:portReferences> </ipxact:adHocConnection> </ipxact:adHocConnections> Best regards, Erwin
  14. Hi Bhargav, In the 1685-2014 version, component wire ports can be multidimensional, i.e., it can have muliple arrays and multiple vectors. For this reason, a portReference must support multiple dimensions as well. This is done using the partSelect element. The partSelect element can contain a single range with left and right to support a single vector as before. Or it can contain can indices plus a range. The indices indicate which dimension the range applies to. If the indices contain more than one index then the first indices apply to the arrays and the last indices apply to the vectors. Best regards, Erwin
  15. Hi David, Let''s create a simple example. Assume some peripheral P with slave interface P_S that references a memory map P_S_M containing an address block P_S_M_B with base address P_S_M_B_base. Assume some bus B with a slave interface B_S and master interface B_M. The master interface references an address space B_M_A and has a base address B_M_A_base. The slave interface references a memory map B_S_M containing a subspace map B_S_M_S. That subspace map references master interface B_M. Assume some cpu C with a master interface C_M that references an address space C_M_A and has base address C_M_A_base. Assume connectivity between the bus interfaces as follows: C_M -> B_S, B_M -> P_S. First, because of the connection B_M -> P_S, the memory map P_S_M is mapped into address space B_M_A. The address block base address P_S_M_B_base shifts that block in that address space. If the block range does not fit in the address space range it should be clipped. Second, because of the internal connectivity in the bus by means of the subspace map B_S_M_S, address space B_M_A is mapped into memory map B_S_M. The bus interface base address shifts the address space in the memory map. Finally, because of the connection C_M -> B_S, the memory map B_S_M is mapped into address space C_M_A. Typically base address C_M_A_base has value 0, or the referenced address space is mapped again in another memory map in which the base address may differ from 0. In this example the subspace map base address is 0 which is equivalent to creating a transparent bridge rather than a subspace map. The subspace map base address can be used to shift address space further in a memory map. In this case the bridge is called opague, although this term is not used anymore in IEEE 1685-2014. Also I have assumed that all addressing units are identical. I hope this helps. Best regards, Erwin
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...