set different constants for simulation than for synthesis (preprocessor?)

Discussion in 'VHDL' started by news.sunrise, Jan 18, 2007.

  1. news.sunrise

    news.sunrise Guest

    Hi NG

    Problem:
    When simulating (Modelsim) one might want to set certain values differently
    than for synthesis (Xilinx ISE).

    Unfortunately it seems there's no possibility to have conditional code
    blocks in vhdl depending on whether the code is read by a synthesizer or a
    simulator.

    Idea:
    Tell Modelsim to call a preprocessor script that does some regexp on the
    vhdl code before reading it. The value for simulation could be set in a
    comment string.

    This preprocessor could do the following:

    change:
    constant FOO : integer := 99999; --simValue(42)
    to:
    constant FOO : integer := 42;

    I could write such a preprocessor, but how to integrate it?

    Questions:
    -How to tell Modelsim to call a script automatically and read the output of
    the script?
    -Is there a better solution?

    Thanks for your help
    Alain
     
    news.sunrise, Jan 18, 2007
    #1
    1. Advertising

  2. news.sunrise

    Arnim Guest


    > Problem: When simulating (Modelsim) one might want to set certain
    > values differently than for synthesis (Xilinx ISE).


    Why would one want to do this? Your synthesized design will be different
    from what you simulate.

    > Idea: Tell Modelsim to call a preprocessor script that does some
    > regexp on the vhdl code before reading it. The value for simulation
    > could be set in a comment string.
    >
    > -Is there a better solution?


    I don't recommend to do this, but there is a better solution:

    constant simulating_c : integer := 0
    -- pragma translate_off
    + 1
    -- pragma translate_on
    ;

    A simulator will initialize the constant to 1. For the synthesizer the
    +1 is eclipsed and the constant is 0. You could do this for all your
    constants or simply use the trick once and derive all other differences
    from this result.
    Just ensure that the -- pragma <something> is recognized by your
    synthesis tool.

    Cheers

    Arnim
     
    Arnim, Jan 18, 2007
    #2
    1. Advertising

  3. news.sunrise

    Duane Clark Guest

    news.sunrise wrote:
    > Hi NG
    >
    > Problem:
    > When simulating (Modelsim) one might want to set certain values differently
    > than for synthesis (Xilinx ISE).


    The caveat applies that doing this means your simulation doesn't match
    the real hardware. That said...

    One method I have used is to make the values I want to change into
    generics, with the defaults being what I want to use for synthesis. Then
    I put a configuration specification in surrounded by
    translate_off/translate_on:

    --synthesis translate_off;
    for ctrl_d: CTRL
    use entity work.CTRL
    generic map (
    SRCNT_START => X"28000",
    SRCNT_END => X"280FF"
    )
    port map(
    RESET => RESET,
    CLK => CLK,
    ...
    );
    --synthesis translate_on;
     
    Duane Clark, Jan 18, 2007
    #3
  4. news.sunrise

    Andy Guest

    Indeed top level generics are probably the best way to go. I usually
    set the default values to be appropriate for synthesis, although some
    synthesis tools allow top level generics to be overridden as a
    synthesis option (most simulators also allow this).

    When simulating, you normally have higher level testbench that
    instantiates the synthesizable design. In the instantiation, those
    default generics can be overridden by a generic map in the
    instantiation. Those generics can be set to values from other generics
    passed down from the top level, which in turn can be set via simulator
    options.

    This can all be done without a configuration at all if you use direct
    entity instantiation, and not have to mess with a component declaration
    either (vhdl '93 feature)

    DUT: entity work.CTRL(rtl) -- use architecture rtl of ctrl
    generic map (
    SRCNT_START => X"28000",
    SRCNT_END => X"280FF"
    )
    port map(
    RESET => RESET,
    CLK => CLK,
    ...
    );

    Andy

    Duane Clark wrote:
    > news.sunrise wrote:
    > > Hi NG
    > >
    > > Problem:
    > > When simulating (Modelsim) one might want to set certain values differently
    > > than for synthesis (Xilinx ISE).

    >
    > The caveat applies that doing this means your simulation doesn't match
    > the real hardware. That said...
    >
    > One method I have used is to make the values I want to change into
    > generics, with the defaults being what I want to use for synthesis. Then
    > I put a configuration specification in surrounded by
    > translate_off/translate_on:
    >
    > --synthesis translate_off;
    > for ctrl_d: CTRL
    > use entity work.CTRL
    > generic map (
    > SRCNT_START => X"28000",
    > SRCNT_END => X"280FF"
    > )
    > port map(
    > RESET => RESET,
    > CLK => CLK,
    > ...
    > );
    > --synthesis translate_on;
     
    Andy, Jan 19, 2007
    #4
  5. news.sunrise

    Jim Lewis Guest

    You can avoid the "translate_off" ... by using
    configuration declarations that are in a separate file.

    >> Hi NG
    >>
    >> Problem:
    >> When simulating (Modelsim) one might want to set certain values
    >> differently than for synthesis (Xilinx ISE).

    >
    > The caveat applies that doing this means your simulation doesn't match
    > the real hardware. That said...
    >
    > One method I have used is to make the values I want to change into
    > generics, with the defaults being what I want to use for synthesis. Then
    > I put a configuration specification in surrounded by
    > translate_off/translate_on:
    >
    > --synthesis translate_off;
    > for ctrl_d: CTRL
    > use entity work.CTRL
    > generic map (
    > SRCNT_START => X"28000",
    > SRCNT_END => X"280FF"
    > )
    > port map(
    > RESET => RESET,
    > CLK => CLK,
    > ...
    > );
    > --synthesis translate_on;
     
    Jim Lewis, Jan 20, 2007
    #5
  6. On Thu, 18 Jan 2007 19:40:29 +0100, Arnim <> wrote:

    >I don't recommend to do this, but there is a better solution:
    >
    > constant simulating_c : integer := 0
    > -- pragma translate_off
    > + 1
    > -- pragma translate_on
    > ...
    >Just ensure that the -- pragma <something> is recognized by your
    >synthesis tool.


    and they tell us that the C preprocessor is ****.

    But then, block comments are politically incorrect, too.

    So, if we need to temporarily remove a block of statements, we have to
    rely on emacs' or gvim's VHDL expertise.

    regards, Gerhard
     
    Gerhard Hoffmann, Jan 20, 2007
    #6
  7. news.sunrise

    Alain Guest

    > Why would one want to do this? Your synthesized design will be different
    > from what you simulate.


    Yes, but let's say I want to simulate a behaviour in millisecond
    clk_en -range. I don't want to count every 50MHz clock until I've reached a
    millisecond. So setting the masterclock to somewhat 10kHz for the simulation
    is easier.



    >
    >> Idea: Tell Modelsim to call a preprocessor script that does some
    >> regexp on the vhdl code before reading it. The value for simulation
    >> could be set in a comment string.
    >>
    >> -Is there a better solution?

    >
    > I don't recommend to do this, but there is a better solution:
    >
    > constant simulating_c : integer := 0
    > -- pragma translate_off
    > + 1
    > -- pragma translate_on
    > ;


    I'll check that out. thanks.

    Alain

    >
    > A simulator will initialize the constant to 1. For the synthesizer the
    > +1 is eclipsed and the constant is 0. You could do this for all your
    > constants or simply use the trick once and derive all other differences
    > from this result.
    > Just ensure that the -- pragma <something> is recognized by your
    > synthesis tool.
    >
    > Cheers
    >
    > Arnim
     
    Alain, Jan 22, 2007
    #7
  8. news.sunrise

    Alain Guest

    This looks like a very correct way to do it.

    The only problem is that you have to know from the beginning of coding what
    values you will want to change for simulation. Ok, this is actually not so
    bad, but I don't like the fact that you'll have to propagate these generics
    through all layers.
    This solution might result in a very long list of generics that doesn't help
    code readability.

    That's why I'd like a statement like
    constant FOO : integer := 99999; --simValue(42)
    even if I break with plain VHDL.

    cheers
    Alain

    "Andy" <> wrote in message
    news:...
    > Indeed top level generics are probably the best way to go. I usually
    > set the default values to be appropriate for synthesis, although some
    > synthesis tools allow top level generics to be overridden as a
    > synthesis option (most simulators also allow this).
    >
    > When simulating, you normally have higher level testbench that
    > instantiates the synthesizable design. In the instantiation, those
    > default generics can be overridden by a generic map in the
    > instantiation. Those generics can be set to values from other generics
    > passed down from the top level, which in turn can be set via simulator
    > options.
    >
    > This can all be done without a configuration at all if you use direct
    > entity instantiation, and not have to mess with a component declaration
    > either (vhdl '93 feature)
    >
    > DUT: entity work.CTRL(rtl) -- use architecture rtl of ctrl
    > generic map (
    > SRCNT_START => X"28000",
    > SRCNT_END => X"280FF"
    > )
    > port map(
    > RESET => RESET,
    > CLK => CLK,
    > ...
    > );
    >
    > Andy
    >
    > Duane Clark wrote:
    >> news.sunrise wrote:
    >> > Hi NG
    >> >
    >> > Problem:
    >> > When simulating (Modelsim) one might want to set certain values
    >> > differently
    >> > than for synthesis (Xilinx ISE).

    >>
    >> The caveat applies that doing this means your simulation doesn't match
    >> the real hardware. That said...
    >>
    >> One method I have used is to make the values I want to change into
    >> generics, with the defaults being what I want to use for synthesis. Then
    >> I put a configuration specification in surrounded by
    >> translate_off/translate_on:
    >>
    >> --synthesis translate_off;
    >> for ctrl_d: CTRL
    >> use entity work.CTRL
    >> generic map (
    >> SRCNT_START => X"28000",
    >> SRCNT_END => X"280FF"
    >> )
    >> port map(
    >> RESET => RESET,
    >> CLK => CLK,
    >> ...
    >> );
    >> --synthesis translate_on;

    >
     
    Alain, Jan 22, 2007
    #8
  9. news.sunrise

    Jim Lewis Guest

    Try a configuration declaration.
    You can do a single configuration for the top level
    that maps blocks at a very low level and not have to
    propagate the generics up through the design.

    Cheers,
    Jim

    > This looks like a very correct way to do it.
    >
    > The only problem is that you have to know from the beginning of coding what
    > values you will want to change for simulation. Ok, this is actually not so
    > bad, but I don't like the fact that you'll have to propagate these generics
    > through all layers.
    > This solution might result in a very long list of generics that doesn't help
    > code readability.
    >
    > That's why I'd like a statement like
    > constant FOO : integer := 99999; --simValue(42)
    > even if I break with plain VHDL.
    >
    > cheers
    > Alain
    >
    > "Andy" <> wrote in message
    > news:...
    >> Indeed top level generics are probably the best way to go. I usually
    >> set the default values to be appropriate for synthesis, although some
    >> synthesis tools allow top level generics to be overridden as a
    >> synthesis option (most simulators also allow this).
    >>
    >> When simulating, you normally have higher level testbench that
    >> instantiates the synthesizable design. In the instantiation, those
    >> default generics can be overridden by a generic map in the
    >> instantiation. Those generics can be set to values from other generics
    >> passed down from the top level, which in turn can be set via simulator
    >> options.
    >>
    >> This can all be done without a configuration at all if you use direct
    >> entity instantiation, and not have to mess with a component declaration
    >> either (vhdl '93 feature)
    >>
    >> DUT: entity work.CTRL(rtl) -- use architecture rtl of ctrl
    >> generic map (
    >> SRCNT_START => X"28000",
    >> SRCNT_END => X"280FF"
    >> )
    >> port map(
    >> RESET => RESET,
    >> CLK => CLK,
    >> ...
    >> );
    >>
    >> Andy
    >>
    >> Duane Clark wrote:
    >>> news.sunrise wrote:
    >>>> Hi NG
    >>>>
    >>>> Problem:
    >>>> When simulating (Modelsim) one might want to set certain values
    >>>> differently
    >>>> than for synthesis (Xilinx ISE).
    >>> The caveat applies that doing this means your simulation doesn't match
    >>> the real hardware. That said...
    >>>
    >>> One method I have used is to make the values I want to change into
    >>> generics, with the defaults being what I want to use for synthesis. Then
    >>> I put a configuration specification in surrounded by
    >>> translate_off/translate_on:
    >>>
    >>> --synthesis translate_off;
    >>> for ctrl_d: CTRL
    >>> use entity work.CTRL
    >>> generic map (
    >>> SRCNT_START => X"28000",
    >>> SRCNT_END => X"280FF"
    >>> )
    >>> port map(
    >>> RESET => RESET,
    >>> CLK => CLK,
    >>> ...
    >>> );
    >>> --synthesis translate_on;

    >
    >
     
    Jim Lewis, Jan 23, 2007
    #9
  10. news.sunrise

    Duane Clark Guest

    Alain wrote:
    > This looks like a very correct way to do it.
    >
    > The only problem is that you have to know from the beginning of coding what
    > values you will want to change for simulation. Ok, this is actually not so
    > bad, but I don't like the fact that you'll have to propagate these generics
    > through all layers.
    > This solution might result in a very long list of generics that doesn't help
    > code readability.


    The style I showed can be used at any level in the design. It does not
    need to be propagated from the top level.
     
    Duane Clark, Jan 23, 2007
    #10
  11. news.sunrise

    Andy Guest

    You can set up a record type with fields for each generic, and then
    pass that single generic record through the hierarchy. This makes it
    simple to add a new parameter for some submodule; you just add a new
    field to the record definition, define the value at the top, or in
    various configurations, scripts, etc., and reference it in the target
    submodule.

    The record type should be declared in a package that each module
    references.

    For reuse, a module could have a package that defines its top level
    generic record type. Then the using design's generic record package
    could reference the reused module's package, making that record a
    sub-record of the top level one.

    Andy


    Alain wrote:
    > This looks like a very correct way to do it.
    >
    > The only problem is that you have to know from the beginning of coding what
    > values you will want to change for simulation. Ok, this is actually not so
    > bad, but I don't like the fact that you'll have to propagate these generics
    > through all layers.
    > This solution might result in a very long list of generics that doesn't help
    > code readability.
    >
    > That's why I'd like a statement like
    > constant FOO : integer := 99999; --simValue(42)
    > even if I break with plain VHDL.
    >
    > cheers
    > Alain
    >
    > "Andy" <> wrote in message
    > news:...
    > > Indeed top level generics are probably the best way to go. I usually
    > > set the default values to be appropriate for synthesis, although some
    > > synthesis tools allow top level generics to be overridden as a
    > > synthesis option (most simulators also allow this).
    > >
    > > When simulating, you normally have higher level testbench that
    > > instantiates the synthesizable design. In the instantiation, those
    > > default generics can be overridden by a generic map in the
    > > instantiation. Those generics can be set to values from other generics
    > > passed down from the top level, which in turn can be set via simulator
    > > options.
    > >
    > > This can all be done without a configuration at all if you use direct
    > > entity instantiation, and not have to mess with a component declaration
    > > either (vhdl '93 feature)
    > >
    > > DUT: entity work.CTRL(rtl) -- use architecture rtl of ctrl
    > > generic map (
    > > SRCNT_START => X"28000",
    > > SRCNT_END => X"280FF"
    > > )
    > > port map(
    > > RESET => RESET,
    > > CLK => CLK,
    > > ...
    > > );
    > >
    > > Andy
    > >
    > > Duane Clark wrote:
    > >> news.sunrise wrote:
    > >> > Hi NG
    > >> >
    > >> > Problem:
    > >> > When simulating (Modelsim) one might want to set certain values
    > >> > differently
    > >> > than for synthesis (Xilinx ISE).
    > >>
    > >> The caveat applies that doing this means your simulation doesn't match
    > >> the real hardware. That said...
    > >>
    > >> One method I have used is to make the values I want to change into
    > >> generics, with the defaults being what I want to use for synthesis. Then
    > >> I put a configuration specification in surrounded by
    > >> translate_off/translate_on:
    > >>
    > >> --synthesis translate_off;
    > >> for ctrl_d: CTRL
    > >> use entity work.CTRL
    > >> generic map (
    > >> SRCNT_START => X"28000",
    > >> SRCNT_END => X"280FF"
    > >> )
    > >> port map(
    > >> RESET => RESET,
    > >> CLK => CLK,
    > >> ...
    > >> );
    > >> --synthesis translate_on;

    > >
     
    Andy, Jan 23, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    4
    Views:
    2,158
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,258
    Technology Consultant
    Sep 9, 2003
  3. Andy
    Replies:
    5
    Views:
    592
  4. Cronus
    Replies:
    1
    Views:
    706
    Paul Mensonides
    Jul 15, 2004
  5. rickman
    Replies:
    9
    Views:
    846
    rickman
    Apr 2, 2011
Loading...

Share This Page