Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test 1.2 V capable level shifters 74AXP1T45 #283

Open
electroniceel opened this issue May 16, 2021 · 14 comments
Open

Test 1.2 V capable level shifters 74AXP1T45 #283

electroniceel opened this issue May 16, 2021 · 14 comments
Assignees
Labels
hardware Component: hardware revC Hardware revision: C revD Hardware revision: D

Comments

@electroniceel
Copy link
Member

Glasgow revC devices use 74LVC1T45 level shifters for the two ports. They support a 1.65 to 5.5 V voltage range, but lack official support for 1.2 V. @attie found out that Nexperia recently released the 74AXP1T45 which supports 0.9 V to 5.5 V. This issue is about testing if 74AXP1T45 would work as a replacement for future Glasgow revisions and thus allow increasing the voltage range of the Glasgow ports.

The side of the level shifter that has the DIR pin is called "FPGA-side" in this issue and is fixed to 3.3 V. The other side is called "DUT-side" and is varied in voltage. The voltages tested on the DUT-side will be the common CMOS-levels 1.2 V, 1.8 V, 3.3 V, 5 V.

Tests to do:

  • shifter driving the DUT-side, measure propagation delay between input and output, repeat with different voltage levels
  • shifter receiving on the DUT-side, measure propagation delay between input and output, repeat with different voltage levels
  • shifter driving the DUT-side, compare signal shape on the output, repeat with different voltage levels
  • shifter receiving on the DUT-side, test max. frequency on the DUT-side the shifter can reliably forward, repeat with different voltage levels
  • measure max DC drive and sink strength on the DUT-side (through the 33 Ohms resistor as on Glasgow), repeat with different voltage levels
  • output shorted to GND on DUT-side, let the shifter constantly drive the short at 5V, measure temperature, check if it survives for a day (check drive strength and leakage afterwards)
  • shifter with 33 Ohms in series, SP3012-06UTG TVS diodes after the resistor as on Glasgow revC2. shifter in receiving mode, slowly increase voltage on the DUT-side until either the TVS diode or the shifter dies. Repeat with new shifters and diodes, lower voltage into negative until one dies. It should be the TVS diode that dies first and thus protects the FPGA.

Repeat these test with the TI SN74LVC1T45DCK, Diodes 74LVC1T45DW and Nexperia 74AXP1T45. Also do the 1.2 V tests with the TI and Diodes parts to check how they perform outside their officially supported voltage range.

@electroniceel electroniceel added revC Hardware revision: C hardware Component: hardware labels May 16, 2021
@electroniceel electroniceel self-assigned this May 16, 2021
@electroniceel
Copy link
Member Author

Attached is the current work-in-progress state of the circuit i plan to use.
level-shifter-comparison.pdf

The AC-coupled input with the comparator is definitely overkill, but I might use this comparator for another circuit I have in mind, so I want to try it out here.

Anyone else got ideas for other tests to do or improvements to the circuit?

@attie
Copy link
Member

attie commented May 16, 2021

This looks good - thanks!

shifter receiving on the DUT-side, test max. frequency on the DUT-side the shifter can reliably forward

I think it would be good to have this in reverse too (i.e: verify max. freq in both directions)

The schematic looks good, though on Glasgow we also have a 33R betwen the shifers and the FPGA, so I'd be tempted to include one here too, just to match the usage as closely as possible.

@electroniceel
Copy link
Member Author

shifter receiving on the DUT-side, test max. frequency on the DUT-side the shifter can reliably forward

I think it would be good to have this in reverse too (i.e: verify max. freq in both directions)

I'm actually not really sure how to measure the exact max. frequency. The common way seems to measure from when the rising signal crosses 0.5xVcc to the next rising crossing. But there doesn't seem to be a common definition how high the signal must rise in between to still be considered a stable setup. Maybe the 0.7xVcc / 0.3xVcc points used for defining the input voltages? But then there is no voltage tolerance left for parasitics between the output and input of the next stage.

So I mostly wanted to do this by comparing the waveforms of the different shifter models in the same setup. But I'm open to other suggestions.

The schematic looks good, though on Glasgow we also have a 33R betwen the shifers and the FPGA, so I'd be tempted to include one here too, just to match the usage as closely as possible.

Good idea, I'll add a 33 Ohms on the other side too.

My signal generator maxes out at 120 MHz for square signals, while I have sine sources up to 3 GHz available. That was why I thought about adding the comparator. But after searching around a bit I'm not sure if the comparator is really the best way to supply really fast logic input signals. The ADCMP602 is the fastest I found with CMOS outputs and it still maxes out between 160 and 200 MHz. If I go to LVDS comparators, the fastest LVDS to CMOS receivers I found claim 200 MHz, e.g. ADN4662.

Nexperia claims about 619 MHz typ. max. freq for some parts in their AUP series:
https://assets.nexperia.com/documents/data-sheet/74AUP1G80.pdf
So maybe build a self oscillating circuit out of an AUP or AUC inverter and a trimmer resistor. This is not as convenient as typing in a freqency, but should still work out.

