Symon, The line was 440 ps long. I will send the simulation to you directly, as posting it here bothers the folks that have to archive the newsgroup (no graphics or html, text only). Austin Symon wrote:> Hi Austin, > Agreed, the simulation is best way! My fag-packet calculation > was a worst case scenario, but still didn't exceed the specification. > Just wanted to confirm to myself there's no problem at the driver end, > and that this talk of using 3V VCCO instead of 3.3V was not needed to > be heeded! (At least for driver pin reasons.) > I imagine your simulation gets a lower value for the reflection > amplitude because the IBIS model includes rise time information and > chip capacitance, rather than variation of the transistors' impedance. > (But I'm willing to be shot down in flames!!) My calculation assumed > instant (worst case) rise time. How long was your lossless t-line? Was > the flight time longer than the rise time of the signal? (Time for > signal travel is about 180ps/in, typically.) > So, thanks for doing the simulation, I don't suppose you'd > publish the results just to put this one to bed for good? > cheers, Syms > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F6F5B7D.7059DDE5@xilinx.com>... > > Symon, > > > > As if often the case, if you do not run a simulation, you will not get results that are > > even close to the truth (by guessing at what is happening). > > > > With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back > > at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx). > > > > Why does this not scale exactly as you state? Because the ON resistance of the > > transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground. > > > > So, unless you simulate the actual circuit, you will not get the actual result. > > > > Austin > > > > Symon wrote: > > > > > Hi Peter, > > > If the pin has 10 Ohms of drive impedance the initial sent pulse > > > will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10 > > > Ohms driver drives a 50 Ohm line. The reflected signal from the > > > unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse > > > then increases the voltage at the pin to 3.667, as it's driven from 50 > > > Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the > > > absolute maximum rating of 3.75V. Hooray! > > > As you say, this calculation disregards the attenuation due to > > > the trace propagation function, which will further reduce the > > > amplitude of the pulse as it travels back and forth down the > > > transmission line(pcb trace). This is caused by skin effect and stuff. > > > I guess you could also reduce the drive strength of the pin from the > > > default 12mA, to increase the source impedance. > > > The receiver pin is the one that gets the big hit. > > > cheers, Symon. > > >
Xilinx S3 I/O robustness question
Started by ●September 8, 2003
Reply by ●September 23, 20032003-09-23
Reply by ●September 23, 20032003-09-23
Hal, Simulation includes a receiver at the end of a 2ns line, and you are correct, it makes things better. Why simulate a driver drving nothing? Unless of course that is a possibility in a system....not a very useful system, though.... Austin Hal Murray wrote:> > The receiver pin is the one that gets the big hit. > > So how bad is that hit? How good are the protection diodes? > > If the clamp diodes are any good they will reduce the reflection > and make things easier back at the transmitter. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.
Reply by ●September 23, 20032003-09-23
Austin, Did both a 440 ps and a 2ns line. Not to confuse. Austin Austin Lesea wrote:> Hal, > > Simulation includes a receiver at the end of a 2ns line, and you are correct, it > makes things better. > > Why simulate a driver drving nothing? Unless of course that is a possibility in > a system....not a very useful system, though.... > > Austin > > Hal Murray wrote: > > > > The receiver pin is the one that gets the big hit. > > > > So how bad is that hit? How good are the protection diodes? > > > > If the clamp diodes are any good they will reduce the reflection > > and make things easier back at the transmitter. > > > > -- > > The suespammers.org mail server is located in California. So are all my > > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > > commercial e-mail to my suespammers.org address or any of my other addresses. > > These are my opinions, not necessarily my employer's. I hate spam.
Reply by ●September 23, 20032003-09-23
But if you are simulating to check the possibility of damage, it seems reasonable to allow for an unconnected trace due to a component being left off a board intentionally or not or the possiblity of an open trace on the board. I don't think many people would expect an open trace to be the cause of a chip failure in a properly designed board. If you don't analyze for this, a chip may have a higher than expected failure rate due to typical repairable board defects. Austin Lesea wrote:> > Hal, > > Simulation includes a receiver at the end of a 2ns line, and you are correct, it > makes things better. > > Why simulate a driver drving nothing? Unless of course that is a possibility in > a system....not a very useful system, though.... > > Austin > > Hal Murray wrote: > > > > The receiver pin is the one that gets the big hit. > > > > So how bad is that hit? How good are the protection diodes? > > > > If the clamp diodes are any good they will reduce the reflection > > and make things easier back at the transmitter. > > > > -- > > The suespammers.org mail server is located in California. So are all my > > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > > commercial e-mail to my suespammers.org address or any of my other addresses. > > These are my opinions, not necessarily my employer's. I hate spam.-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●September 23, 20032003-09-23
Hal Murray wrote:> > > The receiver pin is the one that gets the big hit. > > So how bad is that hit? How good are the protection diodes? > > If the clamp diodes are any good they will reduce the reflection > and make things easier back at the transmitter.This is a good question. So far I have only read people considering the S3 chip driving. What about the case where is is on the receiving end of the signal? My designs typically don't consider signal integrity on traces other than edge sensitive clock lines and chip enables. For non-edge sensitive signals, I have always treated it a bit like metastability, allow some time for the signal to settle out and all will be good by the time of the clock edge. But if we have to consider *every* trace on the board for reflections and overshoot, board design can become a nightmare! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●September 23, 20032003-09-23
Rick, Good point, and without the termination (load or receiver) the difference is: 100 mV higher (lower) peak voltage (+/- 237 mV from Vcco and ground). Still well within the datasheet limits. Again, simulate what you are doing! http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?BV_SessionID=@@@@2073323889.1064333725@@@@&BV_EngineID=ccceadcjhgejgjicflgcefldfgldgjh.0&sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=al_fathers Austin rickman wrote:> But if you are simulating to check the possibility of damage, it seems > reasonable to allow for an unconnected trace due to a component being > left off a board intentionally or not or the possiblity of an open trace > on the board. I don't think many people would expect an open trace to > be the cause of a chip failure in a properly designed board. If you > don't analyze for this, a chip may have a higher than expected failure > rate due to typical repairable board defects. > > Austin Lesea wrote: > > > > Hal, > > > > Simulation includes a receiver at the end of a 2ns line, and you are correct, it > > makes things better. > > > > Why simulate a driver drving nothing? Unless of course that is a possibility in > > a system....not a very useful system, though.... > > > > Austin > > > > Hal Murray wrote: > > > > > > The receiver pin is the one that gets the big hit. > > > > > > So how bad is that hit? How good are the protection diodes? > > > > > > If the clamp diodes are any good they will reduce the reflection > > > and make things easier back at the transmitter. > > > > > > -- > > > The suespammers.org mail server is located in California. So are all my > > > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > > > commercial e-mail to my suespammers.org address or any of my other addresses. > > > These are my opinions, not necessarily my employer's. I hate spam. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●September 23, 20032003-09-23
--------------53B8F2F545754BA2978FBFA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick, You are going to have to consider the receiving end SI. In addition to violating the specifications (possible) you can also create EMI/RFI, and cause substatial substrate and Vcco bounce by slamming the clamp diodes at the inputs. The bounce leads to changing the substrate (ground) and Vcco on die, which causes jitter, and timing failures. All of this is trivially prevented by choosing the right series termination at the driver (or using DCI drivers). With the Vccint at 1.5V and dropping fast, ground bounce is now becoming public enemy number 1. Like I said, you can't get around LA without a car. Get the simulator. Use it. Austin rickman wrote:> Hal Murray wrote: > > > > > The receiver pin is the one that gets the big hit. > > > > So how bad is that hit? How good are the protection diodes? > > > > If the clamp diodes are any good they will reduce the reflection > > and make things easier back at the transmitter. > > This is a good question. So far I have only read people considering the > S3 chip driving. What about the case where is is on the receiving end > of the signal? > > My designs typically don't consider signal integrity on traces other > than edge sensitive clock lines and chip enables. For non-edge > sensitive signals, I have always treated it a bit like metastability, > allow some time for the signal to settle out and all will be good by the > time of the clock edge. But if we have to consider *every* trace on the > board for reflections and overshoot, board design can become a > nightmare! > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX--------------53B8F2F545754BA2978FBFA8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Rick, <p>You are going to have to consider the receiving end SI. <p>In addition to violating the specifications (possible) you can also create EMI/RFI, and cause substatial substrate and Vcco bounce by slamming the clamp diodes at the inputs. The bounce leads to changing the substrate (ground) and Vcco on die, which causes jitter, and timing failures. All of this is trivially prevented by choosing the right series termination at the driver (or using DCI drivers). <p>With the Vccint at 1.5V and dropping fast, ground bounce is now becoming <b>public enemy number 1.</b> <p>Like I said, you can't get around LA without a car. Get the simulator. Use it. <p>Austin <p>rickman wrote: <blockquote TYPE=CITE>Hal Murray wrote: <br>> <br>> > The receiver pin is the one that gets the big hit. <br>> <br>> So how bad is that hit? How good are the protection diodes? <br>> <br>> If the clamp diodes are any good they will reduce the reflection <br>> and make things easier back at the transmitter. <p>This is a good question. So far I have only read people considering the <br>S3 chip driving. What about the case where is is on the receiving end <br>of the signal? <p>My designs typically don't consider signal integrity on traces other <br>than edge sensitive clock lines and chip enables. For non-edge <br>sensitive signals, I have always treated it a bit like metastability, <br>allow some time for the signal to settle out and all will be good by the <br>time of the clock edge. But if we have to consider *every* trace on the <br>board for reflections and overshoot, board design can become a <br>nightmare! <p>-- <p>Rick "rickman" Collins <p>rick.collins@XYarius.com <br>Ignore the reply address. To email me use the above address with the XY <br>removed. <p>Arius - A Signal Processing Solutions Company <br>Specializing in DSP and FPGA design URL <a href="http://www.arius.com">http://www.arius.com</a> <br>4 King Ave 301-682-7772 Voice <br>Frederick, MD 21701-3110 301-682-7666 FAX</blockquote> </html> --------------53B8F2F545754BA2978FBFA8--
Reply by ●September 23, 20032003-09-23
Hi Rick,
As a rule of thumb, when the signal's rise time is faster than
1/6th the time for the signal to get to the other end of the trace,
(guess at 170ps/in of track) then you MUST consider the SI
implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx
pin, you can have 1 inch of track before you have to worry about
reflections!) You can find the rise time data in the IBIS files Xilinx
provides on their website. Remember, the frequency of the signal isn't
important, it's the rise time. Leave those pins in 'SLOW' mode
whenever possible!
As Austin says, the simulation tools are a BIG help here. Those
IC pins drive bloody hard and fast and I would never like to be
relying on the clamp diodes to save the day, this dumps energy into
the supplies and Austin is not joking when he says that ground bounce
is (and will continue to be) a big consideration. There's a reason
Xilinx have gone to the trouble of putting DCI on their devices!
The receivers warrant the most attention as they can appear as
an open circuit, the drivers have low impedance and so limit
deviations a bit better. It's time to dust off "High-Speed Digital
Design" for some bed time reading! There's a new edition out I
believe? (Just found it:- High-Speed Signal Propagation: Advanced
Black Magic) I also recommend http://www.sigcon.com/ also by Dr.
Howard Johnson. More v. helpful stuff there for free!!
HTH, cheers, Syms.
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F70705F.EAB8FBC5@yahoo.com>...
> Hal Murray wrote:
> >
> > > The receiver pin is the one that gets the big hit.
> >
> > So how bad is that hit? How good are the protection diodes?
> >
> > If the clamp diodes are any good they will reduce the reflection
> > and make things easier back at the transmitter.
>
> This is a good question. So far I have only read people considering the
> S3 chip driving. What about the case where is is on the receiving end
> of the signal?
>
> My designs typically don't consider signal integrity on traces other
> than edge sensitive clock lines and chip enables. For non-edge
> sensitive signals, I have always treated it a bit like metastability,
> allow some time for the signal to settle out and all will be good by the
> time of the clock edge. But if we have to consider *every* trace on the
> board for reflections and overshoot, board design can become a
> nightmare!
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●September 24, 20032003-09-24
Symon wrote:> > Hi Rick, > As a rule of thumb, when the signal's rise time is faster than > 1/6th the time for the signal to get to the other end of the trace, > (guess at 170ps/in of track) then you MUST consider the SI > implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx > pin, you can have 1 inch of track before you have to worry about > reflections!) You can find the rise time data in the IBIS files Xilinx > provides on their website. Remember, the frequency of the signal isn't > important, it's the rise time. Leave those pins in 'SLOW' mode > whenever possible!But your use of the term "must" is not totally accurate. The numbers you give are a good rule of thumb for when reflections will be significant to the signal waveform, but that does not automatically indicate a problem will be created. A data line can bounce around for an extra ns or two and won't matter if there is extra time in the setup. Up until now I have not seen a chip rated to exclude ringing or overshoot (or undershoot) because of damage. In fact, most data sheets specifically say that this will not be a problem if it only persists for a few ns.> As Austin says, the simulation tools are a BIG help here. Those > IC pins drive bloody hard and fast and I would never like to be > relying on the clamp diodes to save the day, this dumps energy into > the supplies and Austin is not joking when he says that ground bounce > is (and will continue to be) a big consideration. There's a reason > Xilinx have gone to the trouble of putting DCI on their devices!I have not heard of ringing being the cause of ground bounce. My experience has been that ground bounce is caused by the initial current slug when an output changes state, not the result of a reflection from the other end. As the numbers that have been posted in this thread have indicated, the reflection current is much smaller than the initial slug.> The receivers warrant the most attention as they can appear as > an open circuit, the drivers have low impedance and so limit > deviations a bit better. It's time to dust off "High-Speed Digital > Design" for some bed time reading! There's a new edition out I > believe? (Just found it:- High-Speed Signal Propagation: Advanced > Black Magic) I also recommend http://www.sigcon.com/ also by Dr. > Howard Johnson. More v. helpful stuff there for free!! > HTH, cheers, Syms.If I actually have to simulate every signal on the board I am designing, it may never get done. I think there is something wrong with the idea that this is a overly complex issue and can't be dealt with in a simpler manner. Or am I missing something of what you are saying? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●September 24, 20032003-09-24
Rick, Fight it as long as you can, but everyone else is using the more advanced tools, and simulating everything (at the companies where they want to be successful on the first pcb turn -- as for the others, I don't hear from them often anymore....). And yes, if you do not pay attention now, you will cause ground bounce (50 - 60 mA of reflection current per IO is possible), and with the Virtex II Pro, and Spartan 3 if the IOs are operated at 3.3V, you may exceed the Abs Max data sheet limits if you do not pay attention to what you are doing. And that will cause a reduction in the 20 year projected lifetime. Below 3.0V, there are no reliability issues to consider, as the clamp diodes are sufficient to protect the IOs. Smaller, faster, less expensive technology from the foundries has some drawbacks: leakage current, and IO robustness at voltages greater than 3.75 volts being two of them. The new tools allow for extraction of all pcb parameters, and easy simulation of all tracks/traces. You can also create a design that is correct by construction: use DCI or series or parallel termination, and make 50 ohm (or whatever) traces. Then you do not have to simulate everything. Or use a standard: HSTL, SSTL, PCI. Then you also don't have to think. But I also simulate to make sure I haven't missed anything. Austin rickman wrote:> Symon wrote: > > > > Hi Rick, > > As a rule of thumb, when the signal's rise time is faster than > > 1/6th the time for the signal to get to the other end of the trace, > > (guess at 170ps/in of track) then you MUST consider the SI > > implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx > > pin, you can have 1 inch of track before you have to worry about > > reflections!) You can find the rise time data in the IBIS files Xilinx > > provides on their website. Remember, the frequency of the signal isn't > > important, it's the rise time. Leave those pins in 'SLOW' mode > > whenever possible! > > But your use of the term "must" is not totally accurate. The numbers > you give are a good rule of thumb for when reflections will be > significant to the signal waveform, but that does not automatically > indicate a problem will be created. A data line can bounce around for > an extra ns or two and won't matter if there is extra time in the > setup. Up until now I have not seen a chip rated to exclude ringing or > overshoot (or undershoot) because of damage. In fact, most data sheets > specifically say that this will not be a problem if it only persists for > a few ns. > > > As Austin says, the simulation tools are a BIG help here. Those > > IC pins drive bloody hard and fast and I would never like to be > > relying on the clamp diodes to save the day, this dumps energy into > > the supplies and Austin is not joking when he says that ground bounce > > is (and will continue to be) a big consideration. There's a reason > > Xilinx have gone to the trouble of putting DCI on their devices! > > I have not heard of ringing being the cause of ground bounce. My > experience has been that ground bounce is caused by the initial current > slug when an output changes state, not the result of a reflection from > the other end. As the numbers that have been posted in this thread have > indicated, the reflection current is much smaller than the initial > slug. > > > The receivers warrant the most attention as they can appear as > > an open circuit, the drivers have low impedance and so limit > > deviations a bit better. It's time to dust off "High-Speed Digital > > Design" for some bed time reading! There's a new edition out I > > believe? (Just found it:- High-Speed Signal Propagation: Advanced > > Black Magic) I also recommend http://www.sigcon.com/ also by Dr. > > Howard Johnson. More v. helpful stuff there for free!! > > HTH, cheers, Syms. > > If I actually have to simulate every signal on the board I am designing, > it may never get done. I think there is something wrong with the idea > that this is a overly complex issue and can't be dealt with in a simpler > manner. Or am I missing something of what you are saying? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX
