Design verificattion in FPGA

[Deepika]

Hi all,

I am working on FPGA and I am using chipscope to verify my designs. In this case I will set the input test patterns and I will verify the corresponding output. But the problem with this method is that, it is time consuming.

So, I am searching for techniques to automate the verification in FPGA. Can you please tell me the options available  to automate the verification and their pros and cons.


Thanks

[pix3l]

I think most brand specific IDE's should have some option to simulate the synthesized logic (in other words after place & route). This is not actually an answer to your question directly but it might help 

[tggzzz]

I am working on FPGA and I am using chipscope to verify my designs. In this case I will set the input test patterns and I will verify the corresponding output. But the problem with this method is that, it is time consuming.

In general testing takes at least as long as design, usually longer. That's true for any technology.

So, I am searching for techniques to automate the verification in FPGA. Can you please tell me the options available  to automate the verification and their pros and cons.

It sounds like you want a generic piece tool to automatically understand what your design ought to be doing. If that was possible then that generic tool could also do the design.

You need to understand the concepts of "test driven design" (TDD) and "test benches".

[rstofer]

Some years back I was messing around with designing the ALU for a PDP11.  I came up with a very convoluted method of testing that worked like this:  The FPGA had a long SPI shift register that received arguments and op codes.  It also returned results.  I used an AD Blackfin board to send the test vectors which it grabbed from an NFS server running on my Linux box.  That actually worked a lot better than it sounds because the test vectors could be written in English (sort of) and the desired results were already known.

Now, that scheme worked well and it was certainly fast but it seems a little like overkill.  Still, the idea of stuffing test vectors and retrieving results via a long SPI shift register seems useful.  It's not unlike what JTAG was intended to do.  I have often thought about implementing JTAG around the outside of logic modules but, really, my SPI method worked very well.

These days I suppose I could use the Integrated Logic Analyzer in the Xilinx Vivado toolchain but I'm not sure that would serve exactly the same purpose.  In my case, I knew the logic would do something, all I wanted to check were the boundary conditions.

[legacy]

Some years back I was messing around with designing the ALU for a PDP11.  I came up with a very convoluted method of testing that worked like this:  The FPGA had a long SPI shift register that received arguments and op codes.  It also returned results.  I used an AD Blackfin board to send the test vectors which it grabbed from an NFS server running on my Linux box.

in order to test mathematical algorithms
e.g. the complex exponential, the CORDIC, the DSP engine, etc
I am using my debug engine in a similar way

in your case you used a piece of hardware already implemented
the SPI shift register (it's the one used in the jtag block, ain'it?)

in my case the debug engine is itself a piece of VHDL code, which has been longly tested
before of taking place "as trusted tool" in the step of being reused to test other code

it talks to the host, it gets testing vectors and it sends back results 
on the host the application can compare "expected" with "actual" and fill a "test report"

there is entropy in my approach because I am testing my own code with my own made tool
in the theory: not good, in the practice: it helps, good!

[rstofer]

in your case you used a piece of hardware already implemented
the SPI shift register (it's the one used in the jtag block, ain'it?)

I don't recall all of the details but I probably bit-banged the SPI on the Blackfin due to the odd length of the operands and operator registers.  It was probably one long string of bits including 2 16 bit operands, the initial flags, the operator, the 16 bit result and the result flags.  Pretty long as I recall.

Bit banging SPI is quite easy so that is the approach I took and that's why I used the Blackfin in the middle.  I'm still not clever enough to do the work strictly inside the Linux box with some kind of bit banging between the PC and the FPGA.  But I did know how to program the Blackfin and connect to a network server.

I wouldn't have any idea how to use JTAG on the FPGA end unless I brought all the signals to the pins.  I hadn't thought to do that.  Hm...