cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
6,145 Views
Registered: ‎06-05-2009

Conditional compilation with Makefile build flow

Hi!

(I hope I'm on the right board, otherwise move me to the correct one)

In our current design we use the Makefile build flow (as discussed here: http://forums.xilinx.com/xlnx/board/message?board.id=SYNTHBD&thread.id=643) and we store the project in SVN. The project requires that we have two different binaries. Its basically that the outputs needs to be inverted (or not). I'm looking for a way to build different binaries without modifying the design. Analog to #ifdef/#ifndef in C/C++. Is it possible? For example by different script files for Xst? The only requirement we have is that we must not modify the sources for the project, this will break our build flow.

Thanks in advance!
0 Kudos
3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
6,134 Views
Registered: ‎08-13-2007

2 options for you to consider....

 

1) Add a top-level generic to your module and then use a generate statement, e.g.

 

  generic (

    variantname: boolean := true

  );

...

 

begin

 

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...

 

bt

0 Kudos
Highlighted
Visitor
Visitor
5,930 Views
Registered: ‎06-05-2009

Hello!

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. ;)
0 Kudos
Historian
Historian
5,923 Views
Registered: ‎02-25-2008


hwulff wrote:
Hello!

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.

----------------------------Yes, I do this for a living.
0 Kudos