LSF0108: Droop on VrefB/EN when doing data transfers for PCI bus interface.

Hi Joe,

I have a lot of questions, and rather than me ask them all, can you share a scope shot of this with the Vref_A supply, EN pin, and the output signal together? I'd like to see the signal up close (100ns or less scale) - preferable both at the start and end of the a transfer, as well as a shot showing the droop over time - if possible.

The EN / Vref_B voltage node should remain at Vref_A + 0.8V (approximately), which would be about 4.4V in your system and is what you've described seeing in the static state. The current supplied in this case is only 3uA, which is a bit low - you could reduce the 200k to increase the bias - I'd recommend trying 47k to see if bumping up the bias current helps to stabilize the situation. 

There is some charge injection from each channel to the gate, but with a 0.1uF capacitor, we wouldn't expect that to be causing any major issues. You do have quite a few channels switching though. What kind of load is being driven (leakage / capacitance are my key care-abouts)?

Hello Emrys,

Thank you for your prompt reply!

We do have scope probe images of VrefB/EN, but since the combination of the 0.1uFD capacitor and the 200K ohm resistor is a low pass filter (Tc = 20ms), the high-speed PCI bus traffic (33 MHz) creates a "level" at VrefB/EN that is significantly lower than the 5V VrefB supply rail.  When idle and no PCI bus traffic, we see about 4.4 V.  But, as activity increases, the VrefB/EN gets lower-and-lower in voltage until we start seeing PCI errors.   Estimate VrefB/EN going down to about 2V when we start seeing PCI errors.

Yes, I would suspect lowering the 200K would fix the problem, but I'm not sure if that could cause any other issues.  I was quite surprised that the recommended resistor was so high - possibly only to save power?  How low can we make this resistor?  I wouldn't mind making it 1K (since power is not an issue with our design) meaning bias current through the reference MOSFET = (5 - (3.6 + 0.8)) / 1K = 0.6ma.  Perhaps go even lower than 1K?  We can also change the capacitor to 1uFD instead of 0.1 uFD.

The "load" being driven is a PCI bus - which typically has no resistive load, but there is a capacitive load.  On one side of the LSF0108's we have the host motherboard.   On the other side of the LSF0108s (ie, our board side) we have an Altera Cyclone 10 FPGA.  See schematic I sent in the last email.

The LSF0108 offers an excellent way of precisely "limiting" the PCI bus signals (either 3.3V or 5V depending on PCI "VIO") with a zero-delay device.  Some of the other level translators (LXB family) have active circuits which induce a non-tolerated delay in the "turn around" for a 33MHz PCI bus!   I think LSF0108 is justified for an PCI application note, now that virtually all parallel PCI bus interfaces are going to be implemented in an FPGA, and current FPGAs don't tolerate 5V signaling!

I am not sure if the TXS family, with the one-shot accelerator, would be an improvement.......Again, the reference MOSFET in the LSF family is quite novel in establishing a precise cutoff voltage for the signals going to the FPGA.

RSVP and let me know of what you thing about change 200K/0.1uFD to 1K/1uFD.   Perhaps you can simulate this circuit with what you might already have there at TI?

Also, I'll see if Stefan can generate (or perhaps he already has) scope shots of the problem and I'll send them off to you.

Thank Youl

Joe Norris

Hey Joe,

I can't write up a long response - I have to leave in a minute - but I wanted to give you a quick note here.

I have already been running some simulations and what I've seen so far is that the LM4051 drops off, I haven't figured out why yet.

The green trace is at the EN pin of the LSF, and the purple is at the VREF_A pin.

Are you seeing the same effect in your system?

Two quick things - I don't see any difference with changing the bias resistor, and the time constant of the droop appears to be directly linked to the 470 ohm resistor + the capacitor placed at the enable pin. Again - no answers yet, but I wanted to share. I should be able to look when I get back in about 30 minutes.

Emrys

YES!!!!  Looks like simulation is reflecting reality (for a change)!   Stefan is going to get Scope image of VrefB/EN on one channel and VrefA on the second channel - triggered off of a PCI cycle (such as FRAME).  He said he would have that tomorrow (Thursday).

