Comprehensive Verification of

MIPI SoundWireSM Master-Slave

Subsystem Using UVM-Based Test

Suite Authors: Parul Raj, Synopsys, Inc. and Qingxin

Meng, Analog Devices

Presented by: Jitendra Kushwaha, Synopsys, Inc.

Agenda • MIPI SoundWire – An Introduction •  SoundWire Test Suite Architecture •  Verification Challenges and their solutions •  Additional feature testing •  Conclusions

2

MIPI SOUNDWIRE An Introduction

3

Key Features and Benefits •  Key features

•  Two-pin dual-data rate multi-drop bus for audio applications (1.2 or 1.8V)

•  Robustness and Scalability (one clock and multiple lanes) •  Low power, low latency, well-bounded (PHY and transport) •  Support for multiple streams, formats (PCM/PDM/non-audio), modes

(isoc/async/bulk) •  Embedded control and commands •  In-band interrupts/wakes, support for low-power, jack detection during

clock stop

•  Benefits •  New use cases not possible with existing interfaces (I2S, SLIMbus®,

HDAudio) •  New system topologies across mobile and mobile-influenced industries •  Lower gate count allows for integration in cost-sensitive devices

4

Example Topology and Frame

5

Applica'onProcessor

ADC(PDM)

DAC(192Khz)

DAC(96Khz)

DAC(48Khz)

ClockData

DAC(PDM)

DAC(PDM)

Single frame consists on various audio traffic in both direction!!!

Synopsys SoundWire Test Suite Architecture

6

VERIFICATION Challenges and Solutions

7

Complexity of Scale •  Challenges

•  Up to 11 slaves •  Up to 14 data port, 1~8

channels •  Highly flexible

environment needed to allow for all types of connections

•  Solutions •  svt_mipi_soundwire_lin

k_descriptor to define Source to Sink connections

•  Device to Device command scoreboard

•  Port to Port Payload Scoreboard

8

Command Scoreboard

9

•  Scoreboard Infrastructure

•  Command scoreboard

•  Device to Device connection

Payload Scoreboard

10

•  Scoreboard Infrastructure

•  Payload scoreboard

•  Port to Port connection

Configurability •  Challenges

•  Each data port can operate at different audio frequency and format •  All data ports need to be multiplexed within one frame with no

overlapping payload

•  Solutions •  Source to sink connections can easily be configured using link

descriptor class •  All sequences in SoundWire VIP are capable of multiplexing both

SIMPLIFIED and FULL ports in a single frame

11

Example Code for Link Configuration

12

case(link.sink_port_number) `SVT_MIPI_SOUNDWIRE_CONFIGURE_LINKS(0,svt_mipi_soundwire_configuration::FULL_PORT, 0, 8'h01, 1, 8, 0, sample_rate_real) // For Master and Slave DUT `SVT_MIPI_SOUNDWIRE_CONFIGURE_LINKS(3,svt_mipi_soundwire_configuration::FULL_PORT, 1, 8'h0f, 32, 32, 1, sample_rate_real) // For Master and Slave DUT `SVT_MIPI_SOUNDWIRE_CONFIGURE_LINKS(4,svt_mipi_soundwire_configuration::FULL_PORT, 1, 8'h0f, 1, 1, 1, sample_rate_real) // For Master and Slave DUT endcase

`define SVT_MIPI_SOUNDWIRE_CONFIGURE_LINKS(port_num, port_type, fix_channel_en, max_channel_en, min_word_length, max_word_length, flow_capability, local_sample_rate = 0, flow_mode = 0, bg_ctrl = 0, data_mode = 0) \ port_num: begin \ link.payload_data_port = port_type; \ link.enable_fixed_channels = fix_channel_en; \ link.max_channels = max_channel_en; \ link.min_sample_word_length = min_word_length; \ link.max_sample_word_length = max_word_length; \ link.async_flow_mode_capability = flow_capability; \ link.sample_rate = local_sample_rate; \ end

Debug Ability •  Challenge

•  With increasing number of data ports, it’s hard to trace the data for debugging

•  Most of the information about the processes going on within the system comes from debug messages

•  Solutions •  Log Files •  Trace Files •  Wave files •  Protocol Analyzer

13

Debug Options – Output Logs • Gives a good idea about the processes going on

14

Debug Options – Trace Files •  SoundWire command and payload transactions

15

Debug Options – Wave Files •  Activities going on the phy layer and software layer

both are tracked

16

Protocol Analyzer Support

17

Additional Feature Testing •  Special scenarios such as combination of hard and soft

reset one after another in single simulation created using directed tests and sequences

18

485 10.02 11.37 10.695

2070 89.98 88.11 89.045

TESTCASE FUNCCOV CODECOV TOTALCOV

VIPTEST&CORNERTESTcornertest testsuit

CONCLUSION

19

Coverage and Regression Results •  Time for setup and first test run – approximately 8 hours •  Time for 90% coverage – 2.5months •  Complete coverage within 5 months

20

0

20

40

60

80

100

120

9/2/15 10/2/15 11/2/15 12/2/15 1/2/16

coverage

Funccov Codecov Totalcov

0

20

40

60

80

100

120

0

500

1000

1500

2000

2500

3000

9/2/15

9/9/15

9/16/15

9/23/15

9/30/15

10/7/15

10/14/15

10/21/15

10/28/15

11/4/15

11/11/15

11/18/15

11/25/15

12/2/15

12/9/15

12/16/15

12/23/15

12/30/15

1/6/16

1/13/16

regressionresultwithrespecttonumberoftests

Fail Pass Funccov Codecov Totalcov

Specification Coverage •  Coverage figure as per Verification plans which are

mapped to SoundWire Specification

21

SecBonofSpecificaBon Coverage

6.FrameStructureandControlWord

100%

7.FrameSynchroniza'on 100%

8.SystemControl 100%

9.Commands 100%

10.Registers 100%

11.Interrupts 100%

12.PayloadTransport 100%

Bugs Found and Fixed •  Number of test cases and issues found

22

Block BugsFound SimulaBonsRun Testcases

SoundWire 20+ 2555 99(60testsuite;39cornertests)