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

[news.sunrise]

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

 

[Arnim]

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

 

[Duane Clark]

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]

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

 

[Jim Lewis]

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

 

[Gerhard Hoffmann]

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

 

[Alain]

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.

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

 

[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

 

[Jim Lewis]

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

 

[Duane Clark]

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.

 

[Andy]

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