Detecting Rising edges of Clk1 and Clk2

[manofwax]

Dear All,

I want to stop my counter when clk1 and clk2 are coincidence.//rising edge of them happen at the same time...

The freq of clk1 = 100MHz
The Freq of clk2 = 100MHz * 16/17

Rising edge of clk1 and clk2 should eventually align together at the 16th cycle of clk1 and 17th cycle of clk2 assuming they started at the same time in the beginning.

But i can't detect this event. Here's my code:

entity counter is
generic(n: natural := 8 );
port(clock1 : in std_logic;
clock2 : in std_logic;
count : in std_logic;
Q ut std_logic_vector(n-1 downto 0));
end counter;

----------------------------------------------------
architecture behv of counter is
signal Pre_Q: std_logic_vector(n-1 downto 0) := "00000000";
signal stop : std_logic := '0';
begin
process(clock1, clock2)
begin
if (clock = '1' and clock'event) then
if count = '1' and stop = '0' then
Pre_Q <= Pre_Q + 1;
end if;
if ((clock_ref = '1' and clock_ref'event)) then
stop <= '1';
end if;
end if;
end process;
Q <= Pre_Q;
end behv;

Thanks in advance...

 

[banjo]

Your code never defines the signal clock. I think you need to AND together the two clocks, clock1 and clock2.

I would AND together these clocks as a combinatorial signal, clock3. Then put clock3 by itself into the sensitivity list and into the "clock'event". By combinatorial, I mean outside of all processes, so it is not dependent on other clock events.

I think this will get you working, but it is not without some gotchas. This can produce a narrow glitch pulse instead of a nice clean clock. Assume that the rising edge of clock2 is right before the falling edge of clock1. This still mets the criteria, but may be too narrow to trigger the flop. Solutions to these glitches, if they cause a problem, require some knowledge of the expected phase of the two clocks with respect to each other.

 

[Iouri]

are those clocks are from the same source??? What is phase shift between then, otherwise I dont think you can two risinggs at the same time

 

[manofwax]

Banjo, ANDing them together doesn't help. For Example, if clk1 has a rising edge while clk2 is already high, clk3 will have a rising edge. But this is not what I want, i want to detect the moment when both clk1 and clk2 rise. Thanks...

Iouri, Yes they are from the same source...

Thank you very much for the help...

 

[laststep]

this is onli my 2 cent...

Since 2 clk are from same source and start at the same time i would suggest that xor the 2 signal and count the rising for 18 times as in your case then u will get the same rising clk egde for this 2 signal then reset the counter and keep repeat for the process

 

[bis_]

manowfax: Your idea is wrong. In the theory the rising edges of the two clock are "at the same moment", but in the real word of the FPGA it is practicaly impossible. There are clock jitter and transport delays. You can have situation where edge of the clk1 will be before edge of the clk2 and in another place of the real FPGA clk2 can be before clk1, it depends form delays in routing resources. The jitter can produce more funny errors in edge corelation. You need to change your design architecture to one without this kind of corelation, I think.

bis

 

[laststep]

yup, bis is correct i dunno how u generate the 100Hz *16/17 clk signal but not matter what method u using (circuit or programming) there will be a delay between 2 signal so practically u cant gt 2 signal start at the same time

 

[manofwax]

Bis and laststep,

Yes, totally agree with you guys. If I it's impossible for two clock to happen at the same time. How can I design my fpga so that I can get the attaching waveform... Thanks in advance...

 

[banjo]

Just which signal are you actually trying to generate? A pulse with interval "T" or "T3"? (T1 and T2 are easy has they are fully in a single clock domain.)

To me this seems like a structural verilog problem. You will have to generate logic at the SLICE or CLB level to take full advantage of the resources within the FPGA.

Xilinx for example often has four SLICEs contained in a CLB. There can be only one clock input into any one SLICE. However, usually you can get at least two different clocks into a CLB. I would reduce this down to SLICE based logic and then force the SLICEs to be in the same CLB or very close CLBs. In that way you can better control the routing delays of the async signals where you must cross clock domains. Xilinx does not have a min delay constraint, so exact delay matching is not possible. However, you can get pretty close via trial and error. Once you force the routing to be what you want, it is possible to create a hard macro that will always route that way.

The intervals, N1 and N2 are most easily done with shift registers. Fortunately, it is possible to configure the LUT within the SLICE to a somewhat decent shift register. The output delay is kind of long so we often set the shift register to N-1 and then follow it with a flop in the same SLICE to sharpen up the clock to output timing.

 

[echo47]

Are you trying to build something like a time interval interpolator or vernier?
Maybe if you describe your project more generally, someone could suggest a straightforward solution.

 

[manofwax]

echo, yes yes, i'm trying to build a time interval interpolator with vernier method so i can make the clock resolution higher... Any easy solution? MILLION THANKS...

banjo, i only have the reference oscillator, and a start trigger which isn't shown in the graph. When start_trigger signal goes high, the startTPO will start oscillating WITH A RISING EDGE in the beginning. (sorry for the capital letter, coz it is actually my other problem that is posted on this forum too, please take a look.) I'm not too familiar with the rest of the SLICE stuff u mention. I will do more research tomorrow, it's getting later here. THANK YOU SO MUCH!!!

Million thanks...

 

[Iouri]

what if you put two counters one running from 100MHZ another from 16/17*100MHZ and compare output values to generate your stop signal

stop <= '1' when cntr1 = 16 and cntr2 = 17 else '0'

there is latency will be there