Level translation and propagation delay... - Page 1
Forum section: electronics / projects

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 21, 2022, 07:22:59 pm
content: So I'm trying to plan out connecting an FPGA to an old 5v NMOS system (an on-again/off-again long-running background project I have, and I've been looking at different FPGAs to see what the trade-offs etc. are. One of the candidates only has 1.8v (or lower) i/o voltages, so I went searching for bidirectional level translators...The propagation times can vary wildly between min and max! Looking at the table for the74LVC1T45VccA= 1.8v, VccB= 5v, I see the table:Am I reading this correctly, that it can take anywhere between 1.9ns and 15.1ns to drive low->high from B to A ? Is there some context I'm missing, like it's temperature dependent, or is it just randomly fluctuating between those two extremes on a clock-by-clock basis ?At the top of the data sheet, it says the maximum data-rate is 75Mbps for translation to 1.8v, which implies a propagation delay of 13.3ns. I *think* it's getting that by averaging the best-case maximum propagation times (actually that is for B=5v) for a low->high and a high->low transition, and squinting a bit.Code:15.1ns + 12.2ns = 27.3ns => average of 13.65ns13.65ns delay == 73.26 MHzSo if I use this, I should plan on the worst-case numbers and accept ~30ns (by the time the FPGA has clocked it) delay in signal transfer on a round-trip ? That's ... not great. My timing budget for a response by the FPGA is 40ns. I think I can reduce the task to something pretty trivial (read 8-bit value, use as index into register array, is register set, if so drive pin)I can probably read the 8-bit value on the previous clock, and I guess if I can get the FPGA to go to 200MHz on that logic, I get 2 clocks to do the compare-and-set, but I usually prefer a little more timing leeway than thatI wonder what the fMAXof an XC2S15 is, Digikey (well, Rochester) still has them in stock, and no level converter nonsense

