How to generate a higher frequency than input frequency using DDS compiler from xilinx

[jean]

Hi , I am using DDS compiler to generate sin and cos  I know that  the DDS iP cannot generate an output frequency higher than the input frequency(clock system). I am very grateful if any person can give me any idea to generate a higher frequency than the input. I need to have an output more than 2.6 GHz. Thanks a lot for any idea. I am grateful a lot.  persons speak about polyphased DDS but I am not able to undestand how can I do this implementation to have a higher frequency than the input. Thanks a lot

[zygot]

48 minutes ago, jean said:

I need to have an output more than 2.6 GHz

This is beyond the capability of regular clocking resources of normal FPGA devices. Consult the datasheet for your device to see supported clock rates. Of course the transceivers are a separate but restricted part of some FPGA devices. You can always use external hardware implement GHz signals.

[D@n]

@jean,

This article might give you some things to think about.  But as @zygot hinted, you are getting at a very hardware dependent portion of the design space.  You are also getting towards the limits of what the FPGA can accomplish in the first place.  There will be a lot of tricks required to design a system like this properly.  If this is your first design, you should probably think about doing something simpler and working towards something this complex.

Dan

[jean]

Thanks you for you help. Yes, this is the first design that I do in FPGA. It seems me complex not only FPGA but also telecom, I think

[zygot]

2 minutes ago, jean said:

Thanks you for you help. Yes, this is the first design that I do in FPGA. It seems me complex not only FPGA but also telecom, I think

So, there are no limits when thinking about how to do something using things that you don't understand. All devices have their limits.

Both modern FPGA devices and 'telecom' are quite complex topics and require a lot of preparatory work before venturing on a journey to do anything useful in those areas. Fortunately, Xilinx has a lot of user guides for all of the resources of its FPGA devices. One of the most important is the datasheet where AC switching specifications and limits are listed. This information is different for every device and speed grade. It's also temperature dependent.  I advise starting off getting a feel for what the FPGA device resources are and how to use them before thinking about an end goal.

Don't confuse the rate at which you can toggle output pins with the rate at which you can clock logic resources. I suggest that you start with the ug472_7Series_Clocking guide and then reading the datasheet for the device that you want to work with. It's a good place to start and get your thinking grounded in reality.

[jean]

Thanks a lot. I am really sorry for the inconvenience . I thinks that I have confused between the rate at which I toggle pins with the rate I can clock logic resources. I thinks that i dont undestand an output of DDS with higher frequency than input. Maybee, I have confused. This is the first example I will. For example using a DDS with a clock frequency 100 MHz. I want to have a sin and cos with higher frequency. Please any help, I am new in FPGA; I dont find any perosn help me. The objective is to have IQ data from DDS compiler with frequency higher than input. Maybee, I should use many DDS but I dont undestand. It semms me very complex. Thanks

[jean]

just, I would like to explain to you that my goal to generate sines and cosines having a frequency for example 2GHz using DDS compiler. My goal is not generating a 2.6 GHz clock. The DDS cannot generate sin and cos with a frequency higher than the clock freqeuncy. I dont know but maybee, I have confusion between clock frequency and data rate of the sin and cos

[zygot]

Vendor IP like the DDS compiler is NOT the place to start. FPGA devices are very complex. The development tools are complex. If you start with poor understanding of the IP it's very easy to get the wrong idea of what you can do with it. You need to begin with understanding what the capabilities of you FPGA device are and then think about ways to implement a concept.

You questions aren't an inconvenience. They might be a product of over-promising how easy it is to use FPGA devices by the vendors.

[zygot]

3 minutes ago, jean said:

I have confusion between clock frequency and data rate of the sin and cos

The answers are in the material that I've already mentioned. Do your homework and you will have less confusion and better questions.

[D@n]

@jean,

If this is the kit, then it advertises eight 6.554Gsps 14-bit DACs.

Assuming you can get the outputs up and running at that speed (there should be a demo of this to get you going), you'll probably want more than just a table lookup for the sin/cos generation.  A table lookup is good for about 8-bits or so.  I like using linear interpolation to get more than 8-bits.  You'll want to calculate multiple sinewaves at once, each at a lower rate, and then output all of these in series when sending to the DAC.  To do this, you could either use the DDS compiler or build it yourself.  One of the links I've already posted above will discuss how to handle generating multiple (related) phases at once--something you'll need to make this work.

Dan

[jean]

12 minutes ago, D@n said:

@jean,

This is the perfect place to start a journey.  Just be prepared to make a lot of mistakes along the way.  I've certainly enjoyed my own journey so far.

One of my FPGA mentors once told me: Pick a frequency, and build everything for that frequency.  I have chosen 100MHz on a Basys3 (series-7 Xilinx FPGA), and so everything I tend to build runs at that frequency.  This translates to (roughly) 80MHz on a Spartan 6, 50 MHz on an iCE40 HP*, 25MHz on an iCE40 LP*, and perhaps 140MHz+ on a Kintex.  With a little work, I can build a design for a Xilinx FPGA at 200MHz, but it'd be a *lot* of work to retool everything I've ever done for this speed--not that I haven't thought about it.  So, let's allow a 200MHz clock as a reasonable logic speed.

