5v Fpga Hypothetical Question

[pacmann]

VCCO max for Spartan 6 is 3.75v. What exactly happens if the Fpga is run at 4v or 4.5v for example , to make it compatible with 5v cmos levels? Assuming the Fpga isnt doing anything high speed, is it a thermal problem? Is it shortened life problem because of transistors breaking down? I dont recommend this to try, only wondering what happens..

[Mario87]

Something will likely fail short circuit within the device if run at 5V as the insulation breaks down. This may happen immediately or slowly over time, but regardless, it's not something I would try. If you need to communicate to devices which use 5V CMOS levels then just use a level shifter to go between the 3.3V of the FPGA and 5V of the device. Safer and much more predictable as to what will happen both long and short term.

[SiliconWizard]

Most often, 3.3V logic in CMOS processes supports something like 3.9V as an absolute maximum.

What will happen if you exceed this is oxide breakdown. Transistors's characteristics deteriorate. The higher the "overvoltage" and the shorter this process will take, until complete dysfunction.

I have seen some reliability studies for typical CMOS processes that would show a typical lifetime reduction of several orders of magnitude when powering 3.3V logic @ 1 V to 2 V above the absolute maximum rating. That's definitely not very pretty.

[langwadt]

Most often, 3.3V logic in CMOS processes supports something like 3.9V as an absolute maximum.

What will happen if you exceed this is oxide breakdown. Transistors's characteristics deteriorate. The higher the "overvoltage" and the shorter this process will take, until complete dysfunction.

I have seen some reliability studies for typical CMOS processes that would show a typical lifetime reduction of several orders of magnitude when powering 3.3V logic @ 1 V to 2 V above the absolute maximum rating. That's definitely not very pretty.

some Xilinx FPGAs turn off the supply to the output transistors if the Vcco goes above ~2.9V on outputs  configured
as LVDS because those transistors can't even handle 3.3V

[David Hess]

Over time, hot carriers generated in the channel from the higher electric field damage the interface and gate oxide altering the drain current,  threshold voltage, and transconductance, so there is a gradual deterioration of the device characteristics. 

A high electric field across the gate oxide damages it over time increasing the threshold voltage and gate leakage.  Eventually the gate oxide suffers catastrophic breakdown.

I suspect these effects are exponential with respect to the applied voltage so for example an increase of 50 millivolts might halve the operating life.

[pacmann]

Over time, hot carriers generated in the channel from the higher electric field damage the interface and gate oxide altering the drain current,  threshold voltage, and transconductance, so there is a gradual deterioration of the device characteristics. 

A high electric field across the gate oxide damages it over time increasing the threshold voltage and gate leakage.  Eventually the gate oxide suffers catastrophic breakdown.

I suspect these effects are exponential with respect to the applied voltage so for example an increase of 50 millivolts might halve the operating life.

This was what I was wondering thanks. How are 5v transistors built differently to handle more voltage? Thicker oxide? Larger transistors? Does feature size make a difference?

[Berni]

This was what I was wondering thanks. How are 5v transistors built differently to handle more voltage? Thicker oxide? Larger transistors? Does feature size make a difference?

Yep bigger transistors can handle more voltage because you need more voltage to generate the same strength of electric field inside of it. It's the strength of the electric field that is the limiting factor of the material. Insulators hold on to the electrons in the atoms, this is why they don't conduct since the electrons can't move. But once the electric field becomes strong enough it can overpower those forces that keep the electron confined to the atom, ripping it off and letting it whizz off, carrying current. Those electrons can help knock other electrons off, making it even more conductive, deteriorating the material until it breaks down completely and arcs trough.

In practice the limiting factor for voltage in chips tends to be more the ESD protection circuitry. The protection is mostly in the form on zenner diodes placed on all the pins, they start conducting once the voltage on a pin becomes too high, clamping down the voltage to prevent it from reaching levels that could fry the transistors. So as you slowly increase the voltage out of spec these ESD protection diodes will start passing more and more current, at some point passing so much current that the chip becomes too hot to operate. If it gets too hot it might permanently destroy the chip (Doping diffuses out of the transistor and they die, or the ESD diodes blow up and short out the pins)

