Our customer designs System-on-Chips (SoC) for video processing applications. These chips are the asembly of blocks of intellectual property (IP). These IPs are designed in-house or purchased from third parties.

A full system is the work of multiple teams of engineers who care for a separate sub-system. A sub-system is a functionally coherent set of functionalities implemented with one or many IP blocks organized around a bus structure.

This customer has adopted the following methodology in his design flow: each IP and each 'functionally-coherent' subsystem in the design *MUST* be ported (or prototyped) onto a FPGA platform and functionally validated with a 'live hardware'in addition to the usual validation with simulation and other EDA tools.

The IP implemented in a FPGA is placed under test - that is: it receives a set of stimulus in order to verify its functional behaviour.

Once each block of IP is validated, they can be assembled together as the total system on chip into a FPGA (or an array of FPGA, together with other discrete components). The full prototyped system can then be validated as a whole.

Having a 'live' experience of each block of IP prior to validate the system as a whole helps eliminating many possible causes of failure when encountering a bug - and hence, helps reduce the total bug tracking time.

Customer's requirements

One IP of a new SoC was an image processing functionality. In the complete system, image data was received from an Ethernet network, read from the SoC processor and transmitted to the image processing IP through one the system busses. They had purchased the image processing block and needed to design some wrapper in order to connect it to the system bus. Before proceeding, this customer wanted to evaluate the performance and functionality of this third-party IP. As usual with a 3rd party IP, the customer did not know all the details of the implementation and did not have access to the source code of it.

So, to validate and evaluate this IP, this customers needed to:
- implement the IP into a FPGA of a standard FPGA board;
- stimulate the IP with relevant data (in this case, the stimulus was a set of 16 bits samples sent at a frequency between 60 MHz and 100 MHz - one sample per clock cycle);
- collect the output generated by the IP block;

One of the requirements was that he wanted to be able to generate the stimulus from a PC to be able to reuse data generated for a simulation tool. The output results from the IP should equally be recorded on a PC for subsequent comparison with a simulation.The customer wanted to reuse a logic analyzer he had in the lab to sample the IP outputs (mapped onto the I/Os of the FPGA connected to a debug connector).

Byte Paradigm's solution

GP-24100 used as a Digital Pattern Generator was used to generate the IP input stimulus. This device was chosen because of its ability to generate arbitrary 16-bits patterns at up to 100 MHz without gap, with a total pattern memory of 8 MByte (2 to 4 Msamples x 16 bits wide were ok for the customer). The ability to indifintely loop through the patterns was also used during the validation of the IP.

For the recording of the outputs, the customer used a bench-top logic analyzer. Since then, and with the new possibility of using more than one device from the same PC, this customer is considering using 2 GP-24100 devices is a similar case; one for stimulus generation and the other for recording the outputs of an IP.

Recommended products

- Wave Gen Xpress : 16 bits wide, 100 MHz max and 8 MByte internal memory - stimulus generation only.

- GP-22050 in ADWG / Digital Pattern Generator mode - same specs as WG Xpress;
- GP-24100 in ADWG / Digital Pattern Generator mode - 16 bits wide, 100 MHz max. and 8 MByte internal memory;

- GP-24116 and GP-24132 (coming soon): same specs as GP-24100 with 16 MByte and 32 MByte internal memory respectively.

GP-22050 and GP-24xxx devices can be used in logic analyzer mode of operation as well to record the outputs of a digital IP.