UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
1,597 Views
Registered: ‎01-08-2014

Interfacing DAC with Spartan6 ...

Hi,

 

I have to implement this configuration between Spartan6 and DAC. I do not have much experience in this regard so I ask for help from those more experienced than me. The DAC data is drive from ODDR2 with Clock 0° ana 180°, DAC receive I data on rising edge and Q data on falling edge.

 

Spartan6 with DAC

 

How create constraints for this setup ?

 

INST "dac_data_pin<*>" TNM = "TN_dac_data_pin";
TIMEGRP "TN_data_pin" OFFSET = OUT x.xxx ns AFTER "clk" REFERENCE_PIN "dac_data_pin<0>" RISING;
TIMEGRP "TN_data_pin" OFFSET = OUT x.xxx ns AFTER "clk" REFERENCE_PIN "dac_data_pin<0>" FALLING;

How to calculate OFFSET OUT?

 

Once set OFFSET OUT if you can not reach the constraint I have to add a PHASE shift to the internal CLOCK of FPGA to reach the constraint. I am wrong ?

 

Thanks very much.

 

moreasm

 

0 Kudos
7 Replies
Moderator
Moderator
1,568 Views
Registered: ‎03-16-2017

Re: Interfacing DAC with Spartan6 ...

Hi @moreasm

 

So the interface here is system synchronous DDR. 

 

There are two options to create offset out constraints for this interface. You can have a look into this document WP237 (v 1.0) (page 23 - DDR Example & page 24)

https://www.xilinx.com/support/documentation/white_papers/wp237.pdf

 

To find out the original requirement in your case you need to take the time inbetween CLK FPGA -> DATA OUT PIN FPGA.

which will be fed to the rising edge constraints. 

 

And for falling edge constraint: it will be the "original requirement" plus half the period constraint. 

( As an example if you have the original requirement as 3ns with a period of 10, the falling edge offset out constraint requirement is 8 ns.) This will compensate for the clock arrival time associated with the falling edge synchronous elements.

 

In this way you will able to make offset out constraints with period constraint.

 

Regards,

hemangd

 

 

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Historian
Historian
1,551 Views
Registered: ‎01-23-2009

Re: Interfacing DAC with Spartan6 ...

Moreasm,

 

How to calculate OFFSET OUT?

 

This is one of those places where ISE just doesn't do the full job.

 

An OFFSET OUT can only specify the maximum offset output time, not the minimum - the ISE tools just don't have a mechanism for constraining or reporting on the minimum clock to output time. So you will have to worry about the hold time manually. Lets do that first...

 

The hold time requirement of your device is -.2ns. The clock of the FPGA is 0.468ns-0.142ns=0.326ns later than the clock at the external device. Therefore, if the FPGA is guaranteed not to change its data more than 0.526ns before the clock edge, then the hold time is satisfied.

 

Unfortunately, with the PLL in the clock path, it is theoretically possible for the clock out of the PLL to be earlier than the input clock to the FPGA; it is not easy to figure out by how much... So there is no easy answer to this one - its probably fine, but its not possible to be sure.

 

Now for the maximum.

 

First, lets assume your clock duty cycle is a perfect 50/50. This means you have 5ns for the complete path. If your clock is not 50/50 (say 55/45), then you need to reduce this to 4.5ns. I will assume 5ns, and you can subtract out the extra for the duty cycle later.

 

Next, of this 5

  - the input device needs its setup of 1.6ns

  - the clock of the FPGA is 0.326ns later than the clock of the external device.

 

This means that the FPGA can take 5ns - 1.6ns - 0.326ns = 3.07ns

 

Therefore the OFFSET out should be

 

TIMEGRP "TN_data_pin" OFFSET = OUT 3.07 ns AFTER "clk" RISING;
TIMEGRP "TN_data_pin" OFFSET = OUT 3.07 ns AFTER "clk" FALLING;

 

