Adoption of MIPI standards is accelerating, making design verification and interoperability critically important. In this presentation, Ross Nelson of Protocol Insight discusses effective verification processes to test the physical, link and application layers and the complete system, focusing on debug, stress/corner case testing and conformance/interoperability verification. This presentation also covers effective verification processes and the new MIPI Product Registry model.
Leading Mobile App Development Companies in India (2).pdf
MIPI DevCon 2016: Robust Debug and Conformance Verification Ensures Interoperability
1. Ross Nelson, Protocol Insight
MIPI JEDEC & UFSA Liaisons
Test & UniPro Working Groups
Robust Debug and
Conformance Verification
Ensures Interoperability
4. New Product
New Product Development Methodology
Prototype Debug and Verification Cycle
• Interoperability testing
• Conformance/compliance verification
• Stress and automated testing
• Margin and corner case testing
• Link/interface debug
• Power on/device bring-up
5. Typical Tx Setup
• Oscilloscope –
25GHz or higher
• Probes – N7020A
recommanded
• Switch matrix
automates lane
switching and test
Infiniium DSAV254A
25GHz Oscilloscope
2x6 (1x6 differenTal)
Switch Matrix
Keysight U3020AS26
7. Typical Protocol Setup
Protocol Insight
Test Executive™
• UniPro
• UFS
• Ara
Keysight Analyzer
• Up to HS-G3 x4
• UniPro/UFS
• Packet Generator
• SMA probing
8. Link/Interface Debug
Common Challenges
Customer Interactions Challenges Observed
Interop events (IOTs)
UniPro workshops
GoogleProject Ara
• Ara module initialization
• UFS boot
• Power Mode changes
• Capabilities exchange
• Link Startup Sequence
UniPro Example
9. UniPro Common Challenges
• Link Startup Sequence Phase 0 thru 4
• Invalid Packet Order or Sequence
• Timing violations
• LSS Capabilities Exchange
• Invalid Packet Order or Sequence
• Non-PACP_CAP packets on link
• Power Mode Change
• Invalid Packet Order or Sequence
• Device cannot change power modes reliably
• After multiple Power Mode changes device does not respond
11. Analyzing Link Traffic
State machine trace analysis
• Evaluate every packet in a trace
• Look for states and subsequent events
• Log messages and attributes
• Flag Failure, Warning, Pass, Info and Debug
13. Common LSS Phase 0 thru 4 Failures
• Invalid Packet Order or Sequence
• Timing violations
14. Common LSS Failures – Timing Violations
Time between TRG_UPR0 not ≥ 1.6ms
Reference UniPro v1.6 Table 28 PA_Granularity and PA_TAcFvate and SecFon 5.7.8.2, lines 1148 and 1154
The TAcTvate reset value is 1.6ms, and the device shall wait PA_TAcTvate before beginning a burst. Thus the Tme between
TRG_UPR shall be at least 1.6ms.
15. Common LSS Capabilities Exchange Failures
• Invalid Packet Order or Sequence
• Non-PACP_CAP packets on link
16. Common LSS Failures – Capabilities Exchange
Packets other than EOB, SOB, CAP found before exchange complete
Reference UniPro v1.6 SecFon 5.7.8.5
“Aeer finishing Phase 4 of the Link Startup Sequence, the PA Layer shall start a Burst on logical Lane #0 and transmits its
capabiliTes and the local version informaTon to the peer Device using PACP_CAP_EXT1_ind (see SecTon 5.7.7.4) and
PACP_CAP_ind (see SecTon 5.7.7.3) in this order.” Thus all other packets are not allowed to be sent.
1. Found EOB, transiToning to Phase 5
2. Found PACP_CAP_ind, with no EOB following
3. Found AFC TC1 before CAP Exchange finished init
4. Found AFC TC0 before CAP Exchange finished init
5. Found EOB, transiToning to DL iniTalizaTon
1
2
3 4 5
19. Common PMC Failures
• Invalid Packet Order or Sequence
• Device cannot change power modes reliably
(FAST/SLOW, AUTO/nonAUTO)
• After multiple Power Mode changes device does not
respond
20. Common PMC Failures – Packet Order
Packets other than deskew or another PACP_PWR_req sent while
waiting for the PACP_PWR_cnf
Reference UniPro v1.6 SecFon 5.7.12 Link ConfiguraFon Procedure
Other packets are not allowed to be sent between PACP_PWR_req and PACP_PWR_cnf
.
1 2 3
4
5
1. Found a PACP_PWR_req
2. No other packet besides deskew or another
PACP_PWR_req shall be sent while waiTng for the
PACP_PWR_cnf
3. Found another PACP_PWR_req
4. Found another PACP_PWR_req
5. The requestor shall not start a new burst unTl the
peer device closes its burst
6. PACP_PWR exchange finished
6
21. Margin and Corner Case Testing
• Inject corrupted bits on the link…
• Tx and Rx
• Mask test margin
• Eye width/height
• Unit interval
• Jitter
• Risetime/falltime
• Protocol
• Corrupt packet header/payload
• Invalid packet sequences
• Timing violations
• Timeout errors
then verify appropriate response
22. Example UniPro Error Injection Scripts
AFC Parameters
CRC -inverts CRC of AFC
CREQ_BIT -sets CReq Bit of AFC
RSVD_BITS -inverts reserved bits in AFC
INCR_SEQ_NUM -increases the sequence number in AFC by 1
DECR_SEQ_NUM -decreases the sequence number in AFC by 1
TC0 -replaces TC0 by TC1
SYMB -results in symbol error in AFC
DISP -results in disparity error in AFC
CREDIT -followed by 8 bit value in hex with which AFC is to
be replaced
REPLACE -followed by 3 bit value in hex with which AFC is to
be replaced
EXTRASYMBOL -results in extra symbol in AFC
PACP Parameters
CRC: -inverts CRC of PACP Frame
RSVD_BITS: -inverts Reserved bits of PACP Frame
FUNC_ID: -increases the funcTon id by 1 of PACP Frame
SYMB: -results in symbol error in PACP Frame
DISP: -results in disparity error in PACP Frame
SKIP: -results in not sending PACP_CAP_ind Frame
23. Stress and Automated Testing
• Corner case and margin testing
• Conformance and compliance
testing
• Random order sequencing,
traceable deterministic results
• Test loop management
24. Automated PHY Tx Testing
Stress and Conformance
Configure the Device
Under Test
(make sure proper data
rate are supported)
Select Tests.
Automatically generate
test report.
D-PHY Example
26. Automated Protocol Testing
Stress and Conformance
• Execute any loop order by Speed, Link
widths, or individual test cases
• Each category can be run ascending,
descending, or random seed order
• Stop after a specified number of test case
configuration loops, Warnings, Failures or
No Result Test Cases
UniPro Example
29. Signal Access and Design for Testability
• Board-level signal access
• SMA
• ZIF
• RTB
• Boot or reset signal access
• Automatic DUT Link Startup
Sequence
30. MIPI Product Registry
Testing Process
• New Membership benefit
launched August 2016.
• Allows MIPI Members to
showcase commitment to
conformance testing
• Important Documents:
• MIPI Test Policy
• MIPI Product Registry Program
Policy
• Specifications
• Conformance Test Suite (CTS)
• Method of Implementations
(MOI)
30
hlps://members.mipi.org/wg/All-Members/home/registry-faq
31. Conformance vs. Compliance
• MIPI differentiates between conformance and compliance
• Conformance means:
• An implementation on Product Registry, confirming it meets the normative
requirements of the relevant Specification
or
• a Member-company verified implementation adheres to a Specification’s
requirements
• Compliance implies that a formal evaluation has been made, e.g. as
part of a certification program, which serves as a guarantee of a
company’s right to enjoy applicable licenses.
32. Test Working Group
• Chartered to support
conformance and
interoperability activities
• Works with technical work
groups in development of
conformance testing
resources
• Developed the Product
Registry Program
• All Contributor or Board-level
Members may participate in
the Test Working Group
33. MIPI Product Registry
Testing Process
• Conformance Test Suites (CTS)
• Unique to each MIPI Specification.
• Authored by MIPI Specification Working
Group.
• Reviewed by MIPI Test Working Group.
• Outlines test procedures and requirements.
33
34. MIPI Product Registry
Testing Process
• Method of Implementation (MOI)
• Describes how to perform CTS using specific
Test Equipment
• Authored by Test Equipment Manufacturer
• Approved by Test Working Group
• Outlines how to perform testing
using specific test equipment
• Calibration
• Connecting DUT
• Automation
34
35. MIPI Product Registry
Testing Process
• Contributor Members may perform self testing or use a
MIPI approved test lab
• All products noted as self-tested or independently tested
• Adopter members must use a MIPI approved test lab
• Member provides results summary to MIPI Product
Registry Administrator
35
36. • Products are tested
• according to test procedures defined in current approved CTS
• Or using alternate test methodology if no CTS is available
• Products must pass all applicable tests in CTS
• If an implementation has optional features, it must also pass
those applicable tests
• Listing by similarity determined by the Administrator
and the Test WG
Product Listing Process
39. Summary
• Effective verification methods shorten
time to market by reducing prototype
spins
• Product registry showcases
implementations with a commitment to
interoperability
• Comprehensive tools for Debug,
Analysis, and Conformance are available