PinPort
Application: Legacy IP Migration
The
Challenge
You are
tasked with migrating the functionality of an existing (legacy)
part into an FPGA or an ASIC. This may be because the supplier
is discontinuing production and you are still actively manufacturing
systems containing the part. Because you don't know for certain
how many of the parts are necessary for future production needs,
you don't know how many to stockpile. Alternatively, you may
be designing the next generation of the system and want to reuse
the functionality of the part. You are integrating the functionality
of the part with that of others into a single chip to reduce
the cost and improve the reliability.
You have
a working part and need to come up with a synthesizable description
that is verified to be functionally equivalent to the existing
part. The data sheet describing the part contains barely enough
information to use the part, let alone recreate the exact functionality
in RTL. Relying on the data sheet is sure to leave many holes
in the design that won't be discovered until the recovered IP
is used in the system.
The
Approach
By using
PinPort, the behavior of the RTL can be compared to that of the
actual part on a cycle by cycle basis.
Prepare
the Part
The approach
is to mount the part on an adapter board and insert the adaptor
board into a PinPort device. The PinPort device is connected
to a workstation through a SCSI interface. A Verilog logic simulator
running on the workstation communicates with the part through
the PinPort programming interface (a collection of Verilog PLI
calls). A Verilog wrapper module presents the pin interface of
the part to the test bench and communicates signal changes between
the testbench and the part by making PLI calls.
Create
the Testbench
The data
sheet is used as a starting point for creating the testbench.
The testbench is run against the actual part. It is refined and
added to until the part is thoroughly exercised with the actual
response to each test case observed and verified by the testbench.
This same testbench will be run against the RTL representation
of the part that is being recovered (i.e. reverse-engineered).
It is best if the testbench is setup to drive multiple instances
of the module in parallel, with seperate checker modules for
each instance. It's even better if the testbench has a comparator
capability to automatically compare the outputs of instances
against one another at each cycle.
Write
the RTL
Using
the knowledge you gained crafting the testbench, you begin expressing
the functionality of the part in RTL. When you have questions
about the operation of the part under certain circumstances,
you extend the testbench, observe the actual behavior and reflect
this in the RTL that is being created. Once you have a sufficient
amount of functionality implemented, you apply the testbench
to the RTL module and begin running test cases. When test cases
fail, you use the interactive debugging capabilities of the simulator
to understand why and then modify the RTL accordingly. This process
is repeated iteratively, until you feel the RTL is complete.
Ensure
Equivalence
As a final
test of the equivalence of the RTL to the actual part, you should
run the RTL module and the wrapper module in parallel. If the
testbench has been constructed for this, the behavior of the
RTL module is automatically compared to the wrapper module at
each clock cycle of each test case. Once all the tests cases
pass when the testbench is run against the RTL module, you have
successfully recovered and verified the IP for the part. At this
point you proceed on to system simulation and/or synthesis.
The
Result
This application
of PinPort provides a systematic process for delivering IP that
is 100% functionally equivalent to the real part. The iterative
nature of the process allows the easy measuring of progress and
the early detection of problems. |
