A system for debugging logic chips in-circuit automatically

In a previous entry I introduced an FPGA shield giving 64 bits of bidirectional 5v tolerant IO to a spartan 6. In this entry I will actually make it do something useful and show you how to get one. This post is also sponsored by PCBway.

Device in-circuit testing a 74S04, one pin unhooked to simulate a failed gate on the LEDs and the propagation delay as measured by the FPGA is shown on the scope

This project is intended to allow for the in-circuit testing of 74xx and 40xx style logic chips. We do that by sampling all the pins of a given chip (inputs and outputs) and compare the behavior of the real chip to one that we model in verilog. This lets the circuit operate normally, wiggling the input pins and we can track those changes and compare them to the chip’s output pins. From this we can get an idea of whether a chip is bad, but the chip under test is not necessarily causing the issue, it’s possible that something on the same net as the output pin is interfering with the signal. Hopefully I’ll be able to build up a series of models and clip right on to a running system to get an idea of whether there’s any reason to desolder and check a given chip out of circuit. Let’s walk through this repository one file at a time. First is the pin definitions file for this project.

At the top we have the clock pin which has a 50Mhz oscillator on it, the reset button, and some pins for interface with the onboard LEDs. The SPI and Serial aren’t used in this project, but they are on the mojo main board, so they’re here in case you wat to utilize them in the future. My additional pins start with the data_bit bus.

At the end we have what this project calls debug_bits, but as far as the silkscreen is concerned those are just data_bits 56-63. The enable_bits are needed to turn each 8-bit level shifter individually, if you need to save I/O you can wire them to always on or always off, but our purposes we just turn them all on.

There’s not a lot going on here in the top level verilog file. In the top module declaration I have added a couple things at the bottom that default from the default mojo project. The enable, data, and debug bits are all that’s needed for this board. Below that we invert the reset button signal and set the SPI pins to unused. Then we have to enable all the level shifters, I did this by setting the bits to 0 and then inverting them. This syntax expands to as many bits as you need to set high. Below that we have the high speed clock and dcm module that gets set up in the ISE to get our 50Mhz clock all the way up to 200Mhz. This will help with finer detection of the propagation delay of these chips. Finally we pass the relevant signals into our chip checker module. We’re using the 200Mhz clock to sample the pins, we have the reset signal passed in so we can zero out any latched checks, we have all the pins of the chip we’re checking passed in, and the LEDs to tell us if something’s wrong and the debug pins to help us quantify what’s wrong.

The clocking wizard in the ISE is where I got my 50Mhz clocked sped up to 200Mhz, it’s not a text file but it’s still pretty easy to use. We turned off all the functions that weren’t needed and just have a simple high speed clock out.

The chip checker is nice and modular for ease of expanding in the future. It mostly exists to hook up our chip simulator, the comparator, and our counter/latch. The first thing we do is take the pins that we’re measuring going into our real 74s04 and run them into our model of a 7404, the output data from that model then gets run into the comparator as well as our sampling clock and the actual pins coming from our measured chip. The output from this model is a signal that represents a discrepancy between the model and the actual chip. In the case of a good chip that represents the propagation delay, for a bad chip that would differ from the correct signal for quite some more time than a few clock cycles. That difference signal is fed into the counter function that counts up and if any one of the channels is consistently off by more than a few clock cycles in a row it latches a flag output. Those flags are wired to the LEDs on the mojo board. The debug pins are assigned to the difference signals so we can see exactly how much the signal from our real chip differs from the model.

I don’t know what you were expecting for this model, but this is it. This represents the single simplest chip we could test.

The comparison isn’t complicated, but it’s a good example of a parameterized module. We have defined this one to have a default bus width of 1, but our use case overrides that and calls for 6 of them to be operating in parallel. The registers are all defined with a dynamic width, and every clock we latch in the values to our registers. Then, combiationally, we do a simple XOR of the expected signal with the detected signal to create our difference signal that is high only when the chip does not match our model. I will say it again here, that does not mean it’s broken, it may just have a longer propagation delay than 1 clock cycle.

This is the last and most annoying module (syntactically). We pass in 2 parameters, the width of the count like we did with the compare and the threshold where the flags are set for an error. Everything here happens on a clock pulse, even though it contains some loops. I assume that the ISE unrolls those loops for laying out the chip so it can all be done at once. Inside the always block we have a named begin, it seems that to have variables like a temporary variable for counting in a for loop you need to have a named begin/end block. We then handle the reset condition where all of the counters and all the flags are reset to an initial state of zero. If we’re not holding the reset button then we run through all the channels we’re checking and if it hasn’t hit the threshold yet we check to see if we should either add to the count for that channel or zero it out again. If we should add to it then it’s possible that in doing so we have hit the threshold so we check that inside the same check, but because this is all happening at the same time we have to check using the non-updated states of the variables. That’s why we check “if ((counter[i] + 1) >= THRESHOLD)” even after doing “counter[i] <= (counter[i] + 1);”.

That is all there is to it, when we count up more than the threshold number of differing states in a row we latch that LED on until it’s reset. This allows us to have a device that can be clipped on to chips in rapid succession and test for deviation from the expected behavior without having to remove the chip from the circuit and exhaustively exercise it ourselves. In this situation we do not end up testing certain aspects of the chip if they’re not being exercised but that’s alright as those functions may not be used in that application or something upstream may be broken and thus not exercising those pins. For different chips the threshold will likely have to be changed, the 74S04 we tested passed with a threshold of 3 cycles at 200Mhz, a 74LS04 would likely fail that strict of a threshold, a 7404 almost certainly would. Right now to test each different type and speed of chip requires pushing new code down to the device, but as a proof of concept this works quite well. I hope to continue enhancing this with extra functionality going forward.

To purchase one of these boards for yourself without any work on your part you can go to my project on PCBway’s website. From there you can view the BOM I put together for this as well as buy the boards straight from them. If you want to make some modifications or adapt the design to your own, more modern FPGA board I have the kicad 7 files up on my github here.