07-17-2009 01:53 AM
07-17-2009 05:44 AM
2 options for you to consider....
1) Add a top-level generic to your module and then use a generate statement, e.g.
variantname: boolean := true
variantname_0_g: if not variantname generate
signalname <= '0';
end generate variantname_0_g;
variantname_1_g: if variantname generate
signalname <= '1';
end generate variantname_1g;
You can then set the generic using the -"generics" switch in XST. See the XST User Guide for more information (xst.pdf). I believe this feature was added in 9.1i.
2) Define this signal above in a package included by the top-level module instead of a generic. Decide at build time which one of two source files that define this signal to copy over to this package before synthesizing it - or change keep the same name for the file but in different subdirectories and reference a different .prj file for XST to compile the right one)
I assume you'll also want to have the makefile for these two different configurations handle the file names apropriately so you can keep them straight easily by looking at the filenames of the output files from the flow, e.g. name_0.bit and name_1.bit
There might be other ways, but those are two that come to mind...
08-14-2009 03:04 AM
08-14-2009 10:09 AM
timpe, thanks for your reply. A deeper look into our environment shows that your suggestions is good but not enough for us. :-) We have different FPGA devices on different hardware revisions, where different hardware revisions means that we use FPGA pins differently. So we split our SVN repository to achieve our requirements...
But we still dream of some sort of #if/#ifndef for VHDL as I wrote above. ;)
The generate statement driven by generics is essentially the same as the C preprocessor directives. You can control and override generics from the command-line or from within ISE, and this will not break your flow. Of course you will need to add the generics and generates to your source.
Having said that -- if your PCB supports several different functions in the same FPGA socket, then maintaining these different functions as separate projects is probably a good idea. The stuff that is common to the various different configurations can be brought into each using svn:externals.