You can probably get a chip to fail more spectacularly on the transistor level by overvolting a Vcore rail. Those tend to only be about 0.8 to 1.5V so zenner ESD protection is typicaly not sharp enough to catch it. More core voltage tends to make a chip run faster (hency why this is used in overclocking), but also consume a lot more power, so with very big chips you might again run into overheating before the actual transistors fail. Typically modern x86 CPUs will either reduce its clock speed due to overheating or the chip just falls on its face and crashes at some point (transistor go too far out of spec), but taking overvolting way too far can permanently fry a CPU.

[Zero999]

The practical solutions to the original question are to: 1) Use all 3.3V logic (preffered). 2) Add level shifters between 3.3V and 5V logic.

[David Hess]

This was what I was wondering thanks. How are 5v transistors built differently to handle more voltage? Thicker oxide? Larger transistors? Does feature size make a difference?

Transistors built for lower voltage have a thinner gate oxide, shorter channel length, and different doping.

[SpacedCowboy]

Unless it's an ICE40HX ?

Note: it's very possible he just hasn't experienced the breakdown effect yet, although I'm kind of amazed that pushing 20v through an FPGA pin doesn't release the magic smoke *immediately*...

[David Hess]

This was what I was wondering thanks. How are 5v transistors built differently to handle more voltage? Thicker oxide? Larger transistors? Does feature size make a difference?

For higher voltages, the transistors are constructed to limit the electric field stresses which usually includes a thicker gate oxide and longer channel length but material changes also have an effect.

As far as failures, occasionally it happens where a design accidentally uses transistors above their rated voltage leading to failures months to years later:

https://en.wikipedia.org/wiki/Intel_Atom#Issues

[pacmann]

Unless it's an ICE40HX ?

Note: it's very possible he just hasn't experienced the breakdown effect yet, although I'm kind of amazed that pushing 20v through an FPGA pin doesn't release the magic smoke *immediately*...

20 v is shocking!

This was what I was wondering thanks. How are 5v transistors built differently to handle more voltage? Thicker oxide? Larger transistors? Does feature size make a difference?

For higher voltages, the transistors are constructed to limit the electric field stresses which usually includes a thicker gate oxide and longer channel length but material changes also have an effect.

As far as failures, occasionally it happens where a design accidentally uses transistors above their rated voltage leading to failures months to years later:

https://en.wikipedia.org/wiki/Intel_Atom#Issues

Wonder if some how intel was able to work around it with firmware or only new silicon

[Berni]

Unless it's an ICE40HX ?

Note: it's very possible he just hasn't experienced the breakdown effect yet, although I'm kind of amazed that pushing 20v through an FPGA pin doesn't release the magic smoke *immediately*...

This is very different once you put a resistor in series with the signal.

That series resistor limits the current and lets the ESD didoes inside the chip clamp down voltages to safe levels. So when you have a few KOhm in series you can actually send a 20V signal into most digital chips and they will handle it just fine. This is the reason i love to put series resistors on signals that go into external connectors where i have no idea what abuse might be shoved into them. It really makes the chip survive a lot more since especially on huge overloads of 100V leaves most of the voltage drop across the resistor, so that's where the heat gets dissipated. The physicaly large resistor can handle peak pulses much better than a tiny on die ESD diode. For when i want a really robust pin i still use an external ESD diode as they can handle way more energy, but just a simple resistor already goes a long way.

[asmi]

This is the reason i love to put series resistors on signals that go into external connectors where i have no idea what abuse might be shoved into them.

This also destroys any performance to speak of. Even a 200 Ohm series resistor will kill edges faster than 2-3 ns at 5pF line capacitance and 3-4 ns at 10pF. Anything larger will make situation even worse.

[SpacedCowboy]

