Suitability of/alternative to TXS0108EPW for 5V <-> 3V3 level shifting @ 25 MHz - Page 1
Forum section: electronics / beginners

author: dolbeau
author_rank: Regular Contributor
timestamp: September 24, 2020, 11:27:52 am
content: Hello,I'm trying to figure out how to use a 25 MHz, SE, TTL-compatible CMOS level (read: 5V) parallel bus with a modern FPGA - one that can stand 3V3. My current design uses eleven (!) TXS0108EPW . However, I'm a beginner so I'm not sure if it's the right tool for the job. The maximum delay from the datasheet is about 5ns, which should work but I'm not 100% certain (a prototyping design from the era uses 74FCT244 and 74CFT245 to buffer the signals and those add a similar delay).Any opinion or advice if those would work, or if there is some better tool(s) for the job ? Context here:https://www.eevblog.com/forum/fpga/designing-a-fpga-board-for-a-90s-sparcstation/, this is an attempt with yet another FPGA board as the prospective daughterboard (e.g.https://www.ztex.de/usb-fpga-2/usb-fpga-2.13.e.html), picture in another question (https://www.eevblog.com/forum/beginners/how-much-length-tuning-needed-for-25-mhz-se-parallel-bus/)https://www.ti.com/lit/ds/symlink/txs0108e.pdf

author: Cervisia
author_rank: Regular Contributor
timestamp: September 26, 2020, 01:34:08 pm
content: This should work, if the integrated pull-up resistors are not a problem.But why aren't you using proper buffers like the SN74LVC8T245?

