`timescale 1 ps / 1 ps(verilog command equivalent in VHDL.

[sheri]

hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.

 

[Vince]

sheri a écrit:

hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.

You can't.

 

[sheri]

sheri a écrit:


You can't.

Thanks Vince.
But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.

 

[Vince]

sheri a écrit:

Thanks Vince.
But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.

You have to look into the manual of your simulator. By example with NCSim you
can specify a timescale for VHDL components during the elaboration.

 

[Jonathan Bromley]

But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.

From your other post it seems you're using Modelsim.
When you launch the simulation using the vsim command,
add the option

vsim -t ps <thing_to_simulate>

(or ns, or whatever timeprecision you want).

Global timeunits make no sense in VHDL, because all time
values have explicit units. In principle VHDL can resolve
femtoseconds, but in practice simulators set a coarser
timeprecision which you can then override on the
command line.

Standard installations of Modelsim default to 1ns
precision, but (I believe) the versions that ship
with Quartus and Xilinx ISE are defaulted to 1ps.

As others have said, a similar story applies for
other simulators.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[sheri]

From your other post it seems you're using Modelsim.
When you launch the simulation using the vsim command,
add the option

  vsim -t ps <thing_to_simulate>

(or ns, or whatever timeprecision you want).

Global timeunits make no sense in VHDL, because all time
values have explicit units.  In principle VHDL can resolve
femtoseconds, but in practice simulators set a coarser
timeprecision which you can then override on the
command line.

Standard installations of Modelsim default to 1ns
precision, but (I believe) the versions that ship
with Quartus and Xilinx ISE are defaulted to 1ps.

As others have said, a similar story applies for
other simulators.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Thanks Vince and Jonathan.
But similar kind of setting can be done in modelsim.ini file -
resolution option.
To reduce simulaton time I changed from ps to ns, but did not observe
any reduction.
Looks like altera - dprams need ps resolution - not sure about this.
Can you please throw some light on this as to why changing resolution
did'nt help?

 

[Vince]

sheri a écrit:

Thanks Vince and Jonathan.
But similar kind of setting can be done in modelsim.ini file -
resolution option.
To reduce simulaton time I changed from ps to ns, but did not observe
any reduction.
Looks like altera - dprams need ps resolution - not sure about this.
Can you please throw some light on this as to why changing resolution
did'nt help?

What is your design? VHDL only, Verilog Only, mixed ?

 

[sheri]

sheri a écrit:







What is your design? VHDL only, Verilog Only, mixed ?

vhdl only.

 

[Vince]

sheri a écrit:

vhdl only.

Ok, so you have to change the design (add change models, gated clock, reduce
clock divisor...).

 

[Jonathan Bromley]

Thanks Vince and Jonathan.
But similar kind of setting can be done in modelsim.ini file -
resolution option.
Sure.

To reduce simulaton time I changed from ps to ns, but did not observe
any reduction.

Why do you expect that change to improve simulation speed?
VHDL simulators are event driven. The simulator does NOT
do extra work on each time-resolution "time tick".
Consequently, the only speed improvement you might see
by degrading the resolution to ns is that the rounding
of time values to the nearest ns might possibly cause some
events to appear to be simultaneous; this *might* have a
tiny effect on simulation speed but it's unlikely to be
noticeable. And, as you point out below, it may break
some models.

Looks like altera - dprams need ps resolution - not sure about this.

Yes, I believe that's true. This is why the Altera and Xilinx
versions of the simulator default to picosecond resolution.

Can you please throw some light on this as to why changing resolution
did'nt help?

I suspect you are trying to simulate a large design with a free
version of the simulator. It is hobbled: as your design gets
larger (more lines of executable code) the simulator's speed
degrades, first by about a factor of 5, and then by a much
larger factor. The idea is that the simulator is fully functional
so that you can experiment with it and see what it can do, but
it is useless for simulating large-scale projects - so you are
encouraged to spend real money on the full-performance real
version.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[sheri]

Why do you expect that change to improve simulation speed?
VHDL simulators are event driven.  The simulator does NOT
do extra work on each time-resolution "time tick".  
Consequently, the only speed improvement you might see
by degrading the resolution to ns is that the rounding
of time values to the nearest ns might possibly cause some
events to appear to be simultaneous; this *might* have a
tiny effect on simulation speed but it's unlikely to be
noticeable.  And, as you point out below, it may break
some models.


Yes, I believe that's true.  This is why the Altera and Xilinx
versions of the simulator default to picosecond resolution.


I suspect you are trying to simulate a large design with a free
version of the simulator.  It is hobbled: as your design gets
larger (more lines of executable code) the simulator's speed
degrades, first by about a factor of 5, and then by a much
larger factor.  The idea is that the simulator is fully functional
so that you can experiment with it and see what it can do, but
it is useless for simulating large-scale projects - so you are
encouraged to spend real money on the full-performance real
version.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Vince I cannot break the design as it is very large and proven.My job
is to only reduce simulation time without touching design.

Jonathan I am using full-performance real version & not free version.
Is there any other way to reduce simulation time?

Thanks for ur support.

 

[Vince]

sheri a écrit:

Vince I cannot break the design as it is very large and proven.My job
is to only reduce simulation time without touching design.

Jonathan I am using full-performance real version & not free version.
Is there any other way to reduce simulation time?

So it remains:
- elaboration optimization (no debug, no coverage...)
- simulation optimization (update the simulator, no waveform...)
- hardware optimization (increase memory (if the memory usage is high), increase
processor speed, reduce disk access time...)

You can also try with another simulator (ask for an evaluation license).

 

[Dwayne Dilbeck]

It sounds like you have taken a position as a new verification engineer and
gotten the sh*t job of optimizing regression time. IF this is only a single
testbench run profiling on the TB and DUT. Find out where the time is being
spent. IF all the time is being spent in the DUT and you can't change the
design. You may need to look into hardware acceleration.

If most of the time is spent in the TB, you have alot more options for
speeding up the verification. Everything from optimizing verification
functions, to coding verification in C.

IF you are trying to speed up the overall regression time for multiple
tests, run coverage ananlysis. Map coverage versus time per test. Optimize
the test order for the most coverage in the least time. Some tests may not
be needed or need only be run infrequently.

In the early stages you may just need a wet finger in the air of how good
the desgin is. In that case you can run a subset to get a general idea
quickly of how the regression is doing, while spending more time for the
final full validation.

Why do you expect that change to improve simulation speed?
VHDL simulators are event driven. The simulator does NOT
do extra work on each time-resolution "time tick".
Consequently, the only speed improvement you might see
by degrading the resolution to ns is that the rounding
of time values to the nearest ns might possibly cause some
events to appear to be simultaneous; this *might* have a
tiny effect on simulation speed but it's unlikely to be
noticeable. And, as you point out below, it may break
some models.


Yes, I believe that's true. This is why the Altera and Xilinx
versions of the simulator default to picosecond resolution.


I suspect you are trying to simulate a large design with a free
version of the simulator. It is hobbled: as your design gets
larger (more lines of executable code) the simulator's speed
degrades, first by about a factor of 5, and then by a much
larger factor. The idea is that the simulator is fully functional
so that you can experiment with it and see what it can do, but
it is useless for simulating large-scale projects - so you are
encouraged to spend real money on the full-performance real
version.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Vince I cannot break the design as it is very large and proven.My job
is to only reduce simulation time without touching design.

Jonathan I am using full-performance real version & not free version.
Is there any other way to reduce simulation time?

Thanks for ur support.

 

[Kim Enkovaara]

Vince I cannot break the design as it is very large and proven.My job
is to only reduce simulation time without touching design.

Jonathan I am using full-performance real version & not free version.
Is there any other way to reduce simulation time?

Usually speed improvements without touching the design are minimal.
I think most of the speedup tutorials first start with profiling and
fixing the underlaying code, and after that you can play with
simulator optimization flags etc.

Some small changes in the design might make the simulations 2x faster,
and with some tuning you might gain 20% in the best case. But if you
really can't change the design there are some small things to do

* Profile the design to get understanding where the time is spent

* Try the newest simulator version you can get, usually each major
version has some speedups (but sometimes the speed is not better because
some heuristics changed)

* If no timing checks are needed but he design contains timing arcs
add +notimingchecks

* If you have Modelsim SE try -O5 flag in the compilation

* If you are not using vopt flow try it also, and set the visibility
to be as minimal as possible. vopt vhdl optimization is not very
agressive compared to verilog, but it might help

* Try some other simulator as a evaluation, and if it is faster
complain to your Modelsim FAE that modelsim is slower, they usually
are very interested to fix those problems

* Moan to Altera how slow their simulation models are if that is
the bottleneck. This road is usually impossible because vendors
think their models are perfect although they might be horrible.
And the vendors are very reluctant to change models.

* If you have mixed mode licences try to change the generated
models to verilog, they are usually faster than VHDL models


--Kim