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

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

> 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

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

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

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

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

> 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

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: oups.com...
> 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

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: oups.com...
>> 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

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