IP-XACT syntax

[van]

I have a component with an input port which is directly connected to an output port of the same component.
For describing that case, I created an ad-hoc connection with two externalPortReference connecting both ports.
However after validating my xml file I am reported an error as internalPortReference is mandatory.

How can I do the connection so?

The other problem is how to describe inout port in IP-XACT ?

[edankert]

You can not connect only 2 'external' ports together on a component using the adhoc connection mechanism. You can however instantiate this component and connect the ports for the instance together using internalPortReferences.

 

The next version of IPXACT will allow for this.

 

To describe a port with direction inout, simply describe the direction as inout.

<spirit:port>
  <spirit:name>portname</spirit:name>
  <spirit:wire>
    <spirit:direction>inout</spirit:direction>
  </spirit:wire>
</spirit:port>

--

Edwin Dankert

 

Duolog Ltd.

http://www.duolog.com/

[kock]

Another way is to use a component instance with phantom ports. A phantom port is a port with a direction set to phantom:

<spirit:port>
  <spirit:name>portname</spirit:name>
  <spirit:wire>
    <spirit:direction>phantom</spirit:direction>
  </spirit:wire>
</spirit:port>

The meaning of phantom is that the port does not physically exists on the IP block. Hence, all connections to this port will be resolved to wires. For example, if port a and port b connect to port portname, then a netlister will create a connection between port a and b. In the adhoc connection there is an internal port reference to the phantom port, which is exactly what you need to connect to two external port references.

 

If the phantom port is part of a component which has only phantom ports, then your netlister may decide not to instantiate the phantom component. At the moment this is tool specific. The next version of the standard will allow you to specify how netlisters should behave in this case.

 

Best regards,

Erwin

[van]

Hello all,

I have a question concerning parameters.

 

In IP-XACT component,  what it the difference between <spirit:parameters> and <spirit:mode> --- <spirit:modelParameters> ? Can they contain the same info ?

 

Thanks

Van

[kock]

Hi Van,

 

<spirit:parameters> describe parameters used to configure the IP-XACT component.

<spirit:modelParameters> describe parameters used to configure the Verilog, VHDL, or SystemC model that is described by the IP-XACT component.

 

More specifically, modelParameters describe the parameters that are needed to instantiate the model in the target language, i.e., the Verilog module, the VHDL entity, or the SystemC module. For instance, if a Verilog module has parameters, then these parameters need to be describe as spirit:modelParameters. The same holds for verilog generics and SystemC module template and constructor parameters.

 

The spirit:modelParameters can be expressions in terms of spirit:parameters. So the IP-XACT component can have a set of parameters that is used to calculate the value of the modelParameters.

 

Best regards,

Erwin

[van]

Hi Erwin,

 

Thanks a lot for your help.

 

I am wondering wich is the difference between  "IPXACT IEEE1685 standard" and "IPXACT version 1.4 " (the current version) , is it the same thing ? and does the version 1.4 support all syntax of the versions 1.0 1.1 and 1.2 ?

 

Another question about TGI API, there are commands refering to IDs like "getBusDefinitionID" , "getComponentInstanceID" , .... . Do these IDs refers to elements describeb in IPXACT xml files, so that by executing these commands we get information existing in IPXACT description ? or they refers to other information ?

 

Best regards,

Van

[kock]

Hello Van,

 

IP-XACT 1.4 and IP-XACT IEEE1685 are not the same. IP-XACT 1.4 was released by the Spirit Consortium in March 2008. This consortium also created an update of IP-XACT 1.4 called IP-XACT 1.5 which was never publicly released. Rather the 1.5 version was used as input for the IEEE1685 standard. The IEEE1685 standard dates from December 2009. The 1.0, 1.1, 1.2, 1.4, and IEEE1685 XML schemas do not support the syntax of earlier versions in the sense that an XML document for version 'X' is not valid for version 'Y' of the standard. However, the standardization committee provides XSL transforms that allow you to up-convert an XML document from version 'X' to version 'X+1'. So you can always transform an IP-XACT document to a new IP-XACT document in the latest version of the standard. By the way, the latest version of IP-XACT is not 1.4; it is IEEE 1685-2009. You can find all schema versions at http://www.accellera.org/XMLSchema/SPIRIT.

 

The TGI IDs are handles to objects in an IP-XACT database. The idea is that an IP-XACT Design Environment reads in the IP-XACT XML documents and internally builds a database. TGI allows you to access the objects in that database. So a componentInstanceID is a handle (or a pointer) to the Design Environments representation of a componentInstance object as specified in the IP-XACT design XML file. So indeed, you can use these handles to access information that is described in the IP-XACT XML files. For instance, you can use a componentInstanceID to get the name of a component instance by executing getComponentInstanceName(componentInstanceID).

 

