I need a list of device-specific primitives of Xilinx devices. I know that ISE has a list of templates and there are also PDF user guides but I need them as list of files in a folder so that I can parse them and extract name and port-list of every module.
Any help will be appreciated.
If you are using Xilinx ISE take a look at the folder "C:\Xilinx\14.7\ISE_DS\ISE\vhdl\src\unisims\primitive" (default install location, version may vary).
In this folder you will find VHDL files for all Xilinx primitives, not sorted by device however.
Look for the file named unisim_VCOMP.vhd. It has all the component declarations of the Xilinx primitives.
For ISE, this is located at
[install dir]\[version]\ISE_DS\ISE\vhdl\src\unisims
For Vivado,
[install dir]\[version]\data\vhdl\src\unisims
Note, for Vivado, if you have VHDL that has primitives from older devices, then use unisim_retarget_VCOMP.vhd, which retargets old primitives to 7 Series and Ultrascale equivalents. However, there are some cases when retargeting certain primitives is not possible.
If your code is for 7 Series and Ultrascale families, I wouldn't worry about the "retarget" file.
I have almost found what I wanted. Language templates are stored in location:
[install dir][version]\ISE_DS\ISE\data\projnav\templates
Related
I am wondering if there is a way of version control in vivado for a VHDL project.
One way would be to add the version number to the bitstream file name.
Would that be possible?
What other options are there if that isn't possible?
Thanks in advance
Think about what you require
Version information format and size: What is the version? Is a natural number? String? Real? Do you save date or time stamp? Do you need a build number? Need extra space for sub-unit versions?
Version source and design flow: What sets the version? Is it a source control tool? Do you manually set the version? Do you need automation to update parts of the version information (timestamp, build number, etc.)?
Version accessibility/observability: Where do you want to read the version number and have it viewable? In the source code? External file? The bitstream file name? The flash file contents? Do you need the FPGA logic to be able to access the version information (to be read via communication channel, embedded processor, etc.)?
Vendor Tools/Device/System/Source dependency: Implementation and automation of version information may depend on several things: Each vendor has different tools (even within the same vendor's). Different devices may allow you to do different things. The system where you work may allow different forms of automation (OS, installed script tools, etc.). The source files (VHDL, Verilog, System C, ...) and directory structure may influence the applicability of your solution.
Automation options
Makefile (builder script) automation
The most flexible way is to have some kind of builder script which may or may not be hooked to your source control mechanism (makefile, perl, python, etc.). Think about the transportability of your project between designers and even design platforms (Windows, Linux, etc.).
Pros:
Complete control of what you want to do.
Can be hooked to any source control automation.
Can be modified to work on any platform when using standard tools (be sure to take special care of file paths which differ between OS).
Cons:
Does not flow well with GUI vendor tools (see Vivado TCL hooks).
Vivado TCL hooks
Vivado has TCL hooks which you can use to run when you synthesize, implement, etc.
Using a pre-synthesis TCL hook will allow you to connect a script to run just before synthesis, and implement your version information update mechanism.
Using a post-bitstream TCL hook will allow you to connect a script to run just after bitstream file creation, and create a file name matching your updated version information, or other final operation you may require.
More information:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug894-vivado-tcl-scripting.pdf
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug835-vivado-tcl-commands.pdf
Pros:
Works with a GUI flow (automatically takes care of everything when you click on Synthesize).
Cons:
(Vivado) tool dependent
Need to remember to create the hooks in your Vivado project
Implementation options
Source code modification
Version number, build number, timestamp, and basically everything you need can be modified (within the VHDL/Verilog code) automatically using a script which parses a known file format. I've done this with Vivado TCL hooks and a well formatted package VHDL file. Works like a charm.
Note: When updating source files using pre-synthesis TCL hooks, Vivado will think the files were modified after, and will consider the implementation as not updated. I added to the script a command to save the current timestamp of the package file, updated it, and then wrote back the timestamp (meaning the package file will forever hold its system date and time).
Pros:
Version information easily viewable accessible to designer (package file).
Version information easily accessible for logic usage.
Device independent.
Cons:
Version information cannot be read by examining the bitstream file.
Writing the script may take some work and may force you to a standardisation of your project sources directory structure [which may not be a totally bad thing ;) ]
Top level entity/module generic
Generics at the top level design module/entity can be modified by the Synthesis tool and accessed by the design's logic.
Pros:
Less complicated scripting than modifying the source code.
Cons:
Version information cannot be read by examining the bitstream file.
You still need to save your version/build number somewhere (a file).
For VHDL/Verilog, using generics is more complicated than using a package, since you need to wire the generics through your hierarchies until you reach the design code which writes the value to a register.
Synthesis tool dependency. Different tools have different commands to update the top level generic values.
JTAG USERCODE
Most FPGAs support the IEEE Std. 1149.1 JTAG feature USERCODE, which gives the user a 32-bit value to identify the bitstream. This value can be set using the Vendor tools when creating the bitstream file. However, this value cannot be read by the FPGA's logic (unless you implement logic to read the flash and track the correct address for this value, which is a big overkill).
Pros:
Fit for most devices.
Version information is accessible by examining the file.
Cons:
Version information cannot be read by the logic without extreme procedures.
Limited information size (only 32 bits).
Xilinx USR_ACCESS Register
Similar to the JTAG USERCODE, Xilinx have a implemented a USR_ACCESS Register for Virtex-5, Virtex-6, and all 7 series devices. They provided a primitive for VHDL/Verilog to allow you to read the value via logic.
More information here: http://www.xilinx.com/support/documentation/application_notes/xapp497_usr_access.pdf
Pros:
Version information can be read by the design logic.
Version information is accessible by examining the file.
Cons:
Solution for specific devices (not even all Xilinx devices support this).
Limited information size (only 32 bits).
ROM static information
You can implement a version information ROM and use an external file to set its value. (see Verilog : Memory block Instantiation)
Pros:
Can include large version information (even ASCII code).
Version information viewable by the designer (external file).
Fit for most devices and tools which accept the VHDL/Verilog code for ROM.
Cons:
A bit more complicated logic may be required to read all the ROM (depends on how you implement it).
It is difficult (yet possible) to examine version information by examining the file (You need to extract ROM bitstream locations).
Flash image modification
Many systems have their FPGAs load from flash devices. Usually there is more room than just the FPGA bitstream. It is possible to create a large flash image file to include extra information, among which is version information. This is probably to worst option of all I've written above, and mentioned this for completeness.
Pros:
Potentially large information cache.
Flash image file can be examined for version information.
Cons:
Difficult to implement.
Dependent on vendor tools.
I'm using XST (synthesis tool in the Xilinx ISE 14.7 suite) to compile VHDL source files to a netlist (*.ngc file).
My code uses several Xilinx IP Cores like ChipScope ILAs for debugging, which are also pre-synthesized as ngc files. I would like to ship only one ngc file to our costumer. It's a proof of concept design, so he should see a simple interface:
- our IPCore + VHDL component
- his ChipScope ICON IP Core / netlist with 5 open ports for our IP Core
How can I merge these ngc files info one ngc file?
The ISE design flow uses "Translate" to merge all netlists together and emits a ngd file, which is the input for the "Map" step.
Internal debates on how easy it was to find the answer aside there's some cause for propagating the question and it's answer in Stackoverflow. The idea being Stackoverflow is a search resource before someone asks the same question again, striving to be a higher quality resource in general than found by searching the Internet at large.
While googling merge .ngc Xilinx I found the very first hit lead to an answer on the Xilinx web site (See NGC File include. NGC file problem asking how to merge Native Generic Compiler (ngc) netlists, the answer leading to a now dated v 1.2 UG628 Command Line Tools User Guide, the latest is v 14.7 available only through that version's Help Center, it doesn't show up in on line searches).
So there's a command line tool named ngcbuild that's described as capable of merging .ngc netlists in Chapter 24 of the Command Line Tools User Guide:
The NGCBuild utility:
Compiles multiple source netlists (EDIF and NGC files) into a single NGC file that can be delivered as an atomic entity (also knownas “incremental linkage”).
Annotates a User Constraints File (UCF) onto an existing netlist or collection of netlists
We look in the linked Xilinx support item and we see the presumption that merging netlists is done for ChipScope just as Paebbel's asks. This is a common thread through most of the uses for merging .ngc netlists.
This is supported in the ChipScope Pro Software and User Guide, (UG029, v 14.3) which demonstrates usage. See the section Edit CDC Project Step:
The Edit CDC Project step of the command line ChipScope Pro Core Inserter flow is used to bring up the ChipScope Pro Core Inserter GUI to edit an existing CDC project (see Figure 3-3). The ngcbuild tool is called during this step with the specified arguments following the -ngcbuild argument. The ngcbuild tool combines all netlists associated with the design into a single complete NGC netlist file. This allows the ChipScope Pro Core Inserter tool to provide full debug access to all levels and nodes in the design.
(Without invoking ChipScope repeatedly.)
It certainly appears to be the right tool for what the question asks, and the usage of Chipscope implies it's need in a lot of cases according to the googling results.
I have a vhdl design that is created in Xilinx ISE and I would like to bring it over to the XPS/EDK 14.2 as a pcore. The issue is, I am not really sure how I should be hooking it up. The XPS utility gives me the option of an AXI Burst bus. Am I suppose to create an interface to hook up the AXI signals to my module? I am not really sure how I am suppose to use it as a pcore, since I am new to the XPS tool. I was under the impression the XPS tool would make the appropriate hook ups for me (i.e. ACLK would connect to my clock, etc.).
Any background information would be appreciated. I am only finding tutorials with the older version of XPS and it doesn't really cover my issue.
Have you looked into tools like ImpulseC from Impulse Accelerated Technologies?
I have had years of good results using that tool to develop pcores in ANSI-C and them exporting the results into correctly formed Xilinx pcores.
If you asked, I'm sure you could get a demo license to see if it would help in your situation.
It spits everything out in VHDL and you can read through the results to see how to do it.
I have xilinx macros for uart (.edn files) and i don't know how to use the in activehdl
when i simulate the macros the give uninitialized output ? so what if any one can help me with the right way to use the macro ...?
Use the Xilinx uniMacro library. You may need to compile or download it for your simulator.
ActiveHDL is a simulator package. It typically operates by compile VHDL or Verilog code. The "macros" you are refering to with the extension ".edn" are EDIF netlist files. These are not files that can typically be used by simulator, but are in almost all cases only usable by the synthesizer for the exact device they are targeting.
It may be the case that ActelHDL can import EDIF files. In this case, it still will only work if the primitives used by the EDIF file are also added as part of the project. As another answer said, this most likely would be primitives from the Xilinx unisim library.
The best option is to probably run the EDIF files you have through the Xilinx tools (specifically "Translate" (ngdbuild) and "Generate Simulation Netlist" (netgen)) to generate a simulation model for these pieces. The result will likely require the Xilinx unisim and simprims libraries, which are usually available precompiled for most simulators, but can also easily just be pointed to the source in the Xilinx ISE install.
I'm using VHDL on Xilinx ISE to generate a schematic of the register transfer logic in my project. I know ISE does a number of optimizations and gate reductions before spitting out the RTL and Technology schematics. What I want to do is to export the netlist of these schematics into some file so I can use that for my own program. Is there any way to do this? I keep reading about ngc files, but the contents of the ngc file generated upon synthesis make absolutely no sense.
Please let me know if you've done this before, I'd love to see how this is done. If it's not doable on ISE, can you recommend a tool that could do it?
EDIF is an industry standard format for describing netlists - there are numerous tools for interpreting them and you could easily roll your own since it's a documented textual format.
You can convert an .ngc into an edif file by running the Xilinx tool ngc2edif included in the ISE suite.