Force a signal in the output of a logical gate: destructive?

[Altera_Forum]

Hi all! 

 I've got a question that seems rather stupid at first: what happens if I try to put a signal in the output of a FPGA logic?  Let me explain why this problem could happen: I have to create a design that will be able to work in an environement subject to intensive radiation. In my design, I've got to use some bidirectional port. So I was planing to use some logic to detect the needed state of the port (input or output) to drive the pad in output or input position.  The problem is that there is a slight possibility that because of some radiation, my logic get corrupted, and drive the port in output where it should be an input, or the oposite. In this case, an external component (in my case: a DSP or a SRAM module) would try to set a logical state to the output of the FPGA, resulting in an electrical conflict.  The logical error resulting is not that very important: in worst-case scenario, I could detect it, and reprogram the FPGA. But my main concern is about the electrical conflict: whill the FPGA burn? Is there some kind of protection? Maybe limit the output current or things like that? Because I really can't afford to loose the FPGA...  Thanks in advance for your answer,  Matthieu

[Altera_Forum]

--- Quote Start ---  But my main concern is about the electrical conflict: whill the FPGA burn? Is there some kind of protection? Maybe limit the output current or things like that? Because I really can't afford to loose the FPGA...   --- Quote End ---  Use a series current limiting resistor. For example, consider a 3.3V high driven onto one side of the resistor and a 0V low on the other. The current being drawn is then I = 3.3V/R. If you want to limit the current for the buffers either side of the resistor to say 5mA, then you need a resistor R = 3.3/5mA = 660-Ohms.   A 1k-Ohm series resistor will limit the current just fine.  Cheers, Dave

[Altera_Forum]

Thanks for your replie. 

 But I've got a SRAM behind the FPGA, so the loss of voltage caused by the R will weaken the signal, maybe to the point that the SRAM cannot decode it anymore, no?  When you mean that I can limit the current, does that mean that the FPGA can handle some "reverse" current without burning?  By the way, i've got an other question. Is it possible to make a modified IO buffer so it act like this: -> You can set the direction (input or output) -> You can disable the output if in output mode (so, in output mode, it becomes a tristate gate)? Because when I see the block diagram of the output pad of the FPGA (ug_low_level.pdf), I really have the impression that it's possible. But the primitiv ALT_IOBUF seems to activate the input when it put the output buffer in high impedance.

[Altera_Forum]

--- Quote Start ---   But I've got a SRAM behind the FPGA, so the loss of voltage caused by the R will weaken the signal, maybe to the point that the SRAM cannot decode it anymore, no?   --- Quote End ---    The SRAM input will be high-impedance (it won't draw much current), so worst-case the resistor will form an RC circuit with the pin capacitance of the SRAM pad/pin, and you'll get a slower clock rate.    --- Quote Start ---   When you mean that I can limit the current, does that mean that the FPGA can handle some "reverse" current without burning?   --- Quote End ---    FPGA pins can source or sink current, eg., they can turn on an LED by either driving current through it, or sinking current to ground. So, as long as you keep your pin source/sink currents within specification, you are ok.    --- Quote Start ---   By the way, i've got an other question. Is it possible to make a modified IO buffer so it act like this: -> You can set the direction (input or output) -> You can disable the output if in output mode (so, in output mode, it becomes a tristate gate)?   --- Quote End ---    Sure. Just create a tri-state;   data_pin <= (others => 'Z') when (data_oe = '0') else data_out;    You can always read the state of the pin via data_pin, and you will only ever drive the data_pin bus when data_oe is '1'. You just need to figure out what the logic you require for data_oe is.  Cheers, Dave

[Altera_Forum]

There are some really good books on VHDL and Verilog that show how to do this, as well as many other basic functions. I recommend Ashenden's VHDL book and Thomas & Moorby's Verilog text, depending on which HDL you are using. Viirtually all FPGA I/Os have a tri-state function. 

 As Dave (above) indicates, there really isn't a good reason to have the I/O of your device in the wrong state - that's why we use programmable logic.   Enjoy the learning process - FPGAs can be really fun to work with.