So, perhaps you can see something in the simulation and determine the "why" in the meantime.

Thank You,

Joe Norris

Interesting.  I assume you are referring to R57 (470_ohm) in the schematic.  The LM4051 shut regulator (which is set up for 3.59V nom.) should be generating the proper VrefA bias, and note there is a 4.7ufd cap on VrefA that should give plenty of available instantaneous current for the LSF0108's VrefA pins.

This problem is becoming "interesting" indeed! LOL.

Thank You,

Joe Norris

We have previously captured some traces.

The following trace shows VrefB Power Supply (Yellow) and VrefB input pin #19 (Blue). Traces was taken with all 8 data lines simultaneously going low and then 30ns later simultaneously going high and repeating about every 200ns. VrefB at the input pin does not appear to vary

The following trace is the same setup but repeating the transfer every 4-5us with 50us delay every 16 transfers.

The following trace shows a Data Transfer trace capturing a Data Bit during a PCI Write. B Side (PCI is driving) in Yellow, A side (FPGA) in Blue during heavy load (200ns repeating transfers).

The following trace shows the VrefA Power Supply during heavy load (200ns repeating transfers). VrefA supply is yellow, GND is blue, and differential output (VrefA - GND) is purple. Note that there is some small noise but otherwise the VrefA does not droop. The Cursor A and B values are for the differential out

For reference, the following trace shows the PCI Clock U9 p17. B Side (PCI is driving) in Yellow, A side (FPGA) in Blue with 1s persistence.

I have noted that the number of data bits that is toggling and the speed at which there are toggling has a direct impact on the VrefB input pin voltage.

Stefan

Joe Norris said:

Interesting.  I assume you are referring to R57 (470_ohm) in the schematic.  The LM4051 shut regulator (which is set up for 3.59V nom.) should be generating the proper VrefA bias, and note there is a 4.7ufd cap on VrefA that should give plenty of available instantaneous current for the LSF0108's VrefA pins.

This problem is becoming "interesting" indeed! LOL.

Hey Joe,

I have good news and bad news - the good news is that I found an error in my simulation that was causing this issue (my 5V supply was set to turn off at 1ms), the bad news is that it doesn't help us at all with troubleshooting this issue. My apologies for the false hope there - although I am a bit relieved as that was a very odd issue to see and I had no idea why it was happening / couldn't find an issue in the simulation.

Thanks Stefan for posting the scope shots, this is very helpful.

-

There's quite a bit of undershoot, which may be an issue -- beyond about -0.5V the negative clamp diodes will activate and can cause variations in the local ground for the device (maybe why the ground looks so noisy). Probably not anything you can do about that without a major redesign though. This could affect the body voltage, which can cause threshold variations and thus clamp voltage variations.

-

The most likely culprit for the issue you're describing is going to be charge injection causing the gate voltage to drift internally. It would explain why everything looks fine at DC, but at higher data rates and with more channels switching the clamp voltage shifts. That voltage is directly related to the gate voltage, and the gate voltage is stabilized by only an external capacitor -- which works very well for lower frequency signals, but at higher frequencies, it may not be sufficient.

This would explain why I can't easily replicate it in my simulation software - I'm using simplified models that won't give me that kind of detail.

Would it be possible for you to add a pull-up resistor (330 ohm would be good for a test) to 3.6V at the A side pin on one of these channels? If the issue is related to the gate voltage stability, I would expect that to fix the issue.

Hi Emrys,

So your basically saying undershoot on the data lines is turning on clamp diodes which is feeding current into the reference MOSFET circuit (ie, VrefB/EN).

An interesting hypothesis!   

When you say "Add a pullup resistor of 330 ohms" are you suggesting adding 330 ohms to a PCI bus signal?   And, pullup to the 3.6V VrefA. I'm not sure if that would be allowed and tolerated on the PCI bus.

Better would be to reduce the 200K and/or increase the 0.1uFD to some more aggressive values to filter out the undershoot current.  Do you think this would work?  What's the max current that can  be tolerated by the reference MOSFET?   Going down to 1K should result in a 600 uAmp current.

