Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by kock

  1. Hi Kushi, The user guide does not explain this. Section 12 and 13 and Annex H of the standard explaining addressing. It is not very easy to read though. Best regards, Erwin
  2. Hi Kushi, That completely depends on the UVM register model generator that you use. It is tool dependent. Best regards, Erwin
  3. Hi Kushi, A normal memory map is accessible through a slave bus interface; a local memory map is not. A local memory map is local to the component. You can describe internal registers in it, for instance, for a CPU. A local memory map is described with an address space that can be referenced from a cpu element. The current IEEE std. 1685-2014 does not allow separate definition and instantiation of registers. The Accellera IP-XACT Working Group is working on a proposal for a revision of the standard that does support that. Best regards, Erwin
  4. Hi Kushi, You need to describe the complete system in IP-XACT including the masters with their address spaces. For each master, the address map can be computed and a UVM register model can be generated. Different masters would be able to see the same registers at different locations then. As far as I know, UVM does not support the same register at different addresses allowing write to a register via one address and read of that register via another address. Best regards, Erwin
  5. Hi Suhyun, Your description defines the addressBlock width as 16. If there is no isData qualifier or no port map, then data width of the bus interface is not documented. You cannot assume that it is the same as the addressBlock width. For instance, the data bus width may be 8 in which case you need 2 transactions to read the content of a register. Best regards, Erwin
  6. Hi Suhyun, Your register descriptions are not valid. You have addressUnitBits set to 8 meaning that the unit of addressing is 8 bits. That means that your register offset should 0, 2, 4, … In your example, they are 0, 1, 2, … while the registers are 16 bits. That means register 0 occupies bits 0 to 15, register 1 occupies bits 8 to 23, and so on. Hence, they overlap. The address block width indicates the maximum number of bits that can be accessed in a single transaction. The data bus width can be different. Your bus interface contains port maps. The logical ports in the port maps ca
  7. Hello Suhyun, Yes you are right on Q1 and Q2. On Q2, you miss one zero. It should be 0x40001 rather than 0x4001. Best regards, Erwin
  8. Hi Kushi, I never used whitebox elements but the intend is that you can reference ports, connections, and bus interfaces of/between component instances for verification purposes, for instance, to connect a Verification IP to observe/drive transaction on a particular bus interface. A whitebox element describes the view/HDL specific paths/names of those ports/connections/interfaces. Best regards, Erwin
  9. Hi Kushi, Sorry for my late reply. Support for RTL and TLM views in the same component is limited in 1685-2009. It only works if the RTL and TLM views have the same ports, e.g. in case of a signal-level TLM view. If you have a transactional port in the TLM view then there is no way to handle that port in the RTL view. The 1685-2014 version enables you to hide that transactional port in the RTL view and replace it by signal-level ports. Also in 1685-2009, each bus interface can have only one set of port maps. In 1685-2014, a bus interface can have port maps for an RTL view and port maps fo
  10. Hi Kushi, In IP-XACT, an interconnect connects the logical port bits that are mapped in the connected bus interfaces. The direction of those logical bits does not matter. So the direction can be in on all end points, and also the component port bits mapped to these logical port bits can all have direction in. In an HDL netlist, this would translate to a net with all inputs at its ends. It depends on the netlister tool that you use whether such a net is actually generated or not. Typically your netlister tool generates a warning or error that you have undriven inputs. However, there is no
  11. Hi Kushi, The Accellera bus definitions contains files for I2C. There are two: one for I2C internal (uni-directional signals) and one for I2C external (bidirectional signals). They allow you to make direct connections from master to slave. A bus does not have to be symmetric to support direction connections. The bus definition property directConnection determines if you are allowed to make direct master to slave connections or not. Best regards, Erwin
  12. 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
  13. 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
  14. 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 Componen
  15. 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 c
  16. 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 a
  17. 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
  18. 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
  19. Yes, there are companies that leverage both IP-XACT and PSS. I cannot provide company names. Please talk to EDA vendors.
  20. 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
  21. 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
  22. Hello Harshita, Please see the discussion in this topic: Best regards, Erwin
  23. 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
  24. 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
  25. 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
  • Create New...