Scribd
Upload
50 views2 pages

Verification Plan

The document outlines a verification plan for the PRUTHVI EFUSE Controller over 1 week. It will use Verilog tasks to write and read data to an efuse macro model via JTAG and embedded memory interfaces. Testcases will validate data integrity on write/read and check for hangs under different conditions like asserting/deasserting factory mode or during initialization. A post processing script will compare the source and destination efuse data files.

Uploaded by

Rathnambiga Unnikrishnan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
50 views2 pages

Verification Plan

The document outlines a verification plan for the PRUTHVI EFUSE Controller over 1 week. It will use Verilog tasks to write and read data to an efuse macro model via JTAG and embedded memory interfaces. Testcases will validate data integrity on write/read and check for hangs under different conditions like asserting/deasserting factory mode or during initialization. A post processing script will compare the source and destination efuse data files.

Uploaded by

Rathnambiga Unnikrishnan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

PRUTHVI EFUSE Controller Verification plan:

Timeline: 1 week

ENVIRONMENT:
(1) JTAG Interface BFM:

2 Verilog tasks, viz.,

Jtag_efuse_write (efuse_location_addr, write_data);

This would read x8 bit data lines from text file (efuse_data_source.txt) one after another. This would
assert factory_mode and generate sys_* signals.

Jtag_efuse_read (efuse_location_addr, read_expected_data);

This would raise simulation error and stop simulation if read_expected_data is not same as data
received on sys_* interface

It is better if BALA provides the protocol on sys_* interface, because that way I can verify my
assumptions on this interface based on discussions we had.

No burst support.

(2) Efuse macro model:

This MUST NOT be our behavioural model. This has to be .verilog model provided by library. This
needs to be hooked up to the controller’s chip_fuse_* interface.

(3) Embedded memory efuse interface BFM:

This would sample serial data coming from fuse_mem_* interface of efuse controller one by one on
the source sync clock driven on this interface by efuse controller. Serial-to-parallel convert into 8-
bits (little-endian) and write them down into any text file (efuse_data_dest.txt).

(4) Post processing script:

This would compare efuse_data_source.txt and efuse_data_dest.txt and raise error into a log file.

TESTCASES:
(1) JTAG write read testcase
a. Assert factory_mode and write to efuse macro, read them back and check data
integrity
b. De-assert factory_mode, write and read efuse macro and check no effect but no
hang
(2) De-assert factory_mode, assert por_reset and init_start signals, wait for init_done. After
init_done, do post_processing to see if efuse_data_source.txt and efuse_data_dest.txt and
check for data equivalence.
(3) Combine JTAG write/read amidst loading and check JTAG interface does not hang

You might also like