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

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

Post by news.sunri » Sat, 20 Jan 2007 02:44:04


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
 
 
 

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

Post by Arni » Sat, 20 Jan 2007 03:40:29


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


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

 
 
 

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

Post by Duane Clar » Sat, 20 Jan 2007 05:01:15


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;
 
 
 

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

Post by Andy » Sun, 21 Jan 2007 01:34:47

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
 
 
 

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

Post by Jim Lewi » Sun, 21 Jan 2007 10:21:29

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

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

Post by Gerhard Ho » Sun, 21 Jan 2007 12:20:51


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
 
 
 

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

Post by Alai » Tue, 23 Jan 2007 16:58:45

> Why would one want to do this? Your synthesized design will be different

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'll check that out. thanks.

Alain
 
 
 

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

Post by Alai » Tue, 23 Jan 2007 17:38:47

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
 
 
 

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

Post by Jim Lewi » Wed, 24 Jan 2007 15:53:14

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
 
 
 

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

Post by Duane Clar » Thu, 25 Jan 2007 02:05:26


The style I showed can be used at any level in the design. It does not
need to be propagated from the top level.
 
 
 

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

Post by Andy » Thu, 25 Jan 2007 06:42:48

ou 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: