Jump to content

kock

Members
  • Posts

    91
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by kock

  1. Hi Kushi, Yes, you can express it like this: <ipxact:parameters> <ipxact:parameter parameterId="myparamID" ipxact:resolve="user"> <ipxact:name>myparam</ipxact:name> <ipxact:value>""</ipxact:value> </ipxact:parameter> </ipxact:parameters> The value "" denotes an empty string. The value of the value element is an expression. An empty expression is not allowed. If you want to put a constant string then you have to quote it. You can override it in a design instance by referencing the parameterId attribute value. Best regards, Erwin
  2. Hi Kushi, IP-XACT does not allow that. Parameters always need to have a default value. Best regards, Erwin
  3. Hi Kushi, The standard contains Annex C.3 complexBaseExpression which can be any of the following: — realExpression (see C.3.1) — signedLongintExpression (see C.3.2) — stringExpression (see C.3.3) — stringURIExpression (see C.3.4) — unsignedBitExpression (see C.3.5) — unsignedBitVectorExpression (see C.3.6) — unsignedIntExpression (see C.3.7) — unsignedLongintExpression (see C.3.8) — unsignedPositiveIntExpression (see C.3.9) — unsignedPositiveLongintExpression (see C.3.10) If an IP-XACT element is of a type that is mentioned here, then its value can be an expression. For example, on page 91, the field volatile element is of type boolean so it is not parameterizable, while the field reserved element is of type unsignedBitExpression so it is parameterizable. Note that the standard contains an error here because for reserved the default value false is not a legal value. This should be 0. Best regards, Erwin
  4. Hi Mats, As you say, you can add a special address block with a width of 128 (or more). The width indicates the maximum number of bits that can be accessed in a single transaction. This address block can contain registers with a size equal to the width or smaller. Best regards, Erwin
  5. Hi Mats, Yes, my understanding is that SCR 7.5 "The size of any register shall be no greater than the width of the containing address block" also applies to virtual registers. Best regards, Erwin
  6. Hi Galong, I only know of https://github.com/kactus2 but I never used it so I do not know what quality of documentation is generated. There are commercial solutions that do exactly what you ask for. Some of the vendors are mentioned here https://www.accellera.org/community/ip-xact/ecosystem/. Best regards, Erwin
  7. Hi Kushi, No you should not describe it like that to avoid ".". You can avoid the separator by putting pathSegments in different elements. So in a field you put "fld", in a register you put "reg". The two segments can be put together then as reg.fld by a generator. I do not have an example at end. Best regards, Erwin
  8. Hello Kushi, The intended and recommended way is to avoid the path separator "." inside a pathSegment Name. For this reason, the element is called named pathSegment since it describes a segment of the path. However, it is not illegal to use the path separator inside a pathSegment and sometime this cannot be avoided. Best regards, Erwin
  9. Hi Kushi, No, you cannot describe this using the IP-XACT schema. You may want to introduce a vendor extension for that. Best regards, Erwin
  10. Hello Kushi, Yes indeed you can think of this as arrays of parameters. Section 6.12.6 Module parameters also describes these vectors and arrays. For module parameters, the arrays described the unpacked dimensions of a parameter and the vectors describe the packed dimensions. So for parameter [3:0] PARAM [7:0], [3:0] is a vector and [7:0] is an array. For parameters it works the same as for module parameters, although a parameter does not directly describe an HDL language parameter. Best regards, Erwin
  11. Hi Kushi, Objects such as address blocks, registers files, and registers are not allowed to overlap or to be interleaved. So you cannot create a register array with gaps and interleave it with another register array with gaps. Instead you can create a register file array. Each element in the register file array can contain multiple registers or even register files. The register files can thus be nested. So indeed, certain things, you can only express using register files. You cannot describe registers without IP-XACT registers because IP-XACT registers do appear in IP-XACT register files. A register file is only a container for registers. In general, EDA tools do support register files. I cannot comment on specific tools. Best regards, Erwin
  12. Hi Kushi, No this is not possible. For the next revision of IP-XACT we propose a stride element which indicates the distance between two array elements. For now you have the following options: A) make your register 64 bit wide, B) unroll the registers and do not use dim, C) create a register file with range 8 (64 bits) and dim 8 and put the register in the register file. Best regards, Erwin
  13. Hi Kushi, A register file is a group of registers. The group has its own range and dimension, so you can see it as an array. Assume register file RF with offset 0, range 8, and dimension 2 containing two registers A and B at offsets 0 and 4. Then there are two occurences of register A at offsets 0 and 8 and two occurences of registers B at offsets 4 and 12. You cannot describe this without register files unless you unroll all registers. Best regards, Erwin
  14. 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
  15. Hi Kushi, That completely depends on the UVM register model generator that you use. It is tool dependent. Best regards, Erwin
  16. 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
  17. 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
  18. 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
  19. 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 can have qualifiers. One of the qualifiers is isData. So you can look at the number of bits of the physical port that is mapped to the logical port with the isData qualifier. Best regards, Erwin
  20. 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
  21. 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
  22. 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 for a TLM view. The abstraction type is view specific. However, you can only have one bus type per bus interface. Hence, if you have an AHB bus type, you need to have AHB_rtl and AHB_tlm abstraction types as different representations of the same bus. Best regards, Erwin
  23. 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 semantic rule in IP-XACT that forbids undriven inputs. In order to drive such a net, it is sufficient in IP-XACT to connect it somehow to a component output port. This can be done with adhoc connections, additional bus interface connections, and/or phantom ports. This is completely free to decide depending on which IP-XACT design-style you wish to use. Best regards, Erwin
  24. 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
  25. 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
×
×
  • Create New...