New Contributor
Super ContributorHi,
apart from the posted code that's obviously not working in hardware and will never work, can we get a brief desscription of the overall design purpose? We can probably help to answer the question if and how it's implementable in Cyclone 10 FPGA.
Presently, the only substantial specification is "I have a requirement to count sub-nanosecond ticks, preferably 200ps or less".
Can you elaborate, sketching expected input waveforms and clarifying witch signal parameters have to be extracted?
Before going into HDL descriptions and timing constraints, I would discuss the problem referring to FPGA hardware capabilities.
As a simple starting point, Cyclone 10CL, speed class 8 has a maximal core clock of 400 MHz. That's (simplifying things a bit) the maximal clock speed of FPGA registers, resulting in a time resolution of 2.5 ns. Faster events can be processed under circumstances using DDR and phase shifted clocks. There are nevertheless minimal pulse witdh requirements. 200 ps pulse width is out of reach, 200 ps edge delay generation and measurement can be feasible.
New ContributorTiming diagram with
Comments from the code...
input iLatch1, // signal event that latches the counter to register 1 input iLatch2, // signal event that latches the counter to register 2 input iResetLatch1, // sent after the value in register 1 is read from (or sent to) the USB input iResetLatch2, // sent after the value in register 2 is read from (or sent to) the USB output [31:0] o1COUNTER, // register 1 with latched counter value output [31:0] o1COUNTERHi, // register 1 with latched counter value high bits output [31:0] o2COUNTER, // register 2 with latched counter value output [31:0] o2COUNTERHi, // register 2 with latched counter value high bits output oRdyCOUNTER, // signals that data has been latched in register 1 output oRdyCOUNTER2, // signals that data has been latched in register 2
So - a high speed clock.
2 registers to store the current clock, when triggered by iLatch1 or iLatch2
once the value is latched, the internal latchLock1 and latchLock2 are set, which become the oReadyCounter and oReadyCounter2 signals out.
The values are read over a USB connection from the latched registers (o1Counter, o2Counter in the simulation diagram).
Then the iRstLatch1, or iRstLatch2 is sent to reset the latchLock1 or latchLock2, to allow the iLatch1 or iLatch2 triggers to latch a new value.
latchLock1 <= ( iLatch1 || latchLock1 ) && !( !iLatch1 && ( rstLatchLock1 ||iResetLatch1 ) ); rstLatchLock1 <= ( iLatch1 && (iResetLatch1 || rstLatchLock1) ) ; latchLock2 <= ( iLatch2 || latchLock2 ) && !( !iLatch2 && ( rstLatchLock2 ||iResetLatch2 ) ); rstLatchLock2 <= ( iLatch2 && ( iResetLatch2 || rstLatchLock2 ) ) ;
latchLock is set on posedge iLatch1 , and not reset.
if iLatch1 is still high when the iResetLatch1 comes in, then an internal flag rstLatchLock1 is set until iLatch1 disappears.
same of 2.
So [high speed counter] ->on latch signal -> [register1] or [register2] -> read values -> reset lock on registers so a new timer can be latched.
all of the latching/reset stuff is very slow (the latch signal from a pin will probably be about 1 millisecond, and from the test program is more like 10 milliseconds long) the reset signal is also probably about 10 milliseconds long ... the time from latching until the signal is read should be less than 1 second, but delays of a few milliseconds overall are acceptable.
The only thing that's time critical is 1) a high tick rate and 2) when the signal from a pin is recognized, latch the current clock into a register; and there's two registers which can be latched from the single time source, with separate latching signals.
