PLI based applications

By Reecha Jajodia, Anurag Jindal; Freescale Semiconductor

Introduction:

PLI is a mechanism for invoking C/C++ functions from Verilog code. It can be used for passing data across the verilog boundary, return a variety of information about different objects in design hierarchy, alter the value of objects in design hierarchy and also monitor the value changes of selected objects.

Applications aimed:

a) Analog monitors:

Problem:

During scan and other DFT modes we require to monitorthe input/output ports of certain analog IPs which are required to stay in particular determined state. Generally we need to dump big waveforms each time to monitor those.

Solution:

Using Analog monitor this can be done very easily. Here we will give module instance name as an input to the PLI application. It will find its hierarchy in the design and will dump the values of all its ports in an xls (golden_values).If any port toggle it will report toggle else will report the constant value. User can review the xls and fill with expected constant value against the port name. Next time when user runs the simulation then this sheet will act as a golden reference and will dump another xls highlighting the mismatched between expected an simulation values. So no need to dump big waveforms to monitor signals of analog IP. Suppose we want to monitor whether a signal at analog IP interface toggled ore not during test set-up, load-unload,shift or capture then it can easily be done using this as for can scan-test it will highlight the states attained separately for test-setup ,load-unload, shift and capture.

b) Digital monitors:

Problem:

With increasing design size and time and area crunch it is becomes difficult to dump bigwaveform files(.trn) files to observe signals.

 

Solution:

 

The Digital monitor(similar to Analog monitor) can help us to observe signals at interface of Digital IPS. It will dump the values (along with the time stamp[optional]) of ports of desired modules (whose instance name is given) in an xls format which can be used instead of using waveforms. Also can be reviewed and filled with golden expected data which will act as reference for successive simulations and will flash error if mismatch occurs. So will act as self checking test.

c) Clock monitors:

Problem:

Currently for verification of clock waveform DFT/Verification team writes dedicated testcases and dump waveform(.trn) to view different clock frequencies, their relationship and alignment(especially for scan capture clocks).

Solution:

PLI clock monitors can enable self checking test cases. Here we just need to draw waveform in some format (xls) with proper frequency relationship and alignment and give it as an input to the PLI clock monitor. This monitor will fetch values of desired clocks from the simulation, check its frequency and alignment with that mentioned in xls and report a mismatch if there. There is no need for the user to open waveform (trn) and check for clock frequencies and alignment.

d) Power analysis estimator:

Problem:

Currently for calculating maximum power consumption we estimate the maximum toggling time window of the pattern and cut the vcd of that area and deliver it is to backend team. We never have a full proof confirmation that the time window of the pattern which we consider has maximum power consumption is really the one which we aim to analyze.

Solution:

This PLI application can actually find the time window in which maximum toggling of design occur. It can monitor the activity on each flop and design unit and can report in which time window did maximum toggling of design occurred. So this can give us a deterministic way of calculating power analysis window. We can cut the vcd of this time window on which backend analysis can be carried on.

e) Memory fault injection:

Problem:

Currently for verification of algorithms and diagnostic feature of various MBIST solutions we inject the faults statically on certain location (we generally force wrong values on memory data/output lines and compare against correct values) .This limits us as some faults might be missed which might be caught if can inject faults randomly anywhere.

Solution:

Since PLI enables us to force desired values on verilog objects so using this we can randomly dynamically inject faults on to memory cells during simulation. This can help us to exhaustively use all features of algorithms and can also be used to catch corner cases faults which might be missed in earlier case.

f) Debug PLI:

Problem:

Generally debugging scan patterns is a tedious and time consuming task. The user has to trace the chain one by one from scan out pin.

Solution:

The debug PLI can be used to automate the debug of scan patterns (specially the chain tests).It can automatically strobe and tell which flop in the chain has failed.

Advantages of PLI based approach

• Faster method, Area and Resource Benefits:

Adopting PLI based application for different usage we can effectively save on time and area both. Since it will access data during simulation and give results so there is no need to dump long waveform dumps and vcds to observe results which take a lot of time to get dumped and also occupy lots of disk space. Also since these applications will generate output in form of .xls or some text file so no need of lsf resources and time to open and analyze wave dumps which will be save both machine resources plus user’s time and affords.

• User friendly interface for results:

As PLI will display results in xls or txt format and will highlight mismatches between expected and observed results so it provides highly friendly user interface.

• Ease of usage of PLI based application

Using PLI in verilog/WGL or any simulation environment is very easy. We just need to include the respective PLI along the required arguments in the run command launched to the simulation tool (like Irun).Also need to just put the input files required in the desired directories. The application will run and dump results in expected format.

Detailed Explanation of working and usage of Analog IP monitor:

Flowchart:

Working:

a) This monitor will require the input as whether we are running on scan testcase or non-scan testcase. Accordingly it will behave.

b) Initially when user has no data then he will run with STAGE1 argument. Here he is supposed to give an xls as an input containing instance names of modules whose values he requires to monitor. The PLI will find the hierarchy of the instance and prepare a golden_values sheet containing names and values of all ports of mentioned module instance.

For example if user runs a non-scan test case with STAGE1 argument.

Required input: module.xls containing list of desired module instances.

Output Generated: golden_values.xls containing list of ports of all module instances present in above xls along with values it attained during simulation.

Here when it writes ‘toggle’ against test_mode_0 it means that this signal toggled during simulation ie attained ‘0’ or ‘1’ and was not at constant value. The signals which had constant values during simulation have the attained value besides it.

Here there is an optional feature that can be used.

Also we might want to monitor the values only if certain condition holds true. For example: there might be few signals a,b,c in the design and we might want to monitor only when a.b+c=1.Then we can mention it with argument +COND. So monitoring of data will occur only when the above condition holds true.

The user can review the sheet and the fill desired values against all ports which will act as a golden value. Also if the user doesn’t want to monitor a particular port’s value it can mark an ’-’ against it so that next time it not monitored. Suppose the new modified sheet looks like this.

 

Suppose user did not want to monitor few signals so he wrote ‘-‘ ‘against those. Also he found after reviewing that ADC1/Test_mode should be 0 and DAC1/test_mode_1 should be 0 during entire simulation so he makes corresponding changes in this sheet. Now this sheet will act as input and golden reference for next stage of simulation.

c) Next when the user runs with STAGE2 argument the above golden sheet will act as a reference. The PLI will check the values during simulation and will give the result in compared_values.xls as shown below.

 

 

Output Generated: compared_values.xls which compares the values in golden sheet against those attained during simulation.

 

It will highlight where-ever a mismatch occurs between golden and simulation values.

 

Also suppose in next simulation run if some new version of IP comes with some new port then it will highlight that also.

d) For scan test case the PLI will monitor independently for test-setup, load-unload, shift and capture stages and dump in xls, the way it is explained above. Here also we need to run 1^st with STAGE1 argument where it will prepare golden_values.xls and then with STAGE2 argument where it will compare simulation values and display results. Similar to above it can use +COND arguments if required.

Benefit:

• It is easy to use .
• Easy to monitor results against monitoring in big wave dumps (which we currently do).
• Easy to review analog IPs values with AMS team as we have golden sheet dumped in xls format.
• Self check as displays mismatch.
• Very friendly user interface.

Summary:

The above data is obtained from actual simulation. The application development is do-able and in progress.