Hello, Q1. This concerns the issue of fully 'parametrizing' a design so that the parameter to be exported can be set at the top-most level in a project. For example number of bits at the o/p of an ADC (8 bits, 10 bits, 12 bits, and so forth). Furthermore the project comprises of a lot of multiple hierarchies of BDF modules/sub-modules. Clearly it is too much work to build one design per one setting of a parameter (ADC bits in this case, but could have more parameters). Also, I am not looking to 'massage' the generated code in HDL domain via defParam. This is a Quartus 'design entry' type of question. The goal is to create a parametrized design, so that any number of 'variant-designs' can be generated at will, perform subsequent compilation of the design, and use the existing logic lock bounding boxes, etc. Q2. If there is a way to tackle Q1, the next question is ...How to change the port dimension associated with an existing port so that it is a function of a passed in parameter. For instance an output port associated with a block : how to change out_bits[11..0] to something like out_bits[passed_in_dim..0], where passed_in_dim is an exported parameter. Q3. Assuming there are no workarounds for Q1, and Q2, the only other thing that comes ti my mind is to develop Tcl/Tk scripts that queries the design, obtains the Instance Id of the block, pushes into the instance, gets handle on the parameters, ports, etc changes parameters, modifies port dimension (based on parameter value)....all via the Tcl/Tk script. In other words the final deliverable then would be the a) The BDF design b) The Tcl/Tk parametrization script with the provision to pass-in the required ADC bits. Can anyone point me to a tutorial chapter describing the process. Thanks

If you auto-generate a symbol file for a parameterized HDL entity, you'll notice that all generics/parameters are implemented as bdf symbol parameters, also parameterized dimensions are used for the ports. You can manually insert parameters in the bdf design, use them e.g. for signal and port dimensions or insert them as actual values for symbol parameters. Isn't that what you intend?

Thank you very much FvM. Your quick response is highly appreciated !. It looks like you have taken care of a good part of my queries/questions.However, the question that remains to be answered is how to parametrize DSIZE, so that it's value can be set from many levels above. Assume DSIZE comes in from 3 levels above. Based on this example, we need 3 instances of parameter boxes at 3 different hierarchies. So how do we pass the parameter values inside these parameter boxes sitting at different hierarchies. Thanks once again

A parameter defined in a bdf file will be fed from the above hierarchy. This way, parameters can be passed down through the hierarchies. It's exactly the same as with VHDL generics or Verilog parameters. It's about 5 years that I made a new bdf design, I'm nearly suprized that parameters are working that smoothly with schematic entry.

Hi Fvm, Thanks once again for your prompt response. However, I am not clear how the parameter passing will work in this context (I am not referring to vhdl generic, or verilog parameter), but viewed from within the framework of how parameters gets passed around within the BDF design database from top above thru multiple hierarchies - Let's not worry about HDL generation. The part I am not able to accomplish is to make the value 24 (default value) on PARAM DSIZE change to what is being set from the top - say 20. Let's go with your example in which you have an instance of a block (cic_filter). I see that You have attached ports to this block and parametrized the port dimension based on DSIZE (default value 24). So if you were to generate HDL at this point, you should see the port dimensions appear correctly in the generated file verilog/VHDL. So far, so good. Now let's create a symbol out of the cic_filter with input/output ports as shown. What would be the next step ? Let's add an instance parameter called DSIZE and associate with the newly created symbol. If we were to instantiate the newly created symbol (call it cic_filter_top) and set the instance parameter (DSIZE) and set it's value to say 20, will the value 20 propagate below and 'overwrite' the default value of 24 in PARAM SIZE ? I am afraid, I don't see that happen in my case. This means we have to 'do' something to the default value at the cic_filter level, or rather make it point to the top level's instance parameter, so that the 'default value' is overriden. Now how to do that ? Thank you once again

All you have to do is to replace the numeric parameter value by the new parameter in the symbol's parameter box or table, as I did in the example. To see the effect, look at the respective entity parameter tab in the compilation report.

exporting parameters and manipulating dimension of a BDF design in Quartus II

12 Replies

Altera_Forum
Honored Contributor
15 years ago
If you auto-generate a symbol file for a parameterized HDL entity, you'll notice that all generics/parameters are implemented as bdf symbol parameters, also parameterized dimensions are used for the ports.

You can manually insert parameters in the bdf design, use them e.g. for signal and port dimensions or insert them as actual values for symbol parameters. Isn't that what you intend?
Altera_Forum
Honored Contributor
15 years ago
Thank you very much FvM. Your quick response is highly appreciated !.

It looks like you have taken care of a good part of my queries/questions.However, the question that remains to be answered is how to parametrize DSIZE, so that it's value can be set from many levels above. Assume DSIZE comes in from 3 levels above. Based on this example, we need 3 instances of parameter boxes at 3 different hierarchies. So how do we pass the parameter values inside these parameter boxes sitting at different hierarchies.

Thanks once again
Altera_Forum
Honored Contributor
15 years ago
A parameter defined in a bdf file will be fed from the above hierarchy. This way, parameters can be passed down through the hierarchies. It's exactly the same as with VHDL generics or Verilog parameters.

