Is there a way/workaround to use statements in a UCF file conditionally, or, can UCF files be included into other UCF files conditionally?
The problem I'm facing is that I have a top module with a set of generics which conditionally instantiate or remove certain submodules from the top module via generate statements.
However, most of these submodules have timing constraints defined in the projects UCF file.
Somewhere during map or par the build process is aborted stating that an instance the UCF file is refering to does not exist (which is correct since the instance was never created due to the choice of generics in the top module).
Whats the best possible way to achieve some sort of "conditional constraint", which can avoid this problem? (beside the obvious preprocessor/script which fingers around in my UCF file)
PS: I'm using the Xilinx ISE 14.4 / Vivado 2012.4 command line tools.
This question has been asked several times:
http://forums.xilinx.com/t5/Design-Entry/include-and-ifdef-for-ucf-files/td-p/77822
http://forums.xilinx.com/t5/Design-Entry/Conditional-inclusion-of-ucf-files/td-p/195684
Short answer is no, not possible unfortunately.
Your best bet is to create 2 separate UCF files and either create a script to point to one or the other or to manually replace it each time you turn on/off your generic switch.
IF you are using Vivado, then you should know that UCF files are no longer supported under the Vivado synthesis. Unless you have to use XST, then you no longer limited to use the out dated UCF file format for your constraints.
Vivado is using XDC constraints, which are a sub set ot TCL, which means you can write a code with conditions to handle your constraints in any way you desire.
You can take a look at the UG 903 from Xilinx for moredetails on how to use the constraints in the latest version of their tools:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug903-vivado-using-constraints.pdf
Another potential solution would be to use Xilinx synthesis attributes.
This can be done to constrain timing of nets, just like the UCF can.
The difference is, attributes can be done inline in VHDL, near the signal declaration.
It's clunky, though.
The right solution likely depends on how many constraints you have.
I upvoted FarhadA's answer, but I wanted to emphasize the point that XDC files are TCL scripts and so they can include conditionals and for loops. So much better than UCF files.
Another advantage of the constraint processing in Vivado is that if it encounters a constraint that does not match the design, it issues a Critical Warning and continues.
Related
I have come accross the idea to use pragmas to make PLC code as easy to re-configure from machine to machine depending on what a particular machine requires (they are very similar, but still require to some work to make for every new project). The machine as a whole can contain N units, then you would just remove certain parts if new project does not need it. My idea was:
VAR_GLOBAL
{attribute 'machinePart1'}
{attribute 'machinePart2'}
//{attribute 'machinePart3'} Lets say machine does not use attribute machinePart3
machineParts : BOOL; // dummy variable to add attributes
END_VAR
In the PLC code, I would then use conditional pragmas for code parts that require or don't require certain parts - you would determin which attribute exists by commenting out unnecessary ones.
In the PLC the parts of the machine that are not present would then be disregarded like this:
{IF hasattribute (variable: machineParts, 'machinePart3')}
//this code will not be executed
{END_IF}
{IF hasattribute (variable: machineParts, 'machinePart2')}
//this code will be executed
{END_IF}
{IF hasattribute (variable: machineParts, 'machinePart1')}
//this code will be executed
{END_IF}
So, my question is - is this a valid way to go about making a PLC code as easy to configure as possible? Does it affect efficency/CPU time? I havent looked deep into this, but I would assume the code is compiled, and for whatever conditional pragma the result is false, the code isn't complied and thus not present on the PLC itself when downloaded.
I would apply this to structures for machine parts and PLC code exectuion/function block instance creation.
Beckhoff already provides a solution for your requirements which is called variant management:
https://infosys.beckhoff.com/english.php?content=../content/1033/variant_management/6325752587.html&id=
This does not affect performance as the compiled code only includes the variant that you have chosen.
Jakob is right, there is already a variant management for the project level. And the link describes all necessary steps. The only thing to add here is a little advice from someone who has already fallen on his face with it several times. Be carefull with or rather just don't use the group feature (<=TC4024.20). The behaviour is really strange and very error-prone, from my point of view.
I'm creating code for interfaces specified in IBM Rational Rhapsody. Rhapsody implicitly generates include statements for other data types used in my interfaces. But I would like to have more control over the include statements, so I specify them explicitly as text elements in the source artifacts of the component. Therefore I would like to prevent Rhapsody from generating the include statements itself. Is this possible?
If this can be done, it is mostly likely with Properties. In the feature box click on properties and filter by 'include' to see some likely candidates. Not all of the properties have descriptions of what exactly they do so good luck.
EDIT:
I spent some time looking through the properties as well an could not find any to get what you want. It seems likely you cannot do this with the basic version of Rhapsody. IBM does license an add-on to customize the code generation, called Rules Composer (I think); this would almost certainly allow you to customize the includes but at quite a cost.
There are two other possible approaches. Depending on how you are customizing the include statements you may be able to write a simple shell script, perhaps using sed, and then just run that script to update your code every time Rhapsody generates it.
The other approach would be to use the Rhapsody API to create a plugin/tool that iterates through all the interfaces and changes the source artifacts accordingly. I have not tried this method myself but I know my coworkers have used the API to do similar things.
Finally I found the properties that let Rhapsody produce the required output: GenerateImplicitDependencies for several elements and GenerateDeclarationDependency for Type elements. Disabling these will avoid the generation of implicit include statements.
I'm creating a VHDL project (Xilinx ISE for Spartan-6) that will be required to use decimal "real-style" numbers in either fixed/floating point (I'm hoping fixed point will be sufficient).
Being quite new to VHDL, I found out the hard way that the non-constant real types are not supported for synthesis, so I set about searching for a IP core or library to redress this.
So far I've found 3 options;
1) A floating point IP core provided by Xilinx
2) A downloadable "ieee_proposed" library written by a David Bishop found here
3) After spending a fair while attempting to work out how to "create" a new library with David Bishops files in, I took a quick look through the default IEEE library and saw it contains ieee.fixed_generic_pkg and ieee.fixed_pkg packages.
My question is - of the two libraries - which one would be sensible to use? Is one adapted for synthesis and one not, or one older than the other? And then if floating point is provided, is there any real point to the floating point IP core provided by Xilinx?
I've trawled through many questions of people attempting to add the ieee_proposed libraries, but none seem to have referenced the fact they they already seem to exist in the existing IEEE.
Thanks very much for any help!
============UPDATE (Essentially my own efforts to resolve)==================
I can't actually use the ieee.fixed_pkg - and attempting to do so gives me the error Cannot find <fixed_pkg> in library <ieee>.
After finding the ieee library at C:\Xilinx\14.7\ISE_DS\ISE\vhdl\xst\nt I've found that the fixed_pkg actually resides in ieee_proposed. However, this still throws up the same errors!
Dumb question, but when you downloaded the ieee_proposed did you also remember to compile it?
edit: And also remember to map the library to you simulation as well. Maybe you did all this already but these are the mistakes I make often.
I've been battling with the same problems for days.
The way I solved it is:
1. Add fixed_float_types_c, fixed_pkg_c and float_pkg_c vhdl files to project.
2. Declare them as belonging to work library (Properties in Quartus files window)
3. Compile project and call library using:
Library work;
use work.fixed_pkg.all;
To my annoyance, they don't come up in the nice red writing I want them to but it works!
I'm having some trouble designing a single port rom onto a spartan 6 board. I use the provided core generator to create block memory and choose single port rom with 32 bit width and 256 depth with a coe file that just counts from 0 to 255. I drop the rom into my vhdl as a component and add the XilinxCoreLib as a library. When I try to generate the programming file I get the translate error:
logical block 'rom1' with type 'rom' could not be
resolved. A pin name misspelling can cause this, a missing edif or ngc file,
case mismatch between the block name and the edif or ngc file name, or the
misspelling of a type name. Symbol 'rom' is not supported in target
'spartan6'.
I'm currently using Xilinx ISE 13.1 if that helps. I feel like this should be really easy to do but I haven't been able to find how to do it.
Edit: Thanks everyone, was a combination of things. Wrong speed grade, and didn't add a copy of the ngc file to my working directory. I'll use arrays in the future.
Easiest way is to forget the vendor tools altogether and simply declare a constant array!
If this is in a package separate from the rest of the design, a few lines of printf's or a simple script can generate the VHDL boilerplate around the contents, which come from your assembler or whatever tool creates the actual data
Since you're adding a Xilinx generated core to your design in ISE, you need to add both the VHD file and the NGC file via "Add Source" via the Project menu.
Even easier, depending on how large your ROM needs to be and what data goes into it, would be to not even bother with a Xilinx core, but to use pure VHDL to declare a constant array and initialization values right in your VHDL file. Here is an example:
type array_ROM is array (0 to NUMBER_OF_ROWS-1) of std_logic_vector (ROM_BITWIDTH-1 downto 0);
signal my_ROM : array_ROM
:=
(
x"12345678",
x"ABCDEF01",
...
x"01010101"
);
Now, you don't put the elipsis (...) in that initialization list, just put rows of constants with bit widths matching ROM_BITWIDTH. The NUMBER_OF_ROWS is the number of address locations you need in the ROM. In this example, ROM_BITWIDTH would have to be set to 32 as I've used 32-bit hexadecimal constants in the initialization list. Being a signal, it's actually modifiable, so if you need it to be constant, just use "constant" instead of signal.
I guess the problem is, as the message says, a misspelling. to get the correct component declaration/instantiation, select your rom.xco in the design-window of ISE. then select "view vhdl instantiation template" from process window. use the component declaration and instantiation described therein.
There are a number of things that can cause this problem, one is that you are using a blocck that was generated for another FPGA family and using it inside the Spartan6. the other is that you may have generated the ROM using an older version of the tool and the wrapper for the ROM has changed since then.
You can either generate a anrray like Brian suggested and forgetting about the tool specific ROM type, or re-generate the IP under your curernt project settings and see how it goes.
Is there any way of telling ISE to synthesize my VHDL/Verilog code into combinational circuits consisting only of look-up tables? I would like to avoid multiplexers, multipliers, and the like in the tech schematic... and wouldn't mind having an unoptimized (with many components than is optimal) version because of this preference.
Thanks SOCommunity!
There is a way to do that. Look at the XST user guide for switches that control the use of the primitives you want to avoid:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst_v6s6.pdf
or:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst.pdf
depending on your target architecture.
For example, to avoid DSP blocks use:
-use_dsp48 no
To avoid automatic packing into BRAMs use:
-auto_bram_packing no
This switch can also be useful:
-slice_utilization_ratio
as will others.
I have a convenient way to look at the available switches, along with some explanation of what they do, on my site:
https://www.boldport.com/flow/#new/options
(click 'Edit', and then 'More options...')
I hope this helps.
In Xilinx you can use the Language templates for this purpose. Select the device you are using and check the available type of LUT's and other components. You can individually instantiate these LUT in your design.
You may have to switch off the "optimization during synthesis" option in XST properties to make this work correctly.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/ise_p_lt_using_language_templates.htm