pragma in ModelSim

[chestnut]

Hi,

I am looking for some pragmas supported by ModelSim. These pragmas can
turn on/off the compilation of vhdl source code. In Aldec Active-HDL
simulator, such pragmas are vhdl_comp_off/on

for example, here's a snippet vhdl source:


porta_wren <= '1' ;
--vhdl_comp_off
porta_wren <= '0';
--vhdl_comp_on
porta_datain <= "FF";

Then, the simulator will assume porta_wren is '1' because the second
statement wasn't compiled at all.

But ModelSim doesn't support pragmas like vhdl_comp_on/off. Any other
suggestions?

thanks

chestnut

 

[kenm]

Hi,

I am looking for some pragmas supported by ModelSim. These pragmas can
turn on/off the compilation of vhdl source code. In Aldec Active-HDL
simulator, such pragmas are vhdl_comp_off/on

for example, here's a snippet vhdl source:

porta_wren <=   '1' ;
--vhdl_comp_off
porta_wren <=  '0';
--vhdl_comp_on
porta_datain <= "FF";

Then, the simulator will assume porta_wren is '1' because the second
statement wasn't compiled at all.

But ModelSim doesn't support pragmas like vhdl_comp_on/off. Any other
suggestions?

thanks

chestnut

Simply comment out the line, or lines, that you do not want compiled.
Some editors (e.g. emacs with VHDL mode) can comment / uncomment
blocks of code easily.
This will work with any tool.

The lines of code will not be synthesised either which might not be
what you want.

Alternativedly, in a process

porta_wren <= '0' ;
--pragma translate_off
porta_wren <= '1';
--pragma translate_on


will result in synthesising

porta_wren <= '0' ;

but simulating

porta_wren <= '1' ;

Although it seems dangerous to be synthesising something different to
what you have simulated.

Cheers,

Ken Morrow,
Morrow Elecronics Limited.
www.morro.co.uk (under construction)

 

[chestnut]

Ken,

Thank you. but what I intend is to make a VHDL source file used by
both simulation and synthesis.

for example, the following snippet code:

-- vhdl_comp_off
porta_wren <= '0' ;
-- vhdl_comp_on

--pragma translate_off
porta_wren <= '1';
--pragma translate_on

if compiled by ModelSim, it gonna assume porta_wren <= '1'; if
compiled by Synthesis tools, it gonna assume porta_wren <= '0';

Such feature is easily supported by Aldec Active-HDL. I am wondering
if ModelSim has a similar support.

cheers,

chestnut,

 

[KJ]

Ken,

Thank you. but what I intend is to make a VHDL source file used by
both simulation and synthesis.

That's always a good plan.

if compiled by ModelSim, it gonna assume porta_wren <= '1'; if
compiled by Synthesis tools, it gonna assume porta_wren <= '0';

Such feature is easily supported by Aldec Active-HDL. I am wondering
if ModelSim has a similar support.

Doesn't sound like a good thing...making synthesis and simulation models
intentionally different that is. Your reasoning for why you would want to
do this is likely flawed.

In any case, rather than trying to go outside of the language and using tool
specific pragmas that are not part of any standard and which (as you've just
found out) can lead to incompatibilities, it would be much better to stick
with the design language and pass in some generic that percolates up to the
top level so that you can set it one way for sim and another way for
synthesis. Then instead of the pragmas you have

porta_wren <= '1' when (Sim=TRUE) else '0';

Much more maintainable and not tool specific....and don't bother with the
usual complaint about "It's soooo far down the hierarchy that I'd have to
edit half a dozen file to add the parameter to get it down to where I need
it". It's not that hard to modify code to accept the new parameter (use
copy/paste, it works wonders). Lastly, I'll reiterate that having a
simulation model that is different than the synthesis model is most likely a
bad plan.

KJ

 

[kenm]

That's always a good plan.

That is exactly what your original code did. My code will do the same,
but will work with Modelsim and Aldec, as well as all synthesisers
that I have used recently (Leonardo, Precision, Synopsys DC, Xilinx
ISE all support pragma translate_off/on to disable and enable
synthesis, although it is not guaranteed that all synthesisers will).

Doesn't sound like a good thing...making synthesis and simulation models
intentionally different that is.  