It's about 5 years that I made a new bdf design, I'm nearly suprized that parameters are working that smoothly with schematic entry.
Altera_Forum
Honored Contributor
15 years ago
Hi Fvm,

Thanks once again for your prompt response. However, I am not clear how the parameter passing will work in this context (I am not referring to vhdl generic, or verilog parameter), but viewed from within the framework of how parameters gets passed around within the BDF design database from top above thru multiple hierarchies - Let's not worry about HDL generation. The part I am not able to accomplish is to make the value 24 (default value) on PARAM DSIZE change to what is being set from the top - say 20.

Let's go with your example in which you have an instance of a block (cic_filter). I see that You have attached ports to this block and parametrized the port dimension based on DSIZE (default value 24). So if you were to generate HDL at this point, you should see the port dimensions appear correctly in the generated file verilog/VHDL. So far, so good.

Now let's create a symbol out of the cic_filter with input/output ports as shown. What would be the next step ? Let's add an instance parameter called DSIZE and associate with the newly created symbol. If we were to instantiate the newly created symbol (call it cic_filter_top) and set the instance parameter (DSIZE) and set it's value to say 20, will the value 20 propagate below and 'overwrite' the default value of 24 in PARAM SIZE ? I am afraid, I don't see that happen in my case. This means we have to 'do' something to the default value at the cic_filter level, or rather make it point to the top level's instance parameter, so that the 'default value' is overriden. Now how to do that ?

Thank you once again
Altera_Forum
Honored Contributor
15 years ago
All you have to do is to replace the numeric parameter value by the new parameter in the symbol's parameter box or table, as I did in the example. To see the effect, look at the respective entity parameter tab in the compilation report.
Altera_Forum
Honored Contributor
15 years ago
Hi FvM,

Thanks for your help and assistance - Much appreciated.

However I am badly stuck with the port dimensioning problem (not parameter passing). Parameter passing is resolved now (thanks for your help) and works up to any level of hierarchies via PARAM block instantiation. The real problem is as follows :

a) In your cic_filter example, when you generate HDL (VHDL or Verilog) at that level, you will notice that the port dimensions on the ports connected to the cic_filter is already statically(as opposed to dynamically re-dimensioned) dimensioned from the default PARAM block value (24 in this case). This is where the problem lies.

b). Now assume that a symbol is generated for this BDF : call it cic_filter_top.

c) Quartus generates HDL in a black box sense (not flattened sense). So this means you have to create HDL for b) which is the design instantiating cic_filter_top.

d) While it is true that the parameter DSIZE will get set and passed on down below via VHDL generic, or Verilog DefParam, but the fact still remains that the port dimension of HDL generated in item a) still refers to 24. Meaning it is not going to get re-created. In other words, the damage has already been done and it does not look like anything can be done about it (I hope I am not missing anything here).

The other possibility I am think about is to 'massage' the BDF/BSF text files via reg-exp pattern-matching/replacement, and therefore directly editing the database file. That way when the blocks are pulled up in Quartus for HDL generation, the correct dimensions will appear. Do you see any thing wrong with this approach ?. Or perhaps you have a better alternative.

Thanks in profusion for your help. - Much appreciated.
Altera_Forum
Honored Contributor
15 years ago
Of course DOUTSIZE 24 is wrong in my example. DOUTSIZE DSIZE ist correct.
Altera_Forum
Honored Contributor
15 years ago
Hi Fvm,

Thanks for the reply. I trust you have the feel of the problem now, which in my opinion is unsolvable, since it is a fundamental tool issue. I am summarizing it one more time below :

a) When you generate HDL from the BDF picture you sent me, the port dimensions appearing in the generated HDL are statically dimensioned with numbers (24, 20, or whatever). The value depends on what the default setting on the PARAM block is.

b) When you generate code from the top design that instantiates the BSF corresponding to the BDF in item a), you can pass parameters into the lower level without any problem (HDL generated in a) and have tthe parameter referenced inside the cic_filter, but nothing changes at the port map level. This is the fundamental problem of the tool.

So in summary, and simply put...the port dimensions of a low level hierarchical block will not get modified automatically by setting a parameter coming in from the top. You may use the parameter inside the code for any other purpose, but may not use it to auto-re-dimension the ports. So I think the only way to get around this problem is to do scripting on the BDF/BSF files (both are text files).

Thanks once again.
Altera_Forum
Honored Contributor
15 years ago
Why do you want to generate HDL from bdf file?
Altera_Forum
Honored Contributor
15 years ago
I see the problem in generated HDL. It's simply a bug. It's importance depends on what's the role of generated HDL in your design process.

Forum Discussion

exporting parameters and manipulating dimension of a BDF design in Quartus II

12 Replies

Recent Discussions

how to reduce clock skew between synchronous clock

Duplicate_hierarchy_depth / duplicate_register

Quartus - Users getting license Notification with new license applied

Quartus messages web search goes to Intel

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device 1SN21CEU2F55E2VG?