S
sheri
Guest
hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
V
Vince
Guest
sheri a écrit:
--
Vince
You can't.hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.
--
Vince
V
Vince
Guest
sheri a écrit:
can specify a timescale for VHDL components during the elaboration.
--
Vince
You have to look into the manual of your simulator. By example with NCSim youOn Feb 27, 12:46 pm, Vince <debo...@free.fr> wrote:
sheri a écrit:
hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.
You can't.
Thanks Vince.
But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.
can specify a timescale for VHDL components during the elaboration.
--
Vince
S
sheri
Guest
On Feb 27, 12:46 pm, Vince <debo...@free.fr> wrote:
But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.
Thanks Vince.sheri a écrit:
hi all,
I want know how to write `timescale 1 ps / 1 ps equivalent in VHDL.
You can't.
--
Vince
But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.
J
Jonathan Bromley
Guest
On Wed, 27 Feb 2008 00:19:43 -0800 (PST), sheri wrote:
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
From your other post it seems you're using Modelsim.But I want to know Is there any other way to do time_unit and
resolution settings in VHDL.
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
V
Vince
Guest
sheri a écrit:
--
Vince
What is your design? VHDL only, Verilog Only, mixed ?On Feb 27, 1:51 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 27 Feb 2008 00:19:43 -0800 (PST), sheri wrote:
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.
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
S
sheri
Guest
On Feb 27, 1:51 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
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?
wrote:
Thanks Vince and Jonathan.On Wed, 27 Feb 2008 00:19:43 -0800 (PST), sheri wrote:
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
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
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?
S
sheri
Guest
On Feb 27, 3:20 pm, Vince <debo...@free.fr> wrote:
vhdl only.sheri a écrit:
On Feb 27, 1:51 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 27 Feb 2008 00:19:43 -0800 (PST), sheri wrote:
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.
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 ?
--
Vince- Hide quoted text -
- Show quoted text -
V
Vince
Guest
sheri a écrit:
clock divisor...).
--
Vince
Ok, so you have to change the design (add change models, gated clock, reduceOn Feb 27, 3:20 pm, Vince <debo...@free.fr> wrote:
sheri a écrit:
On Feb 27, 1:51 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 27 Feb 2008 00:19:43 -0800 (PST), sheri wrote:
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.
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 ?
vhdl only.
clock divisor...).
--
Vince
J
Jonathan Bromley
Guest
On Wed, 27 Feb 2008 02:08:52 -0800 (PST), sheri wrote:
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.
versions of the simulator default to picosecond resolution.
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Sure.Thanks Vince and Jonathan.
But similar kind of setting can be done in modelsim.ini file -
resolution option.
Why do you expect that change to improve simulation speed?To reduce simulaton time I changed from ps to ns, but did not observe
any reduction.
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 XilinxLooks like altera - dprams need ps resolution - not sure about this.
versions of the simulator default to picosecond resolution.
I suspect you are trying to simulate a large design with a freeCan you please throw some light on this as to why changing resolution
did'nt help?
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
V
Vince
Guest
sheri a écrit:
- 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).
--
Vince
So it remains:On Feb 27, 4:15 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 27 Feb 2008 02:08:52 -0800 (PST), sheri wrote:
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.
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?
- 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).
--
Vince
S
sheri
Guest
On Feb 27, 4:15 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
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.
wrote:
Vince I cannot break the design as it is very large and proven.My jobOn Wed, 27 Feb 2008 02:08:52 -0800 (PST), sheri wrote:
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
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
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.
D
Dwayne Dilbeck
Guest
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.
"sheri" <saras_rajgiri@yahoo.co.in> wrote in message
news:2af28c01-016e-4be1-960d-1edbbd1ba969@s12g2000prg.googlegroups.com...
On Feb 27, 4:15 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
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.
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.
"sheri" <saras_rajgiri@yahoo.co.in> wrote in message
news:2af28c01-016e-4be1-960d-1edbbd1ba969@s12g2000prg.googlegroups.com...
On Feb 27, 4:15 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
Vince I cannot break the design as it is very large and proven.My jobOn Wed, 27 Feb 2008 02:08:52 -0800 (PST), sheri wrote:
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
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
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.
K
Kim Enkovaara
Guest
sheri wrote:
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
Usually speed improvements without touching the design are minimal.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?
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