Hmm. This is interesting - I've always regarded data sheets to be universal truth from on high, but what you seem to be saying is that if I have a slow bus (~2MHz, maybe as high as 10MHz), I could put series resistors on those 5v lines, and then feed it directly into a VCCIO=3.3v FPGA like the HX series ?

What about driving signals ? Presumably if the i/o is configured as open-drain (or pseudo-open-drain, where you configure the pad as an input instead of driving anything) with an external pull-up to +5v, that would work. I can't find the phrase "open drain" in the ice40 data-sheet, but there is of course an output-enable on the pad...

At the sort of speeds I'm looking at, that might be feasible, and it'd save me on 2x 16-bit level shifters and 7x 1-bit level shifters plus all the associated direction-pins ...

[David Hess]

Hmm. This is interesting - I've always regarded data sheets to be universal truth from on high, but what you seem to be saying is that if I have a slow bus (~2MHz, maybe as high as 10MHz), I could put series resistors on those 5v lines, and then feed it directly into a VCCIO=3.3v FPGA like the HX series ?

The bus frequency is less important than the edge rate.  Adding source termination limits the frequency but also adds considerable delay even at low frequencies.

Wonder if some how intel was able to work around it with firmware or only new silicon

There were a lot of product recalls and replacements.

[SpacedCowboy]

The bus frequency is less important than the edge rate.  Adding source termination limits the frequency but also adds considerable delay even at low frequencies.

Well, the busses in question are the 68k (at ~8MHz) and 6502 (at ~1.7MHz) - Given that some of this is 40-years-old hardware, I'll be grateful if they're not sinusoids...

It's probably safer to leave things as they are - my eyes just lit up at the opportunity to get rid of the need for 11 direction pins... That's a lot of pin real-estate when you've only got 60-odd to start with...

[james_s]

I've used resistors as a crude form of level shifting when interfacing FPGAs to old 5V hardware, I never had a problem with it. If I were designing a commercial product I'd use proper level shifting but the resistors worked for prototyping. YMMV.

[Berni]

This is the reason i love to put series resistors on signals that go into external connectors where i have no idea what abuse might be shoved into them.

This also destroys any performance to speak of. Even a 200 Ohm series resistor will kill edges faster than 2-3 ns at 5pF line capacitance and 3-4 ns at 10pF. Anything larger will make situation even worse.

Not all things are high speed. Sometimes you just have a simple voltage input from some sort of level sensor, encoder, end switch etc... Yet you might have a 12V or 24V power source. In those cases one should assume that eventually someone will touch the wrong two wires together and send power into such an input. In a lot of cases the slowed down slewrate is actually a nice thing since you tend to want to filter out some of the high frequency noise or glitches.

But even small amounts of resistance can help a chip survive. For example you often see 20 ohm series resistors on USB lines that are there to help match the impedance of the cable to the driver and help reduce reflections and ringing. Yet at the same time this 20 Ohm can actually help save a USB pin from destruction when it comes in contact with the 5V supply voltage. You still get a lot of current flow but at least its limited in current to help the ESD handle it rather than dumping in the whole 1A that a USB port might be able to supply.

I don't tend to use the trick for actual level shifting, more just as as edge case for handling huge overloads. Its not hard to get 5V tolerant FPGA/CPLDs so might as well use them. Tho indeed transmitting data out is more tricky. If the stuff is TTL input then a 3.3V counts as a logic 1 anyway. If its CMOS then the only option is indeed to have pullups to 5V and then drive the pin like its open collector. The issue is that the value of the pullup resistor determines the rise time and its not going to be all that fast, but it might work on a memory bus if its not clocked too high and there is a low amount of capacitance. Too slow rise times can coax weird metastable bugs in digital chips, so id just get a octal buffer chip to give it a proper 5V drive.

[pacmann]

The bus frequency is less important than the edge rate.  Adding source termination limits the frequency but also adds considerable delay even at low frequencies.

Well, the busses in question are the 68k (at ~8MHz) and 6502 (at ~1.7MHz) - Given that some of this is 40-years-old hardware, I'll be grateful if they're not sinusoids...

