Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
993 Views

Asynchronous Data Pulse Acquisition

Hi altera gurus, 

 

First time poster here. 

 

I've been teaching myself about writing VHDL, timing analysis, and test benches over the past few months while making a customized DSP application on an FPGA board for an experiment that I'm working with. But, I am running into an issue: 

 

I have a Cyclone V with a 50MHz clock. I am receiving digitized pulses from a sensor that are 5 ns long and randomly (though generally sparsely) spaced. These pulses, naturally, are asynchronous, and they are also shorter (200MHz) than my clock domain (50MHz). So, I use the pulses in the sensitivity list of a process statement in an implementation of a flancter (link here) (https://www.doulos.com/knowhow/fpga/fastcounter/). I use these flancters to bring the data pulses into the clock domain, up / down counter them, do some other stuff, and put results in a FIFO. 

 

Now, I've got 16 channels of this (later it will be 32 or even more). When I compile, timequest rightfully gives me a slew of warnings that these lines were "determined to be a clock but was found without an associated clock assignment." So, I modify the .sdc file with this line: 

 

# Create a clock constraints for the asynchronous data inputs of the 16 channels. create_clock -name "data_clks" -period 20.00ns {A } -waveform {0.000 10.000} set_clock_groups -asynchronous -group {data_clks}  

 

Is this the right way to tell timequest and the fitting tools that this is an input that doesn't really matter in terms of clocks, since it's just an asynchronous pulse? Or should I handle the clock constraints differently? 

 

As an aside, I made the above code before I knew that PLLs existed. So, if the above approach is a complete disaster I may just make a 400 MHz PLL from my system clock and use that with a couple shift registers to bring the 5 ns pulses into my clock domain. Thoughts on that approach?
0 Kudos
7 Replies
Altera_Forum
Honored Contributor I
71 Views

Depending on your chosen device, speed grade and how fast it can comfortably be clocked, I'd consider option 2 and use a PLL to generate the higher clock. The downside, you're obviously going to be clocking more logic at a much higher frequency, even if you do the bare minimum before moving everything onto a clock domain operating at a lower frequency. 

 

However, I see nothing wrong with option 1 - the clear advantages of operating only a handful of registers at the higher clock frequency. I think the only correction to the constraint you posted is to specify the period at 5 ns (not 20ns) - as you mentioned, the effective frequency of these 'clocks' is 200MHz. 

 

Cheers, 

Alex 

 

PS. Just spotted Cyclone V - which should have no real issues solving this with a PLL.
Altera_Forum
Honored Contributor I
71 Views

 

--- Quote Start ---  

However, I see nothing wrong with option 1 - the clear advantages of operating only a handful of registers at the higher clock frequency.  

--- Quote End ---  

 

 

Can you elaborate on this statement, please? I don't quite understand what you mean here. I'll try to write out my understanding of it, which might help you to see my issue: Is the sdc statement causing the fitting tools to make the required number of registers at the higher clock frequency and no more? 

 

I have been testing it a bunch on hardware since my original post, and it works (hooray!) even without the "period 5ns" change in the constraint. But I will put it in and test it just to be safe.  

 

Should it be 10ns for that constraint, since the pulse length is 5ns? I suggest this since it'd be 5ns "on" for that pulse and thus I add 5ns "off" for the "clock" period.
Altera_Forum
Honored Contributor I
71 Views

No - the SDC doesn't affect the number of registers you'll end up with. Only your code will do that. By using option 1 your code will only describe two registers, operating @ '100MHz', per sensor signal - what you'll end up with. 

 

In order to over-sample the signals, as in option 2, you will simply end up with - or should I say likely to end up with, based on the implementation I have in my head - a greater number of registers operating at a much higher frequency, 400MHz. Each will need shifting in through 3 registers and you will then need further logic to detect the pulse and another register to latch it. So, I make that 4 registers for option 2. 

 

Given the device you're using and the number of registers we're talking about here, the 'clear advantage' as I put it isn't actually that great. However, in general, clocking logic more slowly makes everything a little easier. 

 

Yes, I agree with 10ns. 

 

Cheers, 

Alex
Altera_Forum
Honored Contributor I
71 Views

I understand. Thank you for clearing that up for me. 

 

I've gone with the first solution and I've tested it with that 10ns period and it all seems to work. Now to test it with real experiment data!
Altera_Forum
Honored Contributor I
71 Views

To understand if the timing constraint is correct, we should see the logic it's applied to. 

 

I think that the problem of reading 5 ns pulses into a 50 MHz clock domain would be usually solved by a toggle synchronizer.
Altera_Forum
Honored Contributor I
71 Views

 

--- Quote Start ---  

To understand if the timing constraint is correct, we should see the logic it's applied to. 

 

I think that the problem of reading 5 ns pulses into a 50 MHz clock domain would be usually solved by a toggle synchronizer. 

--- Quote End ---  

 

 

The logic it's used for is a flancter. I'm not sure if that answers the question you're asking, though. 

 

I'm not able to use a toggle synchronizer here because I don't actually have access to the clock domain these pulses are coming in at (they're from an external instrument), so I can't put in the required FF on the faster domain.
Altera_Forum
Honored Contributor I
71 Views

I believe you are confusing things. A flancter requires access to the fast clock domain (by using a "Set Clock"), a toggle synchronizer doesn't.

Reply