Best regards,

Erwin

[van]

Hello,

1- While reading IPXACT standard , I am wondering about the purpose of having two references for each bus interface ! : bus definition and abstraction definition .
If I understand , each abstraction definition must refer to a bus definition. Can the bus definition be a reference for several abstraction definitions ?

2- Other topic, In TGI, which is the usefullness of the SOAP protocol ? why do APIs don't act directly on ipxact data base  (in spite of using of a protocol) ?

3- concercning register and memory map descriptions in IPXACT, is the ipxact description  totally extracted from RTL or there is essential user input to be provided ? Can so provide me exemple of register info that can be extracted from RTL?

 

Best Regards

Van
 

[kock]

Hi Van,

 

Ad 1) Yes, a bus definition can be referenced by multiple abstraction definitions. Indeed, one can argue that it is not necessary to reference a bus definition in a bus interface since the bus definition reference can be obtained using the abstraction definition. I think the reason for leaving the bus definition reference in the bus interface is that it is not needed to visit the abstraction definition information for checking if two bus interfaces can be connected (they can only be connected if they reference the same bus definition).

 

Ad 2) The reason for the SOAP protocol is that it is programming language neutral. Typically an EDA vendor provides programming language specific APIs for writing generators, e.g., Tcl, Java, C/C++, and libraries that translate the API calls to SOAP messages. The resulting generator executable or script will work with any IP-XACT database. The generator and the database can even run on different servers.

 

Ad 3) Typically register information cannot be extracted from RTL and needs to be provided in some other format. Other formats can be register documentation, for instance in Excel or FrameMaker (DITA, XML), or even register implementation formats such as SystemRDL.

 

Best regards,

Erwin

[van]

Hi Erwin,

 

I have a doubt about the use of <spirit:parameters> & <spirit:modelParameters>

 

<spirit:parameters> describe parameters used to configure the IP-XACT component.

<spirit:modelParameters> describe parameters used to configure the Verilog, VHDL, or SystemC model that is described by the IP-XACT component.

 

So , If I well understand:

- If I have an Verilog design and I want to create its correspondent IPXACT component description, I put the parameters of the design in <spirit:modelParameters>

- In case of having an IPXACT component and I want to generate its correspondent RTL , I specifiy the parameters in <spirit:parameters> , so the generated RTL contains this configuration

 

Is my understanding is well?

 

Thanks

[kock]

Hi Van,

 

The <spirit:modelParameters> always need to be used to describe the parameters of the target language. So if you have a verilog module then the parameters of this module should be described as modelParameters of the IP-XACT component.  An IP-XACT netlister will use the modelParameters and the associated configurable element values in a design that instantiates an IP-XACT component with modelParameters to set the correct values during instantiation. For example for a verilog module mixer with parameter mix_gain described as modelParameter, a netlister can generate the following instantiation i_mixer:

mixer #(
      .mix_gain (1.0)
      )
i_mixer (
      .vcc(      vsup            ),
      .gnda(     gnda            ),
      .in(       i_lna_out_sig   ),
      .out(      i_mixer_out_sig ),
      .lo_in(    lo              )
      );

The <spirit:parameters> are independent of the target language. They are used to parameterize the IP-XACT XML component, not the verilog view of that component.

 

Wrt to your remarks:

If I have an Verilog design and I want to create its correspondent IPXACT component description, I put the parameters of the design in <spirit:modelParameters>

In the current standard IEEE 1685-2009, designs cannot be parameterized. So indeed, the best you can do is to parameterize the IP-XACT component encapsulating that design. Depending on whether these parameters are needed to instantiate that component (and hence its associated design) or not you should describe them as modelParameter or not, as explain above. The upcoming revision of the standard aims to do better by allowing parameterization of the design and parameter value propagation from component to design.

 

In case of having an IPXACT component and I want to generate its correspondent RTL , I specifiy the parameters in <spirit:parameters> , so the generated RTL contains this configuration

Not sure if I understand this question. However, if you want to instantiate the mixer component as explained above, then this should be done in an IP-XACT XML design. You can set the actual parameter values with configurable element values. On the other hand, if you want to generate a verilog module interface from an IP-XACT component then this generator must use the modelParameters. The spirit:parameters are not relevant in any case.

 

Best regards,

Erwin

[van]

Hi Erwin,

 

In an earlier reply, you said that "the 1.5 version was used as input for the IEEE1685-2009 standard" and in the overview of the PDF of the standard there is  the standard "based on version 1.4 IP-XACT of The SPIRIT Consortium".

Does the IEEE1685-2009 contains information from both 1.4 and 1.5 version ?

 