Using a 200MHz clock you can generate a sine wave internally at 100MHz.  If you want to go faster, you'll need to run multiple sine wave generators in parallel.  You will pay for this in terms of area on your FPGA, but it's often quite doable.  Theoretically, if you could bring a 2.6 GHz signal into an FPGA (you'd need to sample at 5.2GHz or more), you could process 32 samples at a time and so handle the issue.  You'll still have to deal with a nightmare I/O problem, but it's not beyond the realm of the possible.  It might just be a lot cheaper to build some analog up-front processing first ...

You should also know that Xilinx's DDS is not the only solution out there.  At this speed, you might want a basic table lookup instead for your sin/cos generation.  Phase processing is still pretty easy, so don't get attached to Xilinx's DDS for that--it's pretty easy to do on your own.

Dan

I will do my best so that I succeed in my first project. Thanks a lot for your support. Please sir can you explain me more details how can I do this, implementing these parallel DDS, I have problems to understand while I would like to succeed. I am very grateful

[jean]

Please another question sir, the IP DDC DUC from xilinx cannot help me to have this task. In datasheet, thanks

[D@n]

@jean,

Help me out here, what is "the IP DDC DUC from xilinx"?  and ... Why is it that it cannot help you?

Dan

[zygot]

53 minutes ago, jean said:

One of my FPGA mentors once told me: Pick a frequency, and build everything for that frequency.  I have chosen 100MHz on a Basys3 (series-7 Xilinx FPGA), and so everything I tend to build runs at that frequency.  This translates to (roughly) 80MHz on a Spartan 6, 50 MHz on an iCE40 HP*, 25MHz on an iCE40 LP*, and perhaps 140MHz+ on a Kintex.  With a little work, I can build a design for a Xilinx FPGA at 200MHz, but it'd be a *lot* of work to retool everything I've ever done for this speed--not that I haven't thought about it.  So, let's allow a 200MHz clock as a reasonable logic speed.

Using a 200MHz clock you can generate a sine wave internally at 100MHz.  If you want to go faster, you'll need to run multiple sine wave generators in parallel.  You will pay for this in terms of area on your FPGA, but it's often quite doable.  Theoretically, if you could bring a 2.6 GHz signal into an FPGA (you'd need to sample at 5.2GHz or more), you could process 32 samples at a time and so handle the issue.  You'll still have to deal with a nightmare I/O problem, but it's not beyond the realm of the possible.  It might just be a lot cheaper to build some analog up-front processing first ...

@D@n

Ignore the attribution of the above statements from the Digilent hosting software. Really man, I think that you are not helping the person that you are posting to. When you haven't actually done something it's easy to spout nonsensical solutions. And I know that you haven't generated multiple parallel sin/cosine waveforms and wrapped them up into a 2.6 GHz word/s package on any device. BTW if you think that you are going to serialize even 12-bit sine/cosign data at 2.6 GHz Fs you are in for disappointment. But go ahead, post your code for this so that we can all be amazed and in awe of your skills. Talking about doing something and doing something are two different enterprise. Sound concepts don't always extrapolate to mystical proportions.

I think that your mentor set you on an unfortunate path if what you describe is how you think about logic design.

Anyway, I'm happy to leave you to each other.

[D@n]

@zygot,

I haven't mentioned you or your comments yet in this thread because I felt they were right on and didn't need any more mention.  I have had no disagreements with what you've had to say so far.  I still don't.  I've spoken from a generic standpoint--if you want to go faster, you need to parallelize things.  There's nothing rocket science about this, but there are costs to doing so.  The links I've posted discuss how to handle the task in general, from which you would need to build parallel logic to handle things.

3 minutes ago, zygot said:

And I know that you haven't generated multiple parallel sin/cosine waveforms and wrapped them up into a 2.6 GHz word/s package on any device. BTW if you think that you are going to serialize even 12-bit sine/cosign data at 2.6 GHz Fs you are in for disappointment.

Here, again, you have said things well.  This was why I was trying to get @jean to describe how he was going to handle his I/O's.  Running anything at 2.6GHz would be a serious challenge.  I'm just not prepared to say it's impossible--that's just a harder statement to make conclusively and I've been surprised too many times over the years.  He's going to need to find an A/D that can run at this rate (somehow), and even then he's going to have a challenge to drive it.  It'd be much easier to just drive a simple I/O pin (something I referenced above).  Would that work for him?  I have no idea--he never provided a specification for how good  his sine or cosine needed to be.

7 minutes ago, zygot said:

I think that your mentor set you on an unfortunate path if what you describe is how you think about logic design.

Anyway, I'm happy to leave you to each other.

If you would like to criticize the statement from the mentor above, then please tell me what part he got wrong so I may learn?  The comment I tried to quote above was about general logic design, not the I/O design that'd be required to handle a 2.6 GHz signal.  I know I've managed to handle logic design at 200MHz, and have no problems believing that you could parallelize operations at 200MHz in order to handle generating a 2.6GHz signal--at least, that'll work until you get to the I/O design.  From the standpoint of parallelizing logic, this is nothing more than a straightforward observation.  The other half of the problem--that of handling the various I/O's and communicating with something useful--that's a valuable and even necessary piece of the puzzle that you've been bringing to the discussion.  I have appreciated it, but it doesn't reflect on the mentor's observations above since those were general logic development observations.

Dan

[D@n]

@zygot,

One other thought ... back in my service days, I remember a contractor presenting us with a proposal to build a receiver that would sample data at 8GHz and then bring that data into an FPGA.  My point is: I think it's doable, but as I said above, I wouldn't recommend this problem to a beginner.

Of course, we also had a separate problem with the whole concept: suppose you swallow 8Gsps of data into an FPGA ... what do you do next with it?  Kind of like the picture below, no?

Just because you can get an 8Gsps signal into an FPGA doesn't mean you're ready to do anything serious with it.

Dan

[zygot]

49 minutes ago, D@n said:

If you would like to criticize the statement from the mentor above, then please tell me what part he got wrong so I may learn? 

I'm not criticizing your mentor. My suspicion is that you misunderstood his intended point. I don't know the context. I do not believe that your interpretation, as stated by "pick a clock rate' , is a good general way to approach logic design. 

I am not trying to nit-pick particular suggestions that you've made; in another context they might make for an interesting discussion. Not only is Jean confused but he is aware of that. The solution to confusion is replacing ignorance with knowledge. I don't think that you are helping him in this regard.

I will nit-pick this line however; "Theoretically, if you could bring a 2.6 GHz signal into an FPGA (you'd need to sample at 5.2GHz or more), you could process 32 samples at a time and so handle the issue. " It is not a good idea to ignore device specifications to try and achieve a result that the tools can't support. Yes, I know that you can manually place logic into specific LUTs and create a ring counter that has signals that toggle well above the device specifications for guaranteed operation. This is a totally different topic worthy of its own discussion and will not help Jean at all. From all appearances this is someone who knows nothing about FPGA devices and tools and little more than the existence of certain IP that for some reason he believes will allow him to achieve an impossible result. 

I don't think that asking someone who presents solutions that appear to be well outside of normal practice to back it up with code is being critical. All you have to do is demonstrate that the general concept is viable. If you haven't actually been successful at implementing a concept in hardware that is robust and repeatable then perhaps you shouldn't mention it in this setting.

 

[zygot]

19 minutes ago, D@n said:

Kind of like the picture below, no?

Now, that is a picture of an impressive feat. I suspect that even the top guns on board presented a special salute to the captain of that plane and the deck crew. I guess that you don't have pictures of the thing taking off...

[D@n]

@zygot,

I ran a quick search for what frequencies a Xilinx FPGA might support.  The MPSOC manual I have suggests support for 100GHz outputs.  While this seems far fetched for me, I haven't dug into the statement to see either how they are managing it or how to set up that speed under the hood.  If 100GHz is doable, surely 2.6GHz is as well.  Now, 2.6GHz into an 8-12bit A/D?  That'd be more challenging--but I noted that above.  Perhaps that's not required--that'd be determined by his specification--which he hasn't (yet) shared.  Not having a specific FPGA to have a discussion with or about, it's hard to discuss hard numbers here.

@jean's question was not about how to go about outputting a signal this fast, but rather how to replace Xilinx's DDS in order to generate such a signal.  To that question, I believe I've provided a reasonable answer.

Dan

[jean]

2 hours ago, D@n said:

@zygot,

I ran a quick search for what frequencies a Xilinx FPGA might support.  The MPSOC manual I have suggests support for 100GHz outputs.  While this seems far fetched for me, I haven't dug into the statement to see either how they are managing it or how to set up that speed under the hood.  If 100GHz is doable, surely 2.6GHz is as well.  Now, 2.6GHz into an 8-12bit A/D?  That'd be more challenging--but I noted that above.  Perhaps that's not required--that'd be determined by his specification--which he hasn't (yet) shared.  Not having a specific FPGA to have a discussion with or about, it's hard to discuss hard numbers here.

@jean's question was not about how to go about outputting a signal this fast, but rather how to replace Xilinx's DDS in order to generate such a signal.  To that question, I believe I've provided a reasonable answer.

Dan

Hi I am using ZCU111 board which support more than 2.6 GHz. My question how to generate a 2.6 GHZ signal using multiple DDS compilers then they will be connected to FFT unitil the DAC. The number of DDS should I use, the configurations of each DDS and etc. I am using vivado hlx. a priori I did not ask the question well. Another thing they is another IP in xilinx The Digital Up Converter (DUC) and Digital Down Converter (DDC). I dont know using this IP can increase the data rate until 2.6 GHZ OF THE SIN AND COS compoents. Sorry for the disturbance