Simulation vs Synthesis

A

ALuPin@web.de

Guest
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é
 
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,

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
 
Ajeetha schrieb:

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
Click to expand...
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
 
ALuPin@web.de wrote:

what do you mean with pragmas - "dbg_p" ?
Click to expand...

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
 
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é
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
Click to expand...
 
Ralf Hildebrandt wrote:

To be independed from any tool, I would recommend Peter's suggestion:
Use an if-generate statement and a generic parameter.
Click to expand...
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
 
ALuPin@web.de wrote:


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;
Click to expand...
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
 
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é
 
Some additional info:
The code inside the debugging process is correct (for simulation) -
Modelsim is able to compile it.

Rgds
André
 
Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de> writes:
-- 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.
Click to expand...
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
 
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
 
"Thomas Stanka" <usenet_10@stanka-web.de> wrote in message news:1140083177.013125.141240@g14g2000cwa.googlegroups.com...
[...]
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 :).
Click to expand...
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
< simulation - only code >
-- synthesis translate_on

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
Click to expand...
 
I tried but Synplify seems to have problems with that
generate statement. Our FAE is working on that problem ...

Rgds
 
Hi,

Ralf Hildebrandt schrieb:
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.
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top