The REFERENCE_CLOCK is only useful in a clock forwarded (source synchronous) interface, as opposed to this system synchronous interface.

 

This is not a lot fo time. You don't tell us what the I/O standard is, but unless it is a fast output pad, this will be very hard, or even impossible to meet. In theory, you can advance the PLL clock to get it to meet the timing, but in doing so you run the risk of violating the hold time requirement of the external device. Since ISE can't do hold time analysis (as I described above), you can't really know when the negative shift you are adding to the clock is "too much".

 

In general, a 100MHz DDR system synchronous interface is not the best idea. Above about 150Mbps (and this is 200Mbps), it is recommended to do source synchronous interfaces... (where the clock to the external device is generated by the FPGA using an ODDR and an output pad identical to the one driving the data).

 

Avrum

0 Kudos
Contributor
Contributor
1,530 Views
Registered: ‎01-08-2014

Re: Interfacing DAC with Spartan6 ...

Sorry for the delay, I read but I could not answer before.

 

I did not understand correctly but the setup / hold values were reversed ?

 

Summing up :

 

Device Setup : -0.2 nS

Device Hold : 1.6 nS

 

Clock at FPGA : 0.486 - 0.142 = 0.326 nS

 

The data at "DATA Out PIN" it must remain stable before 0.526ns the clock edge : 0.326 - ( -0.2 ) = 0.526 nS

 

Next, of this 5

 

  - the input device needs its setup of 0.2ns

  - the clock of the FPGA is 0.326ns later than the clock of the external device.

 

This means that the FPGA can take 5ns + 0.2ns - 0.326ns = 4.8474ns

 

Therefore the OFFSET out should be :

 

TIMEGRP "TN_data_pin" OFFSET = OUT 4.8474 ns AFTER "clk" RISING;
TIMEGRP "TN_data_pin" OFFSET = OUT 4.8474 ns AFTER "clk" FALLIN;

I use this setup for pin:

 

NET "data_pin<*>" IOSTANDARD = "LVCMOS33" | SLEW = FAST | DRIVE = 12 | IOB = FORCE;

I prefer use of "system synchronous interface" but I did not know it was not recommended in this type of configuration.

 

Is the clock generated by the FPGA to drive the clock input of a DAC is recommended?

 

Is not it too noisy?

 

Do you not ruin the cleaning of the analog signal generated in this way?

 

Thanks for the help but could you correct my calculations ?

 

moreasm

 

0 Kudos
Historian
Historian
1,522 Views
Registered: ‎01-23-2009

Re: Interfacing DAC with Spartan6 ...

I did not understand correctly but the setup / hold values were reversed ?

 

Yes, I misread the setup/hold times...

 

With these setup/hold times, the setup time becomes easier, but the hold time will be virtually impossible with an "obvious" implementation. And, again, with ISE it is almost impossible to figure out what hold time you can actually provide.

 

Most DACs have two clocks - a clock for the actual DAC function and a data clock. The two clocks need to be "mesochronous"; coming from the same clock source, but they can have different (and even somewhat varying) phase delays between them. I don't know what DAC you are using, but these setup hold times are very unfriendly to system synchronous interfaces (which generally look like what what I interpreted the first time, negative hold times and "reasonable" setup times), which leads me to believe that they are intended for use in a source synchronous setup.

 

If your DAC does have two clocks (a data clock and a "real" clock), then you should consider redesigning with a source synchronous data approach.

 

If not, then you will have to figure out an appropriate clocking scheme to try and make this work. You have a reasonable amount of margin (since the DAC only needs 1.4ns out of the 5ns half-period), but it's in a funny place, so you will need to do some clock shifting to meet the timing.

 

Avrum

0 Kudos
Historian
Historian
1,521 Views
Registered: ‎01-23-2009

Re: Interfacing DAC with Spartan6 ...

By the way, the OFFSET OUT looks correct, but I am not sure if you are looking at the hold time correctly...

 

