If you want a synthesizable code, you can have a counter, and it's increased by clock.. When counter reaches the limit you can give your input to output..
If you don't need a synthesizable code; you can have
If you want a synthesizable code, you can have a counter, and it's increased by clock.. When counter reaches the limit you can give your input to output..
If you don't need a synthesizable code; you can have
Something misunderstood here. I wanna output signal to be delayed by clock. But your way just takes input at posedge clk by some clockcycles, but does not delay it.
If you want a synthesizable code, you can have a counter, and it's increased by clock.. When counter reaches the limit you can give your input to output...
Something misunderstood here. I wanna output signal to be delayed by clock. But your way just takes input at posedge clk by some clockcycles, but does not delay it.
W3Y
win3y, if you wait for 10 cycles after seeing a transition on the input before letting "delay <= ctrl;" then it will be 10 cycles later. i.e.
Code:
last_ctrl <= ctrl
if (ctrl != last_ctrl)
counter <= 1
else if counter < 10
counter++
else
delayed <= ctrl.
Unfortunately this only works if the control input can be guaranteed to never transition faster than once every 10 cycles. Otherwise you will "deglitch" pulses that are shorter than 10 cycles and they will not show up at the output.
Note that for a delay of 10, you still need 6 flip-flops (1 for edge detect, 1 for output, 4 for counter). Your original way only needs 10, and works for the short-pulse case. So unless you need tons of these, or you're doing this for N >> 10, not sure why you feel that this is "expensive".