@attie
Copy link
Member

attie commented May 16, 2021

I'm actually not really sure how to measure the exact max. frequency.

Hmm, fair point. I've not looked at the figures (IIRC there were a few missing from the new part), and I'm probably not well placed to comment much further, but...

  • For our usage, I might expect that the phase shift introduced will start to become problematic before the part's max freq is reached? (should we try to measure that too, if it's not spec'd)
  • Depending on how the part behaves at the higher frequencies, I'd suggest that when the signal starts to get attenuated due to bumping into the rise/fall times would be the cutoff... but as you say, that's going to be influenced by parasitics... It's a difficult one to quantify.

PS: Do we just want to verify that they'll work to (and a bit above) our current specs? You have access to 120MHz, and that will satisfy the 100 MHz Glasgow spec...?

@electroniceel
Copy link
Member Author

electroniceel commented May 17, 2021

* For our usage, I might expect that the phase shift introduced will start to become problematic before the part's max freq is reached?

With phase shift you mean the one between input and output of the shifter, introduced by the transition delay? Wouldn't that only become a problem with a protocol where Glasgow needs to reply in time to some external event, like in a SPI peripheral applet? An applet which just receives, like a logic analyzer or frequency counter, shouldn't be affected by that.

(should we try to measure that too, if it's not spec'd)

I had the propagation delay on the list. But maybe we are meaning something different with phase shift.

PS: Do we just want to verify that they'll work to (and a bit above) our current specs? You have access to 120MHz, and that will satisfy the 100 MHz Glasgow spec...?

Boo! Where is the fun in that? 😏

Here is an updated version of the schematics:
level-shifter-comparison.pdf

@attie
Copy link
Member

attie commented May 18, 2021

An applet which just receives, like a logic analyzer or frequency counter, shouldn't be affected by that.

While this is true, from a usability point of view if there are certain restrictions like "btw, don't try 2-way comms at high speeds because of phase shift / propagation delays" might be a bit invisible / unexpected, and could cause weird behaviour for people who don't realise - especially if we quote "works up to 100 MHz", with a subtext / caveat of "for one-way interfaces only".

I wonder where our current level shifters sit on this?

I had the propagation delay on the list. But maybe we are meaning something different with phase shift.

Ah yes, apologies.

Boo! Where is the fun in that? 😏

🙃

@electroniceel
Copy link
Member Author

While this is true, from a usability point of view if there are certain restrictions like "btw, don't try 2-way comms at high speeds because of phase shift / propagation delays" might be a bit invisible / unexpected, and could cause weird behaviour for people who don't realise - especially if we quote "works up to 100 MHz", with a subtext / caveat of "for one-way interfaces only".

Ah, good point. I was just thinking of measuring and comparing the shifters first, not what we will communicate as "supported" or similar in the end.

So I'd say I'll make the planned measurements and comparisons, when we have the results we'll draw conclusions on what can be considered as safe to be called supported.

I wonder where our current level shifters sit on this?

I don't know and I haven't seen any systematic measurements (like with different voltage levels and so on) yet. I guess we'll find out when I'm done with the measurements listed above.

What I'm also interested in is how the same shifter model from different manufatcurers compare. This is why I included the I SN74LVC1T45DCK and Diodes 74LVC1T45DW in my list above.

@shuffle2
Copy link

shuffle2 commented Nov 21, 2021

1.2v would be great to expand the existing nand support to newer versions of jedec/onfi spec. Just an anecdote as I am currently searching for a device to interface with such nand and was hoping glasgow would work.

@attie

This comment has been minimized.

@shuffle2
Copy link

I hope it was on topic for this thread :) glasgow already has nand protocol support. But the DUT logic levels go down to 1.8v only. So implementing this level shifter change would enable otherwise existing functionality of glasgow to support the newer ("NV-DDR3/NV-LPDDR4") nand protocols which have 1.2v I/O levels, maybe modulo the turnaround time issues which were pointed out in previous messages.

@whitequark whitequark added revD Hardware revision: D and removed revC Hardware revision: C labels Jul 31, 2023
@whitequark
Copy link
Member

This is not happening for revC (please confirm @esden) so I'm going to bump this to revD.

@electroniceel
Copy link
Member Author

This is not happening for revC (please confirm @esden) so I'm going to bump this to revD.

Yes, this is more for revC4 (if we ever have one) or revD

@esden
Copy link
Member

esden commented Jul 31, 2023

We can definitely evaluate it for revC4, which can happen after we run out of parts for the current boards. By that time I will also know what DFM improvements to make.

@whitequark whitequark added the revC Hardware revision: C label Aug 1, 2023
@whitequark
Copy link
Member

We can definitely evaluate it for revC4, which can happen after we run out of parts for the current boards. By that time I will also know what DFM improvements to make.

Got it. Tagged back as revC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware Component: hardware revC Hardware revision: C revD Hardware revision: D
Projects
None yet
Development

No branches or pull requests

5 participants