Electronics > FPGA

Correctly handling clocks on a older Cyclone IV

(1/5) > >>

pieroc91:
Hi everyone. I'm trying to wrap my head around this but I cannot make any sense of it.

I have a board based on an old EP4CE6E22, i'm using it to control a very old digital camera which returns data on a 8 bit parallel bus plus a 6 Mhz clock signal.
I'm sending this data to a cache made with registers inside the FPGA in order to make slightly bigger chunk sizes and send at faster rates so i have idle time to allow for RAM refresh.
The FPGA board has a built in 66 Mhz clock that i'm using for every other operation on the FPGA.

The problem is when I interface the clock signal. The code increments a bit counter on the negative edge of that 6 Mhz clock and when it reaches certain amount it request the next line of the sensor.

if i use:

always @(negedge 6mclock)
counter = counter +1;

it does not work at all, sometimes doesn't even count anything, sometimes it does, but when it does, it's a complete mess and ends up hanging the counter, I got a similar behavior by floating the pin.

if i use:

always @(negedge copyclock)
counter = counter +1;

always @(posedge 66mclock)
copyclock = 6mclock;

Works a little jumpy and misses some chunks of clock cycles but mostly works.

If i divide the 66 Mhz clock and use it instead I got a solid and stable burst of data but i'm not sure if i'm on sync with the signal.

I've sent the 6 Mhz clock and my 6 Mhz divided clock to two different output pins of the FPGA for a few seconds and counted the pulses with a logic analyzer and i got the exact same number of pulses so i know the 6 Mhz clock is arriving fine to the innards of the FPGA.

What am i doing wrong?

c64:
How clean is the 6M clock? If you route it through fpga and use your LA to count, does it still count correctly?

Like this CAM_6M -> fpga -> LA

What happens if you change your code to posedge and non-blocking assignments?

pieroc91:
Hi @c64, thanks for your reply.

Routing both the failing external 6M clock and the divided 6M i divide inside the FPGA that makes it work to two pins and make the LA to count gives me the exact amount of between both clocks, which means it's clean enough to be routed and replicated.

By using posedge i get the same result. Haven't tested the non-blocking part but i'm not sure that it will change the behavior.

How can you suggest to make some test-code?

Someone:
You'll need to step back and validate exactly what the signals are that arrive at the FPGA, with a scope. Signal integrity and timing relationships/constraints.

also

Draw out all the clocks you are planning to use and what they interact with, to identify where clock crossing (magic pixie dust) methodologies are needed.

pieroc91:
Yeah, signals are fine, if i route them inside the fpga and back out again they come out again perfectly. that's ruled out.

The problem is why is not counting with it, that counter is completely unrelated to any other signal, it just adds up and count the cycles from that.

I know that by "buffering" the signal on a internal register tied to the faster clock can change the phase of the buffered signal a little bit with a margin of change of the size of one clock cycle of the 66mhz clock, that's minor and it's ok on this case, but the effect is dramatic enough to almost fix the problem of not counting.

Why does the "buffered" signal works and the real signal doesn't?

(i say "buffer" on quotes because is not a real buffer but just a copy inside the fpga)

Navigation

[0] Message Index

[#] Next page