Prev: Programmer for Spartan-6
Next: Programming individual FPGAs in a daisy chain
From: Casey Smith on 7 Jul 2010 17:10
I'm troubleshooting a design that uses a XC3S50 as a way to take a
125Mhz clock and, using 2
DCMs, output 4 copies of it shifted 45deg from one another. The 1st
DCM CLK0/90 ports give you the 0 and 90deg output clocks and the
second
DCM has a fixed phase offset so it's CLK0/90 ports give you the 45 and
135deg clks. However, the client didn't provide any external feedback
of
the clocks to the DCMs on the PCB and internal routing/gate delays are
screwing up
the phase relationship at the output pins of the FPGA. I'm having a
hell of a time
trying to constrain path delays to compensate. Has anyone done
anything
like this before? I have a post PAR simulation so I know what deltas
I'm looking for. My thought was that there must be some way to
request a particular routing delay via a constraint. So far I've not
had much luck. It's the only thing the device is doing so I have
routing resources to burn.... the difference in routing delay I need
to compensate for is ~1ns. If I
could match the internal DCM to PAD paths for the 0/90 outputs of each
DCM I could use the phase offset of one of the DCMs to set the phase
relationship between the two output clock groups and save a re-spin of
the board. Thoughts?

Thanks,
Casey
From: John McCaskill on 7 Jul 2010 18:07
On Jul 7, 4:10 pm, Casey Smith <cjs1...(a)gmail.com> wrote:
> I'm troubleshooting a design that uses a XC3S50 as a way to take a
> 125Mhz clock and, using 2
> DCMs, output 4 copies of it shifted 45deg from one another.  The 1st
> DCM CLK0/90 ports give you the 0 and 90deg output clocks and the
> second
> DCM has a fixed phase offset so it's CLK0/90 ports give you the 45 and
> 135deg clks.  However, the client didn't provide any external feedback
> of
> the clocks to the DCMs on the PCB and internal routing/gate delays are
> screwing up
> the phase relationship at the output pins of the FPGA. I'm having a
> hell of a time
> trying to constrain path delays to compensate.  Has anyone done
> anything
> like this before?  I have a post PAR simulation so I know what deltas
> I'm looking for.  My thought was that there must be some way to
> request a particular routing delay via a constraint. So far I've not
> had much luck. It's the only thing the device is doing so I have
> routing resources to burn.... the difference in routing delay I need
> to compensate for is ~1ns.  If I
> could match the internal DCM to PAD paths for the 0/90 outputs of each
> DCM I could use the phase offset of one of the DCMs to set the phase
> relationship between the two output clock groups and save a re-spin of
> the board. Thoughts?
>
> Thanks,
> Casey

Hello Casey,

It sounds like you are trying to take the clock signals and drive them
directly out IO pins. That requires that the clocks leave the
dedicated clock routing an use the general purpose routing. That will
introduce skew to their phase relationship that is difficult to
control.

There is a better way to do this. Use the DDR registers in the IOBs to
mirror the clock that is driving them by tying one of the inputs high,
and the other low. By doing this, the clocks will stay on the
dedicated clock routing, and you can more precisely control their
phase relationship with the DCMs.

While that is the approach that I would take, it is interesting to
note that you can also hand route a net in the FPGA editor, and then
have it saved as a directed routing constraint that you can put into
the UCF file so that it will be repeatable. I have done that once, but
only as a last resort.

Regards,

John McCaskill
www.FasterTechnology.com
From: Casey Smith on 10 Jul 2010 02:11
On Jul 7, 5:07 pm, John McCaskill <jhmccask...(a)gmail.com> wrote:
> On Jul 7, 4:10 pm, Casey Smith <cjs1...(a)gmail.com> wrote:
>
>
>
>
>
> > I'm troubleshooting a design that uses a XC3S50 as a way to take a
> > 125Mhz clock and, using 2
> > DCMs, output 4 copies of it shifted 45deg from one another.  The 1st
> > DCM CLK0/90 ports give you the 0 and 90deg output clocks and the
> > second
> > DCM has a fixed phase offset so it's CLK0/90 ports give you the 45 and
> > 135deg clks.  However, the client didn't provide any external feedback
> > of
> > the clocks to the DCMs on the PCB and internal routing/gate delays are
> > screwing up
> > the phase relationship at the output pins of the FPGA. I'm having a
> > hell of a time
> > trying to constrain path delays to compensate.  Has anyone done
> > anything
> > like this before?  I have a post PAR simulation so I know what deltas
> > I'm looking for.  My thought was that there must be some way to
> > request a particular routing delay via a constraint. So far I've not
> > had much luck. It's the only thing the device is doing so I have
> > routing resources to burn.... the difference in routing delay I need
> > to compensate for is ~1ns.  If I
> > could match the internal DCM to PAD paths for the 0/90 outputs of each
> > DCM I could use the phase offset of one of the DCMs to set the phase
> > relationship between the two output clock groups and save a re-spin of
> > the board. Thoughts?
>
> > Thanks,
> > Casey
>
> Hello Casey,
>
> It sounds like you are trying to take the clock signals and drive them
> directly out IO pins. That requires that the clocks leave the
> dedicated clock routing an use the general purpose routing. That will
> introduce skew to their phase relationship that is difficult to
> control.
>
> There is a better way to do this. Use the DDR registers in the IOBs to
> mirror the clock that is driving them by tying one of the inputs high,
> and the other low.  By doing this, the clocks will stay on the
> dedicated clock routing, and you can more precisely control their
> phase relationship with the DCMs.
>
> While that is the approach that I would take, it is interesting to
> note that you can also hand route a net in the FPGA editor, and then
> have it saved as a directed routing constraint that you can put into
> the UCF file so that it will be repeatable. I have done that once, but
> only as a last resort.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Thanks John,

I've used the DDR forwarding trick before with success but it's not
cutting it in this case. I have been exploring the FPGA editor but was
hoping there might be an easier way. I'll give the hand route option
another look. This problem might be the perfect opportunity to learn.

Casey
 | 
Pages: 1
Prev: Programmer for Spartan-6
Next: Programming individual FPGAs in a daisy chain