author: dolbeau
author_rank: Regular Contributor
timestamp: September 26, 2020, 03:08:45 pm
content: Quote from: Cervisia on September 26, 2020, 01:34:08 pmGood question... most of the signals have a pull-up on the host side already, but not all. I (think I) understand what those are meant to do, but I've yet to master how everything interact... and I don't want to take chances and damage the host.QuoteMostly because I don't yet understand the difference beyond the lack of directionality (https://www.ti.com/lit/sg/slyy165/slyy165.pdf).The TXS0108EPW seemed less scary to the newbie, as it doesn't have a direction pin. With a direction pin, I will need extra logic to drive it the proper way - and more importantly, I need to group signals properly (rather than just in connector order to minimize routing issue) as there is just one direction pin for all 8 signals: the have to go the same way as the same time.But re-looking at the TXS0108EPW datasheet again, I'm not sure the direction of all 8 is independent, either. I just assumed :-(Looking at the documentation, I would probably need at least 4 SN74LVC16T245 to begin with (seems to me to be the 16-bits equivalent of the SN74LVC8T245; I have 32 bits of data lines and 28 bits of PA lines so easier with larger chips). Then I need to finish understanding all the signals and a basic protocol FSM to figure out how to group the other 22 (i.e. anything asserted by the controller including the CLK is input-only for the daughterboard, so can go to the same chip; I think ACK are output-only).And for more fun, unlike the others, the interrupts line are 'open drain', which probably means I will have to do something different there...Learning :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 26, 2020, 03:13:57 pm
content: I wouldn't worry about it, TTL V_OH is roughly compatible with 3.3V LVCMOS. I would add a clamp diode from each pin to VDD, and a series resistor on the bus if ESR is tolerable (if the bus is source terminated, this is even mandatory).And yes, a proper bus interface is preferable, also because it can be powered down without loading the bus.Note you need a HCT style (TTL threshold) bus interface here, because 5V CMOS is not compatible with TTL. The SN74LVC8T245 won't work by itself, not powered from 5V (V_IH max 3.5V vs. TTL V_OH min 2V). I forget if there's a similar family with TTL compatible thresholds (VHCT??) or what. Else, running it from 3.3V both sides, and using clamp diodes and resistors as needed/as is possible, will do; or using the FPGA directly.Or, y'know, old fashioned TTL or FAST, if you have the 5V available onboard as well.The buffer might not be doing much in that case, but it can still be of value to isolate the FPGA's pin drivers, which are usually on the weak side; many aren't rated for much DC bias, for example. Not to mention ESD. A socketed buffer can be used sacrificially to deal with both, without compromising the FPGA.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 26, 2020, 04:12:59 pm
content: Quote from: T3sl4co1l on September 26, 2020, 03:13:57 pmI wish I understood all of that :-) My understanding is that yes, the usual 3.3V level for 'high' and 'low' are compatible with the bus itself - anything below 0.4V is 'low' and anything above 2.4V is 'high' in the specifications. But the bus can put up to 5V, which would burn the FPGA. I guess that 'clamping' the signal to 3.3V would work, but then you lost me with ESR and 'source terminated'... any pointers?I do have a table describing 'Bias circuit and drive requirements', and I'm still trying to figure that out; the schematics for the vintage test board I have doesn't seem to have anything between the bus and the input buffers they added (74FCT244 uni-directional, 74FCT245 bi-directional, 74FCT191 with an extra counter for some protocol stuff). Looking again, the data lines (but only them, apparently) *are* pulled up by 10kohms on the other side...(BTW my primary concern should that board ever get made is to preserve the host as it's a hard-to-replace vintage system; secondary concern is to preserve the FPGA/board, as they're expensive).QuoteBy a 'proper bus interface' you mean a chip similar to what we were talking about ?QuoteIndeed, looking at the specifications again, both devices (TXS0108EPW and SN74LVC8T245) have V_IH=VCC*0.7 (or .65). So that would mean some of the bus' 'high' signals might not register as 'high' if they're in the 2.4-3.5V range?There's a 74VHCT245A, but it's single-voltage.By 'using the FPGA directly' I assume you mean the 'clamping' from before?QuoteNot sure what you mean. The bus supply +5V, but the FPGA won't take it (I found a seemed-to-be-suitable board which helpfully accept 5V input on the headers, has an internal 3.3V supply, and route the proper 3.3V back to the headers so I have both voltage available for the unsuitable TXS0108EPW, the pins are also supposed to accept 3.3V).QuoteI don't think socketed will fit (I understand that as 'through-hole socket and a DIL package'...) Even with surface-mounted packages routing is not easy and I have buffers on both sides of the PCB to reduce congestion. But then the principle still stand that it might be better to burn just the adapter board than the FPGA board :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 26, 2020, 05:58:29 pm
content: Quote from: dolbeau on September 26, 2020, 04:12:59 pmWell you said it's TTL, that means V_OH ~ 3.5V. It can pull up to 5V, sure, but that doesn't mean it does, continuously, at full I_OH current. (Indeed, I_OH is weaker than I_OL, part of why TTL's input threshold is off center. It can't pull up as well as it can pull down, so everything is positioned a bit below center to keep things reasonable.)Unless it's mixed TTL and CMOS drivers or something, in which case clamping diodes aren't such a great idea, and a 5V interface would be wise.QuoteAh okay, not quite TTL, but still very similar:https://www.ti.com/lit/ds/symlink/cd74fct244at.pdfV_OH min 2.4V, output curves not given but description says pulls up to 3.7V (two diode drops below VCC) which is very close to compatible with 3.3V CMOS.Typical 3.3V CMOS is rated for inputs up to VCC + 0.3V or so (so, 3.6V), with significant current flow about a diode drop above (3.9V+). A schottky clamp diode (BAT54 say) conducts earlier, limiting the voltage safely.At worst, you might have a few mA from the bus driver (pulling up to ~3.7V) into the clamp diode, which actually you may want a clamp on VCC to prevent it being pushed up in this way (a TL431 shunt regulator can do this).QuoteExactly. You need V_OH min greater than V_IH max. Otherwise, there may be conditions where V_OH is insufficient, and the logic level gets misinterpreted.QuoteYes. Its outputs may be relatively weak (less I_OL / I_OH), whether by nature or by specification (like a DC current rating), but if it's adequate, then that's fine. The remaining case is when the bus gets driven above 3.3V, see above.QuoteYou didn't mention anything about form factor. I've been imagining this is a dev board with wires hanging off of it...Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 26, 2020, 06:54:18 pm
content: Quote from: T3sl4co1l on September 26, 2020, 05:58:29 pmThe standard is clear for the levels (0.4V, 2.4V) but doesn't specify explicit maximum except VCC+0.5V and VCC is, I think, the 5V supply - hence I figured I needed some shifting as someone on the bus could drive as high a 5.5V. The standard originated in 1989 at Sun and was published by IEEE in 1993, so it wasn't really made for modern technology.The published standard says this before the table:Quote from: IEEE 1496-1993That last paragraph must have made things costly back then, I would guess... and aren't helping me today, it seems :-)Interestingly, the older Sun standard on which IEEE1496 is based (publicly available:http://www.bitsavers.org/pdf/sun/sparc/800-5922-10_SBus_Specification_B.0_Dec90.pdf, page 111 in the pdf [labeled 91]) is explicit for the 5.5V.From the 74FCT used in the prototyping board (not a reference design, but if it worked for them...) and the 7400 family in wikipedia, your suggestion of HCT seems quite right; as TTL-compatible CMOS I see HCT, ACT, ALVT, FCT, VHC(T) and the BiCMOS stuff (if it still exists, I should go for BiCMOS for the added period-accurate tech ;-) )I see a74ALVT162245, could that do the trick ?Quote from: T3sl4co1lLooking up those references together, I find this:https://electronics.stackexchange.com/questions/433388/protect-adc-input-from-over-voltage-with-schottky-diodes, is that what you suggest? I was hoping for a more integrated version as I have 82 signals to protect :-)Quote from: T3sl4co1lThe info was buried in a link, sorry; I'm trying to interface a FPGA on aSBusexpansion card for a 90'sSPARCstation... so I have to interface with the proper connector (obsoleted but Mouser still has stock, apparently) in the proper form factor (146.7 * 83.82 mm). The physical aspect and the connector were the easy part ;-)Thanks for all the advice, it's very much appreciated :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 27, 2020, 12:28:30 am
content: Quote from: dolbeau on September 26, 2020, 06:54:18 pmYes, that looks very much like the kind of thing.Wouldn't be surprised if it shows up in reference to the standards in question, even...QuoteNo worry.https://www.digikey.com/product-detail/en/diodes-incorporated/BAT54CDW-7-F/BAT54CDW-FDICT-ND/717822There might be even bigger ESD clamp devices, though I'm not sure if you'll find a schottky based one.Bigger diode arrays do tend to be specialty/boutique/pricey (unless they're popular for specific applications like ESD), a dual-dual like this is probably the best bet. If it can't be avoided entirely, that is.QuoteOh pffbt, that's huge. Tons of room for bus interface, an FPGA and some regulators to run it. Unless you need some other stuff tacked onto it, no idea. Picky picky.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 27, 2020, 10:05:21 am
content: Quote from: T3sl4co1l on September 27, 2020, 12:28:30 amThe standard doesn't say anything, and the associated experience book mentions only 74FCT - and warns on potential issue due the delay from enabling/disabling OE (output enable) in that family. I've lloked at the 74ALVT in more details, turns out the V_OH is only guaranteed to be >= 2.0V, I need 2.4V :-(74HCT245 or 74LVC16245A are both in the right range (dual inputs, proper V_), but are very slow - about twice as slow as 74FCT or 74ALVT families.So, back to square one... I'm now considering your other option:Quote from: dolbeauSo I figure I could do (BAT54C seems to be two BAT54 in one package), see schematic below.But I'm not sure what it all means, and more importantly if it will work both ways - even if a minimalist implementation of the protocol has most signals one-way (input or output), the data lines can be inputoroutput. So I need:If the bus drives a signal on SBUS_5V_D, to 'see' a tolerable/detectable signal by the FPGA on SBUS_3V3_D - that's the point there so it should be OKIf the FPGA drives a signal on SBUS_3V3_D, to 'see' a tolerable/detectable signal by the bus on SBUS_5V_D - will that work as well ?To be able for the FPGA to not drive (or even read) most of the timeAlso I'm not sure where the number really come from (except the ratio for the 'voltage divider' made by the two resistors _DIVHIGH/_DIVLOW), and in particular for the _ABOVE resistor and the two inline ones (I wouldn't say I fully understand why any of those are needed, either...).Software is easier, 0 is 0 and 1 is 1 and that's it, there's just a lot of them :-)QuoteIt's used length-wise - those 14.67cm are quite long for fast signals. And it's not anywhere near as big as a full-length, full-width PCI card :-) (also, the high-density connector is much nicer than those card-edge things, IMHO).Currently I only have a pair of 2.54mm header for the FPGA board proper (figure I'll let a professional handle that part, so I picked one that seemed to fit the bill and was the perfect size - 83.8mm long for my 83.82mm wide board), the SBus connector, a micro-sd connector, some LEDs, and the inadequate level-shifters that started this discussion. It's already a routing nightmare for a newbie.And thanks again for your help :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 27, 2020, 11:46:10 am
content: Quote from: dolbeau on September 27, 2020, 10:05:21 amEh, close enough. Or could raise VCC slightly. Probably the FPGA would be okay with 3.5V or so?QuoteEh?https://www.ti.com/lit/ds/symlink/cd74fct244at.pdfsays t_pd 1.5 4.5 6.5 (min/typ/max) ns,https://www.ti.com/lit/ds/sces584b/sces584b.pdfsays (8.9, 8.10) 0.5 4.4 / 0.6 6 / 0.7 6 / 0.3 4.5 (min/max) ns for the various edges and combinations of supplies.I don't know under what conditions an LVC runsthatslow. Possibly it's the guaranteed process corner, either by per-part testing or by design. I forget what exactly. The average case will be towards the low end.Process spread is a production yield thing. If you want to guarantee operation after fixing every possible assembly error, then you need to work with the worst possible batch of chips. If you can afford some testing and lost yield or rework, you won't need to follow the max limits as tightly.Probably, you'll see limits near max, over production runs of 10k+ units.(Are there even that many SPARCStations left in the world?)HCT is slower though, and yeah, probably marginal to useless here, even if the bus has lenient timing.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 29, 2020, 12:56:31 pm
content: Quote from: T3sl4co1l on September 27, 2020, 11:46:10 amWell, it's that slow if you read the wrong documentation in the wrong tab of the browser :-/The 74LVX245 and 74LVX16245 are the ones that are slow, actually, sorry (up to more than 10ns A->B, vs. 5ns or less as you quoted for the LVC family).QuoteHehe, perhaps not that many, though I could probably boot 10 with SBus connectors if needed :-) (some entry-level were built in monitors and didn't have any, while older ones where VME only, and yes I do own samples for all of those... I'm an old geek)Anyway, in the end, thanks to this thread I'm much more proficient at reading datasheets (or perhaps I'm just deluding myself!), and there's somehelpful document out thereonce you've been explained what to look for. So here's what I'm currently using at for a slave-only design, all buffers running on 3.3V (and driving high at >= 2.4V so they should be able to talk to the bus):2 74LVC16245A for the data lines (with common OE/direction signals for all 4 bytes)2 74LVC16245A for the physical address lines, size and r/w signals - they are only inputs on slaves, and can be switched collectively to outputs to support 'extended transfer' (64-bits). Master have size & r/w as outputs, but shouldn't drive the PA when doing so, so this precludes implementing a master-capable design (in the FPGA, that is)1 74LVC126A for Clock, Reset, Assert & Select - those 4 are always inputs, so need don't need bi-directionality, and will be 'always-on' (OE tied to +VCC)1 74LVC126A for ACKs and Error - those 4 are always outputs on slaves (they are inputs on master, another issue for that use case)1 74LVC2G07 to implement the open-drain driver for two of the interrupts (I really don't need all seven)I just ignore parity (as advised by the book!), the two master-only signals as bus mastering won't be possible from the above anyway, and 5 of seven interrupts linesI could make the design master-possible, but it would require another half-used 74LVC16245A (size and r/w in one byte, ACK/err on the other, plus two OE and direction lines) and another half-used 74LVC126A (for the two master-only signals, one each way, plus yet another OE though that can be always-on as they are dedicated lines, not buses). I'm going to run out of FPGA I/O pins from the daughterboard, so I might stick to slave-only for the moment.I'm still not sure about some details from those datasheets. In particular, I want to pull-up/down the OE (some are active-low, some active-high...), but I'm unsure what to read in the datasheet to compute the resistor value.I have a 7LVC126A whose OE is tied to +VCC (always on, easy); for the other there should be a pull-down - but how much? I have 4 OEs tied together, driven by a pin of the FPGA, but the 7LVC126A doesn't say how much current OE will take - is that just the "input leakage current"? If so it's only 5uA per pin, 5kohm would do the trick (0.1V on the resistor above GND for 4*5=20uA). Should I take into account the FPGA output as well?For the 74LVC16245A the OE is active-low, so I need a pull-up; do I need one per chip (or even per pin, I tie both pins of two chips together, 4 in all), or can I just use one between the chip (my current choice)? In which case with the same input current as above, 10kohm would do the trick (0.2V below 3.3V is largely above the 2.0V high).The 74LVC2G07 will also need a pull-up per line, same maths as above so 10kohm as well I would guess?Thanks again for all the previous help, and thanks in advance to anyone that can shed even more light on the subject :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 29, 2020, 02:06:36 pm
content: Excellent. You're welcome!Quote from: dolbeau on September 29, 2020, 12:56:31 pmIf you're using more for other enabled signals, reuse is fine; but if just for buffering, a '17 or '50 will be denser. Let's see... there's no LVC17, but there are mini versions (74LVC1G17, etc.). There's LVX and VHC50, with similar speed.Or grab another '245 and strap it enabled.QuoteWhich -- if you want to implement these, there are byte sized LVC245s, or you can use some combination of -16-s, '245s and '126s (or '50s, or..) to do it, sounds like there's enough signals and choices of buffer to do it with few unused gates.QuoteCMOS input current is just leakage, ~uA. So megs will do. You probably want <= 10k to have a more stable level (reduce susceptibility), or just tie it hard to VCC/GND when you know you'll never need it wired anywhere else. (That includes a 0-ohm jumper, the best case I suppose.)TTL shouldn't be strapped hard to VCC because of potential latchup conditions, but CMOS doesn't have that. (Heh, CMOS has a different latchup condition, but that's avoided by not overdriving the pins.)QuoteI didn't catch where the enable is coming from? If it's from the bus, it may already have a pull-up, but maybe it's intended to have one per interface as well, for which the recommend pull-up would be good. (I know GPIB does this -- it's a parallel bus with pretty large fanout and local pull-ups on each (open collector) control signal, so the drivers (SN75160, etc.) are quite beefy to handle the total worst-case load!). Maybe 10k is enough, maybe 1k is enough, depends. Note risetime is about 2 RC, where R is the total pulling-up and C is the total bus and pin capacitance.If it's internal, just drive it from the FPGA? If you have other drivers and you're using an open-drain signal internally, yeah, total pullup around 1k, give or take speed/power tradeoff, should be fine.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 29, 2020, 02:44:21 pm
content: Quote from: T3sl4co1l on September 29, 2020, 02:06:36 pmI find it easier to have fewer chips (the more chips, the more I'm likely to scr*w-up something :-) ), so for 4 lines the '126 does the job and isn't too big (they are not visible in the picutre because I put them on the underside).QuoteYes, but the byte-sized 245 have just one OE per byte, like the 16245, not one per nibble (4 bits) as some other devices in other families do. Probably easier to use a single 16245 than two 245. At least for me :-) I didn't find a way to get proper output levels and 4-bits granularity of OE/direction, only 8 bits granularity. Unidirectional chips have more references.QuoteSo I seem to have gotten it somewhat right, yeah :-)QuoteThe FPGA. My idea (could be wrong...) is to disable the lines when not in use, to only expose the high-impedance 'off' mode to the bus. The bus doesn't want to have multiple drivers active at any one time, and the protocol is designed to make sure it doesn't happen when implemented properly (i.e., only one player is meant to be driving a line at any time). I figure disabling the buffer is a good way to make sure I'm compliant, I would just enable+put the value on the bus when required, and disable afterward.QuoteI will drive it from the FPGA, but I'm not sure the FPGA will load bitstream + configure and start disabling lanes *before* the host is using the bus. I don't like the idea of an undefined OE driving undefined signals during POST. I figure I need to disable all drivers to the bus when the FPGA is not doing it's job properly (of course if the FPGA put the wrong signal at the wrong time the system will crash, but avoiding that is a future job ;-) ).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 29, 2020, 03:15:54 pm
content: Try 74LVC244.Quote from: dolbeau on September 29, 2020, 02:44:21 pmAh, of course. Pull-ups/downs are a good idea during configuration!Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 29, 2020, 03:35:21 pm
content: Quote from: T3sl4co1l on September 29, 2020, 03:15:54 pmYes, that's the nibble-sized unidirectional one. It could replace both 126, but then signals from different parts of the connector would have to converge to just the single 244, I can shorten things a bit by splitting the 'in' and 'out' signals over two 126. 'reset' has a fairly long wire but that's irrelevant, it's asserted for 512 cycles at least (>20 us!). 'clock' wirelength isn't ideal, mostly because it has to go to one of a small subset of FPGA pins that are 'clock-capable' (and 'P' in the differential pair as I'm single-ended), as I understand it (all other signals go to FPGA pins not labeled "VCC" or "ground" ;-), because I've no idea what all those extra labels means; as far as I can tell, all the pins routed by the FPGA board to the headers can do single-ended in-out LVTTL signals which is what I need).Thinking about it, splitting the 126 into 4*1G17 as you suggested might make routing easier/shorter, as well...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 29, 2020, 05:58:11 pm
content: Routing should be no problem, surely you're using a 6 or 8 layer board for an FPGA that size?Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: September 29, 2020, 06:23:30 pm
content: Quote from: T3sl4co1l on September 29, 2020, 05:58:11 pmI'm not routing to the FGPA, but to apre-existing board carrying the FPGA (link to the commercial website). The board should handle power, programming off-line, etc., so the complete newbie that I am doesn't have to worry about all that. And a 4 layer 'carrier' board should be cheaper, if this ever gets made (read: if I feel confident enough it won't burn the host, and that it might work).I just route the bus' 5V supply to the 5V input of the board (which supply back regulated 3.3V from the onboard power system), and the signals (through all those extensively discussed chips!) to the various available pins on the 2.54mm headers. Perhaps somewhat haphazardly, I should add :-) I also added a micro-sd card slot and some LEDs, because everyone else has LEDs. I'd love a HDMI output (or DVI or whatever), but examples I've seen tell me it's too complex and I don't have the available pins anyway.Designing a full board with a modern FPGA and some SDRAM doesn't seem within reach of a newbie... I thought the solution above had a higher probability of success. And would be a better learning experience and much cheaper than having a board professionally made. I don't mind spending a bit of money on such a ridiculous idea, but I suspect an actual professional design would be way over any reasonable budget! Though if an actual professional wants to PM me some quote(s), I'm curious how much a design like that would be :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 29, 2020, 09:37:37 pm
content: Ah, and that would constrain the outline and placement rather a bit more than the full-custom. I see.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: October 09, 2020, 09:45:07 am
content: Hello again,I was happy with the chips I selected (thanks again for the help!) and was writing some VHDL to figure out how to implement the protocol (timing is *hard*...), when I came acrossthis board (link to a commercial website)which has "5V tolerant I/O". So I looked atthe schematic, and apparently they useTI SN74CB3T16210chips - TI also has wider (24 bits) and narrower (10, 8, 4, 2, 1 bits) references. The 24-bitsSN74CB3T16211looks really good to me.Propagation seems much faster (0.25ns propagation delay), voltage response (for low and high level) seems fine for my use case (input 0.8/2, output 0.4/2.4), no direction signal required. I'm not 100% if I put the input on B at high-Z that A will also be high-Z, but I believe so. I also don't understand if it's 100% symmetrical (using A or B on the FPGA side doesn't matter), or if there is something that justify the company having the FPGA on the A side and the pins on the B side.Any reason to keep my previous selection (74LVC-based) over this (clear advantages, or fatal flaw in this that I missed)? Not having to worry about directions and having everything ON all the time (so no issue with ON/OFF delays) would make the FSM easier to deal with :-)Thanks in advance to anyone who can shed some light & cordially,

