Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

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

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

12 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.