Verifying Performance of a HDL design block

1. Verifying Performance of a HDL design block Chhavi Patni Maninder Singh

2. Agenda • Objective • Performance parameters • Application Scenario 1 • Bus Probes • Application Scenario 2 • Conclusions

3. Objective • Verification and Analysis of performance parameters of a Design Block • Data Bandwidth • Latency • Efficiency • Pipeline • Protocol specific parameters • Bus interface plugs requirement DUV

4. Performance Parameters • Bandwidth : • Rate of data transfer. Usually specified as KB/s, MB/s or Mb/s. • Theoretical maximum bandwidth = (Data width) x (Bus Freq.) • Actual Bandwidth = Amount of data transferred / Total clock cycles • Example: • Clock Freq: 200 MHz , Data Bus: 4 bytes • Theoretical Max Bandwidth = 200 x 4 = 800 MB/s • Efficiency : • number of clock cycles transferring data divided by the total number of clock cycles. Clock cycles transferring data x 100 Efficiency (%) = Total Clock cycles

5. Performance Parameters cont. • Latency Requirements : • Requests should be granted within certain cycles • Request to response latency. • Pipeline Features: • Max. or Average Pending request transfers • Protocol specific parameters : • DDR Bus : bank BW analysis, ACT / PRECHARGE with no read/write cycles • Bus Interface plugs requirements : • Capable of accepting back to back requests. • Capable of providing back to back responses.

6. Application Scenario 1 • Cache IP Functional Specifications : • Bandwidth Supported : • Allegro streams : Max / AvgBW (MB/s) = 809 / 487 • DVD streams : Max / AvgBW (MB/s) = 474 / 245 • Efficiency : • Reduction in number of Memory accesses = 30% • Other requirements : • request can be read every clock cycle • data can be sent by IP every clock cycle

7. Verification Environment Verification Environment Reference Model checker checker Target BFM Initiator BFM Cache IP Bus Probe

8. Bus Probe • Internal tool - Bus probes – on STBus, AXI, DDR3 • "Probes" are transaction monitors, that observe the transitions of RTL signals, recognize transactions and record them in a transaction database • Purpose : • Monitor for Bus protocol compliance. • Provides all transactions for scoreboarding/checking. • Provides summary of transaction types along with start and end time for analysis. • Provides latency, bandwidth figures.

9. Bus Probe • Non-intrusive probing of the simulation • A probing file defines each probe and the paths of the signals to monitor • Usage : • Static Mode: • Need vcd/ shm database of simulation. • Dynamic Mode: • Reports generated on the fly during simulation run. Axi_probe <probe_name> .data_size(_value_of_attribute_data_size_) .*("_common_path_and_signal_root_*_suffix_") …….. OR Axi_probe <probe_name> .data_size((_value_of_attribute_data_size_) .AWVALID(“testbench.awvalid") .AWREADY(CONSTANT(1)) …………

10. Bus Probe Output • Example Output :

11. Application Scenario 2 • DDR Traffic Sequencer SoC Traffic Sequencer RTL BFM BFM Sequencer Architecture Model #N #3 Memory #2 Traffic Generator #1 Model BW, η, Latency RTL BW, η, Latency Bus Probe

12. Conclusions • Performance Verification of IP • Performance Analysis of architecture models • RTL v/s Architecture Model Comparison • Tuning third Party IP for maximum performance

14. DDR Probe • Efficiency of the memory • Compute the percentage of the maximum available bandwidth that is actually used by the DDR. • global bandwidth, read / write bandwidth • bandwidth per bank, read bandwidth per bank, write bandwidth per bank • Bank access analysis • number of pages accessed in each bank (different row addresses) • number of ACT commands per bank • Bus turnarounds • Bus turnarounds between read transactions and write transactions, or the opposite. • Sub-optimal usage of the memory banks • ACT followed by a PRE on the same bank, without READ nor WRITE transactions • continuous use of a single bank (as the efficient usage of the ddr is based on alternate bank accesses)