How to understand this code in a package definition

This is a discussion on How to understand this code in a package definition within the vhdl forums in Programming Languages category; Hi, How to understand the part: ---------------- constant simulating : boolean := false -- synopsys translate_off or true -- synopsys translate_on ; --------------- This is part of the code generated by System Generator 10.1i. It can compile through by Modelsim. I am curious about "or true" line. It is like broken code, but it works. Could you explain its meaning to me? Thanks in advance. library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; package conv_pkg is constant simulating : boolean := false -- synopsys translate_off or true -- synopsys translate_on ; constant xlUnsigned : integer := 1; constant xlSigned : integer := ...

Go Back   Application Development Forum > Programming Languages > vhdl

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 07-31-2008, 04:36 PM
fl
Guest
 
Default How to understand this code in a package definition

Hi,
How to understand the part:
----------------
constant simulating : boolean := false
-- synopsys translate_off
or true
-- synopsys translate_on
;

---------------
This is part of the code generated by System Generator 10.1i. It can
compile through by Modelsim. I am curious about "or true" line. It is
like broken code, but it works. Could you explain its meaning to me?
Thanks in advance.








library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
package conv_pkg is
constant simulating : boolean := false
-- synopsys translate_off
or true
-- synopsys translate_on
;
constant xlUnsigned : integer := 1;
constant xlSigned : integer := 2;
....
....
end conv_pkg;
Reply With Quote
  #2  
Old 07-31-2008, 04:54 PM
Mike Treseler
Guest
 
Default Re: How to understand this code in a package definition

fl wrote:


> This is part of the code generated by System Generator 10.1i. It can
> compile through by Modelsim. I am curious about "or true" line. It is
> like broken code, but it works. Could you explain its meaning to me?
> Thanks in advance.




-- modelsim sees:
constant simulating : boolean := false or true; -- = true

-- quartus/ise sees:
constant simulating : boolean := false; -- = false
Reply With Quote
  #3  
Old 07-31-2008, 05:45 PM
Andy Peters
Guest
 
Default Re: How to understand this code in a package definition

Mike Treseler wrote:
> fl wrote:
>
>
> > This is part of the code generated by System Generator 10.1i. It can
> > compile through by Modelsim. I am curious about "or true" line. It is
> > like broken code, but it works. Could you explain its meaning to me?
> > Thanks in advance.

>
> -- modelsim sees:
> constant simulating : boolean := false or true; -- = true
>
> -- quartus/ise sees:
> constant simulating : boolean := false; -- = false


Seems to me that ModelSim does the right thing. The expression on the
RHS is evaluated (and we should know that 1 or 0 is 1) at analysis
time and assigned to the constant.

ISE and Quartus appear to be wrong.

-a
Reply With Quote
  #4  
Old 07-31-2008, 08:49 PM
Brian Drummond
Guest
 
Default Re: How to understand this code in a package definition

On Thu, 31 Jul 2008 14:45:27 -0700 (PDT), Andy Peters <google@latke.net>
wrote:

>Mike Treseler wrote:
>> fl wrote:
>>
>>
>> > This is part of the code generated by System Generator 10.1i. It can
>> > compile through by Modelsim. I am curious about "or true" line. It is
>> > like broken code, but it works. Could you explain its meaning to me?
>> > Thanks in advance.

>>
>> -- modelsim sees:
>> constant simulating : boolean := false or true; -- = true
>>
>> -- quartus/ise sees:
>> constant simulating : boolean := false; -- = false

>
>Seems to me that ModelSim does the right thing. The expression on the
>RHS is evaluated (and we should know that 1 or 0 is 1) at analysis
>time and assigned to the constant.
>
>ISE and Quartus appear to be wrong.


They are all three right, because the synthesis tools must obey the
"synthesis translate_on/off" pragmas.

This constant can be used to generate different behaviour in synthesis
and simulation.

Which is not usually a good idea; though there are occasionally good and
safe uses for it. (For example, to greatly speed up a serial interface
to reduce wasted simulation time, or to bypass a very long
initialisation delay for some external component such as a PLL, or the
DLL in DDR memory)

- Brian
Reply With Quote
  #5  
Old 08-03-2008, 12:44 PM
KJ
Guest
 
Default Re: How to understand this code in a package definition


"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:n0n4941trp10iib4lfmcbsfgoc2euraa3e@4ax.com...
> On Thu, 31 Jul 2008 14:45:27 -0700 (PDT), Andy Peters <google@latke.net>
> wrote:
>
> This constant can be used to generate different behaviour in synthesis
> and simulation.
>
> Which is not usually a good idea; though there are occasionally good and
> safe uses for it. (For example, to greatly speed up a serial interface
> to reduce wasted simulation time,


I usually use simply it to surround...
- Code that writes to files during simulation for logging purposes during
debug.
- To add signals that are not intended to be synthesized which are of type
'real' to make working with designs that use the fixed point package easier
to debug.

In either case, I'm not creating different functional behaviour, just adding
additional debug capability.

KJ


Reply With Quote
  #6  
Old 08-05-2008, 11:14 AM
Amal
Guest
 
Default Re: How to understand this code in a package definition

One can use the following pragma to remove code that is only used for
simulation purposes and not translated to logic during synthesis:

-- pragma translate_off
...
-- pragma translate_on

I think you need to make sure the the pragma is placed correctly
around the "or TRUE" as follows:

constant SIMULATING : boolean := FALSE
-- pragma translate_off
or TRUE
-- pragma translate_on
;

During simulation the pargma is not seen and the constant becomes
TRUE. But synthesis would ignore "or TRUE" and the constant becomes
FALSE.

Basically, I think the purpose of this constant is to EXCLUDE code for
simulation, like the way you exclude code for synthesis using the
translate_off/translate_on pragmas. Example could be, debugging logic
that you do not want to be there in your simulation, but you want them
for synthesis. FPGA examples could be the XILINX ChipScope and ALTERA
SignalTap. I do not want or care about these to be in my simulation,
but I need them for debugging in the lab.

g_SYNTHESIS_ONLY: if ( not SIMULATING ) generate
-- Put debugging code that does not show up in simulation
i_chipscope_icon icon port map ( ... );
i_chipscope_ila ila port map ( ... );
end generate g_SYNTHESIS_ONLY;

Cheers,
-- Amal
Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 04:57 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.