The data must remain stable 1.6ns after the clock at the DAC. The clock at the FPGA is 0.326ns after the clock at the DAC, therefore from the FPGA point of view, the FPGA must not change its output data until at least 1.27ns after the clock edge. To do this, you will have to add some serious positive shift to the clock coming out of the PLL, more than 1.3+ns, but again, in ISE it is impossible to know exactly how much more...

 

Avrum

0 Kudos
Contributor
Contributor
1,474 Views
Registered: ‎01-08-2014

Re: Interfacing DAC with Spartan6 ...

Thanks very much Avrum, your support is very helpful to me.

I do not have much experience in interfacing between FPGA and DAC, I only saw some configuration looking around, but from what you describe the thing is much more complex than I thought.

Unfortunately, the hardware board (PCB) has already been created, mounted and turned on. So I have to find a solution to make it work. In the next review I will take your advice into consideration. One thing we have taken into account is the length of the data bus tracks to the DAC, all data bits have the same length.

The DAC I use is an Analog Device and exactly: AD9117

With my stupor, you explained to me why this DAC has two clocks, I honestly did not give it much weight and were connected together, but now I understand what they are for. Unfortunately, a little late.

The DAC is equipped with:

 

- DCLKIO : Data Input/Output Clock. Clock used to qualify input data.

- CLKIN: LVCMOS Sampling Clock Input.


By the way, the OFFSET OUT looks correct, but I am not sure if you are looking at the hold time correctly...

 

The data must remain stable 1.6ns after the clock at the DAC. The clock at the FPGA is 0.326ns after the clock at the DAC, therefore from the FPGA point of view, the FPGA must not change its output data until at least 1.27ns after the clock edge. To do this, you will have to add some serious positive shift to the clock coming out of the PLL, more than 1.3+ns, but again, in ISE it is impossible to know exactly how much more...


At least I made the right calculations.

 

I had come to the same consideration, but I had not taken into account "hold" time.

 

The only way is therefore to redesign the interface ?

 

Thanks very much.

 

moreasm

0 Kudos
Contributor
Contributor
1,507 Views
Registered: ‎01-08-2014

Re: Interfacing DAC with Spartan6 ...

Thank you so much Avrum for your help.

I'm not very experienced in interfacing FPGA to DAC, I just looked at some
development boards trying to figure out how to do it. From what you tell me,
however, it is not something so obvious.

I use an Analog Device DAC exactly: AD9117

To my amazement, from what you say, I realize now that this DAC has exactly two
clocks:

- DCLKIO: Data Input/Output Clock. Clock used to qualify input data
- CLKIN:  LVCMOS Sampling Clock Input.

Unfortunately, the PCB has already been designed, built and assembled, so in
some way I have to try and make it work. I will take your advice into
consideration in the next circuit review.

These two clocks now (DCLKIO and CLKIN) are connected together (DCLKIO = CLKIN)
so the pattern you saw in the first post is the one you have made. One thing
that I have taken into consideration is that of having relocated the data bus
from FPGA and DAC of the same length.

As you advised me it is necessary to find an appropriate clock scheme.

To start, as you indicated to me, the times I have calculated are right:

TIMEGRP "TN_data_pin" OFFSET = OUT 4.8474 ns AFTER "clk" RISING;
TIMEGRP "TN_data_pin" OFFSET = OUT 4.8474 ns AFTER "clk" FALLIN;


I just need to add a phase shift to the PLL clock of about:

PLL shift : 1.6 - 0.326 = 1.274 ns

Exactly 1.274 ns + a certain unknown margin.

Is there any way to find this unknown margin ?

PLL shift in degree is = (1.274 nS / 10 nS) * 360 = 45.864°

The output PIN is "ODDR2" interface on IOB , the only variable delay is on
internal routing of clock that drive "ODDR2".

If I could stabilize this internal routing delay I could calculate precise times.

Any other ideas or help ?

Thanks very much.

moreasm

0 Kudos