author: Cervisia
author_rank: Regular Contributor
timestamp: October 09, 2020, 03:38:44 pm
content: The CBT devices are passive switches. You can use them only if your FPGA can drive the bus through them.

author: dolbeau
author_rank: Regular Contributor
timestamp: October 09, 2020, 04:17:35 pm
content: Quote from: Cervisia on October 09, 2020, 03:38:44 pmI'm not sure what you mean by "drive the bus" precisely; do you mean enough voltage to register the '1' on the bus? From my understanding of the voltage response of the 74CB3T (figure 3 in the SN74CB3T16211 doc), as long as the FPGA output > 2V, the chip should 'boost' the voltage to ~3.3V (and the bus only require >=2.4V). Also the Artix-7 pins will be set to LVTTL levels, which are exactly the one from the bus (except the limit to 3.3V where the bus can do 5V, the very reason I need an intermediate chip to limit the voltage to ~3.3V or less when the bus is driving a signal to the FPGA).Or do you mean enough current to rapidly ramp up said voltage between clock pulses? *that* part I've yet to fully understand...Thanks & cordially,

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 09, 2020, 08:20:39 pm
content: It doesn't have a I_OLH rating because it's not a driver. If your FPGA has less current, that's all you're going to get, not the 20mA+ or whatever is required to drive that bus.Which is also why they can claim fast speeds, they can just drive one side with an ideal pulse generator, and see what comes out the other side.It will have Z on both sides though, that's correct -- that would be very difficult indeed to arrange with an active circuit, but it's absolutely natural for a switch, thanks to reciprocity.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: October 10, 2020, 06:56:05 am
content: Quote from: T3sl4co1l on October 09, 2020, 08:20:39 pmOK, so as theArtix-7 can drive up to 24mA in LLVTL (table 8 page 10 note 5), which is the same as the 74LVC16245A I was previously looking at, this won't make the situation worse from that point of view.Looking at the standard, I see:QuoteSo I would guess the FPGA has drivers strong enough to drive the bus. In fact, I might want to set the FPGA driver to _less_ than 24mA ? It can do 4, 8, 12, 16, 24; 4mA is supposed to be enough if I read the standard correctly, is it dangerous to set the FPGA driver to 8 or 12 ?Thanks to both of you for all the help :-)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 10, 2020, 11:44:32 am
content: I would keep it on the high drive strength option.That seems to be the simplest option then. It does voltage clamping as a pass-through instead, and with minimal propagation delay; plus it can be disabled, should you ever need to.Tim

author: dolbeau
author_rank: Regular Contributor
timestamp: October 10, 2020, 01:12:00 pm
content: Quote from: T3sl4co1l on October 10, 2020, 11:44:32 amThanks again. I will go for that option then (and I only need 3*24 bits chip and a 4 bits chip, so it's also easier to fit).