Intra-clock period timestamp capture

Altera_Forum · ‎12-12-2011

Good afternoon,

I have an input pin which goes from low to high asynchronously. I am interested in WHEN this transition occurred. As the first step, I have a clocked counter and I record the value of this counter when the clocked process sees the pin transition low to high.

However, I need to detect the transition time more accurately than the clock period. I know what I want to do in hardware, but worry that quartus will 'optimize' my circuit into something that's wrong. I want to ensure this doesn't happen... ideally as cross-vendor as possible.

Here's my plan for detecting the intra-period offset:

signal inp : std_logic; -- the input pin

signal a, b, c, d : std_logic; -- the pin with increasing delay

signal clk : std_logic; -- the main clock

signal ra, rb, rc, rd : std_logic; -- captured trace

a <= '1' and inp;

b <= '1' and a;

c <= '1' and b;

d <= '1' and c;

...

process(clk) begin

if (rising_edge(clk)) then

ra <= a;

rb <= b;

rc <= c;

rd <= d;

...

end if;

end process;

The idea here is that the input pin goes through some combinatorial logic that delays it. Then on the clock edge, I latch the logic in parallel registers. Afterwards, I can count how many registers stored a '1' to see how far the signal transition propagated. The further it went, the earlier it arrived. Calibration and conversion of these registers to an actual timestamp is a solved problem and not part of my question.

My concern is that quartus will see that:

a <= '1' and inp;

is the same as:

a <= inp;

... and eliminate my introduced delay.

How can I force quartus to add delays to my signal between the capture registers. Is there a way to do this portably? (I will need to do it on a spartan6 afterwards as well).

Altera_Forum · ‎12-12-2011

Might lcell be what I'm looking for?

... I somehow didn't find this on my previous google searches.