1. Home
  2. Field-Programmable Gate Arrays
  3. Disconnect the FPGA I/O pads from the outside world

Disconnect the FPGA I/O pads from the outside world

Hello all, What is the method to isolate a FPGA (XCV600E) from a bus. I am asking this because i observed starnge behaviour while trying it. I am working with a development board from ARM. In two buses are shared by a bus switch and an FPGA (XCV600E). Input to the bus switch (PI3C34X245B) is from the ARM chip which is under software control. And the output is connected to 'A' and 'B' buses. These 'A' and 'B' bus are connected to FPGA which outputs peripheral signals to these buses. In the initial configuration the bus switch was disabled so the 'A' and 'B' was used only for the peripheral control signals. To suit our rquirement we enabled the bus switch and connected the signals from the ARM to these buses and removed all occurance of these buses from the FPGA ( to free the bus fronm the peripheral siganls). Both buses were declared "inout" in the RTL. Assigned high impedance state to both buses. Thus both the buses are now used by the bus switches. But when output all '1' to these buses bit 12 and '0' of the bus A was permanently connected to zero and 'B' was working perfect. But when i changed the direction of 'A' bus in the FPGA to 'in' the problem with a vanished but bit 6 and 16 of 'B' bus was permannently connected to low. What could be the reason behind this starnge behaviour. When i repeated the test several times by varying the status of both buses to 'in' 'inout' 'out' etc each time different bits were found faulty. I am not able to give any logical reason to this strange behaviour. What is the best procedure to completly disconnect FPGA I/O pads from the external bus. If i delete the signal itself from the RTL of the FPGA will that help??? Sumesh

Reply to
vssumesh
Loading thread data ...

Sumesh, If you want to complete isolate the FPGA from the rest of the board for troubleshooting purposes, you should be able to hold the "program" pin low. This will tristate ALL of the FPGA signals.

An alternative method would be to instantiate the startup macro and use the "GTS" input to issue a global tristate to the part. This will disable ALL outputs from the FPGA. Of course, both of these methods remove all the FPGA functionality from your board, not just the bus interface.

As you suggested, deleting the bus from your RTL code should disable it as well. If it isn't there, it shouldn't drive the bus. The unkown here is whether your bus inputs are used in the code and therefore cause synthesis errors. You might try declaring the bus as "input" rather than IO. Without drivers, the FPGA would simply be sniffing the bus.

Pipjockey

Reply to
pipjockey

I wont be able to do the first two methods as it will disable all the output pins. I know that the third method is reasonable. But i am unable to explain the behaviour.

  1. I deleted all the connection to the 'A' and 'B' bus from the FPGA. But still some bits in the bus 'B' was missing. Then i connected the FPGA to the bus 'B' and assigned input status. Then bus 'B' started working but bus 'A' reported errors. How can it be possible. The same thing happend when i assigned input to both buses. If i go for bus 'B' bus 'A' gets corrupted and vice versa. If i assign input to both the buses still bus 'A' reported errors. And for your question i dleted all the driving of bus 'A' and 'B' from the RTL. Sumesh
Reply to
vssumesh

The same thing happend to me also. But now the constrains are correct.

Reply to
vssumesh

... sorry if i'm repeating myself :-) Design F/X Pin Assignment tracks IO standards as they change, allows for interface driven design and much more with real-time Xilinx FPGA DRC's. And it generates UCF files on demand to help address these kinds of issues. It's free for < 600 pins and can be downloaded from our website,

formatting link
- help file in the install directory. Have fun !

M.

Reply to
dfx

The problem which you report remembers me of an odd behavior I encountered with a previous design. It turned out that the top-level port mapping (VHDL design flow) didn't match the UCF file (my mistake). More precisely, I had a couple IOs in the port mapping which weren't declared in the UCF file (running PACE and uncheking the "Allowing Unmatched LOC Constraints" implementation option revealed the error).

The SW tools (AFAIR) connected these undeclared IOs into the first unused physical pad it found. It goes without saying that the design was then acting a bit strangely ;)

Reply to
Matthieu Michon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.