On 19 Dez., 11:17, o pere o <m...@somewhere.net> wrote:
> On 12/19/2012 10:19 AM, Thomas Stanka wrote:
>
>
>
> > On 19 Dez., 09:32, o pere o <m...@somewhere.net> wrote:
> >> My current goal is to implement some digital signal processing (filter=
s)
> >> on a FPGA. I am currently using Terasics DE0 nano board. This board ha=
s
> >> an ADC128S022 ADC. I have started as follows:
>
> >> =A0 From the 50 MHz board reference I derive a 25.6 MHz signal with a =
PLL.
> >> =A0 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
>
> > 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.
>
> 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
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _____ =A0 =A0 _____ =A0 =A0 =A0 =A0 =A0 =
=A0_____
> ADC =A0clock ____ =A0 =A0 _____ =A0 =A0 ___...._____ =A0 =A0 ___...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0_
> smpl_rdy =A0 _________________________________ _____...
>
> =A0From all this, I would say that I am doing a fully synchronous design.

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

On Thursday, December 20, 2012 9:58:23 AM UTC, o pere o wrote:
> On 12/19/2012 11:55 PM,  wrote:
> 
> > On Dec 19, 9:32 am, o pere o <m...@somewhere.net> wrote:
> 
> >> 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
> 
> >
> 
> > 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
> 
> 
> 
> 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.
> 
> 
> 
> > 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
> 
> 
> 
> That's certainly true!
> 
> 
> 
> BTW, any inputs on whether using my smpl_rdy as an enable for each 
> 
> register is a good/bad idea?

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


> 
> 
> 
> > -Lasse
> 
> >
> 
> Thanks for your inputs!
> 
> 
> 
> Pere

On 12/19/2012 11:55 PM, langwadt@fonz.dk wrote:
> On Dec 19, 9:32 am, o pere o <m...@somewhere.net> wrote:
>> 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
>
> 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

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.

> 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

That's certainly true!

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

> -Lasse
>
Thanks for your inputs!

Pere

On 12/19/2012 5:17 AM, o pere o wrote:
> On 12/19/2012 10:19 AM, Thomas Stanka wrote:
>> On 19 Dez., 09:32, o pere o <m...@somewhere.net> wrote:
>>> 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
>>
>> 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.
>
> 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.

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.


> 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.

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.


>> 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.
>
> 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.
>
>> best regards Thomas
>
> Thanks!
> Pere

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

On Dec 19, 9:32=A0am, o pere o <m...@somewhere.net> wrote:
> 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:
>
> =A0From the 50 MHz board reference I derive a 25.6 MHz signal with a PLL.
> =A0From 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

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

On 12/19/2012 10:19 AM, Thomas Stanka wrote:
> On 19 Dez., 09:32, o pere o <m...@somewhere.net> wrote:
>> 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
>
> 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.

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.

> 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.

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.

> best regards Thomas

Thanks!
Pere

On 19 Dez., 09:32, o pere o <m...@somewhere.net> wrote:
> 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:
>
> =A0From the 50 MHz board reference I derive a 25.6 MHz signal with a PLL.
> =A0From 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

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

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