Jason H

The fieldMaps are a great addition in the 1685-2022 release. However, the language about fieldMap modeRef elements is somewhat unclear. A use case which seems to be supported is specifying multiple fieldMap elements to cover less straightforward mappings to fields, leveraging the fieldSlice indices and range, as well as the partSelect, to map the bits. As a simple example, if I have a "logic [63:0]", e.g. port with 64-bit vector, that I want to map to two 32-bit fields within an array of two registers, it seems like I can do that with two fieldMaps on the port. Effectively: myPort[31:0] -> blk.reg[0].fld myPort[63:32] -> blk.reg[1].fld This can be done with two fieldMap elements on the port. My confusion comes when you then consider modeRefs. In other places where modeRefs are used, such as fieldAccessPolicies, there can only be one active fieldAccessPolicy. However, the wording is different. For fieldAccessPolicy: For fieldMaps: In the fieldMap case, the uniqueness of the modeRef value as well as its priority are stated relative to a single fieldMap, whereas the fieldAccessPolicy uniqueness is required across all fieldAccessPolicy elements within the parent fieldAccessPolicies element. There is also no uniqueness constraint in the schema for modeRef priority on fieldMap elements. TL;DR Based on the above, my interpretation is that you can have multiple active fieldMap elements, and when there is a mode-dependence, you can have multiple fieldMap elements referencing the same mode at the same priority. Is this the correct interpretation?

@Eric D, @blewis, the schema files are up! http://www.accellera.org/XMLSchema/IPXACT/1685-2022/.

FYI it looks like the supplemental material has been uploaded: https://www.accellera.org/downloads/standards/ip-xact. However, the schema files are not showing up yet.

Got it, yes, your UVM RAL generator also needs to support parameterization. From what you are showing, the generator you are using doesn't support generating "parameterized" models. Again, I don't know how many, if any, of the big vendor companies support that, but it's certainly doable if you own the generator. You can use parameterized classes, though that is not required. You can also add instance attributes to the uvm_* classes which hold parameter values. The implementation is beyond the scope of this forum, but I have seen RAL models generated from IP-XACT which have "configurable" classes to align with the parametrizable register module RTL. TL;DR IP-XACT can capture the parameterization information, but your UVM RAL generator needs to support creation of configurable classes.

@PrashanthP are you describing your design hierarchically in IP-XACT, or just generating leaf-level RTL? I'm not sure what you mean by needing to re-generate your SV code, unless your tooling doesn't support generating parameterized RTL. It'll depend on the vendor, but if you declare a moduleParameter in your component/componentInstantiation, that can be used by RTL generators to create parameterized RTL modules from the IP-XACT. Something like this: <component> <model> <instantiations> <componentInstantiation> <moduleParameters> <moduleParameter> <name>RANGE_PARAM</name> <value>RANGE_PARAM</value> </moduleParameter> </moduleParameters> </componentInstantiation> </instantiations> </model> <!-- ... --> <parameters> <parameter parameterId="RANGE_PARAM" resolve="user"> <name>RANGE_PARAM</name> <value>20</value> </parameter> </parameters> </component> At least, that's one way I've seen it done. I really have no idea what number of RTL generators actually create parameterized RTL.

Given IP-XACT does not support glue logic, I believe I have exhausted every possible route with busInterfaces and adHocConnections to somehow describe interrupt aggregation. My current plan is to use a very generic "interrupt" busDefinition/abstractionDefinition. I've played with system interfaces and target/initiator (as I've seen examples of both), though the problems are the same regardless. The fundamental problem is simple: I need to OR some wires together, and there isn't a way to explicitly describe that. The least annoying workaround I can think of is to define a generic "OR" component that, by convention, is known to represent the OR of all bits of all input ports fed to the single bit output port. It could even contain a channel to make the many-to-one explicit, though that's not the right use of a channel. Any other recommendations, approaches, or potential workarounds?

