Forum Discussion

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

how to export macro to system.h?

eg, I want to put

# define MOD_0_FREQ 50000000u

to system.h as many altera sopc ip do. And I try to add some line in the MOD_hw.tcl:

add_parameter FREQ_PARAM 0

set_parameter_property FREQ_PARAM SYSTEM_INFO CLOCK_RATE {clock}

set_module_assignment embeddedsw.CMacro.FREQ [get_parameter_value FREQ_PARAM]

(these line may not be exactly, i can't remember clearly..)

But when i open sopc builder, it says "get_parameter_value can not run GLOBAL", so what is wrong with those tcl command?

11 Replies

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

    This is how I'm doing it:

    In the main part of the .tcl file I have this:

    add_parameter CLOCK_SPEED INTEGER 1

    set_parameter_property CLOCK_SPEED AFFECTS_GENERATION false

    set_parameter_property CLOCK_SPEED HDL_PARAMETER false

    set_parameter_property CLOCK_SPEED SYSTEM_INFO { CLOCK_RATE clock_reset }

    In my elaboration callback I'm using this:

    proc elaborate_me {} {

    set_module_assignment embeddedsw.CMacro.CLOCK_FREQUENCY_IN_HZ [get_parameter_value CLOCK_SPEED]

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

    There are a couple of good documents on all of this..

    http://www.altera.com/literature/hb/qts/qts_qii54022.pdf

    http://www.altera.com/literature/hb/nios2/n2sw_nii52018.pdf

    We use the validation phase for the main clock frequency that feeds a SOPC module as it is usually derived and you don't really want them editable in the gui..

    But I guess it's much the same depending on how you write the proc callback....

    ******* The following is in the ___hw.tcl file for the component **

    set_module_property VALIDATION_CALLBACK validate

    add_parameter clock_freq INTEGER

    set_parameter_property clock_freq SYSTEM_INFO {CLOCK_RATE "clock"}

    proc validate {} {

    set_module_assignment embeddedsw.CMacro.FREQ [get_parameter_value clock_freq]

    }

    ****

    This will add a C Macro to the system.h file like this# define "SOPC_MODULE_NAME"_FREQ 1000000

    the "clock" above is the endpoint you defined somewhere else in you tcl file.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks for the posts, helped me get things working--with a caveat. I'm passing parameters for a custom instruction, and so I've added the following to my validation callback:

    set_module_assignment embeddedsw.CMacro.SYNCHRONOUS [get_parameter_value SYNCHRONOUS]

    What ends up happening is that the parameter shows up twice in my system.h, once as

    # define "SOPC_MODULE_NAME"_SYNCHRNOUS 0

    which is what I want and expect, and once just as

    # define SYNCHRONOUS 0

    after the custom instruction macros, which I don't expect and is probably bad.

    Any idea what might be happening? It seems like a bug (I'm using the Web edition of 11.1sp1 in linux). Right now it's not a problem, but if I want to do something like have two custom instructions in the same system, bad things happen (#define SYNCHRONOUS happens twice, bsp generation fails).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Try 'set_interface_assignment' instead. I've noticed that set_module_assignment duplicates paramaters for each interface which may or may not be what you want. I think you'll end up with a longer name of <module name>_<interface_name>_<parameter> but the module name should be unique between your two custom instructions.

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

    Hrm. So I added

    set_interface_assignment ci_slave embeddedsw.CMacro.CI_SLAVE_SYNCHRONOUS [get_parameter_value SYNCHRONOUS]

    to the validation callback, and it shows up correctly in my .sopcinfo under the interface, but nothing got added to system.h after generation...

    I can workaround this by assigning some unique ID to each parameter (the base address of the custom instruction, or the instance name if there's an easy way to get it in the tcl script) if I have to, but it seems like there should be a better solution.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Can you file this as a service request on the Altera website and attach the system and custom instruction files. I have a hunch what is happening here and I think you are running into a bug (in both cases) that I don't think can be easily worked around.

    For now I would create a non-HDL parameter into your .tcl file and append it to the end of "SYNCHRONOUS". That way when you add the CI you can ennumerate them to avoid the overlapping '#define SYNCHRONOUS'.

    I think this should work assuming you call the non-HDL parameter "ID" and the combined name "UNIQUE_NAME".

    append UNIQUE_NAME "SYNCHRONOUS", $ID

    Then you would use "UNIQUE_NAME" to create the macro for the header file. You could use ID = 0 for one CI, and ID = 1 for example make sure there is no overlap in names. Note I hate .tcl so you might need to tweak that code a bit to get it to work :)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I found a bug report that states set_interface_assignment isn't working correctly so that explains why system.h didn't contain what I was expecting when I had you try it.

    So that workaround I mentioned is probably the only way to get around this.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks. Filed the bug report, and figured out at least that the reason I have two entries is that I have a MM avalon slave in the custom instruction, and the

    # define "INSTANCE_NAME"_SYNCHRONOUS 0

    goes away if I remove the avalon slave. The

    # define SYNCRONOUS 0

    is associated with the custom instruction. Having separate entries for the custom instruction and avalon slave makes sense, but there needs to be a prefix on the custom instruction parameter name so I can have multiple instances.

    Haven't tried the workaround yet as I'm working on other things and it's not blocking me at the moment, but will let you know if I run into problems.