Broad question about ASIC

Discussion in 'General Electronics Chat' started by krnx2oh7, Aug 12, 2012.

  1. krnx2oh7

    Thread Starter New Member

    Jul 17, 2011
    For application specific ICs

    After you get the chip made and you have this IC...

    What equipment do you use to test inputs and outputs...I'm wondering how this is all done. I understand you use scripting and use hardware description language like verilog or vhdl. But how is this physically set up. Where do you hook up inputs, how do you hook up inputs and same for outputs. I assume you don't need a board with other circuit components hooked up to the ASIC as you designed it with everything needed within.

    From what I understand you have some scripted input file that you save and load to the asic and then read ouputs?

    I apologize if this is a broad question, but I want to at least know some basics over ASIC verification. Also please correct any of my incorrect assumptions.
  2. takao21203

    AAC Fanatic!

    Apr 28, 2012
    For this purpose sometimes JTAG interface is used.

    Some ARM controllers have it, 24F PICs / PIC32 have it I think,
    and it is used for most Freescale controllers.

    It is also present inside modern CPLD/FPGA.

    It is quite complex, not only used for programming (similar to ICSP), but also it has functionality to test chips in-circuit.
  3. WBahn


    Mar 31, 2012
    You are mixing a few concepts together. After an ASIC is fabbed, you have an IC just like any other IC. That IC has certain power, inputs, and outputs and you test it by applying power and some inputs and checking to see if the outputs are acceptable (i.e., meet spec), just like any other IC.

    There are several points in the process at which IC testing can take place (whether it be a commercial standard logic chip or an ASIC). The first is at the wafer level, after the processing is complete but before the wafer is diced into individual chips. To get signals into and out of the chip, wafer probes are used to make the physical connections to a given die's bond pads (which will eventually be connected to the IC's package pins). This let's you determine which die are bad so that they can be marked and discarded before more money is wasted on packaging them. Then, the wafer is diced and the part is packaged (or, it may be made available as loose die for things like COB (chip-on-board) applications (those blobs of epoxy you see on circuit board). Frequently, additional testing is done at the package level because there are limitations to wafer probing that may make it so that you still have bad die that weren't detected during wafer probing -- or perhaps no wafer probing was done.

    You remarked that an ASIC has everything it needs designed into it. This is almost never the case. An ASIC is designed to perform certain functions within a circuit but seldom is it possible to truly put everything into one chip, for a whole variety of reasons.

    The whole thing about making test files and using FPGAs and loading things to the ASIC are completely separate from the basic concept of IC testing (be it ASIC or something standard). The way to think of it is that every IC started life as an ASIC (or, more accurately, as a custom-designed IC). Some of those designs, say a RS-232 level shifter, simply take inputs and produce output. No memory, no configurations. How you test whether that IC is working depends on your testing capabilities. Perhaps you plug it into a solderless breadboard and plug in some wires from a power supply to provide the inputs and look at the outputs on a voltmeter. I've tested a number of ASIC designs where much of the initial testing was just that simple. If the chip passed those tests, then we would plug it into a board (either a custom PCB or just a wire-wrapped board that we had thrown together) so that we could feed it an input signal and look at the output signal on a scope.

    If the chip had memory (typically control registers) that had to be programmed, then there is some kind of a communications interface and protocol that has to be used to make that happen. For some of our chips, I could program them by plugging in wires to establish an address on a bus, stroke the address-write pin by momentarily grounding that pin, then establish the data on that same bus and stroke the data-write pin by momentarily grounding that pin. We had a customer that had spent thousands and thousands of dollars developing a custom test step that could be computer controlled and were claiming that the chip couldn't be programmed. I tried to get them to do the simple test I just described to see if they could program the LVDS output current level and common mode voltage. They insisted on using their test setup and continued to claim our chips weren't working. They finally sent one of their engineers halfway across the country in a rented car with all of their test equipment to us and while he was starting to set it all up I took their chips and, one-by-one, plugged them into a solderless bread board and programmed the LVDS current level using the technique I described and showed him that every chip was working fine (at least in terms of being able to program those registers). That convinced him that perhaps they had been a bit too quick to declare that their test system was fully checked out and before he left the next day he had identified numerous errors in their board and software. Meanwhile, I had thrown together a test system, all on a solderless breadboard, that let us verify that all the chips except one fully met spec. Now, that was in a day that signals were slow enough (for the stuff we did) that you could get away with that. Today you are less likely to be in that position. But you can still frequently get 'proof-of-life' confirmation for chips by looking at power supply voltage levels and current draws and checking bias voltages. If those aren't acceptable, there's little point going further (unless all of your chips fail the same way, but then your testing takes a decidedly different turn).
    krnx2oh7 likes this.