Sorry about that, my example was the simpleAccessHandle schema, and an addressBlock accessHandle uses the slicedAccessHandle schema. The slicedAccessHandle allows you to specify an optional range that would correspond to a part/bit select (e.g. mem[msb:lsb]). You shouldn't need that here. So the more accurate example: <addressBlock> <accessHandles> <accessHandle> <slices> <slice> <pathSegments> <pathSegment> <pathSegmentName>mem</pathSegmentName> </pathSegment> </pathSegments> <!-- this is allowed, but likely not useful <range> <left>some_msb</left> <right>some_lsb</left> </range> --> </slice> </slices> </accessHandle> </accessHandles> </addressBlock> I don't know why they chose to give the accessHandle element three different schemas depending on its parent element, but there is fundamentally no difference in the construction of the path in this scenario. Just more complex XML.

This could depend on what tooling you are using to generate your UVM RAL model from the IP-XACT, but the addressBlock accessHandles is what you want. See section 6.9.2.2 in the 1685-2014 standard, and C.1 for accessHandles specifically. As an example: <addressBlock> <accessHandles> <accessHandle> <pathSegments> <pathSegment> <pathSegmentName>partialpathto</pathSegmentName> </pathSegment> <pathSegment> <pathSegmentName>thememory</pathSegmentName> </pathSegment> </pathSegments> </accessHandle> </accessHandles> </addressBlock> This is equivalent to setting an HDL Path of "partialpathto.thememory" on the uvm_mem instance. Each node (e.g. the addressBlock) should only set its related partial path. Assuming this is right at the top of the RTL module, then there isn't much "path" to specify. It may just be a single name, such as MemoryBlock in your example. Some tools will allow use of the IP-XACT hierarchy of addressable elements if that matches the RTL implementation already.

@PrashanthP you might want to check out simple built-in sequences like the bit bash sequence as a baseline for whether your (presumably generated from IP-XACT) UVM RAL model matches the design. Details beyond that could be answered in UVM forums or other docs.

You need to avoid embedding "instantiation" information in the register name itself. Arrays are very useful in the address map, and you don't need to uniquify the names when you leverage them. For example, <registerFile> <name>RfGrp</name> <dim>3</dim> <register> <name>Reg1</name> </register> <register> <name>Reg2</name> </register> <register> <name>Reg3</name> </register> <register> <name>Reg4</name> </register> </registerFile> Then, your names are defined by path, so instead of Reg1_0 you have RfGrp[0].Reg1. Your IP-XACT logical representation doesn't have to match exactly to the implementation (e.g. RTL module), but if they do differ and you want to use backdoor paths in UVM RAL or similar, you can add accessHandles to specify the "view" specific names. And as for the parameter part, dim is an positiveUnsignedIntExpression, so you can reference a parameter which will adjust the dimensionality. <component> <parameters> <parameter parameterId="N" resolve="user" type="int" signed="false" minimum="1"> <name>N</name> <value>3</value> </parameter> </parameters> <!-- ... --> <registerFile> <dim>N</dim> </registerFile> </component>

@Khushi The existing IP-XACT User Guide from 2018 has an example of parameter passing. If you are like me, you will need to read through it several times, then play with the example to fully understand it. It's far more complex than parameter passing in a language like SystemVerilog.

@Dako Just to build on @kock's answer, 1685-2022 modes are complicated, but incredibly powerful. Since alternateRegisters are now mode-dependent, you can specify define a dynamic (unresolved) condition under which an alternateRegister description is the one to use. Some pseudo-code for the component with the different register descriptions at the same offset: <component> <!-- ... --> <mode> <name>STATE_0</name> <condition>$ipxact_port_value("sel") == 1</condition> <portSlice> <name>sel</name> <portRef portRef="state_select"/> </portSlice> </mode> <!-- ... --> <port> <name>state_select</name> <wire> <direction>in</direction> </wire> </port> <!-- ... --> <register> <alternateRegister> <name>foo</name> <modeRef priority="1">STATE_0</modeRef> </alternateRegister> </register> </component> This says alternateRegister foo is selected when the STATE_0 mode condition is active. This condition references the value of a port on the component. You says it's an external register field, so you can use the concept of port fieldMap (fieldMap also new in 1685-2022) in the other component. <component> <!-- ... --> <port> <name>state_sel</name> <fieldMap> <memoryMapRef memoryMapRef="m"/> <addressBlockRef addressBlockRef="b"/> <registerRef registerRef="r"/> <fieldRef fieldRef="your_control_field"/> </fieldMap> <wire> <direction>out</direction> </wire> </port> </component> You would then connect those ports in a design description. This allows you to explicitly base that mode condition on the value of a field within a different component. That is huge, because it's a common case. Note: If the field controlling the "active" register was within the same component, you would simply use a fieldSlice instead of a portSlice to use in the mode condition.