[Altera_Forum]

Thank you very much for your help. 

 I'll have some reading for the next days then :p  I know it's not a good idea to have a port in the wrong direction, but the problem is that I can't have control over SEU (single event upset caused by charged particle in space). In the meanwhile, I've minimized as much as possible the weak spot of my design (I mean the place where a SEU can operate and the cause an electrical conflict).  Again, thanks a lot :)

[Altera_Forum]

--- Quote Start ---   I know it's not a good idea to have a port in the wrong direction, but the problem is that I can't have control over SEU (single event upset caused by charged particle in space). In the meanwhile, I've minimized as much as possible the weak spot of my design (I mean the place where a SEU can operate and the cause an electrical conflict).   --- Quote End ---  Space applications either use radiation hardened devices, and/or a combination of redundant circuits, i.e., multiple instances of the same logic are implemented in the device and 'voting' logic determines the majority answer, and that majority drives the output-enable or whatever.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Space applications either use radiation hardened devices, and/or a combination of redundant circuits, i.e., multiple instances of the same logic are implemented in the device and 'voting' logic determines the majority answer, and that majority drives the output-enable or whatever.  Cheers, Dave  --- Quote End ---    In fact my work's graduate is just about that: creating a complete TMR system, including the voter. But there is still a point where you have to put your 3 entries together. When data travel in one direction, I use a three state buffer controlled by a voting logic to disable a path if there is a problem in it. (See Xilinx application note 197)  But when I use a bi directional port, there is two signals that must drive the tree state buffer: the voting logic, and the signal that says if the port is in input or output. Which means I have to AND that two signals. And if there is a SEU just at this AND gate, I can have problems.  If I was able to put two three states buffer in serie, there will be no problem, but it's impossible in the FPGA... And rad hard external three-state buffer are way too slow.

[Altera_Forum]

I've got an other question. 

 I've got an error: Pin "name" is stuck at GND. In my design, and in normal operation, this pin will be all the time at GND. But If there is a SEU at a bad place, there is a possibility it goes high, so it is usefull (because the purpose of this pin is to detect the SEU...)  My question is: is the program implement exactly the schematics, or does it detect this "error", and the do some optimization?  I've got an other warning just after saying that this pin does not drive any logic, so I'm a bit afraid that the system removed for optimization purpose this part of my design...  If yes, is it possible to force it to implement my design exactly? (I'm currently using the schematic editor to implement my design...)

[Altera_Forum]

--- Quote Start ---   I've got an error: Pin "name" is stuck at GND.   --- Quote End ---    You'll get that for logic like;  my_output <= '0';  I do that for unused outputs, and then ignore the warning.    --- Quote Start ---   In my design, and in normal operation, this pin will be all the time at GND. But If there is a SEU at a bad place, there is a possibility it goes high, so it is usefull (because the purpose of this pin is to detect the SEU...)  My question is: is the program implement exactly the schematics, or does it detect this "error", and the do some optimization?   --- Quote End ---    I suspect it will optimize the logic and delete it.    --- Quote Start ---   I've got an other warning just after saying that this pin does not drive any logic, so I'm a bit afraid that the system removed for optimization purpose this part of my design...   --- Quote End ---    Sounds like it.    --- Quote Start ---   If yes, is it possible to force it to implement my design exactly? (I'm currently using the schematic editor to implement my design...)  --- Quote End ---    How about;  You have two pins; my_input and my_output.   my_output <= '0';   will generate the FPGA driven low value  my_input can be physically tied to my_output on the PCB (use two BGA pads that are right next to each other). Drive the my_input signal to your voting logic.  If you get a SEU in the my_output or my_input path, you'll detect it.  Cheers, Dave

[Altera_Forum]

That's a very good idea! I will try to do that :) 

 Thanks for the tip :)