Unreactive Output Pins on Xilinx Virtex-II

Hi,

I have some trouble with the outputs of a Xilinx Virtex-II 1000 FPGA. The pins in question are conencted to a bi-directional data buffer, but a logic analyser tells me that the values are not changing every time they are supposed to.

The logic in the FPGA works as expected most of the time, but occasionally screws up.

Has anyone expeirenced this before, or shed light on the situation?

I've tried two different FPGA chips with the same result, my VHDL is not at fault...

Many thanks for your help, Robin University of Newcastle

Reply to
Robin.Emery
Loading thread data ...

Robin,

I'm curious, how do you know your VHDL is not at fault?

As two separate devices display the same behavior it appears likely the cause is your code or the test setup.

Have you ChipScope-ed your design to ensure that the internal signals going to those IOBs are indeed driven at the correct times?

Stephen

Reply to
Stephen Craven

The traditional debugging starts with a thermal test (hairdryer and cold spray), then change Vcc up and down, and then (if possible) change the main clock frequency up and down.

That should give you a feel for possible timing marginality.

If several chips behave the same bad way, the suspicion is on the VHDL side... Peter Alfke

Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Stephen,

Thank you for your reply.

I am "pretty sure" my VHDL is correct, because the FSMs in the design function correctly most of the time, and do not pre-empt the host computer on the other end of the parallel port I'm using, which the data buffer is connected to.

It is as though the latch and/or the IO pin does not respond to a change in an internal signal. From what I can see on the logic analyser, this problem sometimes persists for a long time, or until the board is reset.

Unfortunatly, I don't have access to ChipScope, so I cannot observe the internal signals.

I am at a loss to explain this behaviour, and of course I am open to accepting that my VHDL is incorrect with some evidence. I am not familiar with the ins and outs of the Virtex-II (or any FPGA really) so there may be some small detail of which I am unaware...

The exact problem I am having is that the output enable of the bi-directional buffer is not always set active when it should be. A FSM in the FPGA will then read what appears to be a non-driven input. I am happy that the test setup is OK, as the results I observe are consistent with the behaviour resulting from incorrect data on the data lines from the parallel port.

Have you observed similar behaviour on IO pins before?

Thanks, Robin University of Newcastle

Reply to
Robin Emery

Oh, and just to qualify what I said in the last post...

I am able to see which state the FSM is in on the logic analyser, and when the FSM moves from a state in which it will change the value of the output pin into the next, the signal does not change. There is no conditional expression or anything that would prevent it from changing the signal...

--------------

Peter, thank you for your suggestion. I'll see what I can do, but I too would expect incorrect VHDL. I am unable to find an error, however!

---------------

If you would like some more information, I'll happily post it.

Reply to
Robin Emery

Sometines when it looks like a flip-flop not changing, it actually changed twice, forard and then back. That could be the result of a glock glitch. A flip-flop can react to a 2-ns clock double-transition that are difficult to see on the scope. Peter Alfke

Reply to
Peter Alfke

Something simple like making sure you are probing the right pin ? Give it some simple code that toggles the pin, and verify you see that, and alias the expected OP onto some other pins, and see if _any_ change ?

-jg

Reply to
Jim Granville

You can evaluate ChipScope (full version) for free for 60 days without license. Just download it from the Xilinx website.

Good luck.

--
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
 Click to see the full signature
Reply to
Johan Bernspång

Did you simulate your VHDL description ? A functional simulation could shed some light on it, at least concerning functionality.

Rgds Andre

Reply to
ALuPin

Thank you all for your help.

I thought it might be helpful to post a quick conclusion...

With the use of ChipScope, we found that the problem was a timing error of sorts: an asynchronous (from the POV of the FPGA) control input from the parallel port was not synchronised in the design, resulting in a 1 in 10 failure rate (the rate was related to the CE input to some of the flip-flops). Adding this to the VHDL fixed the problem ;-)

Many thanks, Robin

Reply to
Robin Emery

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.