I have one clock of 140 MHz. This clock drive a DAC and FPGA. I would like
to generate a sample rate that is not a integer of this clock and drive a
DAC with this sample rate.
>I have one clock of 140 MHz. This clock drive a DAC and FPGA. I would like
>to generate a sample rate that is not a integer of this clock and drive a
>DAC with this sample rate.
>This sample rate must be brought to the speed of the clock of DAC to
>generate it, by interpolating.
>How to achieve ? It is possible ?
How much do you care about the quality of the signal your DAC
is generating?
If you want a clean signal, your best bet is to run the DAC off
a low jitter osc package.
You can make a signal that's close to 9.4 MHz, but it will have
some jitter. Google for dds. If you get close enough the
error in your source clock will be the major source of error.
--
These are my opinions, not necessarily my employer's. I hate spam.
On Fri, 21 Nov 2008 21:14:16 +0100, "Kappa" wrote:
>I have one clock of 140 MHz. This clock drive a DAC and FPGA. I would like
>to generate a sample rate that is not a integer of this clock and drive a
>DAC with this sample rate.
>
>Example: Clock 140 MHz --> Sample rate "66Mhz / 7" = 9.428571429 MHz.
>
>This sample rate must be brought to the speed of the clock of DAC to
>generate it, by interpolating.
Which FPGA? Does it have PLLs or (Xilinx) DCMs? If so
you can multiply your clock by M/N where M and N are integers;
of course there are limits both on the values of M and N,
and on the possible range of output frequencies, but with a
little creativity you can probably do what you need.
It's all in the data books, or alternatively you can
learn a lot simply by running the IP-generator wizard.
Another choice is to find out about DDFS (Direct Digital
Frequency Synthesis). With this technique you can generate
an output frequency with arbitrarily good precision, but
the output will suffer jitter of up to one period of the
input clock (140MHz, so about 7ns of jitter).
More advanced techniques for getting both high resolution
and low jitter have been discussed here at length in the past.
--
Jonathan Bromley, Consultant
> How much do you care about the quality of the signal your DAC
> is generating?
The signal must be good SFDR 60 dB or more.
> If you want a clean signal, your best bet is to run the DAC off
> a low jitter osc package.
Yes, 140 MHz is a OSC with low jitter.
> You can make a signal that's close to 9.4 MHz, but it will have
> some jitter. Google for dds. If you get close enough the
> error in your source clock will be the major source of error.
I should not generate an output signal of 9.4 MHz, are able to do this with
a DDS, but clocking data at this speed.
On Nov 21, 3:58*pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 21 Nov 2008 21:14:16 +0100, "Kappa" wrote:
> >I have one clock of 140 MHz. This clock drive a DAC and FPGA. I would like
> >to generate a sample rate that is not a integer of this clock and drive a
> >DAC with this sample rate.
>
> >Example: Clock 140 MHz --> Sample rate "66Mhz / 7" = 9.428571429 MHz.
>
> >This sample rate must be brought to the speed of the clock of DAC to
> >generate it, by interpolating.
>
> Which FPGA? *Does it have PLLs or (Xilinx) DCMs? *If so
> you can multiply your clock by M/N where M and N are integers;
> of course there are limits both on the values of M and N,
> and on the possible range of output frequencies, but with a
> little creativity you can probably do what you need.
> It's all in the data books, or alternatively you can
> learn a lot simply by running the IP-generator wizard.
>
> Another choice is to find out about DDFS (Direct Digital
> Frequency Synthesis). *With this technique you can generate
> an output frequency with arbitrarily good precision, but
> the output will suffer jitter of up to one period of the
> input clock (140MHz, so about 7ns of jitter).
>
If you have DDR output registers it's easy enough to
make a DDFS with 1/2 cycle jitter or 3.5ns
> More advanced techniques for getting both high resolution
> and low jitter have been discussed here at length in the past.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
> If so you can multiply your clock by M/N where M and N are integers;
> of course there are limits both on the values of M and N,
> and on the possible range of output frequencies, but with a
> little creativity you can probably do what you need.
> It's all in the data books, or alternatively you can
> learn a lot simply by running the IP-generator wizard.
I am okay. But if I place a two DCM for example:
synthesis attribute CLKFX_MULTIPLY of DCM0 is 2
synthesis attribute CLKFX_DIVIDE of DCM0 is 11
synthesis attribute CLKFX_MULTIPLY of DCM1 is 10
synthesis attribute CLKFX_DIVIDE of DCM1 is 27
actual frequency generated is: 9.427609 MHz (Not exactly frequency)
This is OK.
Now I have to interpolate order to bring the data to the DAC but how ?
> Another choice is to find out about DDFS (Direct Digital
> Frequency Synthesis). With this technique you can generate
> an output frequency with arbitrarily good precision, but
> the output will suffer jitter of up to one period of the
> input clock (140MHz, so about 7ns of jitter).
I am okay. But the signal is SQUARE WAVE ?
> More advanced techniques for getting both high resolution
> and low jitter have been discussed here at length in the past.
On Fri, 21 Nov 2008 21:14:16 +0100
"Kappa" <[email protected]_NO_SPAM> wrote:
> Hi,
>
> I have one clock of 140 MHz. This clock drive a DAC and FPGA. I would
> like to generate a sample rate that is not a integer of this clock
> and drive a DAC with this sample rate.
>
> Example: Clock 140 MHz --> Sample rate "66Mhz / 7" = 9.428571429 MHz.
>
> This sample rate must be brought to the speed of the clock of DAC to
> generate it, by interpolating.
>
> How to achieve ? It is possible ?
>
> Thanks.
>
> Kappa.
>
>
Not to ask what may be a stupid question, but why exactly do you want
to generate this precise sample rate?
--
Rob Gaddi, Highland Technology
Email address is currently out of order
On 21 Nov., 22:21, "Kappa" <NO_SPAM_78kapp...@virgilio.it_NO_SPAM>
wrote:
> Perhaps I explained badly.
Yes, I think so.
Your DAC ist running at 140MHz?
So probably you should run your signal processing and the data
transfer between FPGA and DAC also at 140MHz.
Do you want to sent arbitrary PCM coded signals that arrive at
9.4...MHz to the DAC at 140MHz?
(google "sample rate conversion", specifically "non integer
upsampling")
or do you want to use your DAC to output a 9.4...MHz Signal, for
example a 9.4MHz sine wave?
In that case google "DDS" or "Direct Digital Synthesis" or look for
some posts by Peter Alfke in this newgroup.
> So probably you should run your signal processing and the data
> transfer between FPGA and DAC also at 140MHz.
Yes. My DAC and FPGA works at 140 MHz.
> Do you want to sent arbitrary PCM coded signals that arrive at
> 9.4...MHz to the DAC at 140MHz?
Yes. My data is at 9.4 MHz Sample Rate.
> or do you want to use your DAC to output a 9.4...MHz Signal, for
> example a 9.4MHz sine wave?
> In that case google "DDS" or "Direct Digital Synthesis" or look for
> some posts by Peter Alfke in this newgroup.
>> How much do you care about the quality of the signal your DAC
>> is generating?
>
>The signal must be good SFDR 60 dB or more.
60 dB isn't a lot, but my math skills are good enough
to translate that to/from clock jitter.
>> If you want a clean signal, your best bet is to run the DAC off
>> a low jitter osc package.
>
>Yes, 140 MHz is a OSC with low jitter.
There are two sources of jitter that seem important in this
discussion.
If you run the clock thrugh the FPGA, that will add some jitter,
more if you use the DCM. This comes from things like noise on the
power supply rails.
If you use something like a DDS to make another clock you can get
lots of "interesting" spurs that may or may not be a problem for
your application.
>> You can make a signal that's close to 9.4 MHz, but it will have
>> some jitter. Google for dds. If you get close enough the
>> error in your source clock will be the major source of error.
>
>I should not generate an output signal of 9.4 MHz, are able to do this with
>a DDS, but clocking data at this speed.
I can't figure out what that means.
--
These are my opinions, not necessarily my employer's. I hate spam.
>Yes. My DAC and FPGA works at 140 MHz.
>
>> Do you want to sent arbitrary PCM coded signals that arrive at
>> 9.4...MHz to the DAC at 140MHz?
>
>Yes. My data is at 9.4 MHz Sample Rate.
(Assuming I understand what you are doing...)
If you were doing it with pencil and paper, you would
interpolate between your 9.4 MHz data points to find
the appropriate values to send to your 140 MHz DAC.
I think that is something like a filter, but I'm not
fluent in this area. You might ask in the dsp newsgroup.
--
These are my opinions, not necessarily my employer's. I hate spam.
> >Yes. My data is at 9.4 MHz Sample Rate.
>
> (Assuming I understand what you are doing...)
I'm happy ...
> If you were doing it with pencil and paper, you would
> interpolate between your 9.4 MHz data points to find
> the appropriate values to send to your 140 MHz DAC.
The value is not exactly 9.4 MHz but "66Mhz / 7" = 9.428571429 MHz.
This "Sample Time" clocking data to be brought to the sample rate of
140 MHz and then be sent to the DAC.
On that we agree ?
In theory the data should be interpolated to "140 MHz / (66Mhz / 7)" =
"(140 MHz * 7) / 66MHz" = "980 MHz / 66 MHz" = "14,8484...."
How is this possible ? I can not imagine a possibility of
realization.
How to make a SQUARE WAVE CLOCK of "66MHz / 7" from 140 MHz to
clocking data ?
I am frustrated :-( ....
> I think that is something like a filter, but I'm not
> fluent in this area. *You might ask in the dsp newsgroup.
>Hi Hal Murray,
>
>Thanks for your support ...
>
>> >Yes. My data is at 9.4 MHz Sample Rate.
>>
>> (Assuming I understand what you are doing...)
>
>I'm happy ...
>
>> If you were doing it with pencil and paper, you would
>> interpolate between your 9.4 MHz data points to find
>> the appropriate values to send to your 140 MHz DAC.
>
>The value is not exactly 9.4 MHz but "66Mhz / 7" =3D 9.428571429 MHz.
>
>This "Sample Time" clocking data to be brought to the sample rate of
>140 MHz and then be sent to the DAC.
>
>On that we agree ?
>
>In theory the data should be interpolated to "140 MHz / (66Mhz / 7)" =3D
>"(140 MHz * 7) / 66MHz" =3D "980 MHz / 66 MHz" =3D "14,8484...."
>
>How is this possible ? I can not imagine a possibility of
>realization.
>
>How to make a SQUARE WAVE CLOCK of "66MHz / 7" from 140 MHz to
>clocking data ?
>
>I am frustrated :-( ....
>
>> I think that is something like a filter, but I'm not
>> fluent in this area. =A0You might ask in the dsp newsgroup.
>
>I'am try ...
>
>Thanks.
>
>Kappa.
Hi Kappa,
If you want to upsample your signal by 66/7 then this should be possibl
using one FIR filter that implements fractional(rational)interpolation(on
filter for FPGAs is attractive, DSP people may use more filters).
The idea is a bit difficult but depends on using one Filter only and le
it do an interpolatin of 66 followed by decimation of 7. I have mor
details on this if you are interested.
>
> If you want to upsample your signal by 66/7 then this should be possible
> using one FIR filter that implements fractional(rational)interpolation(one
> filter for FPGAs is attractive, DSP people may use more filters).
>
> The idea is a bit difficult but depends on using one Filter only and let
> it do an interpolatin of 66 followed by decimation of 7. I have more
> details on this if you are interested.
>
> Kadhiem
>
...... and this works in a time sampled system .. or is the FIR unclocked?
(!)
>..... and this works in a time sampled system .. or is the FIR unclocked
>(!)
Hi,
Any FIR filter works as a sampling system and needs a clock. It will wor
at 140MHz clock but will clock data in at any lower rate.
I am still not clear what you actually want to do.
I know your DAC is at 140MHz.
You also say that your FPGA runs at 140MHz(but possibly not your data)
What is your FPGA data sampling frequency then(effective clk if enabl
used)?
> The idea is a bit difficult but depends on using one Filter only and let
> it do an interpolatin of 66 followed by decimation of 7. I have more
> details on this if you are interested.
I'm interested, but why interpolate for 66 ? I do not understand.
> Any FIR filter works as a sampling system and needs a clock. It will work
> at 140MHz clock but will clock data in at any lower rate.
Ok.
> I am still not clear what you actually want to do.
> I know your DAC is at 140MHz.
> You also say that your FPGA runs at 140MHz(but possibly not your data)
> What is your FPGA data sampling frequency then(effective clk if enable
> used)?
So you need to upsample by [140/(66/7)] = 140 * 7/66 = 70 * 7/33 = 490/33
Thus I = 490, D = 33
step(1) coefficient design (most difficult)
The total taps should be a multiple of 490 e.g. 490 * 8 = 3920
(this implies 490 subfilters (polyphases) each of 8 taps.
design any low pass FIR filter of your choice, let passband ripple b
minimum, let it cutoff to remove first image and further. This depends o
your maximum signal frequency(fmax) and remember the I = 490 so the cutof
of the filter must be assuming this Fs as 1 hence your Fmax will move 1/49
with respect to new Fs. Note also that the D of 33 will move your Fmax bac
33 times towards Fs.
Try Matlab function upfirdn to design your filter correctly
You may increase the number of taps per polyphase instead of 8 to improv
filtering but the number of polyphases of 490 must stay.
step(2)Implement in FPGA
First:
break up your taps sequentially into 8 sections each having 490 taps an
store in 8 memory blocks. section (1) to contain first 490 taps, sectio
(2) the next 490 taps and so on...
Second:
you will need a delay line of 8 stages for the input.
Third:
use a free running modulo adder(0 ~ 498) running on 140MHz, increment b
33.
The adder will address all the 8 blocks at every value.
At overflow ONLY advance the input and delay stages by one sample only
i.e. generate your enable from this overflow signal by one sample o
140MHz
-convolve the taps and stages at every clock of 140 and produce a
output.
An important issue here is to synchronise input with polyphases. When th
input starts it must convolve with polyphases in the right order startin
from first(not wrap up) and this is meant at the multipliers. Else th
filter will distort your signal.
I hope it is clear ...
If it is difficult let me know
> So you need to upsample by [140/(66/7)] = 140 * 7/66 = 70 * 7/33 = 490/33
>
> Thus I = 490, D = 33
There is a possibility that this filter comes in a Spartan 3A DSP 1800 ?
> step(1) coefficient design (most difficult)
>
> The total taps should be a multiple of 490 e.g. 490 * 8 = 3920
> (this implies 490 subfilters (polyphases) each of 8 taps.
> design any low pass FIR filter of your choice, let passband ripple be
> minimum, let it cutoff to remove first image and further. This depends on
> your maximum signal frequency(fmax) and remember the I = 490 so the cutoff
> of the filter must be assuming this Fs as 1 hence your Fmax will move
> 1/490
> with respect to new Fs. Note also that the D of 33 will move your Fmax
> back
> 33 times towards Fs.
>
> Try Matlab function upfirdn to design your filter correctly
> You may increase the number of taps per polyphase instead of 8 to improve
> filtering but the number of polyphases of 490 must stay.
% Parameter interpolator
I = 490; D = 33;
% 490 subfilter of 8 taps
N = 8 * I;
% Filter coefficient
h = fir1(N, 1/I, kaiser(N+1, 8));
> step(2)Implement in FPGA
> First:
> break up your taps sequentially into 8 sections each having 490 taps and
> store in 8 memory blocks. section (1) to contain first 490 taps, section
> (2) the next 490 taps and so on...
>
> Second:
> you will need a delay line of 8 stages for the input.
>
> Third:
> use a free running modulo adder(0 ~ 498) running on 140MHz, increment by
> 33.
> The adder will address all the 8 blocks at every value.
> At overflow ONLY advance the input and delay stages by one sample only.
> i.e. generate your enable from this overflow signal by one sample of
> 140MHz
>
> -convolve the taps and stages at every clock of 140 and produce an
> output.
>
> An important issue here is to synchronise input with polyphases. When the
> input starts it must convolve with polyphases in the right order starting
> from first(not wrap up) and this is meant at the multipliers. Else the
> filter will distort your signal.
Before commiting to the design, you will need to look at other options:
-If you are resource limited then you can use a CIC filter
(Tools can generate a CIC for you). This only needs few adders.
The drawback is the passband droop of CIC which is similar to that o
running average filter and needs a correcting filter(inverse sinc).
- you can factorise 490/33 right down to prime numbers e.g.
[49 x 5 x2]/[3 x 11] and design multistage but this complicates it furthe
and only makes sense for a DSP software platform. In fpga you may prefe
245/33 stage then x2 stage.
> So you need to upsample by [140/(66/7)] = 140 * 7/66 = 70 * 7/33 = 490/33
There is an alternative, that might be better or worse than Kadhiems
proposal, depending on your application: You can do sin(x)/x
interpolation.
Your 140MHz DAC clock runs periodically through 490 positions relative
to your sample clock, so you need 490 coefficient sets resulting in
one coefficient BRAM per Multiplier.
You than compute
Y[t1] = c(i)(-n)*X[t2-n] + .... + c(i)(n)*X[t2+n]
where i cycles through 0...479.
n will determine the quality of the result and is application
dependent (in theory it must be infinite)
t1 is the time position in your output sequence and is incremented by
one every clock cycle.
t2 is the time position in your input sequence and must be incremented
33 times in 490 clock cycles. You can have the times at which t2 must
be incremented stored in the coefficent RAM as well (490x1 RAM), or
compute them on the fly using Bresenhams line drawing algorithm.
The coeficients are sin(x)/x with x being the relative position of the
DAC clock to the input clock.