It's probably safer to leave things as they are - my eyes just lit up at the opportunity to get rid of the need for 11 direction pins... That's a lot of pin real-estate when you've only got 60-odd to start with...

This is interesting as its common to want to connect a 5v chip like this to a Fpga. Out of interest why so many direction pins if only the data bus changes direction? I havent tried but wonder if auto direction level shifters as TXB0108 will work for something like this to save direction pins. Has any one had success?

[dolbeau]

This is interesting as its common to want to connect a 5v chip like this to a Fpga. Out of interest why so many direction pins if only the data bus changes direction? I havent tried but wonder if auto direction level shifters as TXB0108 will work for something like this to save direction pins. Has any one had success?

Having done that from my SBusFPGA project, I can point you to the thread were I received a lot of help: Suitability of/alternative to TXS0108EPW for 5V <-> 3V3 level shifting @ 25 MHz. I did not go with the chip in the title, but with a set of SN74CB3T16211DGGR (mostly) instead. They don't go all the way to 5V for output so are only suitable for TTL 5V (where the 'high' is at only 2 / 2.7 V, so 3.3V is enough), not for CMOS 5V (which requires 3.5 / 4.95V for high); the 74CB3T just clamp at 3.3V from my 5V TTL SBus to the FPGA, and let the signal through at 3.3V the other way - which is enough for my use case.

An issue with a lot of the 'true' level-shifters was the delay they introduced; for a design that need to do a round trip at 25 MHz (40 ns), having several ns of delay each way can become a problem (I also have fairly lengthy traces from the bus connector to the FPGA daughter-board connector). But if you need 'true' 5V CMOS, then you will probably need such 'true' level shifters.

[SpacedCowboy]

The bus frequency is less important than the edge rate.  Adding source termination limits the frequency but also adds considerable delay even at low frequencies.

Well, the busses in question are the 68k (at ~8MHz) and 6502 (at ~1.7MHz) - Given that some of this is 40-years-old hardware, I'll be grateful if they're not sinusoids...

It's probably safer to leave things as they are - my eyes just lit up at the opportunity to get rid of the need for 11 direction pins... That's a lot of pin real-estate when you've only got 60-odd to start with...

This is interesting as its common to want to connect a 5v chip like this to a Fpga. Out of interest why so many direction pins if only the data bus changes direction? I havent tried but wonder if auto direction level shifters as TXB0108 will work for something like this to save direction pins. Has any one had success?

Well, in my case it's not just the data-bus that's changing direction

The DECA board for $37 has resurrected an old pet project that fell by the wayside a while back, to add standardized "expansion slots" to old computers via their exposed bus signals. I'm going to start with the Atari XL/XE line, but it seems to me that the ST could work just as well using its cartridge port, and the C64 seems like a good candidate too. I know nothing about the Amiga internals, but maybe that too..

The idea is to monitor the A,D,control signals, and to provide a couple of general capabilities

