signal delay

[raullim7]

i have a signal and i implement it to be an inversion of the clock
pulse after a 2.5ns delay.
" S1 <= NOT(CLK);
CLK2 <= S1 after 2.5 ns; "

S1 is the signal, CLK is the master clock, and CLK2 is an out pin
which i will route it back to another pin to use it as another input
clock.

my question is, i am assigning S1 to CLK2 after a 2.5ns delay. may i
know if the delay that i will actually get from this statement is 2ns
or 2.5ns, that is, ignoring the delta delay that will be incurred by
assigning the signal.

thanks

 

[raullim7]

i have a signal and i implement it to be an inversion of the clock
pulse after a 2.5ns delay.
" S1 <= NOT(CLK);
  CLK2 <= S1 after 2.5 ns; "

S1 is the signal, CLK is the master clock, and CLK2 is an out pin
which i will route it back to another pin to use it as another input
clock.

my question is, i am assigning S1 to CLK2 after a 2.5ns delay. may i
know if the delay that i will actually get from this statement is 2ns
or 2.5ns, that is, ignoring the delta delay that will be incurred by
assigning the signal.

thanks

sorry, i mean if no delay is specified, the signal S1 will be updated
after a delta delay. but here, i have set a delay of 2.5ns. for other
integers that are used in VHDL, i understand that decimal value like
2.5 will be rounded off to 2. so i wish to know that my statement to
delay a signal will can be taken as a decimal value or not.

if possible, is this restricted to only a single decimal place? that
is, if i have a signal statement with "after 1.25 ns;", will it be
1.25 or 1.2?

please advise. thank you

 

[Mark McDougall]

if possible, is this restricted to only a single decimal place? that
is, if i have a signal statement with "after 1.25 ns;", will it be
1.25 or 1.2?

I hope you're not synthesizing this code! Delays are ignored by synthesis
tools, so this only has meaning during simulation.

To answer your 2nd question, the resolution of the delay will be affected
by the time delta setting (simualtion resolution) in your simulation run.
If your delta is 500ps or less, then 2.5ns will be 2.5ns. Otherwise you'll
get rounding errors.

Regards,

 

[backhus]

I hope you're not synthesizing this code! Delays are ignored by synthesis
tools, so this only has meaning during simulation.

To answer your 2nd question, the resolution of the delay will be affected
by the time delta setting (simualtion resolution) in your simulation run.
If your delta is 500ps or less, then 2.5ns will be 2.5ns. Otherwise you'll
get rounding errors.

Regards,

Hi,
Mark is right, but theres something more to know.

The simulation time resolution is a common trap for beginners.
Delta delays of the event driven simulator are a completely different
thing. They do not impact the timing of the simulated circuit, though
somtimes the behavior but that's another topic. Any number of delta
delays sums up to 0 ns.

A value followed by a unit like e.g. ms, us, ns, ps will be recognized
as of type time which behaves like a real type value. Not like integer.
Something like x <= a after 1.3429 us; is no problem at all, unless it
fits in the time resulution of your simulator.

And again: Never ever try to synthesize it!

Have a nice simulation
Eilert

 

[kennheinrich]

Hi,
Mark is right, but theres something more to know.

The simulation time resolution is a common trap for beginners.
Delta delays of the event driven simulator are a completely different
thing. They do not impact the timing of the simulated circuit, though
somtimes the behavior but that's another topic. Any number of delta
delays sums up to 0 ns.

A value followed by a unit like e.g. ms, us, ns, ps will be recognized
as of type time which behaves like a real type value. Not like integer.
Something like x <= a after 1.3429 us; is no problem at all, unless it
fits in the time resulution of your simulator.

And again: Never ever try to synthesize it!

Have a nice simulation
Eilert

A minor technical point: physical types (like 'time') actually are
integer ranges, *not* floating point. All physical literals of type
'time' denote an integer number of femtoseconds (the primary unit of
'time'). The only reason it "behaves like a real type value" is that
femtoseconds are so small! (See LRM 2000 section 3.1.3).

The reason that writing "1.3429 us" does what you expect is that it
*really* represents the (integer-valued) 1,342,900,0000 fs. (I hope I
got the right number of zeroes

Then the resolution limit further mashes the resolution down, as has
been pointed out.

- Kenn

 

[raullim7]

in that case, is there any method to delay the signal that is able to
synthesize?
even if i were to implement a few logic delays for some dummy signals,
all the dummy signals will be updated at the same time and therefore,
i will not be able to obtain the desired outcome.
the period of one single clock pulse of my design is 10ns. i am hoping
to achieve a second clock which is around 2-3ns off the master clock.
please advise. thank you.

 

[mk]

in that case, is there any method to delay the signal that is able to
synthesize?
even if i were to implement a few logic delays for some dummy signals,
all the dummy signals will be updated at the same time and therefore,
i will not be able to obtain the desired outcome.
the period of one single clock pulse of my design is 10ns. i am hoping
to achieve a second clock which is around 2-3ns off the master clock.
please advise. thank you.

If this is for an ASIC most standard cell libraries have delay cells
which can generate large delays but min/max differential of course
woud be quite large. You can instantiate one with the delay you can
live in the best corner assuming worst delay is not too much for you.
For an FPGA you can use manually placed clock buffers to get a similar
effect or use a set of pins to go out of the chip and get back in
again through the board if on-chip delay is not enough.
None of these solutions are synthesizable per se, but they are manual
solutions which can be used in a design the rest of which can be
synthesized. You of course need to remember your "dont_optimize",
"force keep", "dont_modify" or any other magical incantation necessary
to keep things in order.

 

[backhus]

Hi

in that case, is there any method to delay the signal that is able to
synthesize?
even if i were to implement a few logic delays for some dummy signals,
all the dummy signals will be updated at the same time and therefore,
i will not be able to obtain the desired outcome.

You really got the point.

the period of one single clock pulse of my design is 10ns. i am hoping
to achieve a second clock which is around 2-3ns off the master clock.
please advise. thank you.

I'm assuming now that you are going to work with fpgas:

With a 10 ns clock period and some tricky risig edge - fallig edge clock
scheme it is possibel to acheive a 5ns delay easily.

Actual FPGAs have DLLs, DCMs or other kinds of clock manipulating
macros. These are often able to generate synchronous 90°, 180° and 270°
clocks from your original clock. That would provide you with the desired
2,5 ns delayed clock you need.

But do you really need such a delay inside your design, or is it just to
match some timing on the input or output lines? Some modern fpgas have
programmable delays in their IO-Blocks for that purpose.

If you are really working on a fpga design consider to read (and post
on) comp.arch.fpga. There you find a lot about this topic, and more.

Have a nice synthesis
Eilert

 

[sudeep]

someone please give a synthesizable code for similar case to generate 40MHz clock and to produce delay of 7us please help i need it in my project!!