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

[Altera_Forum]

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

[Altera_Forum]

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]

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]

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]

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]

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]

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]

Of course DOUTSIZE 24 is wrong in my example. DOUTSIZE DSIZE ist correct.

[Altera_Forum]

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]

Why do you want to generate HDL from bdf file?

[Altera_Forum]

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.

[Altera_Forum]

Hi FvM, 

 Thanks once again for your prompt reply.   I am glad that we both agree that there is a bug in the tool. For my part, I see it as a very fundamental one. Here are some noteworthy points. I am sure you will agree with them.  a) The very reason one would want to see the flexibility in the tool that allows port dimensions to be tied to a parameter (such as DSIZEOUT defined in the PARAM block) in a massively hierarchical design such as what I have, is to avoid going thru the trouble of manually manipulating/typing the dimension(s) of each an every port associated with various blocks that are directly effected by the incoming number of ADC bits (16, 12, 10, 8, etc).  b) If the ADC bits are reduced, then each and every block connected in chain (multiplier, filter, scaler/normalizer, etc) must reflect port_width reduction (in order to make the H/W efficient). The expectation therefore is that once the design is parametrized in terms of ADC bits entering the system, then then everything is seamless and effortless from the user perspective. Note I don't mind chasing multiple hierarchies and generating HDL code for hierarchies as long as there is no typing involved, as is the case here.   b) The reason HDL code has to be generated is because every time the incoming ADC bits are changed and a new design is 'generated', then a modelsim simulation has to be run as well in order to study the effect of quantization, performance loss, fixation of optimal bits at strategic nodes of the system etc. So code generation is a must, and there is no way around it.  c) I will get to Altera's hotline and report this bug and see if they can come up with a fix for this.   All of the above said, I'd like to thank you once again for your help.

[Altera_Forum]

I guess, the bug exists since long. Apparently, there aren't much designers using schematic entry for parameterizable design units, otherwise the problem had been noticed before. (Or they accepted to edit the generated code manually). 

 If you prefer schematic entry, you could also think about using ModelSim Designer. It has nice features beyond bdf.