Real Time Extraction in Simulation

M

M. Norton

Guest
Good morning,

I'm working on a signals testbench for a receiver. I started putting together a cosine lookup table and some code to run an NCO based on a current setting of frequency.

As I was leaving work yesterday I started thinking that maybe I'm going about this backwards, and could I create a signal in real numbers? It has some advantages of being more straightforward and much easier to create more sophisticated signals than CW (or multiple additions of CW). However I seem to remember tinkering with this notion in the past and the major problem was finding out what the current time was.

Since time is a physical type in VHDL, I seem to remember that when it converts into a math type, it does so at its lowest physical quantized level, femtoseconds. Thus, it doesn't take a lot of time before femtoseconds overwhelm the integer type. I might be able to go straight to real but I'm going to lose precision.

Is there a simulator environment method of extracting the current simulation time in real type rather than using "now"?

Thanks,
Mark Norton
 
On Wednesday, October 1, 2014 9:42:07 AM UTC-4, M. Norton wrote:
Is there a simulator environment method of extracting the current simulation
time in real type rather than using "now"?

a <= real(now / 1 ps); -- For 1 ps accuracy
a <= real(now / 1 ns); -- For 1 ns accuracy
a <= real(now / 1 us); -- For 1 us accuracy
etc.

Kevin Jennings
 
On Wednesday, October 1, 2014 10:44:05 AM UTC-5, KJ wrote:
On Wednesday, October 1, 2014 9:42:07 AM UTC-4, M. Norton wrote:



Is there a simulator environment method of extracting the current simulation

time in real type rather than using "now"?





a <= real(now / 1 ps); -- For 1 ps accuracy

a <= real(now / 1 ns); -- For 1 ns accuracy

a <= real(now / 1 us); -- For 1 us accuracy

etc.

Alright, well that seems simple enough. Thank you. I'll try that out and see if I can make something interesting out of it.

Mark
 
On Wed, 01 Oct 2014 11:17:41 -0700, M. Norton wrote:

On Wednesday, October 1, 2014 10:44:05 AM UTC-5, KJ wrote:
On Wednesday, October 1, 2014 9:42:07 AM UTC-4, M. Norton wrote:



Is there a simulator environment method of extracting the current
simulation

time in real type rather than using "now"?





a <= real(now / 1 ps); -- For 1 ps accuracy

a <= real(now / 1 ns); -- For 1 ns accuracy

a <= real(now / 1 us); -- For 1 us accuracy

etc.

Alright, well that seems simple enough. Thank you. I'll try that out
and see if I can make something interesting out of it.

You may need to set the simulator resolution appropriately to stop it
rounding the physical unit. I had a 1kHz waveform simulating correctly in
one simulator and producing 992Hz in another (and in synthesis!) because
the clock period rounded down to nanoseconds (its default) before
computing the counter compare value...

- Brian
 
On Thursday, October 2, 2014 4:07:08 AM UTC-5, Brian Drummond wrote:
On Wed, 01 Oct 2014 11:17:41 -0700, M. Norton wrote:



On Wednesday, October 1, 2014 10:44:05 AM UTC-5, KJ wrote:

On Wednesday, October 1, 2014 9:42:07 AM UTC-4, M. Norton wrote:







Is there a simulator environment method of extracting the current

simulation



time in real type rather than using "now"?











a <= real(now / 1 ps); -- For 1 ps accuracy



a <= real(now / 1 ns); -- For 1 ns accuracy



a <= real(now / 1 us); -- For 1 us accuracy



etc.



Alright, well that seems simple enough. Thank you. I'll try that out

and see if I can make something interesting out of it.





You may need to set the simulator resolution appropriately to stop it

rounding the physical unit. I had a 1kHz waveform simulating correctly in

one simulator and producing 992Hz in another (and in synthesis!) because

the clock period rounded down to nanoseconds (its default) before

computing the counter compare value...



- Brian

Yes I've run into that before, and every now and then when setting up a new machine because of the default 1 ns resolution in modelsim.ini. I typically have it set to picoseconds for the stuff I do.
 

Welcome to EDABoard.com

Sponsor

Back
Top