I agree.

Your reasoning for why you would want to
do this is likely flawed.

It would be interesting to know the reasons.

In any case, rather than trying to go outside of the language and using tool
specific pragmas that are not part of any standard and which (as you've just
found out) can lead to incompatibilities, it would be much better to stick
with the design language and pass in some generic that percolates up to the
top level so that you can set it one way for sim and another way for
synthesis.  Then instead of the pragmas you have

porta_wren <=   '1'  when (Sim=TRUE) else '0';

Much more maintainable and not tool specific....and don't bother with the
usual complaint about "It's soooo far down the hierarchy that I'd have to
edit half a dozen file to add the parameter to get it down to where I need
it".  It's not that hard to modify code to accept the new parameter (use
copy/paste, it works wonders).  Lastly, I'll reiterate that having a
simulation model that is different than the synthesis model is most likely a
bad plan.

KJ

Using generics sounds like a good suggestion KJ.

Cheers,

Ken

 

[chestnut]

Outside a process, this creates two drivers in simulation (and hence
some interesting problems!) but only in synthesis.

An alternative is

function sim_synth_val is
variable val : std_logic := '0';
begin
--pragma translate_off
val <= '1';
--pragma translate_on
return val;
end function sim_synth_val;

porta_wren <= sim_synth_val;

which only generates a single driver wherever you are, with the required
semantics.


In general, yes.
But two cases where it is safe and almost essential;

A DDR memory controller requires a VERY long delay at one point in its
initialisation sequence; you can safely reduce that delay and save a
fruitless hour of simulation time without rendering the rest of your
simulation meaningless;

Somebody here recently was trying to simulate a slow serial port; he
thought his simulations weren't working because the TX output line
wasn't toggling in a few thousand cycles... switching the baud clock to
a much faster rate could have saved him days of simulation time and
doubt.

(OK, these are two forms of the same case)

You could use this to switch between a fast behavioural model and a
slower RTL model (rigorously checked for equivalence as a separate
exercise), again to improve simulation time while testing something
else.

I have also ONCE resorted to this trick to work around a synthesis bug
where a combination of variable assignments and signal assignments in
procedures in a process apparently confused the synth tool, and the
resulting pipeline delay was off by 1. Ugly hack I need to re-visit (a)
to characterise the bug better and (b) rewrite to bypass the bug in a
portable form. This I would NOT call safe, but faced with the problem it
was the best short term answer.

- Brian

Brian,

thank you for reply. You are right. In fact, I am working on the DDR2
simulation, which require a 200us calibration stage after reset.
Because the calibration design, I want to shift the focus on the
application logic and speed up the simulation. Your suggestion is
great. But I feel like it is not as handy as vhdl_comp_off/on (pragmas
supported by Aldec simulator). Hopefully, ModelSim will have the
similar pragmas in the near future.

Adam

 

[Peter]

I am looking for some pragmas supported by ModelSim. These pragmas can

turn on/off the compilation of vhdl source code. In Aldec Active-HDL
simulator, such pragmas are vhdl_comp_off/on

If you want slightly different hardware generated by synthesis, why
not use a conditional generate statement?

Example:

Entity something is
Generic( insert_pll : Boolean := True);
Port(
.....
);
End Entity something;

Architecture RTL of something is

Begin

......

u1: If insert_pll Generate

-- Your "normal" logic
End Generate;

u2: If not insert_pll Generate

-- Your "simulation" logic
End Generate

U1 is normaly generated. In the testbench, the default value is
overridden and set to FALSE which makes u2 to be generated instead.

/Peter

 

[Amal]

If you want slightly different hardware generated by synthesis, why
not use a conditional generate statement?

Example:

Entity something is
   Generic( insert_pll : Boolean := True);
   Port(
          .....
       );
End Entity something;

Architecture RTL of something is

Begin

.....

u1: If insert_pll Generate

    -- Your "normal" logic
   End Generate;

u2: If not insert_pll Generate

    -- Your "simulation" logic
   End Generate

U1 is normaly generated. In the testbench, the default value is
overridden and set to FALSE which makes u2 to be generated instead.

/Peter

Take a look at my answer at the bottom of this post:

http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/0651841f05837dad#

-- Amal