author: jbb
author_rank: Super Contributor
timestamp: August 21, 2022, 09:55:12 pm
content: HmmThose times aren’t great.For signal out of FPGA: how about a high speed comparator (eg TLV3601) to compare FPGA output to a mid-rail reference?Continuing that thought: do you have LVDS IO available? Some transceiver chips can do 5V supply (eg S90LV019). Also handy if you need to move the signal some distance, especially over cabling.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 21, 2022, 10:14:47 pm
content: The delay will not vary much from cycle to cycle. This seem to include the voltage ranges, temperature range (e.g. -40 to +85 C) and variations from chip to chip.There are curves at least for the typical temperature effect. The 15.1 ns are the worst case for one direction. The other direction worst case is already better.The delay can not be directly translate to the maximum speed. With multiple internal stages the clock period can be shorter than the delay.The data also look a bit strange - having a higher speed both with higher or lower VccA. So there may also be a typo / error in the DS. It may be worth checking a different manufacturer for the datasheet.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 21, 2022, 11:24:13 pm
content: So to give a little more clarity to the problemThe 5v system is an old 8-bit computer, yes *that* old, but it has a nice port on the back with all the CPU signals exposed. The goal is to do clever things with 40-years-later FPGA technology to, amongst other things, upgrade the RAM a bit (to 32MB, suitably windowed for access), add better video, and to give "expansion slots". I'm planning on plugging the new PCB directly into the back of the old computer. The timing constraint is that the "take over the bus for this cycle" signal has to be asserted by 225ns into the cycle, but the address takes 177ns to become valid - rounding those off to clock-cycles in the FPGA gives me ~40ns.One thing I have come across while trawling around this afternoon is theSN74CB3T3384which might really help - it's propagation speed is effectively negligible at <= 0.25ns. I'm not sure how well this will drive data from the FPGA to the 6502 though - this is an old NMOS CPU, and I *think* logic-high (it's hard to find datasheets of the original 6502, there were so many copies) is ~4.5v. I haven't any experience with this particular chip, but the level translators without directionality pins I've used in the past haven't had much drive capability, and it's entirely possible there could be a pull-up on the internals of the computer for a signal which is "disable the internal RAM fetch and let an external box do all the work".> Continuing that thought: do you have LVDS IO available? Some transceiver chips can do 5V supply (eg S90LV019).I wouldn't have thought of an LVDS transceiver, and I do have them available - lots of them in fact since the HS io's can all be differential! That's a really cool idea for the FPGA->single-ended output pin, and the propagation times are quite a bit faster - typical 5.8ns, max of 9ns.Putting the two above together might be a good solution - effectively 0ns on the read-part and 6(maybe 9)ns on write. That gives me a lot more leewayThanks for the idea

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 22, 2022, 01:38:49 am
content: Propagation delays are guard-banded more by design, and statistics, than by actual test. Something like that. Measure the actual performance of parts sampled from production, double or triple the variance, and write that range into the datasheet. Maybe it could happen, but it's very rare that you get a part anywhere near so bad that it's pushing into that extended range.Really sucks to design with discrete logic, I don't at all like that they did that. But that's accepted methodology, unfortunately. (Assuming I've correctly guessed the method of course; but, whatever it is, everyone does it, I mean, and the max is extremely pessimistic.)Tim

author: Kleinstein
author_rank: Super Contributor
timestamp: August 22, 2022, 07:07:36 am
content: The bus switches like SN74CB3T3384 would not do level conversion. They are more like CMOS switches. The short delay given there is just conduction though the already closed switch combined with capacitive loading. So it is not the time the swiches need to change state.The 6502 and similar old CPUs should likely be OK with TTL levels, as many of the old bus drivers were still TTL, at least at the time the CPUs were planed. Even with standard CMOS it usually only take 70% of VCC for a vaild high. 4.5 V is more like the high level that the 6502 can provide at it's outputs with a certain load.

author: pcprogrammer
author_rank: Super Contributor
timestamp: August 22, 2022, 08:33:48 am
content: Take a look at this project:https://github.com/bitfixer/bf-romulatorIt might answer all your questions.See a video about it:It is made for interfacing with old 6502 based 8 bit computers.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 22, 2022, 05:40:12 pm
content: Quote from: Kleinstein on August 22, 2022, 07:07:36 amWell, they claim to be level switchersBut on closer reading, you're right they wouldn't do. It looks as though they convert the outputs to Vcc, with any input from 1.1 to 5v being accepted. Unfortunately Vcc is 3.3v, which isn't exactly ideal.Given that you've now put me off the above , there are other possibilities...I do have 23 "high voltage" i/o pins, which can operate at 3.3v. I was initially planning on using them elsewhere, but needs must and all that: if I use those for the address pins (which are what I need to read to make the decision), then I could use something like aSN74LXCH8T245and get better timings because I'm now translating between 3.3v and 5v. That chip has maxima of 6.5 and 8.5ns for the two directions.These "high voltage" pins are, annoyingly, concentrated at the corners of the FPGA, and in groups of max-size 7, but whatyagonnado *shrug*.I'm still at 10ns in both directions really (assuming a 200MHz clock on the FPGA) but that's probably enough slack to do:Code:////////////////////////////////////////////////////////////////////////////// Sync a8clk to the FPGA clock using a 3-bit shift register to avoid// metastability due to the different clock rates////////////////////////////////////////////////////////////////////////////reg [2:0] clkDetect;always @(posedge clk)if (rst_n == 1'b0)clkDetect <= 3'b0;elseclkDetect <= {clkDetect[1:0], a8clk};////////////////////////////////////////////////////////////////////////////// We want to know about rising/falling edges to handle bus traffic timing////////////////////////////////////////////////////////////////////////////wire clkRising= (clkDetect[2:1]==2'b01);wire clkFalling= (clkDetect[2:1]==2'b10);////////////////////////////////////////////////////////////////////////////// This is the page-map we use to indicate the memory request is ours to// fulfill////////////////////////////////////////////////////////////////////////////reg[255:0] pageInUse;always @ (posedge clk)if (rst_n == 1'b0)beginbusState<= `BS_WAIT_FALLING_CLOCK;delay<= 5'h0;busData<= 8'b0;busAddr<= 16'h0;mpd_n<= 1'b1;extsel_n<= 1'b1;endelsebegincase (busState)// Everything is synced off the falling 8-bit clk, where// all the signals are reset`BS_WAIT_FALLING_CLOCK:begin// At the start of the clock cycle, reset thingsif (clkFalling)begindelay<= `BS_ADDR_VALID_DELAY;busState<= `BS_WAIT_READ_ADDR;mpd_n<= 1'b1;extsel_n<= 1'b1;endend// Wait for the address to stabilise on the bus`BS_WAIT_READ_ADDR:begindelay <= delay -1;if (delay == 6'h0)beginbusState<= `BS_HANDLE_MPD;endend// We've waited 180ns, sufficient for the address to be// stable on the bus, detect whether this address is one// of "our" pages and assert outgoing signals`BS_HANDLE_MPD:beginbusState<= `BS_WAIT_RISING_CLOCK;busAddr<= addr;mpd_n<= ~pageInUse[addr[15:8]];extsel_n<= ~pageInUse[addr[15:8]];end... further casesendcaseendWhich will give me something like:... when page 0xF3 is marked as being in-use by the external system. Assuming a 200 MHz clock in the FPGA, there's enough wiggle room there for /MPD and /EXTSEL to be asserted in timeQuote from: Kleinstein on August 22, 2022, 07:07:36 amThe 6502 was NMOS though, not CMOS - and I'm not familiar enough with the differences to know if that's importantGoogling to do, I guess. I've founda pdfof what seems to be an NMOS variant, which claims minimum logic high voltage of 2v, but it also has specs for a 4MHz 6502 (which uses 3.3v as minimum logic high on the clock signal) and that wasn't an option when the Atari came out IIRC, so this data sheet is probably a later model.Anyway, if I'm driving 5v, it's hopefully going to work

author: bson
author_rank: Unknown
timestamp: August 23, 2022, 09:15:17 pm
content: How does your circuit compare to the test circuit those numbers are for?CL=15pF and RL=2kΩ is pretty high load, chances are good you will present less load and get substantially faster transitions.The only way to really know is to create your own test circuit to reflect your intended use, and measure it yourself for your conditions.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 24, 2022, 04:02:36 pm
content: Yep, that's a good point. The circuit in question will probably be nowhere near that - it's a direct 1:1 connection about 4cm from chip to chip, with no other load on it. I'm waiting on a replacement PSU (mine blew something and it's sufficiently old that I'm good with replacing) and then I'll solder some test wires and link them up to the scope to see.