Forum Discussion

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

Set properties of VHDL package file from component TCL file

Hello,

is it possible to change a value in a VHDL package file from a component TCL script?

I have a component which is parameterized by a constant value which is set in a package:

package constants_pkg is

--! @brief Symbol width of the Avalon bus

constant avalon_symbol_width_c : integer:= 8;

end package constants_pkg;

package body constants_pkg is

end package body constants_pkg;

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    you could get the TCL script to modify the VHDL and change the constant.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Here's some Tcl code I use in an SOPC _hw.tcl file ...

    
       #  Replace the generic values (suffixed by _VAL in the template)
        set params {
            AWIDTH
            BWIDTH
            DWIDTH
            CLK_FREQUENCY
            WRITE_CYCLE
            READ_CYCLE
            AWIDTH_MINUS_1
            BWIDTH_MINUS_1
            DWIDTH_MINUS_1}
        foreach param $params {    
            eval set buffer \ \$buffer\]
        }
    

    to replace the generics in a template file ...

    
        u1: ftdi_to_avalon_mm_bridge 
            generic map (
                CLK_FREQUENCY => CLK_FREQUENCY_VAL,
                READ_CYCLE    => READ_CYCLE_VAL,
                WRITE_CYCLE   => WRITE_CYCLE_VAL,
                AWIDTH        => AWIDTH_VAL,
                BWIDTH        => BWIDTH_VAL,
                DWIDTH        => DWIDTH_VAL
            )
            port map (
                -- Reset and clock
                rstN        => rstN,
                clk         => clk,
                -- FTDI interface
                ftdi_rxfN   => ftdi_rxfN,
                ftdi_txeN   => ftdi_txeN,
                ftdi_rdN    => ftdi_rdN,
                ftdi_wr     => ftdi_wr,
                ftdi_dq_oe  => ftdi_dq_oe,
                ftdi_dq_out => ftdi_dq_out,
                ftdi_dq     => ftdi_dq,
                -- Avalon-MM interface
                avm_read    => avm_read,
                avm_write   => avm_write,
                avm_byteen  => avm_byteen,
                avm_addr    => avm_addr,
                avm_wrdata  => avm_wrdata,
                avm_rddata  => avm_rddata,
                avm_wait    => avm_wait,
                avm_rdvalid => avm_rdvalid
            );
    
    The generic values ending in _VAL get searched-and-replaced by the Tcl code.

    You could do the same.

    The other way is to simple generate the package file from Tcl, or move the configuration values into their own package, eg.. config_pkg.vhd, and generate that. Much like you would with Autotools, ./configure, to generate a config.h file.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Would the script then modify the code? The best solution for me would be that it overrides the value given in the package for the generation of the system but it shouldn't touch the file.

    If this is not possible I would be interested in your solution which modifies the constant. Do you have an example on how to do that?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Would the script then modify the code?

    --- Quote End ---

    The script essentially generates the code. The template file has a .txt extension. For SOPC builder, each component is uniquely named, so the template is read into a buffer, the parameters are set, and then a .vhd file is written out.

    --- Quote Start ---

    The best solution for me would be that it overrides the value given in the package for the generation of the system but it shouldn't touch the file.

    --- Quote End ---

    Then the above will not work. Unless you consider 'the file' to be the template, and the package to be generated code.

    --- Quote Start ---

    If this is not possible I would be interested in your solution which modifies the constant. Do you have an example on how to do that?

    --- Quote End ---

    What is the constant doing? If the constant is a generic used on components within the design, then you can just set the generic in Quartus via a Tcl synthesis script or via the GUI. If however, you have a 'generic package', then it depends on the support for that feature in Quartus ... last time I looked that construct was not supported, but I haven't tried in 11.1sp1.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    i recently switched from make files and bash scripts to python for project builds

    the language is so pleasant and powerful that i've started to do this sort of dynamic generation

    my strategy is to have golden files which get copied into the generated project directory. the files can be modified upon copy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    What is the constant doing? If the constant is a generic used on components within the design, then you can just set the generic in Quartus via a Tcl synthesis script or via the GUI. If however, you have a 'generic package', then it depends on the support for that feature in Quartus ... last time I looked that construct was not supported, but I haven't tried in 11.1sp1.

    --- Quote End ---

    I should have chosen the following example:

    package simulation_pkg is

    -- if this constant is set to true some settings which have a strong

    -- impact on simulation time are set so that the simulation runs faster

    constant simulation : boolean := true;

    end package simulation_pkg;

    This setting influences the values of some counters and the bitwidths of some signals in my component. When this setting is set to true some initialization counters will count for only a few cycles instead of a few thousand cycles. This way the simulation time is drastically shortened. The synthesis will fail because if this value is set to true then the toplevel file expects some signals, which the component exposes, to have other bitwidths (luckily for me the synthesis fails in this case, it would be worse if synthesis was successful and I didn't recognize that I synthesized the system with the wrong settings...).

    Regards

    Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    my strategy is to have golden files which get copied into the generated project directory. the files can be modified upon copy

    --- Quote End ---

    Under what conditions have you found you need to modify files? Were generics not enough?

    An argument against copying unmodified source code into a project, is that it makes it harder to verify a suite of designs that use the component. For example, using Modelsim, you can compile components into a library, and then testbenches into another library, and then run all of the testbenches to confirm the functionality of the components in the library. You can then simulate multiple designs against the component library without having to build the source for each-and-every component, testbench, and design.

    In the _hw.tcl example I give above, a wrapper is generated for a component that uses generics with types that are not supported by SOPC Builder. Hence the wrapper is needed because of SOPC Builder, not because of VHDL or Verilog language limitations.

    I'm curious as to your experience with the need to generate code.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Ah, yes, I have had to solve that one too ... the following is just typed in (so the VHDL syntax might be slightly wrong):

    
    package simulation_pkg is
         function simulation returns boolean;
    end package simulation_pkg;
    package simulation_pkg body is
         function simulation returns boolean is
             variable result := false;
         begin
            -- altera translate_off
            result := true;
            -- altera translate_on
            return result;
         end function;
    end package simulation_pkg body ;
    
    The other synthesis constraint that can be useful is

    -- synthesis read_comments_as_HDL on

    -- synthesis read_comments_as_HDL off

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    
    -- synthesis read_comments_as_HDL on
    -- synthesis read_comments_as_HDL off
    

    --- Quote End ---

    This looks just what I was looking for. Thanks a lot!

    I'm still intimidated by the scripting solution as I still consider myself a FPGA/VHDL beginner.

    Regards

    Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I'm still intimidated by the scripting solution as I still consider myself a FPGA/VHDL beginner.

    --- Quote End ---

    There's plenty of people on this forum that will offer help.

    If you get stuck, just ask.

    Cheers,

    Dave