• Provide "memory apertures" which allow banking in of external RAM (I was originally going for 8MB of SDRAM, but now it's 512 MB of DDR3!) on a page-by-page basis. Define a memory-descriptor which the host can write to, consisting of page-start, page-stop, DDR-offset and take over the bus to return the correct value from DDR if an access is made there. An extension of this would add 'stride', x,y,w,h and allow off-screen bitmaps to be easily manipulated from the host
• Monitoring the bus will let me detect (apart from perhaps the Amiga with its FastRam) the accesses the computer makes to draw the screen, and I was planning on making a dumb frame buffer (or handing off to an STM32H7) but then BrianHG helped out Nockieboy with an 8-bit GPU and now the plan is to render to a 16-bit frame buffer using Brian's DDR controller and output over the HDMI on the DECA board. I'll also be able to offer high-resolution, full-color graphics to old computers as-standard, it's impressive how many filled ellipses nockieboy's z80 is throwing around the screen, and MAGGIEs could be useful for the hardware sprites that older systems had in them

Given the first of those above, I can provide memory-mapped access to expansion slots - I'm planning on 4 or 6 of them at the moment, probably using RP2040's essentially as intelligent bi-directional io-expanders-with-buffers because they're so damn cheap. The idea is that the card in the slot (probably using PCIe x1 for physical hardware) will talk over SPI or maybe even UART (or both, basically interfaces that every modern microcontroller has) to the RP2040(s) which will then talk to the FPGA over a far faster bus. It's possible I might allow "bus masters" so slots can talk to each other without involving the FPGA, but probably not. Once the data is in the FPGA, it's accessible to the host via a memory aperture for the slot.

It also means I can expose the other devices on the DECA card (SD-card for "hard drive", Ethernet, USB) as built-in "slots" in the same manner. Once ethernet is working, it'd be possible to have 'virtual' slots, which connect to a socket on the network and you can run a program on a server which provides a 'peripheral' to the host.

Anyway, to (finally, sorry) answer your question... To take over the bus and even possibly DMA directly into the host computer's internal RAM, there's several other signals that I want to control, which let me /HALT the processor on demand or signal a bogus /REFresh command. About the only signal I've not found a possible use for controlling is the host computer CLK

I've had bad experience at work with the auto-level changers - I'm not an EE, I'm an aging physicist-cum-software-engineer, but I worked with EE's for several years in Platform Architecture, which is basically prototyping and none of them had nice things to say about the auto-level changers. Things like inadequate drive strength, signals not being pulled to where you want them to go, and speed etc.

I figured it was easier, especially with old hardware - none of this new-fangled CMOS stuff, we're NMOS baby, and we like it that way - to have the variants with power on both sides and a dedicated direction pin. I don't mind wasting the company's money on experiments but I'm a lot more persnickety about my own [grin]

[BrianHG]

• Monitoring the bus will let me detect (apart from perhaps the Amiga with its FastRam) the accesses the computer makes to draw the screen, and I was planning on making a dumb frame buffer (or handing off to an STM32H7) but then BrianHG helped out Nockieboy with an 8-bit GPU and now the plan is to render to a 16-bit frame buffer using Brian's DDR controller and output over the HDMI on the DECA board. I'll also be able to offer high-resolution, full-color graphics to old computers as-standard, it's impressive how many filled ellipses nockieboy's z80 is throwing around the screen, and MAGGIEs could be useful for the hardware sprites that older systems had in them

My example on the DECA board throwing out those random ellipses is 32bit color, not 16bit, and it is still fast enough to run an Amiga ZorroIII 32 bit interface directly into an A3000/A4000 at the same time, never mind the 16bit ZorroI/II of a normal 7MHz 68000 Amiga.  It will do all that and provide a HardDrive through the DECA's SD-Flash card which will run circles around anything else as you can sustain something like >800 megabytes a second to the onboard DDR3 if you design things smart, or almost 1400 megabytes a second with large sequential bursts.  (Running my DDR3 controller at 400MHz)  Just use the same bidirectional CMOS 3.3v-5v 245 level translators which Nockieboy is using right now for the Z80 interface.   The FPGA IO will control the Direction pin on the 245s.  Also use the newer open-drain CMOS ic recommended in the thread to drive open-collector signals like bus !wait/!hold/!reset/!req lines.

Both Nockieboy's and my GPU code currently has the GPU memory pointer controls limited to 20bit, so 1 megabyte.  But this was originally designed for a 6K gate, -8 Altera FPGA.  The Max10 board has a 50K gate -6 FPGA.  Upgrading everything to 32bit pointers for 4GB access and adding audio would be next on Nockieboy's GPU thread once he gets the ram connected.

The GPU fill/draw/blitter copy rate is fixed at 100 million pixels a second regardless of the display being 8bit, 16bit, or 32 bit color.  The difference is how many hardware full screen translucency layers you want running at once which will eat the majority of the bandwidth if you are running resolutions like 1080p at 60Hz.

If you want 200million pixel fill per second, you can always add a second geometry unit, or add 4.  Though, there wont be a mechanism to decide who draws first and which pixels will end up on-top when some objects will have the same destination pixels.

[SpacedCowboy]

Oh! I don't think I was sufficiently clear - I wasn't trying to say that the design would in any way be limited by the GPU side of things. As I said, I know nothing of the inner workings of the Amiga, and having just briefly read up on it, it seems I had it the wrong way around anyway. The "fast-ram" is targeted at the CPU not the chipset, which presumably means that spying on the chipset accesses ought to be fine - I *had* thought it was the chipset that had the fast access, and thus I wouldn't know what was being shown on-screen  

On the 8-bit computers, it's easy. Every access (by "GPU" or CPU) runs over the system bus - monitor A[15:0] and D[7:0], some logic to look for 'important' registers in case someone changes a color-register in an HBLANK for example, a bit of pixel-shifting, and you're done.

On the ST, there's just no port that exposes the entire address bus without going into the box unless you limit yourself to the Mega-STE and TT, so it'd be a new VDI driver that implemented GEM VDI calls as writes to registers in cartridge-space. The same could be done for the Amiga with a Zorro-x interface of course.

[All of this is a bit hypothetical until I get Quartus up and running well...]

[Shadowfire]

On the Amiga, the processor bus sees none of the CHIP memory transactions that it didn't itself initiate from its opcode stream (i.e. it doesn't see anything Agnus is doing with its DMA channels).  You can see the reads and writes to CHIP ram from the processor, but there is write-DMA (blitter, floppy) going on behind your back in that area.

