How to get 45Mhz clock out?

If you look at DSP builder you will see many examples of time folding.

A faster clock allows for resource sharing at the expense of spaghetti logic.

for example a 32 taps filter requires 32 mult if run at sampling rate. If you run system clock at say 4 times the sampling rate then you can use 32/4 = 8 multipliers only. every clock uses 8 mult in turn and the result is then accumulated. Saves resource but makes life difficult...

In reverse to that you may split up the data path into say two channels odd/even running each runing at half speed and process in parallel until some point. This doubles some of the resource but may help avoiding fast clock to achieve timing.

The notion is all about speed/resource trade off.

I haven't used DSP Builder, and probably will not for some time as we build industrial cameras over here. But I have used resource sharing before, but it was just stuffing a pipelined cordic.

Saving resources always comes at the expense of more work, unfortunately but then it shows off great when we get the job done with the limited resources anyhow ...

Coming back to the original start of this: can you humour me and explain, in the upsampling case of a 100 MHz system / DAC clock and a 45 MHz sampling rate, where the 45 MHz sampling rate comes from?

--- Quote Start ---

Coming back to the original start of this: can you humour me and explain, in the upsampling case of a 100 MHz system / DAC clock and a 45 MHz sampling rate, where the 45 MHz sampling rate comes from?

--- Quote End ---

The original post is just saying a system clock is 100MHz, fpga modules need 45MHz clock. There is nothing about the issue of DAC or upsampling.

In this scenario, I am suggesting to look at the possibility of running fpga modules at 100MHz enabled by clken at 45MHz rate. So 45 comes from the post.

With regard to upsampling diversion:

if you are given data at 45Mhz sampling rate then you will be told whether system clock is 45MHz or 100MHz (i.e. whether sampling rate = clock or is less).

1) possibility 1: data on 100MHz clock. If you want to upsample it to 100Mhz rate then you use an interpolation technique to create new samples.

2)possibility 2: data on 45MHz clock then you cross it over to 100MHz using dcfifo idea then interpolate it to 100MHz

--- Quote Start ---

The original post is just saying a system clock is 100MHz, fpga modules need 45MHz clock. There is nothing about the issue of DAC or upsampling.

--- Quote End ---

I meant where we went off-topic ...

--- Quote Start ---

With regard to upsampling diversion:

if you are given data at 45Mhz sampling rate then you will be told whether system clock is 45MHz or 100MHz (i.e. whether sampling rate = clock or is less).

1) possibility 1: data on 100MHz clock. If you want to upsample it to 100Mhz rate then you use an interpolation technique to create new samples.

2)possibility 2: data on 45MHz clock then you cross it over to 100MHz using dcfifo idea then interpolate it to 100MHz

--- Quote End ---

Say the system clock is 100 MHz and the data is sampled at 45 MHz, but magically is presented in the 100 MHz clock domain as you present in 1). How do we get the sampled data into that 100 MHz domain? I'd say we have to cross over somewhere.

we don't play magic Josyb. the given data clocking scheme is an implementation issue. You are referring back to possibilty 2 when data is clocked by 45MHz physical clock which is separate from 100Mhz and so needs crossing.

When you process your given fpga data(say from LUT) on 100Mhz with clken at 45Mhz then this fits possibilty 1. Thus data is already in 100Mhz domain and does not need any crossing but will need upsampling if it has to get rid of that clken rate of 45 and join the 100Mhz rate nicely.

--- Quote Start ---

we don't play magic Josyb. the given data clocking scheme is an implementation issue. You are referring back to possibilty 2 when data is clocked by 45MHz physical clock which is separate from 100Mhz and so needs crossing.

When you process your given fpga data(say from LUT) on 100Mhz with clken at 45Mhz then this fits possibilty 1. Thus data is already in 100Mhz domain and does not need any crossing but will need upsampling if it has to get rid of that clken rate of 45 and join the 100Mhz rate nicely.

--- Quote End ---

My point was that any real data sampled at a different then system clock needs crossing.

What you referred to as 1) only exists when you downsample to a lower rate and back up again, hence my notion of a 'virtual' (or better said hypothetical?) clock.

I believe we have to stop here at some point, because we start saying the same thing with other words ...

--- Quote Start ---

I just tried on a blank project and it worked perfectly. Is 45MHz the only output? Because as joysb says if you have other output frequencies it can make it impossible for the pll in some cases.

--- Quote End ---

Hello, Thanks for your reminder.

You are right! It can run well, if there is just only one output of the PLL. It seems that I should use another PLL for this 45Mhz clock out.

Thanks