In your simulation, can you apply a negative undershoot to the data lines and see what happens?

Thank You,

Joe Norris

Hey Joe,

Joe Norris said:

When you say "Add a pullup resistor of 330 ohms" are you suggesting adding 330 ohms to a PCI bus signal?   And, pullup to the 3.6V VrefA. I'm not sure if that would be allowed and tolerated on the PCI bus.

Forgive my ignorance of PCI bus - I have never designed with it. I was hoping to do this just to see if the issue goes away or not - it would help to isolate the issue. I understand if the system won't support this idea.

Joe Norris said:

Better would be to reduce the 200K and/or increase the 0.1uFD to some more aggressive values to filter out the undershoot current.  Do you think this would work?  What's the max current that can  be tolerated by the reference MOSFET?   Going down to 1K should result in a 600 uAmp current.

You can give both a shot -- it certainly won't hurt. If I'm correct about the charge injection issue, it won't make a difference though. I think the problem is happening internal to our device - ie there's too much parasitic inductance & resistance between our internal gate node and the external pin / capacitor node to allow the gate to properly charge/discharge at higher frequencies.

The MOSFET can handle about 100mA, so you're very safe dropping to a 1k resistor. You may see some additional issues though -- increasing the bias current also increases the overdrive voltage and thus changes the clamp voltage a bit.

Joe Norris said:

In your simulation, can you apply a negative undershoot to the data lines and see what happens?

Unfortunately my simulation model isn't that good - I'm using relatively simple (level 1) MOSFET models that won't handle any of the more complex behaviors at all. We don't have a more complex model due to the age of the device.

I think there might have been confusion on the pullup and which side it is connected to. The "A" side is the FPGA side. Note this currently has an approximately 25k pullup to 3V within the FPGA.

To CONFIRM you want us to try pulling up the "A" side to VrefA with a 330 Ohm pullup? 

Stefan

Hey Stefan,

If possible, yes - I would like to see if that eliminates the positive voltage variation.

You could also try a larger resistor size, however I expect 330 ohms or less is required to impact such a fast signal. 

Hello Emrys,

We changed the 200K ohm to 1K ohm on one of the LSF0108 chips, and that seemed to solve the problem on that chip.   We are going to change the 200K to 1K on the other chips.  

With the 1K change, the VrefB/EN node goes up to 4.8V with no activity on the buss.   Previously, it was at about 4.4 volts.

Can you run your simulation with:

A. 1K ohm instead of 200K ohms on the VrefB/EN to the chip

B. VrefB rail set to 5V.

C VrefA rail set to 3.6V

C. 5V voltage source driving into one of the "B" side data I/Os.

D. What is the resulting voltage at the corresponding "A" side?   If you need a load on the A side, try 10 Meg, 1 Meg, 100K, 10K.

Thank You,

Joe Norris

Emyrs,

This is looking good.   We are seeing 4.8V instead of 4.51 volts for the "Vbias" node in your second simulation, above (ie, with 1K resistor).

I have a better idea of our "load" going into the FPGA.  If you could please replace the 100MEG resistor with a 3.0 Voltage source and a 25K series resistor, that would be what the FPGA is presenting as a load.   The FPGA is being programmed so that it has a "pullup" resistor (i25K) and the FPGA I/O power rail is set to 3.0V in our design.

Your help has been much appreciated, and I suspect we can close the case with this final simulation!

Thank You,

Joe Norris

Hey Joe,

I adjusted the simulation as requested and reran the DC values:

I also included a copy of my simulation file below (for Tina-TI), in case you'd like to tinker with this further. 

LSF_Bias_Change.TSC

Emrys,

I downloaded the latest copy of TINA.   I added some voltage meters.  Revised .TSC file is attached; "JPN" in file name are my initials.   For some reason, I'm getting 3.57V at the V_A1 node while you are getting 3.74V.  Why?

LSF_Bias_Change_JPN_032122.TSC

Node_Voltages.TXT

Thank You,

Joe Norris

Hey Joe,

Your pull-up resistor is 1k.

you are correct, Emrys.  I fixed and reproduced your result.  Thank You,  Joe Norris