Simulation vs Synthesis

[ALuPin]

Hi,

I want to use a process inside a VHDL module for debugging mode that is
for simulation.
That process contains constructs which are not suitable for synthesis.

How can I make that process inactive when synthesizing my design
without having to delete the process ?
Is there any easy solution ?

Thank you.

Rgds
André

 

[Ajeetha]

Use pragmas - With DC as synthesis tool, you can put:

-- synopsys translate_off
dbg_p : process;
...
end process : dbg_p;

-- synopsys translate_on

HTH
Ajeetha, CVC

 

[Peter]

Hi,

Why not use a boolean signal to control a conditional Generate
statement?
This boolean signal may have a default value for synthesis which is
overridden
in your testbench to generate what you want.

/Peter

 

[ALuPin]

Use pragmas - With DC as synthesis tool, you can put:

-- synopsys translate_off
dbg_p : process;
...
end process : dbg_p;

-- synopsys translate_on

HTH
Ajeetha, CVC

Hi Ajeetha,

what do you mean with pragmas - "dbg_p" ?

How can I use these pragmas so that the synthesis tool will not try
to synthesize the process ?

Rgds
Andrés

 

[Ralf Hildebrandt]

what do you mean with pragmas - "dbg_p" ?

External tools use their own specific commands, hidden behind VHDL
comments. No language extensions are needed. To avoid collisions with
other tools, the commands are often started with a keyword. Synopsys has
chosen "synopsys" as keyword.

-- synopsys <command>

Two <command>s are "translate_off" and "translate_on". The code between
both will be ignored by tools from Synopsys.

Such commands behind comments are called "pragma".


To be independed from any tool, I would recommend Peter's suggestion:
Use an if-generate statement and a generic parameter. Because of the
limitations of generate-statements not every problem can be solved with
this.

Ralf

 

[ALuPin]

Hi Ralf,

thank you for your answer.
Is it possible to deactivate a process for synthesis
by means of the generate statement ?

for example:

IF Simulation=0 THEN
GENERATE
DEBUGGING: PROCESS
....
END PROCESS DEBUGGING;
END GENERATE;


Rgds
André

 

[Mike Treseler]

To be independed from any tool, I would recommend Peter's suggestion:
Use an if-generate statement and a generic parameter.

I agree. Vendor-specific code is a last resort.
The OP could also do "printf" style debugging
by inserting report statements in-line.
When debugging is complete, these could become
-- comments or be wrapped with
an "if generic_bool_c then () endif;"

Of course, the clean way to do all this is
to trace code with breakpoints using the simulator.


-- Mike Treseler

 

[Ralf Hildebrandt]

Is it possible to deactivate a process for synthesis
by means of the generate statement ?

for example:

IF Simulation=0 THEN
GENERATE
DEBUGGING: PROCESS
....
END PROCESS DEBUGGING;
END GENERATE;

Yes, but this syntax is not correct. Let simulation be defined similar to:
....
generic(
simulation : integer:=1 );
port(
....

the you can use it with:

gen_sim_label : if simulation=1 generate -- label is mandatory

-- do whatever you want here during simulation

end generate;


You could even use the generic parameter inside a process. Let me give
an example for a synchronous process:

process(reset,clock)
begin
if (reset='1') then
-- do some reset
elsif rising_edge(clock) then
-- do some synchronous stuff
if (simulation=1) then
assert ... -- some assertions
end if;
end if;
end process;

Note, that I don't know if synthesis tools will accept this. They will
definitely produce a warning that the code inside the if-statement
cannot be reached, but they might reject to synthesize, because the
"see" and unsynthesizable command.
Inside an inactive generate-statement they don't "see" anything.


Pragmas are unavoidable (AFAIK), if you want to comment something
outside the begin-end of an architecture. Example: For debugging it
could be useful to include a package, that defines a shared variable or
global signal. You can eliminate the code to access this shared variable
or global signal with an if-generate, but you can't eliminate the
include instruction.

Ralf
Ralf

 

[ALuPin]

Hi Ralf,

thank you for your answer.

I use the generate statement as you proposed.
Nevertheless the synthesis tool analyzes the code inside
the generate construct and fails to synthesize. It does
not matter whether I define
constant simulation : integer := 0;

or

constant simulation : integer := 1;

So the only possibiity is to delete the debugging process
for synthesis. (?)

Rgds
André

 

[ALuPin]

Some additional info:
The code inside the debugging process is correct (for simulation) -
Modelsim is able to compile it.

Rgds
André

 

[Marcus Harnisch]

-- synopsys <command>

Two <command>s are "translate_off" and "translate_on". The code
between both will be ignored by tools from Synopsys.

Such commands behind comments are called "pragma".


To be independed from any tool, I would recommend Peter's suggestion:
Use an if-generate statement and a generic parameter. Because of the
limitations of generate-statements not every problem can be solved
with this.

IIRC, the pragma syntax has been incorporated into IEEE
1076.6. Although I am not sure if that version has been released, yet.

To remain vendor independent they modified the syntax to read

-- synthesis <command>

Hope that helps,
Marcus

 

[Thomas Stanka]

Hi,

Two <command>s are "translate_off" and "translate_on". The code between
both will be ignored by tools from Synopsys.

Such commands behind comments are called "pragma".


To be independed from any tool, I would recommend Peter's suggestion:
Use an if-generate statement and a generic parameter. Because of the
limitations of generate-statements not every problem can be solved with
this.

Just wondering if there's any commercial synthesis tool that ignores
the synopsys translate_on/off pragmas? Ok, for at least Synplify or Xst
it would be enough to write translate_on/off without synopsys .
I prefer tool (and technology) independancy where ever posible, but I
never had a bad feeling about using the translate_on/off pragmas. Of
course you need to know, how to tell your tool to use them (especially
Synopsys DC).

I would expect that you will find more commercial tools having problems
with (complex) generic parameter and generate statements.

bye Thomas

 

[Andy]

Another possibility is to call procedures that are defined in a package
for these "simulation only" tasks. Then define two packages (or better
yet, two package bodies), one with empty procedure definitions for
synthesis, and one with complete definitions for simulation. Compile
the former into the synthesis tool, and the latter into the simulator.

Andy

 

[Rob Dekker]

Just wondering if there's any commercial synthesis tool that ignores
the synopsys translate_on/off pragmas? Ok, for at least Synplify or Xst
it would be enough to write translate_on/off without synopsys .

Almost all tools will accept multiple keywords as 'pragma-triggers'.
Check the tool's documentation. To stay vendor independent, use 'synthesis' as a pragma trigger.
I think that is commonly accepted (in at least 40 tools that I know of) :

-- synthesis translate_off

 

[ALuPin]

I tried but Synplify seems to have problems with that
generate statement. Our FAE is working on that problem ...

Rgds