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

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

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.

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

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.

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 :)

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

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

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

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

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

Thanks for the tip :)