The concept of isPresent is incredibly useful, in my opinion. However, it is difficult to implement in practice because you have different use cases and you need to define exactly what being non-present means for your team. As @kock mentioned, the standard does not detail the specifics of these things (I don't think it would be feasible). It is reasonable to treat isPresent=0 on a field the same as reserved=1 from a software point of view (though, as also mentioned above, reserved is up to interpretation). That wouldn't work in concert with the idea of a separate field with an inverse isPresent expression at the same address. I have found it useful to align with some of the rules in SystemRDL 2.0, which also has an ispresent property, but your mileage may vary. TL;DR I do think a field which is "not present" returning a non-zero value on read would be unexpected by most.

Since moduleParameter values are expressions, then string literals must be quoted, so this version is correct: <ipxact:moduleParameter parameterId="ip_config" resolve="user" type="string"> <ipxact:name>portname</ipxact:name> <ipxact:value>"ABC"</ipxact:value> </ipxact:moduleParameter> Otherwise, as you mentioned, a tool would parse the value and see ABC as an identifier (parameterId reference) which is not what you want.

I see that my statement was also mentioned in a previous post. Those functions were present in 1685-2009, and missed in 1685-2014. Regardless, getRegisterFileArray is not standard.

An issue may be that getRegisterFileRegisterFileIDs and getRegisterFileRegisterIDs were missing from the TGI Annex in 1685-2014. Some vendors filled in the blanks and implemented them anyway. Others may not have.

These are SystemVerilog rules, not IP-XACT. As Erwin mentioned, the signal is pure-vector. That means you have to match the "shape". However, abstractionDefinition ports have a more generic width that is not language specific. You cannot specify data[0][11:0] That is invalid. However, you can specify data[0][2:0] which is 12 bits, and data[1][2:0] which is also 12 bits. In fact, you can just specify data[0] and data[1]. I recommend looking up unpacked arrays in the SystemVerilog LRM.

Your second case is correct. Always the parameterId. You can obviously make the parameterId the same as the name. On the other extreme, some editors, like kactus2, use UUIDs for the parameterId but always show the parameter name in the UI to abstract away the ID referencing details.

Hi Khushi, A componentInstantiationRef points to the name of a componentInstantiation in the same document. Basically, it contains view-specific information about the current component (I like to think of it as describing "how to instantiate this component in this view"). A designInstantiationRef references a designInstantiation in the same document, where the designInstantiation references the VLNV of a separate design document for that view. The only reason you would want to reference them in different views is if they weren't both valid in the same view. In my experience, we always reference a local componentInstantiation and a designInstantiation for any view of a hierarchical component. There may be some scenario I could invent where you may want them separate. Maybe you have a documentation view in which the docs should be generated at that component, but not the implementation underneath. They maybe you could have <model> <views> <view> <name>rtl</name> <componentInstantiationRef>ci-rtl</componentInstantiationRef> <designInstantiationRef>di-rtl</designInstantiationRef> </view> <view> <name>documentation</name> <componentInstantiationRef>ci-rtl</componentInstantiationRef> </view> </views> </model> I've never encountered such a requirement, though.

In IP-XACT Std 1685-2014, the stringURIExpression type is listed along with the other expression types which must be a valid SystemVerilog expression resolving to a string. However, in all example cases I have found (e.g. Leon2), elements which are of this type are unquoted file paths. This means, technically, they are not valid expressions unless they are wrapped in double quotes prior to parsing as a SystemVerilog expression. In addition, there are cases with stringURIExpression types in documents which don't have parameters (ipxactFile/name in a catalog) where an expression type provides no benefit. Looking for guidance on whether it is safe to treat these elements simply as file paths with optional environment variables, or if this will be clarified in an upcoming revision of the standard.

I looked into this because I've been referencing the 2014 standard, and I can confirm your findings. It appears that particular detail changed in the schema between 1685-2009 and 1685-2014. In the 2009 revision, the schema itself does require you list registers followed by registerFiles. In the 2014 revision, they can be intermixed, which would enable you to list them by offset order.