This is only problematic if you're trying to keep track of CHIP memory, though.  AmigaDOS already has functionality for marking all of CHIP ram as non-cacheable.

Any accelerator boards would probably also do the same in hardware, as you only have two ways to get around this: you either somehow snoop the chip RAM bus coming off of agnus (requires an interposer socket(s)), or you re-implement enough of Agnus's DMA channels and Copper (because the Copper can also configure and initiate blits, although it typically isn't used for this) to know when something has been written to a memory location and mark that cache line as invalid (you can see the processor setting up the DMA transfers by snooping the processor bus).

As far as your project is concerned, you would probably just pass the bus requests through to the system untouched except performing address translation when accessing the expansion memory.  The Amiga has OS support for expansions cards (called Autoconfig, in some ways its like  a predecessor to PCI-express), but systems like the Atari and C-64 do not and mucking around with the memory maps on these systems is likely to break software.

[SpacedCowboy]

I think it'll work fine on the Atari 8-bit, the external hardware will be under software control (and be invisible if the software doesn't enable it). I'm not using any addresses normally accessible without hardware being added (there's a couple of pages dedicated to external h/w on the XL/XE). As for writing into the 8-bit's memory, all Atari 8-bits already halt the processor when Antic (the "gpu") wants control of the bus - there's a signal dedicated to that (/HALT). I'll have control of that signal too, and as long as I time my accesses to not conflict with Antic, the 6502 won't even know anything has happened. Memory is active however (because Antic needs to read RAM to draw the screen), it's just the 6502 in pause-mode.

I'm less sure about the C64, but have yet to look into it in any great detail. On the ST, everything will be memory-mapped into the cartridge space, so I'm not foreseeing too many problems there.

[TomS_]

Hmm. This is interesting - I've always regarded data sheets to be universal truth from on high, but what you seem to be saying is that if I have a slow bus (~2MHz, maybe as high as 10MHz), I could put series resistors on those 5v lines, and then feed it directly into a VCCIO=3.3v FPGA like the HX series ?

Only if the FPGA has built in over voltage protection. Check the datasheet.

e.g. some Altera CPLDs contain internal zener diodes that make some IO pins tolerant of higher voltage by using an external series resistors. But others don't, and the datasheet explicitly says that the user has to place external zener diodes if they want to work with higher voltages.

Depending on how many signals you need to interface with, lots of external components could end up taking up more board space than some level shifters.