Jump to content
sachinpatela

common library files definition for Component

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×