GlasgowEmbedded / glasgow

Scots Army Knife for electronics
BSD Zero Clause License
1.88k stars 167 forks source link

Test 1.2 V capable level shifters 74AXP1T45 #283

Open electroniceel opened 3 years ago

electroniceel commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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...

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 commented 3 years ago
* 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? :smirk:

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

attie commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@shuffle2 is that on topic for this thread (i.e: low voltage parts), or a feature request (i.e: new parts / protocol)? (or both)

If the latter, please create a new issue. and give details about the part(s) you have in mind.

shuffle2 commented 2 years ago

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 commented 11 months ago

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

electroniceel commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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.