Jump to content

common library files definition for Component


sachinpatela

Recommended Posts

Hi All

 

For my HW project we use IP components

I am trying to define a component this component uses sub-blocks

file location for these sub-block will be different for various projects

 

Also this component will have different views such as Simulation, Synthesis

I specified all files related with this component in fileset which are referenced in views of model related with component

these files are specified using relative path in file attribute of fileset

But I am not sure How and where I can specify common sub-blocks related files

since path location will be variable which depends on the project in which this component is instantiated

If I get some example how to handle this using IPXACT then that would be great!

 

Thanks

Sachin

Link to comment
Share on other sites

Hello Sachin,

 

In an IP-XACT file element you can use either a relative path or a path using an environment variable. For instance ${MY_VAR}/my_common_lib/my_common_file.v. In this way, the file path is independent of the location of the IP-XACT component xml file containing this file element.

 

Best regards,

Erwin

Link to comment
Share on other sites

Hi Erwin,

 

Thanks for reply, Yes environment varibles could be used

But this could arise other problem since Environment variable is global  

If multiple component using same Env Name then that could cause coflict !

Most of time components are develop by different team,

if they don't follow env naming guideline then could cause clashes!

 

If there is any way to define variable name local to component then that variable name could be used to

prepend file path , But not sure there is any way to specify such variable in IP-XACT

 

Thanks

Link to comment
Share on other sites

Hi Sachin,

 

There is no way to define environment variables locally to components. You need to organize that yourself outside of IP-XACT. You may derive the names of your environment variables from the IP-XACT VLNV identifier. For instance, rather than using MY_VAR you could use <Vendor>_<Library>_<Name>_<Version>. Since the VLNV is unique, also your environment variables are unique. However, I think a better approach is to organize your directory structure such that each team in your organization works in its own sub-tree of this directory structure. Also the common files should have one location in this directory structure. An example of such a structure is the CoReUse directory structure. In this way all your paths can be relative.

 

Best regards,

Erwin

Link to comment
Share on other sites

Hi Sachin,

 

The directory structure in this document is as follows:

 

data/<library>/<cell>/<view>

 

where

  • data is the root of your tree,
  • <library> is placeholder for a collection of IPs (for instance matching with the library field in the IP-XACT VLNV),

  • <cell> is the name of your IP (this name must be unique in your company),

  • <view> is the name of a view (directory) of that IP that contains the implementation of that view

 

An example for a soft IP named my_ip:

data/my_lib/my_ip/RTL/my_ip.v

                 /DOCUMENTS/my_ip.pdf

                 /METADATA/my_ip.xml

 

The METADATA view is the location for an IP-XACT XML file. The file my_ip.xml can contain a view named RTL referencing a fileSet named RTL. The fileSet RTL can contain a file named ../RTL/my_ip.v. This verilog file would implement the module my_ip. You can think of many other views such as NETLIST for gate-level netlist and LAYOUT for gdsii.

 

If you would replace the prefix "my" by a unique prefix for each team in your organization, then all IP would be unique and in a unique location.

 

Best regards,

Erwin

Link to comment
Share on other sites

  • 5 months later...

Sachin,

 

I don't understand what you mean by sub-blocks at different locations. A sub-block of an ip-xact component is itself another ip-xact component. You download all of your ip into your design environment and every component is stored in its own place. If it is used by multiple other componennts then they all get its files from that one  location.

 

 

The best way that I have found to use environment variables is to run all off your toolflow scripts from the top level of your design environment. If you do that then $HOME provides the absolute pathname to your design environment and everything else is relative to that.

 

 

John Eaton

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...