cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
311 Views
Registered: ‎01-09-2018

Rise Time requirement on input of Spartan3 (XC3S400-4PQ208I)

Jump to solution

I'm troubleshooting a weird issue with an existing FPGA design.  It seems to be failing on the clocking network.  I creating a little test circuit inside the FPGA.   The clock comes in thru ibuf, then bufg, then to FF configured as a divide by 2 (D=!Q).  This divided clock is passed to a IOB FF using the same input clock as the divide by 2 FF as it's clock source.  From there to a pad.  The divided by 2 clock seems to be errantly clocking on the falling edge of clk with a slight application of temperature. (FF's are wired to positive clock edge).  Initially I thought this would be an easy clock reflection issue.   However, I'm unable to observe any clock reflections at the input of the FPGA using an oscilloscope.  And the physics don't seem to warrant any clock termination (ie..traces are a few inches long...).  I notice the rise time of the clock signal coming into the FPGA is 10nS.  Is there any issue with this rise time?  I couldn't find any information in the datasheets.

Thanks,

Michael 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Contributor
Contributor
175 Views
Registered: ‎01-09-2018

Did you write a timing constraint for ISE that defines the clock entering the FPGA. I forgot the ISE form of this constraint, but in Vivado it is called a create_clock constraint.  Yes.   The design is fully constrained and the clock has a period constraint.  I finally figured out what was going on.  It was a signal integrity issue with the Clk originating from off chip device that makes up a part of a source synchronous interface.  The length of track was not of concern here.  However, the chip that generates this clock just passes through and delays a clock  that the FPGA provides to align it with the data.  The clock originating from the FPGA seems to be the problem.   These tracks are in the order 8 to 9" definitely in the realm of needing a termination.  I have installed the terminations, and things are now stable again as I was unable to get the registration to fail inside my clock divider with the application of temperature.

To answer your question regarding 6).  I have the compile ready to go, but never programed it in because I felt it was kind of moot after my discovery of the clock reflection thing.

I will put this board into an environment chamber as part of today's tasking and test it out over the operating temperature range of the design to make sure things remain stable.

 

View solution in original post

5 Replies
Highlighted
246 Views
Registered: ‎01-22-2015

@mlm155 

I notice the rise time of the clock signal coming into the FPGA is 10nS.  Is there any issue with this rise time?

You did not tell us the IOSTANDARD being used at the clock input pin.  However, for LVCMOS, problems usually develop (eg. increased power consumption, increased jitter for clocks) for switching speeds slower than 10ns/V.  Switching speed for LVCMOS depends on load capacitance, but is typically near 1ns/V.

1) What IOSTANDARD are you using at clock input to FPGA?

2)  Have you checked that clock input signal meets VOH and VOL specifications for IOSTANDARD and that signal does not exceed absolute maximum specifications (see UG331)?

 

The clock comes in thru ibuf, then bufg, then to FF configured as a divide by 2 (D=!Q).  This divided clock is passed to a IOB FF using the same input clock as the divide by 2 FF as it's clock source.  From there to a pad. 

3) A clock should enter the FPGA on a global clock (GCLK) pin and be routed from there through IBUFG.  Are you using GCLK pin?

4) What is the frequency of your clock?  Does it have 50% duty cycle?

 

The divided by 2 clock seems to be errantly clocking on the falling edge of clk with a slight application of temperature. 

This seems to indicate a timing problem. 

5) Does ISE say that your design passes timing analysis?

6) If you do not use the IOB FF (ie. route directly from "FF configured as a divide by 2" to OBUF and pad), does output show the same problems?

Cheers,
Mark

Tags (1)
0 Kudos
Highlighted
Contributor
Contributor
230 Views
Registered: ‎01-09-2018

1) What IOSTANDARD are you using at clock input to FPGA?  LVCMOS33

2)  Have you checked that clock input signal meets VOH and VOL specifications for IOSTANDARD and that signal does not exceed absolute maximum specifications (see UG331)?  Did you mean VIH and VIL?  Yes they do meet VIL, and VIH.

3) A clock should enter the FPGA on a global clock (GCLK) pin and be routed from there through IBUFG.  Are you using GCLK pin?  I misstated my original post it is indeed coming in a global clock pin through a IBUFG.

4) What is the frequency of your clock?  Does it have 50% duty cycle?  10Mhz.  It does not have a 50% duty cycle.

5) Does ISE say that your design passes timing analysis?  Yes

6) If you do not use the IOB FF (ie. route directly from "FF configured as a divide by 2" to OBUF and pad), does output show the same problems?  I don't know the answer to that.  I'll give that a try in the next compile and get back to you.

0 Kudos
Highlighted
Teacher
Teacher
226 Views
Registered: ‎07-09-2009

Strange behaviour indeed .

To answer your question directly , there is no inherent rising / falling edge requirement in a clock input , 

 

But 

 

As I think your aware , 10 ns is a very very slow rise time by modern standard. 

The pll / dll does have a minimum frequency requirement , I think that's around 25 Mhz for the old Spartan 3 but pls check in data sheet. 

How did u manage to make such a slow clock in ? 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
189 Views
Registered: ‎01-22-2015

@mlm155 

Thanks for answers to my questions.

I still think this sounds like a timing problem.

In addition to what you are doing for 6) please check:

7) Did you write a timing constraint for ISE that defines the clock entering the FPGA.   I forgot the ISE form of this constraint, but in Vivado it is called a create_clock constraint.

 

0 Kudos
Highlighted
Contributor
Contributor
176 Views
Registered: ‎01-09-2018

Did you write a timing constraint for ISE that defines the clock entering the FPGA. I forgot the ISE form of this constraint, but in Vivado it is called a create_clock constraint.  Yes.   The design is fully constrained and the clock has a period constraint.  I finally figured out what was going on.  It was a signal integrity issue with the Clk originating from off chip device that makes up a part of a source synchronous interface.  The length of track was not of concern here.  However, the chip that generates this clock just passes through and delays a clock  that the FPGA provides to align it with the data.  The clock originating from the FPGA seems to be the problem.   These tracks are in the order 8 to 9" definitely in the realm of needing a termination.  I have installed the terminations, and things are now stable again as I was unable to get the registration to fail inside my clock divider with the application of temperature.

To answer your question regarding 6).  I have the compile ready to go, but never programed it in because I felt it was kind of moot after my discovery of the clock reflection thing.

I will put this board into an environment chamber as part of today's tasking and test it out over the operating temperature range of the design to make sure things remain stable.

 

View solution in original post