FPGA DSP basics: clock enable / new clock

My current goal is to implement some digital signal processing (filters) on a FPGA. I am currently using Terasics DE0 nano board. This board has an ADC128S022 ADC. I have started as follows:

From the 50 MHz board reference I derive a 25.6 MHz signal with a PLL. From this clock I generate the signals required to drive the ADC, essentially a clock at 3.2 MHz. Every 16 clock cycles, the ADC gives a

12 bit sample. This translates into 200 ksps. I generate a signal "smpl_rdy" at the appropriate position which allows me to latch the 8 most significant bits.

The main question is how should I do the signal processing:

a) Using the 25.6 MHz clock and using smpl_rdy as a clock enable b) Deriving a new 200 kHz clock from the PLL

I have done some projects on FPGAs but they were quite simple, so I consider myself only a little more than a beginner. I can think of some problems with both approaches, but I may have overlooked may others:

For instance, if I followed a), I guess that Quartus II would think that the processing happens at 25.6 MHz: if there is a long combinational path between registers, the timing analyzer will not be able to figure out that the data and the enable signal are stable during 16 clock cycles. Is there a way to provide this info to Quartus II? OTOH, using the same signal as an enable for everything further down does not seem sound enough, thinking of fanouts. So what?

If I tried to follow b), how would I ensure that there is the proper phase relationship between both clocks? Is there a way to achieve this?

Thanks for any advice.

Pere

Reply to
o pere o
Loading thread data ...

If you have not that much experience try to use only _one_ clock for everything in the FPGA, this gives a synchronous design. As this clock is higher than the ADC clock you can easily treat the signals from ADC as asynchronous, and get them still proper (oversampling of ready, allows you to determine, when the data is stable). The easiest design is complete synchronous with only one clock and considering all inputs as asynchronous. The frequencies you mention indicate no reason, why that should not be possible in your case.

25 MHz should not be the big deal for a most operations in modern FPGAs if you use some pipelining. In case you would like to use some enable and have the operation processing within several clock cycles use "multicycle path" constraint. I have no experience with quartus but in general every tool should be able to allow setting multi cycle constraints in a certain way.

best regards Thomas

Reply to
Thomas Stanka

Well, this is just to get started. Once I'm running I will try to speed everything up as much as possible, just to learn something from it :) So, I'd also like to know "the" way to do it right.

BTW, I don't understand what you mean saying that I can treat the signals as asynchronous: At a given time point in the ADC serial stream, I generate a 1-clock-wide signal that indicates that the data is ready. In the approach a) I plan to use this signal as an enable for all the registers in the processing path.

main clock TTTTTTTTTTTTTTTTTTTTTT....TTTTTTTTTTTTTTT _____ _____ _____ ADC clock ____ _____ ___...._____ ___... _ smpl_rdy _________________________________ _____...

From all this, I would say that I am doing a fully synchronous design.

Aha! This is exactly what I was looking for. I would rather not have to pipeline something just because the fitter is trying to meet the 25.6 MHz timing when the true clock is just 200 kHz. With this keyword I will (hopefully) find the way to do in Quartus.

Thanks! Pere

Reply to
o pere o

Do you need the 25.6MHz or could you do everything synchronous on a

3.2MHz ? Then, even without telling it that you have multi cycles paths, timing should be easy

But also consider that for a lower clock rate you might need more resources

i.e. filter running at 25.6MHz might only need one mul-acc, where a filter running at 3.2MHz needs 8

-Lasse

Reply to
langwadt

I don't know that there is a single "right" way to do this. Certainly there are many "wrong" ways. In general it is easy to use a single clock, but as you say, you then have concerns about how to provide the appropriate timing constraint to Quartus. I haven't used Quartus in years, but I am sure this is possible.

Some folks call this "multi-cycle" timing. The way constraints are handled under the Xilinx tools it is just a different timing constraint than the clock period specification and so has priority for the paths a specific timing constraint is specified for.

I think Thomas is saying you can treat the ADC interface as if it were async to the main clock. But your ADC is driven synchronously with your

25.6 MHz clock so this is not really needed and will likely use extra logic and work.

To use a 200 kHz clock should not be any real problem. You just need to consider the timing of the 200 kHz clock when you design your circuit. An easy way to cross the clock domain boundary is to register the data from the ADC using the 25.6 MHz clock and a 200 kHz enable. Make sure the rising edge of the 200 kHz clock is delayed at least one cycle from this register enable. Then register the data a second time in the 200 kHz clock domain. This will help save some power as well as minimizing your timing analysis issues.

Rick

Reply to
rickman

In this case, I could do everything at a much lower frequency. As I have to generate the signals to control the ADC, my approach has been to start with a system frequency at least 2x the ADC clock frequency that I have to generate. So, I could work with 6.4MHz and timing would be much easier. However, the main point of my question was to learn the proper way to do this.

That's certainly true!

BTW, any inputs on whether using my smpl_rdy as an enable for each register is a good/bad idea?

Thanks for your inputs!

Pere

Reply to
o pere o

That is how I would do it for sure in this case.

Reply to
Dave

s)

s

PLL.

 _____
         _

As Rickman already stated there are ways to do this right and more ways to do it wrong. Synchronous design means same frequency with _known_ phase relation (within a reasonable window) of clock at all nodes at which you use the clock. Same frequency but unknown phase relation should be considered asynchronous if you could not guarantee, that the phase will not drift over a certain edge that leads to undesired behavior.

bye Thomas

Reply to
Thomas Stanka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.