DCM question

Hi, for my project I'd like to use the same 25MHz clock signal (coming from an external oscillator) for both the DSP and my Spartan3. A pll inside the DSP creates the 600MHz clock from the 25MHz. I still don't know how fast I'll let the FPGA work, so I was supposed to acquire the 25MHz clock and through a DCM bring it to the level, i.e. 50MHz or 60Mhz, that optimizes my design. In such a way I would have the same clock for both my devices, syncronized and each with its proper frequency. Can I do that or should I avoid this way of working? Is it a common way to work? Suggestions? Thanks, Marco

Reply to
Marco
Loading thread data ...

I don´t know the exact way the DSP creates the 600 MHz, but my best suggestion would be to use the DCM to go up from 25MHz to 50 or 60 MHz (whichever fits you best), and then output this signal to the DSP, so that it derives its internal clock from the one generated by the FPGA. You may even need to feedback the clock to the FPGA.

Thus way, you may have a better control of the phase between both devices, and the inter-clock jitter will be limited to that coming from the DSP, the other way you might get more jitter as both the devices would put their own contribution.

Maybe there are better solutions, but you must first analyse the synthesiser and DCM parameters, and how they will fit together.

Regards, Zara

Reply to
Zara

It would be wise to check the jitter requirements for the DSP clock input if doing it that way. Many clock inputs on processors (etc) are designed with the assumption that the signal is coming straight from a crystal oscillator.

A DCM will generate some hundreds of ps p-p of jitter. That is more than enough to make some designs fail. Whether it matters for the OP's problem can't be determined from the information presented.

Regards, Allan

Reply to
Allan Herriman

My solutions is not a good one? Sending 25MHz to both DSP and FPGA, the former uses its pll to go up to 600MHz, the latter modifies with the DCM the frequency according to the program (in VHDL, not yet complete) need. Marco

Reply to
Marco

Hi Marco, I'm really not sure on what your exact application is, but obviously there is a need to transfer data between the FPGA and the DSP. In this situation the DSP will be the bus master in most common cases, and so should generate it's own clock signals for the bus. These would then be used in the FPGA to clock any input/output flipflops. If you want to internally transition these to a higher clock frequency, then that's fine and it wouldn't matter too much how you come by that clock, though it may affect how much difficulty the domain transfer is.

It might be easier to just use the bus clock output from the DSP, as this will be locked to the internal DSP clock in some manner. Then you could step this frequency up using a DCM and phase align it to the bus clock transitions. This would make clock domain transfers much easier in the FPGA as the internal FPGA clocks would be in sync as well as the bus clock.

The internal clock of the DSP is of no concern as you can't access data that is related to that clock, just the data presented on the data bus, which is with relation to the bus clock anyway.

Regards, Bevan Weiss

Marco wrote:

Reply to
Bevan Weiss

You had better look at your DSP data sheet and see what clock the external bus timing parameters are referenced to. In my design (similar to yours), there were no timing specs between the DSP bus signals and the DSP clock input; the specs referred to the DSP's bus clock output. So I had to send the oscillator to the DSP clock input, and the DSP clock output to the FPGA.

Reply to
Barry Brown

I have not a bus, just a serial connection between DSP and FPGA. I think it could be fine if they do both generate their internal clock from a common crystal source. Marco

Reply to
Marco

Marco, just concentrate on the communication between the two devices, ignore the 600 MHz, since you will never see that in the interface. You have to be able to grab the (serial?) data coming from the DSP, and synchronize it to the FPGA clock. Everything else seems to be irrelevant. So, determine the DSP output clock and make sure it is synchronous to the circutry in the FPGA that receives the data. Otherwise you are in to complicated data movements across asynchronous clock domains. Avoid that! Peter Alfke

Reply to
Peter Alfke

Peter, I was thinking about this scheme:

- DSP grabs 25MHz clock from crystal and generates its 600MHz;

- FPGA grabs that same 25MHz directly from the crystal too and generates the clock that better suits the code, maybe 50MHz;

- then the FPGA, or the DSP (this has not yet been decided), will put the serial clock in between the 2 at 25MHz or 50MHz;

- this way they should have a syncronized internal clock (I mean when the signal rises on the FPGA, it also rises on the DSP, the latter having much more rises during an FPGA's period due to the higher frequency it works with). Do you suggest me to:

1) send the serial clock out from the FPGA to the DSP or 2) send the serial clock out from the DSP to the FPGA and use this clock also to let the VHDL program running? The FPGA has to count from some encoders and the, when asked from the DSP, it has to send the quotes, so the FPGA keeps on working even out from the communication (that's why the serial clock would in either the 2 cases be continous). If I've not been that clear, please let me know what I missed. Thanks, Marco
Reply to
Marco

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.