Soft failures (?) 9536XL

I have a small circuit using the 9536XL CPLD. The complete machine uses

64 of such circuits. I have tested it on the lab and everything works just fine.

The problem is the other day, while at the client premises, I saw something wrong with one of the boards. The CPLD stopped responding to the commands sent by the computer. As I had no test equipment available, I just tried to send some reset commands to the board and get no response. I turned power off to change the board, but just before replacing it I gave it another try. To my surprise, everything worked fine this time. I did some intensive testing to the board, and again everything went OK.

To me, it looks like the CPLD lost its configuration. Is this at all possible ? If so, what can I do to prevent this from happening ? Anybody seen something like this before ?

NB - it is a 2 layer board (no GND plane) about 3 sq inches.

Thank you for your time.

Josep Duran

Reply to
Josep Duran
Loading thread data ...

The XC9536XL is a Flash-based CPLD. Different from an SRAM-based FPGA, you do not reconfigure it just by cycling Vcc. The CPLD would need a fresh in-system programming operation, which is not automatic nor happens by accident. So, what might have happened is that your design got into an illegal state, out of which it cannot excape, but which did not affect the configuration.

A more far-fetched explanati>

Reply to
Peter Alfke

configuration.

Correct - Check if you have any state machines, and what they do from illegal states.

You can sometimes find this hidden in the fine print, in the appx form of "Vcc must be reduced to < 0.9V before being increased again'. Systems that are prone to brown-out and non monotonic Vcc are more risky in this area.

If you have the resource room, you can add read-back or similar 'check-it-actually-happened' to the PLD code, and have your system watch for any out-to-lunch behaviour.

-jg

Reply to
jim granville

Did you analyze your design for nominal conditions or worst case operating conditions?

I have seen boards fail when the got warm after being closed up (or after a friend sets their engineering notebook on top of the box and it heated up a little).

This happened to a board that I was interfacing to. Problem went away after we drilled larger vent holes in the product. I guess that is what you get when you get a product that is still in beta testing.

Cheers, Jim

Josep Duran wrote:

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

Souds like you have asynchronous circuit in your design. I saw many times your troubles in the past using CPLD andor FPGA. Every times these troubles became from kinds of asynchronous circuit or conception. When running asynchronous circuit, temperature can be affect your design, sometimes or sometimes not.

First, make sure you synchronize all your input signals, before to use it !!! Make sure your design DONT use comb. latch !

Regards, Laurent

formatting link

Josep Duran wrote:

Reply to
Amontec Team, Laurent Gauch

Thank you Peter,

"Peter Alfke" escribió en el mensaje news: snipped-for-privacy@xilinx.com...

Yes. That part I understand.

configuration.

This was my first thought, I double checked the state machine, and I don´t think there is a problem there.

This is the part I am actually concerned. Could a noisy or poorly decoupled Vcc be the source of the problems. How far-fetched explanation is this ? Is it really possible ?

If I read the configuration through the JTAG port, do I get the internal-actual-RAM configuration, or the Flash configuration ?

Or should I be looking for a bad solder point or other more mechanical explanation ?

Josep Duran

Reply to
Josep Duran

Illegal states have to do with combinations of your state FFs that are not accounted for in your machine. Or if you have more than one machine and have not accounted for all the state combinations you can get into trouble. Sometimes two machines interact in a way that they need to be considered one machine. Make sure you have a bubble in your state diagram that cooresponds to every possible state encoding, then there are no "illegal" states. Also account for all combinations of inputs at every state.

Yes, noise on the Vcc can cause trouble for any design that has volital storage, state machine or not. Your state FFs can be corrupted by noise on Vcc.

Reply to
Ralph Malph

Your problem reminds me of a problem I had a while ago. The FPGA locked up just your CPLD was doing. By digging a bit, I found that ISE had implemented my state machines as one-hot so I thought that somehow the FSM had gone into an illegal state. Forcing the FSM to binary encoding reinforced my belief. To shorten the story, it turned out the FPGA wasn't really going into an illegal state: the problem was that there was poor signal integrity on the clock signal, which occasionally would have a double edge, causing the bit in the one-hot encoding to be lost. You might want to check out the clock after looking at the Vcc.

Reply to
Pascal Chamberland

If you have clock glitch problems, and cannot resolve them by proper attention to board-level signal integrity methods ( which you should! ), then there is always a band-aid method to make the problem vanish. A few years ago, I published a way to suppress clock glitches, which has saved several designs alreay:

http://www.xil>

Reply to
Peter Alfke

Hi, What I've done in the past is this. Get your noisy clock into the FPGA, call it CLKA. Feed it through spare unbonded IOBs with the input delay feature turned on to make a delayed version, CLKB. Make the delay longer than the glitch time by using as many IOB delays as necessary. Now make two signals, SET attention to board-level signal integrity methods ( which you should! ),

Reply to
Symon

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.