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: 
Participant rhc110again
Participant
2,753 Views
Registered: ‎08-18-2017

Global Clock pin voltage tolerance for Virtex-5

Jump to solution

I need to implement new functionality on legacy hardware that uses a Virtex-5.  The legacy design uses an external clock source (let's call it "Sample Clock" for simplicity) to drive buffered data out a user-selectable rate much slower (40MHz or less) than the internal logic clock (100MHz).  Unfortunately, the Sample Clock was not connected to a global clock input pin in the legacy hardware.  The legacy logic/PPC design runs just fine on this legacy hardware.  However, I need to add a lot of logic functionality that would also use the Sample Clock, so it seems to me like a really good idea to move the Sample Clock to a global clock input pin.

 

There are unconnected and available global clock input pins on my 1136-pin package, but:

- Sample Clock source is 1.8V CMOS (this cannot be changed)

- Bank 3 is set to 2.5V VCCO (this cannot be changed)

- Bank 4 is set to 3.3V VCCO (this cannot be changed)

 

The Sample Clock is currently connected to a 1.8V bank, of course, with 0.9V VREF and 50-ohm VRN and VRP resistors.  The declared IO standard is IOSTANDARD=SSTL18_II.

 

The best solution that I see is to connect my 1.8V CMOS Sample Clock to Bank 3 (2.5V VCCO).  Note that the other signals already on Bank 3 are all LVCMOS25.  I could declare IOSTANDARD=LVCMOS25 for my new Sample Clock global clock pin, but that sets the V-in-high-min at 1.7V.  On the other hand, I could declare IOSTANDARD=SSTL18_II.  Either way, VCCO for Bank 3 will remain at 2.5V.  I plan to NOT use DCI for any of the pins (none is used on Bank 3 in the current design either).  The questions become as follows:

- Can I connect 0.9V to VREF for Bank 3?  Keep in mind that VCCO is 2.5V.

- Should I connect VREF for Bank 3 to 1.25V instead?  This shifts my logic level thresholds a little higher than desired, but still better than using IOSTANDARD=LVCMOS25.  I don't think I need a 50% duty cycle on Sample Clock, so that shouldn't be a concern, provided the clock is still stable.

 

A few considerations:

- Yes, I know that none of what I am suggesting is anything close to a good design practice.  I just want to make sure I'm not going to damage any hardware (these are Virtex-$5k chips, after all).

- Yes, I've read DS202, UG190, UG195, and the relevant forum posts that I could find.

- I can't put a PLL or DCM/DLL on the Sample Clock, as it needs to change rates very quickly (and the rates are not known in advance).

 

Thanks for any answers

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
4,780 Views
Registered: ‎01-23-2009

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

What do you need to do with this "Sample clock"? Does it drive any input or output interfaces?

 

If the answer is no, then you should just leave it alone. Bringing a clock in on a non-clock capable pin means that it needs to go through fabric routing to reach the global clocking resources - the BUFG or DCM/PLL in Virtex-5. This "trip" through fabric routing introduces a fairly long insertion delay which is not process/voltage/temperature compensated, and may vary from implementation run to implementation run. This means that the clock (once it is on a global clock network), will have unknown and unknowable skew with respect to the input pin.

 

However, this only matters if you care about the skew of the internal clock with respect to the input pin, and this will only matter if this clock is used to receive any input interface, or to drive out any system synchronous output interfaces. If the clock is used purely internally, and/or the only interface driven by it is a clock forwarded output interface, then the skew of the internal clock is probably irrelevant.

 

The only other issue with this clock is that it can pick up some extra jitter travelling through the fabric. However, at 40MHz, this shouldn't be a problem - just declare it with a little extra jitter.

 

Only if this clock is used as a reference for an input interface or a system synchronous output interface do you need to fix this. In the Virtex-5, according to UG190 table 6-39 footnote 2, it is legal to put a lower voltage referenced input into a higher voltage bank, as long as you set VREF correct for the input standard (so in this case 0.9V). It not legal to do the opposite (put a higher voltage signal in a lower voltage bank - regardless of whether the input standard is referenced or not).

 

Just out of curiosity, why SSTL18_II rather than SSTL18_I?

 

Avrum

6 Replies
Historian
Historian
4,781 Views
Registered: ‎01-23-2009

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

What do you need to do with this "Sample clock"? Does it drive any input or output interfaces?

 

If the answer is no, then you should just leave it alone. Bringing a clock in on a non-clock capable pin means that it needs to go through fabric routing to reach the global clocking resources - the BUFG or DCM/PLL in Virtex-5. This "trip" through fabric routing introduces a fairly long insertion delay which is not process/voltage/temperature compensated, and may vary from implementation run to implementation run. This means that the clock (once it is on a global clock network), will have unknown and unknowable skew with respect to the input pin.

 

However, this only matters if you care about the skew of the internal clock with respect to the input pin, and this will only matter if this clock is used to receive any input interface, or to drive out any system synchronous output interfaces. If the clock is used purely internally, and/or the only interface driven by it is a clock forwarded output interface, then the skew of the internal clock is probably irrelevant.

 

The only other issue with this clock is that it can pick up some extra jitter travelling through the fabric. However, at 40MHz, this shouldn't be a problem - just declare it with a little extra jitter.

 

Only if this clock is used as a reference for an input interface or a system synchronous output interface do you need to fix this. In the Virtex-5, according to UG190 table 6-39 footnote 2, it is legal to put a lower voltage referenced input into a higher voltage bank, as long as you set VREF correct for the input standard (so in this case 0.9V). It not legal to do the opposite (put a higher voltage signal in a lower voltage bank - regardless of whether the input standard is referenced or not).

 

Just out of curiosity, why SSTL18_II rather than SSTL18_I?

 

Avrum

Scholar austin
Scholar
2,728 Views
Registered: ‎02-27-2008

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

?

- Can I connect 0.9V to VREF for Bank 3?  Keep in mind that VCCO is 2.5V.

 

Yes.

 

For a 2.5v ref based comparator input standard, this should work just fine.  ?0.9v = logic high (internally), ang < 0.9v = logic low.  That is what you desire, right?

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Participant rhc110again
Participant
2,612 Views
Registered: ‎08-18-2017

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

Thanks, Avrum!

 

Yes, the Sample Clock drives many (100+) timing-critical outputs.  They need to be tightly synchronous to each other.  I suppose I should have mentioned that the legacy design significantly predates my arrival on this team.  That will hopefully explain a bit, including the fact that I'm rather curious about the use of SSTL18_II rather than SSTL18_I, myself!

 

Anyhow, it seems pretty obvious to me that the Sample Clock needs to be on a Global Clock net (I don't know yet if that's the case in the legacy design or not - I haven't dug into what is instantiated and inferred between the input pin and the signal net that arrives to clock the output flops).  The fabric-trip delay you mentioned as possibly varying across implementation runs seems to me like it would be a problem for the requirements of the legacy design as I understand them.  

 

All that said, everything has been working well enough for the last 5 or 6 years that nobody has complained about the timing of the output signals I mentioned.  However, I've been tasked with adding some programmable delays between the output FIFOs (clocked at 100MHz) and the data pins (clocked by Sample Clock).  The new logic I'm adding will be clocked by Sample Clock.  So I know I need Sample Clock to be on a Global Clock net, and I'm worried about variation across implementation runs as well.

 

Thanks again for all the info and good food for more thought.  Apologies for posting on the "Welcome & Join" Forum - that wasn't intentional.  I've been cruising the forms for many years, but never needed to post myself before; always found the answers here.

0 Kudos
Participant rhc110again
Participant
2,609 Views
Registered: ‎08-18-2017

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

Thanks, Austin!

 

More details in my reply to Avrum, but I appreciate the concise answer to my long-winded question.  I'm evaluating risk and effort, so it's really nice to have this additional confirmation.

0 Kudos
Highlighted
Historian
Historian
2,604 Views
Registered: ‎01-23-2009

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

Yes, the Sample Clock drives many (100+) timing-critical outputs.  They need to be tightly synchronous to each other.

 

Do they need to be synchronous to each other or synchronous to the sample clock input?

 

Anyhow, it seems pretty obvious to me that the Sample Clock needs to be on a Global Clock net...

 

There is a difference between being on a global clock input and being on a global clock network - they are not the same thing. There are, in fact, a number of combinations...

 

Using a clock that is not on a global clock network (not driven by a BUFG or other clock buffer) is called a local clock. It is not recommended in most circumstances. This clock has a potentially large skew to its different endpoints and will vary from place and route to place and route.

 

A global clock network starts at a BUFG and distributes the clock to all potentially clocked endpoints on the device with a low and predictable clock skew. Using a clock on a global clock network is sufficient for internal clocked logic of any size as well as for maintaining synchronization among any number of output pins (with each other).

 

If the input to a BUFG is driven by a global clock pin, then the delay to from the pin to the BUFG is on a dedicated net and is therefore predictable from placement and route to place and route. So this gives you predictability of the global clock insertion. However, in this configuration, while the clock insertion is the same from run to run, it still varies (pretty significanty) over Process, Voltage and Temperature.

 

If the input to a BUFG is driven by a non-global clock pin, then this doesn't change the characteristics of the BUFG and the global clock network, but changes the timing of the signal arriving at the input of the BUFG. This is what I was referring to before - the input to the BUFG will have a longer insertion latency that will vary from run to run, and will have increased jitter. However, the endpoints will still get the clock with low skew (compared to each other).

 

Using a global clock pin driving a DCM or PLL with internal BUFG feedback and then a global clock network gives the "best" characteristics. A clock done this way has predictable, low and PVT compensated insertion delay. This is really the only viable way of doing system synchronous interfaces  or source synchronous input interfaces (these are all the cases where the timing of the inputs or outputs are defined with respect to the clock input pin). A clock forwarded (or source synchronous) output interface does not need to have its timing fixed with respect to the input clock, only the output clock, which is synchronous to the output data if the clock and data are both fed from the global clock (the clock should be forwarded using an ODDR).

 

There are also other clocking resources in the FPGA - the BUFIO and BUFR, but these require a clock to be on a CC pin, and are less flexible than the global clocking resources.

 

So, again, depending on what you need this clock for, you may not need to modify the board.

 

Avrum

0 Kudos
Participant rhc110again
Participant
2,598 Views
Registered: ‎08-18-2017

Re: Global Clock pin voltage tolerance for Virtex-5

Jump to solution

Thanks again, Avrum.  That's pretty much the "food for thought" I was talking about.  I believe I understand all the points you enumerated.  For background:

- My outputs do not need to be synchronous to the Sample Clock, just synchronous to each other.  However, it would be best if the phase relationship between the outputs and the Sample Clock were constant and known, thus my desire to use a clock pin.

- I always use a PLL (or DCM where appropriate) on my clocks, but this application requires quick adjustments to the Sample Clock.  So I can't accommodate the potentially lengthy and potentially variable lock-up time.

- PVT should be fairly constant in my application, but any related variations will have to be accepted (and they have been to this point, as I mentioned before).

- There's a minor board spin already in the works, so I'll be adding the VREF and a couple resistor jumpers to send Sample Clock either to the old pin or a clock pin.  I really appreciate your comments, though.  I'll be able to evaluate the old clock route in current hardware, but also hedge my bets whenever the board spin takes place.

0 Kudos