Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
2,128 Views

Passing parameter/generic to the top level in Quartus/tcl?

I'm trying to pass a git sha1 as a parameter to the top level in Quartus tcl 

 

 

I added a source probe: 

 

 

gits u_gits (.probe (160'habbaface000000000000000000000000acdcbabe)); Which I can read with a small script: 

./read-gits.sh GIT_SHA1: ABBAFACE000000000000000000000000ACDCBABE Then I do: 

 

 

module top # ( parameter GIT_SHA1 = 160'h0) ( input wire pad_clk_50m_fpga, ... gits u_gits (.probe (GIT_SHA1));  

 

./read-gits.sh GIT_SHA1: 3462636237316231396130366135366562373434 Which seem to be the ascii representation of the last 160 bits of the sha1 

 

 

Inside the project file I have: 

 

 

grep GIT_SHA1 project.qsf set_parameter -name GIT_SHA1 160'ha26916cc5fa8d5dbda994bcb71b19a06a56eb744 Then I tried to pass it as an integer 

 

 

grep GIT_SHA1 project.qsf set_parameter -name GIT_SHA1 927200069134354371996170413995076949976682510148 But then I just got: 

 

 

./read-gits.sh GIT_SHA1: 00000000000000000000000000000000FFFFFFFF  

 

So what is the recommended way to pass a 160 bit vector to the top level as a parameter or generic using tcl in Quartus? Passing it as a string would result in control characters and would require some quoting of tcl delimiters
0 Kudos
9 Replies
Highlighted
Valued Contributor III
81 Views

I'm not sure what you are trying to do here. If you are talking about synthesis, the parameter must be a set value at compile time. What does "read-gits.sh" actually look at and do? Are you talking about the In-System Sources & Probes debugging feature? It's a little confusing what's happening here.

0 Kudos
Highlighted
Valued Contributor III
81 Views

Yes it's synthesis in Quartus (17.0.2), it's a constant known at synthesis time, and it's a probe as in-system sources & probes. The script is using a quartus_stp tcl script which is simply calling "start_insystem_source_probe" and "read_probe_data -value_in_hex". 

 

To me it seems like Quartus can only pass 32-bit integers as parameters to the top level. 

 

I can use pre processor defines in verilog, but in vhdl I would have to generate vhdl code containing the constants unless Quartus can handle the vhdl number syntax better. This is quite cumbersome, and I would expect parameters/generics to work in Quartus. It works fine in simulation (modelsim, ncsim, and vcs) as well as in Xilinx Vivado where I can write (where $sha1 is a tcl variable holding the 160-bit value): 

 

set_property generic "GIT_SHA1=160'h$sha1"  

My question is if there is a way to pass a parameter/generic of a given size larger than 32-bit?
0 Kudos
Highlighted
Valued Contributor III
81 Views

Either if larger generics than 32 bit integer can be passed or not, isn't it much easier to generate a VHDL package or Verilog include file holding the parameters?

0 Kudos
Highlighted
Valued Contributor III
81 Views

It's not difficult to generate rtl code, but to me it's much simpler to put 

 

set_parameter -name GIT_SHA1 160'h$sha1  

into my build script. It's actually already there. It just doesn't work. I already have the same structure in my other scripts for simulation and build for other vendors.
0 Kudos
Highlighted
Valued Contributor III
81 Views

The answer is no. The passing of generics to top levels in quartus has been fairly limited for a long time. You're limited to strings, integers, booleans. 

You could probably pass it in as a string and have the HDL parse the string into a sensible value. The annoying part you'll find though, is that Quartus doesnt support textio during synthesis, so you'll probably have to write your own conversion function.
0 Kudos
Highlighted
Valued Contributor III
81 Views

Up to 32-bit integers... I find it a bit odd. They have a parser capable of parsing Verilog numbers so why not use this to parse the expression passed by the set_parameter tcl command. 

 

In Verilog it's possible to use the pre-processor as a work around: 

 

module top `ifdef M_GIT_SHA1 # ( parameter GIT_SHA1 = `M_GIT_SHA1) `else # ( parameter GIT_SHA1 = {20{8'h42}}) `endif ( input wire pad_clk_50m_fpga,  

And then set: 

 

set_global_assignment -name VERILOG_MACRO "M_GIT_SHA1=160'h$sha1"  

in the build script, which yields: 

 

$./read-gits.sh GIT_SHA1: 1B15850CADD9D969468FEE6669D86837E7B19239 $git rev-parse HEAD 1b15850cadd9d969468fee6669d86837e7b19239
0 Kudos
Highlighted
Valued Contributor III
81 Views

Verilog numbers are not integers. Integers in Verilog are 32 bit 4 state values (0,1,X,Z). Reg can be any length, but it is not an integer. 

I guess the restrictions come from system. And most people dont pass a lot into the top level.
0 Kudos
Highlighted
Valued Contributor III
81 Views

Yes I know Verilog regs/wires/logic types can have other values than integers/0/1 and are arrays/vectors. I expected scalar constants to work as it works in all the other tools mentioned, and since Quartus has a parser which presumably can parse Verilog constants witch could be re-used to parse parameters/generics. But again Quartus seem to support only up to 32-bit integers which I tried as a work around for the git SHA1 I tried to pass (160-bit vectors). Things could of course get ugly when you start to pass enums, packed arrays, structs, and combinations of these (even though not so common in synthesis).

0 Kudos
Highlighted
Valued Contributor III
81 Views

I think most tools are pretty consistant in what they support.  

Modelsim and ActiveHDL only support basic top level generics - integers, strings, booleans, logic_vectors (as a string). They do not support passing in arrays or records/structs
0 Kudos