Thanks

[kock]

Hi Van,

 

Yes, the IEEE 1685-2009 version is largely identical to IP-XACT 1.4. There have been some changes going from 1.4 to 1.5; these changes are mainly in the register descriptions.

 

Best regards,

Erwin

[mignotn]

Hi Erwin,

 

In reply #8, you are saying "However, the standardization committee provides XSL transforms that allow you to up-convert an XML document from version 'X' to version 'X+1'."

 

Where can we find those XSL transforms ?

 

Accelera is providing a library of busDef as examples, but they are written for 1.2 standard. Is it possible to transform these examples in IEEE 1685-2009 with those XSL ? or, does Accelera provide these examples directly for the latest schema versions?

 

Best Regards,

Norbert

[kock]

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

[mignotn]

Hi Erwin,

 

Thanks, this would be great.

 

Making such example libraries available in the latest release of the standard on the website is probably a good way to promote the use of IPXACT.

Then, it is also easier for people to post their contributions for other bus descriptions, once they have examples to start from.

 

Best Regards,

Norbert

[Mohamed]

Hi all,

Is there a way in IPXACT standard to specify that a port is corresponding to a clock port ?

Or we must specify this in vendorExtensions ?

Thanks

[marknoll]

Hello Mohamed,

 

If you mean that you want to indicate that a particular port is a clock port, the typical way to do that would be to define a driver/clockDriver element for the port. This allows you to define the properties of the clock within the port definition. If you are instead asking how to say that a given port is clocked by another port (which is a clock), then there is no explicit way to do that. You could however define a timingConstraint on the port which could link the port to a clock port. Technology independent timing constraints are stored in the constraintSets/constraintSet element within the port. Only technology independent constraints are allowed, as others should be stored in an SDC file and included via fileSet within the component.

 

Regards,

Mark

[Mohamed]

Hello Mark,

 

Thanks for the answer.

In fact, I want to indicate that a particular port is a clock port.

 

      <spirit:port>
        <spirit:name>clkin</spirit:name>
        <spirit:wire>
          <spirit:direction>in</spirit:direction>
          <spirit:driver>
            <spirit:clockDriver spirit:clockName="clkin">

              <spirit:clockPeriod>8</spirit:clockPeriod>
              <spirit:clockPulseOffset>4</spirit:clockPulseOffset>
              <spirit:clockPulseValue>1</spirit:clockPulseValue>
              <spirit:clockPulseDuration>4</spirit:clockPulseDuration>
            </spirit:clockDriver>
          </spirit:driver>
        </spirit:wire>
      </spirit:port>

 

Regards,

Mohamed

[marknoll]

Hello Mohamed,

 

Yes this is the correct syntax. You should be able to confirm this on your side using any XML schema validation tool.

 

Thanks,

Mark

[Mohamed]

Hi all,

 

Is it possible to describe conditional statements of RTL ('ifdef,...) in IPXACT ?

 

Another question about memory maps: if a memory map is declared into an IPXACT file, is it mondatory to reference it into a "memoryMapRef" of bus interface ? (otherwise, there is no link between memory maps and physical/RTL objects)

 

Thanks,

[marknoll]

Hello Mohamed,

 

It is not possible to model conditionality like this in the current version of the standard. However it will be possible in the P1685-2014 version of the standard due out in the Sept/Oct timeframe. It may take some time for tools to support this, but the new version of the standard will definitely support it.

 

Regarding the memoryMapRef -- it is not technically required that you reference the memory map via a bus interface, but as you state, if you don't do this there is no way for a tool or IP integrator to know how to reference the memory map.

 

Thanks,

Mark

[Mohamed]

Hello all,

 

I’d like to know How can I specify VHDL configuration (entity/architecture pair) in IPXACT if multiple architecture in the specified VHDL file ?and how I can specify the VHDL source file names ?

Or, should this assume only one architecture in one VHDL file ?

 

Can you explain me the concept of Configuration or Configurability in IPXACT. ? (how I select a specific configuration, ...)

 

Best Regards

[marknoll]

Hello Mohamed,

 

VHDL configuration information can be specified within the view/modelName element. This is a string which (for VHDL) can specify entity and architecture using the format <entityName>(<architectureName>). If you have multiple architectures, you would have multiple view elements (one per architecture). If you have different file sets for each architecture, then you can specify the files in different IP-XACT fileSets. Then in each view you indicate the appropriate fileSet using the fileSetRef element.

 

The "selected" view is documented in the top-level IP-XACT designConfiguration file. That file contains (among other things), a list of viewConfiguration elements which document the selected view for each instance (via the viewName and instanceName elements within the viewConfiguration).

 

Thanks,

Mark