Interop Test Plan - LnK Tools · 2012. 5. 10. · 3.3.6. Data Channel Suppression! 51 3.3.7. Data...

SLIMbus®INTEROPERABILITY WORKSHOP

TEST PLAN

!

SLIMbus Interoperability Test Plan V0.90 -‐ 8 DEC 2010! 1

Table of Content

1. Introduction! 42. Design Maturity Verification Tests! 5

2.1. REPORT_PRESENT message validity! 62.2. Logical Address Assignment! 72.3. Logical Address Assignment Verification! 82.4. Guide Channel Tracking! 92.5. Guide Channel Generation! 102.6. Subframe Mode Change! 112.7. Clock Gear Change! 122.8. Stacking reconfigurations! 132.9. Reconfiguration Message Execution Order! 142.10. Aborted Reconfiguration Sequence! 152.11. Frame Sync Pattern Error! 162.12. Superframe Sync Pattern Error! 172.13. Message Sync Lost - UDEF! 18

3. Multi-Peripheral Setup! 193.1. Isochronous Transport Protocol! 20

3.1.1. Boot and Enumeration! 203.1.2. Data Channel Creation! 213.1.3. Add Sink Device to Active Data Channel! 233.1.4. Data Channel Reshuffling! 243.1.5. Data Channel and Subframe Mode Change! 253.1.6. Data Channel Deactivation / Reactivation! 263.1.7. Data Channel Suppression! 273.1.8. Data Channel and Clock Gear Change! 283.1.9. Data Channel and Clock Pause! 303.1.10. Data Channel and Synchronization Errors! 31

3.2. Pushed Transport Protocol! 323.2.1. Boot and Enumeration! 333.2.2. Data Channel Creation! 343.2.3. Add Sink Device to Active Data Channel! 363.2.4. Data Channel Reshuffling! 373.2.5. Data Channel and Subframe Mode Change! 383.2.6. Data Channel Deactivation / Reactivation! 393.2.7. Data Channel Suppression! 403.2.8. Data Channel and Clock Gear Change! 413.2.9. Data Channel and Clock Pause! 433.2.10. Data Channel and Synchronization Errors! 44

3.3. Pulled Transport Protocol! 453.3.1. Boot and Enumeration! 463.3.2. Data Channel Creation! 473.3.3. Data Channel Reshuffling! 483.3.4. Data Channel and Subframe Mode Change! 493.3.5. Data Channel Deactivation / Reactivation! 50

!


3.3.6. Data Channel Suppression! 513.3.7. Data Channel and Clock Gear Change! 523.3.8. Data Channel and Clock Pause! 533.3.9. Data Channel and Synchronization Errors! 54

4. LnK products & services! 555. Testronic Labs services! 56

Revision History

Revision Date Editor Comments

0.8 27/10/2010 X. Lambrecht Add:-‐ Channel structure table in 3.2 to cope with various Root Frequencies-‐ Channel structure table in 3.3 to cope with various Root Frequencies

0.81 28/10/2010 X. Lambrecht Fixes:-‐ P 30: Test ID: IP9: Stimulus sentence changed to match the message sequence.-‐ P 43: Test ID: PP9: Stimulus sentence changed to match the message sequence.

0.82 19/11/2010 X. Lambrecht Changes/Fixes:-‐ P 8: Test ID: DE3: The TID used with the unassigned LA is now equal to 0.-‐ P 9: Test ID GC1: Added a Sigure deSining ENT bit value-‐ P13: Test ID BR3 : The new Clock Gear value is 5 instead of 1.-‐ P16: Test ID SR1 : Fix in the timing of “At the beginning of the frame following the second corrupted frame sync symbol (764 cells later, then), transmit a REQUEST_INFORMATION (TID=1, EC=0x4008) message to the Interface Device.”-‐ P21: Test ID IP2: Fix the LA of the source and sink devices.-‐ P23: Test ID IP3: Fix the LA of the sink device.-‐ P34: Test ID PP2: Fix the LA of the source and sink device.-‐ P36: Test ID PP3: Fix the LA of the sink device.-‐ P47: Test ID Pu2: Fix the LA of the source

0.90 8/12/2010 X. Lambrecht Fixes:-‐ P 9: Test ID: GC1: Removed the veriSication of the message response of the Sirst REQUEST_INFORMATION as it gets a UDEF-‐ P 10: Test ID: GC2:-‐ P 18: Test ID: SR3: Removed the veriSication of the message response of the Sirst REQUEST_INFORMATION as it gets a UDEF

!


1. IntroductionSLIMbus® is a standard interface between baseband or application processors and peripheral components in mobile terminals, and was developed within the MIPI® Alliance by a dedicated group of MIPI member companies (LML WG). SLIMbus is a trademark of MIPI Alliance, Inc.

This particular suite of tests has been developed to help implementers evaluate the SLIMbus functionality of their MIPI products. This test suite is aimed at validating products in support of the work being directed by the MIPI Alliance.

These tests are designed to determine if a product conforms to speciSications deSined in the MIPI Alliance SpeciSication for Serial Low-‐power Inter-‐chip Media Bus (SLIMbus®), Version 1.01.01 -‐ 14 July 2008 standard (hereafter referred to as the “SLIMbus specSication”). Successful completion of all tests contained in this suite does not guarantee that the tested device will successfully operate with any other SLIMbus products. However, when combined with satisfactory level of interoperability testing, these tests provide a reasonable level of conSidence that the Device Under Test (DUT) will function properly in many SLIMbus environments.

The tests contained in this document are organized in 2 groups:• The aim of the Sirst group is to assess the maturity of a SLIMbus design before connecting it to a multi-‐device setup. The DUT will interact only with a SLIMbus TrafSic Generator in order to validate the basic bus features (boot, synchronization, enumeration, message transactions and bus reconSigurations).

• With the tests of the second group, peripheral devices, active Framer and active Manager will be connected together. The tests will focus on data channel management and data transport.

Note that the second group of test can be run with either a real framer and a real manager or simply with a SLIMbus TrafSic Generator that will emulate the Framer and Manager role.

All the devices are requested to operate their SLIMbus interface at 1.8V.

!


2. Design Maturity Verification TestsThe following tests will verify the ability of the DUT to support the fundamental mechanisms of SLIMbus. The tests will target both the Clock Receiving components and the Clock Sourcing Components.

The DUT will be connected to the SLIMbus Protocol Analyzer and TrafSic Generator.The operating voltage of SLIMbus must be 1.8V.The SLIMbus link is realized either with Slat cablesand DIL06 or DIL20 sockets or with SATA cables.

!


2.1. REPORT_PRESENT message validityTest ID: DE1Test Description:When the Boot sequence is completed, the Clock Sourcing Component will enter the Booted state and Clock Receiving Component will enter the Operational state. These 2 states are equivalent as the devices of the component are ready for nominal operations.The expected behavior of a properly booted device is the transmission of a REPORT_PRESENT message. This implies that the devices have acquired all the synchronization levels (Frame, Superframe and Message sync) and that the subframe mode is correctly decoded.The REPORT_PRESENT Messages will be Sirst NACKed to trigger message retransmission. The SLIMbus speciSication mandates a device to keep retransmitting the REPORT_PRESENT message till it gets a positive Acknowledge from the active Manager.Initial conditions:The Clock Sourcing Component is entering the Booted state or the Clock Receiving Component is entering the Operational state.Stimulus:Negatively acknowledge (NACK) the REPORT_PRESENT messages sent by all the Devices 5 times in a row and then send a Positive Acknowledge (PACK) to all the Devices.Success Criterion:Verify that all the devices present in the Component are issuing their REPORT_PRESENT message.Verify that all the REPORT_PRESENT messages are retransmitted as long as they receive a negative acknowledge (NACK).Verify that a REPORT_PRESENT message of the Interface device is transmitted and contains the Interface Device Class code (0xFD) and the Interface Device Class version (0x01). Verify that only one device reports a DC=0xFD.If a Framer Device is present in the Component, Verify that the REPORT_PRESENT message of the active Framer device is transmitted and contains the Framer Device Class code (0xFE) and the Framer Device Class version (0x01).If an inactive Manager device is present in the Component, verify that the REPORT_PRESENT message of a Manager device is present and contains the Generic Device Class code (0xFF) and the Generic Device Class version (0x01).If a Generic device is present in the Component, verify that the REPORT_PRESENT message of a Generic device is present and contains the Generic Device Class code (0x00) and the Generic Device Class version (0x01).Verify that each device has a unique Enumeration Address (which de facto includes a unique Device Index)Verify that the Manufacturer ID, Product Code and the Instance Value are identical for all the devices that reported Present.

!


2.2. Logical Address AssignmentTest ID: DE2Test Description:When a device has sent a REPORT_PRESENT message, the active Manager will send an ASSIGN_LOGICAL_ADDRESS message to deSine the logical address the device (used in any further transactions with that device). We must verify that the device under test properly receive the newly assigned logical address. Initial conditions:The Component has been properly booted and all of its devices have reported present and have been positively acknowledged (PACK).Stimulus:Send an ASSIGN_LOGICAL_ADDRESS to all the devices present in the component (start at value 0x01 and increase the LA by one unit on each iteration). Assign Logical Address 0x01 to the Interface Device.Success Criterion:Verify that the all the ASSIGN_LOGICAL_ADDRESS messages are all positively acknowledged (PACK).

!


2.3. Logical Address Assignment VerificationTest ID: DE3Test Description:Once all the devices have been properly enumerated, we shall verify that the devices under test properly received the newly assigned logical address and moved to the Enumerated state. Initial conditions:The Component has been properly booted and all of its devices have reported present. Each Device of the Component has received a Logical Address. The Interface device gets a Logical Address = 0x01.Stimulus:Send a REQUEST_INFORMATION(TID=0, EC=0x0098) message to a non assigned logical address (use 0xEF by default).Send a REQUEST_INFORMATION(TID=i, EC=0x0098) message to each of the devices in the component. The TID value i used in the REQUEST_ message must be equal to the Logical Address of the destination device.Success Criterion:Verify that the REQUEST_INFORMATION to the non-‐assigned LA is not acknowledged (read NORE).Verify that the REQUEST_INFORMATION to enumerated devices are all positively acknowledged (read PACK).Verify that all the devices are transmitting a REPLY_INFORMATION message with a TID that is equal to the Logical Address of the source device.Verify that the DEVICE_CLASS code of the REPLY_INFORMATION message correspond to the device class of the device that got assigned the logical address that is sending back the message (code=0xFD for LA=0x01, for instance).

!


2.4. Guide Channel TrackingTest ID: GC1Test Description:Once all the devices have been properly enumerated, we shall verify that the device under test properly tracks the Guide Channel and decodes the Guide Byte information. We will Sirst force the component to lose the message sync by transmitting a corrupted message. Then we will transmit a message crossing the superframe boundary (forcing the guide value to get a non zero value). And Sinally we will send a REQUEST_INFORMATION message to the DUT to get its synchronization status.

Initial conditions:The Component has been properly booted and all of its devices have reported present. Each Device of the Component has received a Logical Address. The Interface device gets a Logical Address = 0x01.Stimulus:Send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to a non assigned logical address (use 0xEF by default). Give it a UDEF value (0b0110) in the Message Response Sield.Send a REQUEST_INFORMATION(TID=2, EC=0x4008) message to a non assigned logical address (use 0xEF by default). Set the start position of the message in such a way that it is crossing the superframe boundary with the ENT bit equal to 0.Send a REQUEST_INFORMATION(TID=3, EC=0x4008) message to the Interface device of the component.Repeat the complete sequence but in such a way that the ENT bit equals to 1 when sending the third REQUEST_INFORMATION message.Success Criterion:Verify that the second REQUEST_INFORMATION to the non-‐assigned LA is not acknowledged (read NORE).Verify that the REQUEST_INFORMATION sent to the Interface Device is positively acknowledged (read PACK).Verify that the Interface Device transmits a REPLY_INFORMATION message with a TID that is equal to 3.Verify that the LOST_MS IE of the REPLY_INFORMATION message has a value equal to 1, indicating that the Component lost the message sync.Verify that the Interface Device sends a REPORT_INFORMATION (EC=0x4008) to signify a loss of Message sync.

!


2.5. Guide Channel GenerationTest ID: GC2Test Description:Once all the devices have been properly enumerated, we shall verify that the active Framer under test properly generates the Guide Byte information. We will transmit a message crossing the superframe boundary (forcing the guide value to get a non zero value) and verify that the GV value and the ENT bit value are correct.Initial conditions:The Component has been properly booted and all of its devices have reported present. Each Device of the Component has received a Logical Address. The Interface device gets a Logical Address = 0x01.Stimulus:Send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to the Interface device of the Clock Sourcing Component. Set the start position of the message in such a way that it is crossing the superframe boundary with the ENT bit equal to 0.Send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to the Interface device of the Clock Sourcing Component. Set the start position of the message in such a way that it is crossing the superframe boundary with the ENT bit equal to 1.Success Criterion:Verify that the value of the ENT bit is equal to 0 and that the GV value is equal to XXX.Verify that the REQUEST_INFORMATION sent to the Interface Device is positively acknowledged (read PACK).Verify that the Interface Device transmits a REPLY_INFORMATION message with a TID that is equal to 1.Verify that the LOST_MS IE of the REPLY_INFORMATION message has a value equal to 0.Verify that the value of the ENT bit is equal to 1 and that the GV value is equal to XXX.Verify that the REQUEST_INFORMATION sent to the Interface Device is positively acknowledged (read PACK).Verify that the Interface Device transmits a REPLY_INFORMATION message with a TID that is equal to 2.Verify that the LOST_MS IE of the REPLY_INFORMATION message has a value equal to 0.

!


2.6. Subframe Mode ChangeTest ID: BR1Test Description:A device must be capable of supporting all the Subframe modes. The modes are modiSied through a bus reconSiguration sequence. After a Subframe mode change, a device must keep all the synchronization levels.Note that the mode change as such does not always produce visible changes if messages are not transmitted. To amplify the effects of a subframe mode change, it is necessary to cycle through all subframe modes with a given order.There are 2 parameters implicitly given by the subframe mode value: the controls space size in slots and the subframe length in slots. When the control space size is equal to 1 or 2 slots, the Guide Byte slots are not contiguous and not happening always at the same position in the superframe. If the decoding of the subframe mode is not properly done, the device might not look at the right place for the Guide Byte and may fail the integrity checks. This will trigger the Interface device to set the LOST_MS IE and to try to transmit a REPORT_INFORMATION message with the relevant information (EC=0x4008). Note that such transmission might just fail because of the wrong subframe mode decoding.A REQUEST_INFORMATION message sent to the device right after the reconSiguration boundary will indicate if the device is still in message sync. A PACK followed by a REPLY_INFORMATION message is a proof of good sync.Initial conditions:The Component is in the Enumerated state and the LOST_SF, LOST_SFS and LOST_MS IE are all cleared. The FE bit (of the Framing Information) is equal to 0.Stimulus:Send a Subframe mode change reconSiguration sequence. Right after the reconSiguration boundary, send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to the Interface Device of the Component.Repeat the test 27 times with the following sequence in the subframe mode (SM) parameter value: 0, 4, 13, 21, 5, 12, 22, 6, 15, 23, 7, 14, 25, 8, 16, 24, 9, 17, 26, 10, 18, 27, 28, 11, 19, 29, 31, 7, 0.Success Criterion:Verify that the REQUEST_INFORMATION message is positively acknowledged (PACK).Verify that the REPLY_INFORMATION message is sent with the right TID=1.Verify that the LOST_MS, LOST_SFS and LOST_FS Information Elements are all equal to 0.If the Component is a Clock Sourcing Component (it contains an active Framer), verify that the active Framer updates the content of the SM Sield in the Framing Channel.

!


2.7. Clock Gear ChangeTest ID: BR2Test Description:A device must be capable of supporting all the Clock Gears. The gears are modiSied through a bus reconSiguration sequence. After a Clock Gear change, a Device must keep all the synchronization levels.Initial conditions:The Component is in the Enumerated state and the LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Send a Clock Gear mode change reconSiguration sequence. Right after the reconSiguration boundary, send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to the Interface Device of the Component. Repeat the test for 10 clock gear (CG) values: 10, 9, 8, 7, 6, 5, 4, 3, 2, 1,10Success Criterion:Verify that the REQUEST_INFORMATION message is positively acknowledged.Verify that the REPLY_INFORMATION message is sent with the right TID=1.Verify that the LOST_MS, LOST_SFS and LOST_FS Information Elements are all equal to 0.If the Component is a Clock Sourcing Component (it contains an active Framer), verify that the active Framer updates the content of the CG Sield in the Framing Channel and effectively modiSies the clock frequency according to the requested value.

!


2.8. Stacking reconfigurationsTest ID: BR3Test Description:A device must be capable of supporting multiple reconSiguration messages in a single reconSiguration sequence. After the reconSiguration sequence is executed, the Device framing layer must be conSigured accordingly to the reconSiguration messages.Note that in case of the component would loose the message sync, the Interface device of the component must transmit a REPORT_INFORMATION(EC=4008) message to signify to the Manager a loss of sync.Initial conditions:The Component is in the Enumerated state. The clock gear is equal to 9 and the subframe mode equal to 25. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Send a Clock Gear mode (CG=5) and a Subframe mode (SM=7) reconSiguration sequence. Right after the reconSiguration boundary, send a REQUEST_INFORMATION (TID=1, EC=0x4008) message to the Interface Device of the Component.Success Criterion:Verify that the REQUEST_INFORMATION message is positively acknowledged (PACK).Verify that the REPLY_INFORMATION message is sent with the right TID=1.Verify that the LOST_MS, LOST_SFS and LOST_FS Information Elements are all equal to 0.If the Component is a Clock Sourcing Component (it contains an active Framer), verify that the active Framer updates the content of the SM and CG Sields in the Framing Channel and effectively modiSies the clock frequency according to the requested values.

!


2.9. Reconfiguration Message Execution OrderTest ID: BR4Test Description:A device must execute the messages in the order they arrive. When transmitting many times the same reconSiguration message with different parameters in a reconSiguration sequence, the device must execute the last received message and discard the other ones.Note that in case of the component would loose the message sync, the Interface device of the component must transmit a REPORT_INFORMATION(EC=4008) message to signify to the Manager a loss of sync.Initial conditions:The Component is in the Enumerated state. The clock gear is equal to 9 and the subframe mode equal to 25. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Send a Subframe mode reconSiguration sequence with many NEXT_SUBFRAME_MODE messages. Use SM=31, SM=7 and SM=19. Right after the reconSiguration boundary, send a REQUEST_INFORMATION(TID=1, EC=0x4008) message to the Interface Device of the Component.The subframe mode must change to value 19 without going through 31 and 7.Success Criterion:Verify that the REQUEST_INFORMATION message is positively acknowledged.Verify that the REPLY_INFORMATION message is sent with the right TID=1.Verify that the LOST_MS, LOST_SFS and LOST_FS Information Elements are all equal to 0.If the Component is a Clock Sourcing Component (it contains an active Framer), verify that the active Framer properly updates the content of the SM value in the Framing Channel.

!


2.10. Aborted Reconfiguration SequenceTest ID: BR5Test Description:Upon reception of a BEGIN_RECONFIGURATION, a device must discard any announce changes. Verify that a device can support an aborted reconSiguration sequence.Note that in case of the component would loose the message sync, the Interface device of the component must transmit a REPORT_INFORMATION(EC=4008) message to signify to the Manager a loss of sync.Initial conditions:The Component is in the Enumerated state. The subframe mode (SM) value is equal to 25. The clock gear (CG) value is equal to 9. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Send the following reconSiguration message sequence

-‐ BEGIN_RECONFIGURATION -‐ NEXT_SUBFRAME_MODE (SM=7)-‐ NEXT_CLOCK_GEAR (CG=1)-‐ BEGIN_RECONFIGURATION -‐ RECONFIGURE_NOWRight after the reconSiguration boundary, send the following messages:-‐ REQUEST_INFORMATION(TID=1, EC=0x4008) to the Interface DeviceSuccess Criterion:Verify that the REQUEST_INFORMATION message is positively acknowledged (PACK).Verify that the REPLY_INFORMATION message is sent with the right TID=1.Verify that the LOST_MS, LOST_SFS and LOST_FS Information Elements are all equal to 0.If the Component is a Clock Sourcing Component (it contains an active Framer), verify that the active Framer does not modify the SM and CG Sield value and does not modify the frequency of the bus clock.

!


2.11. Frame Sync Pattern ErrorTest ID: SR1Test Description:A device that has acquired the frame sync must continuously monitor the frame sync symbol. If the veriSication fails once, it must be ignored (it can be an isolated error). If the veriSication fails twice (because of a clock glitch, for instance), the device must lose message sync, superframe sync and must reacquire the frame sync. The loss of sync must happen no more than 764 slots after the second corrupted frame sync symbol.In operation, the loss of frame sync will result in the interface device to transmit a REPORT_INFORMATION (EC=0x4008). The LOST FS, LOST_SFS and LOST_MS will be set.Initial conditions:The Clock Receiving Component is in the Enumerated state. The FE bit of the Framing Information is equal to 0. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Corrupt the Frame sync symbol at the beginning of a superframe. Any slot value other than 0b1011 is suitable.Wait 10 superframes with no message trafSic and no errors.Corrupt 2 consecutive frame sync symbols at the beginning of a superframe. Any slot value other than 0b1011 is suitable.At the beginning of the frame following the second corrupted frame sync symbol (764 cells later, then), transmit a REQUEST_INFORMATION (TID=1, EC=0x4008) message to the Interface Device.Positively acknowledge the incoming REPORT_INFORMATION message.Success Criterion:Verify that the Interface Device does not send any REPORT_INFORMATION after the isolated frame sync symbol error.Verify that the REQUEST_INFORMATION message is not acknowledged (NORE in the message response Sield).Verify that the REPORT_INFORMATION (EC=0x4008) message is sent by the Interface device after the 2 erroneous frame sync symbols.Verify that the IE LOST_MS, LOST_FS and LOST_SFS are set.

!


2.12. Superframe Sync Pattern ErrorTest ID: SR2Test Description:A device that has acquired the superframe sync must continuously monitor the superframe sync punctured symbol. If the veriSication fails once, it must be ignored (it can be an isolated error). If the veriSication fails twice (because of a clock glitch, for instance), the device must reacquire the superframe sync.In operation, the loss of frame sync will result in the interface device to transmit a REPORT_INFORMATION (EC=0x4008). The LOST_SFS and LOST_MS will be set.If the superframe sync cannot be reacquired within 4 superframes (32 frames), the component is likely not locked to the right frame sync symbol (pathological case) and must transition to the SeekingFrameSync state to reacquire reliably the frame sync.Initial conditions:The Clock Receiving Component is in the Enumerated state. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Corrupt the superframe sync symbol once. Any value other than 0X011XXX (where X is “don’t care”) is suitable.

At the superframe boundary, send a valid REQUEST_INFORMATION (TID=1, EC=0x4008) to the Interface device of the Component.

Corrupt 2 consecutive superframe sync symbols. Any value other than 0X011XXX (where X is “don’t care”) is suitable.

Positively acknowledge the incoming REPORT_INFORMATION message.

Corrupt 4 consecutive superframe sync symbols. Any value other than 0X011XXX (where X is “don’t care”) is suitable.

Positively acknowledge the incoming REPORT_INFORMATION message.

Success Criterion:Verify that the Interface Device positively acknowledges the REQUEST_INFORMATION message sent after the isolated superframe sync symbol error.Verify that the Sirst REPORT_INFORMATION (EC=0x4008) message is sent by the Interface device after the 2 erroneous frame sync symbols.Verify that the IE LOST_MS and LOST_SFS are set.Verify that the second REPORT_INFORMATION (EC=0x4008) message is sent by the Interface device after the 2 erroneous superframe sync symbols.Verify that the IE LOST_MS, LOST_SFS and LOST_FS are set.

!


2.13. Message Sync Lost - UDEFTest ID: SR3Test Description:A Component gains (or regains) Message synchronization by looking at the Guide Byte. Many events can lead to a loss of Message synchronization:

-‐ Invalid Guide Integrity-‐ Mismatch between the broadcasted Guide Value and the expected one-‐ Primary Integrity error (CRC failing)-‐ Illegal Arbitration Type-‐ Illegal Message Type-‐ UDEF Message Response-‐ Collision in the Message Response

A message that gets UDEF in the Message Response Sield will cause the transmitting device to lose Message sync. The Message sync acquisition will be veriSied by the transmission of a REPORT_INFORMATION (EC=0x4008) sent by the Interface Device of the Component.Initial conditions:The Clock Receiving Component is in the Enumerated state. The LOST_SF, LOST_SFS and LOST_MS IE are all cleared.Stimulus:Send a REQUEST_INFORMATION (TID=1, EC=0x4008) message with the value 0b0100 in the Message Response Sield to the Logical Address 0xEF (not assigned LA).

Just after the erroneous message, send a valid REQUEST_INFORMATION (TID=2, EC=0x4008) to the Interface device of the Component.

Right at the beginning of the next superframe, once the device has read the new correct Guide Byte, send a valid REQUEST_INFORMATION (TID=3, EC=0x0098) to the Interface device of the Component. Positively acknowledge the REPLY_INFORMATION message.

Positively acknowledge the incoming REPORT_INFORMATION (EC=0x4008) message sent by the Interface device of the component.

Success Criterion:Verify that the Component regains Message sync after the corruption of the Guide Integrity:

-‐ Verify that the REQUEST_INFORMATION (TID=2, EC=0x4008) message is not acknowledged (NORE).-‐ Verify that the REQUEST_INFORMATION (TID=3, EC=0x0098) message is positively acknowledged (PACK).-‐ Check the transmission of the REPLY_INFORMATION message. Verify that the TID=3.-‐ Check the transmission of the REPORT_INFORMATION message. Verify that the LOST_MS IE is set.

!


3. Multi-Peripheral SetupIn this section, we will describe tests to validate the setup of data channels between devices. The setup may not have an active Manager, in which case this role will be played by the SLIMbus TrafSic Generator. An active Framer can be present in the system.When testing the Pulled protocol, only 1 source device and 1 sink device can be tested at a time. Isochronous and Pushed protocols will allow for multiple sinks.When testing the Asynchronous Protocol family, only 1 source device and 1 sink device can be tested at a time.Whenever possible, the setup will comprise 3 SLIMbus Components.The primary focus will be on setting up a single data channel. However, some components will be able to stream or receive multiple channels. In this case, using multiple data channels will be equivalent to duplicate the test list deSined for one channel.

!


3.1. Isochronous Transport Protocol3.1.1. Boot and EnumerationTest ID: IP1Test Description:Boot the bus and enumerate the different devices on the bus. If we have 2 or 3 components, we will also have 2 or 3 Interface devices. The Logical Address assignment shall be performed according to the following table. Note that all the devices of a component do not need to get a Logical Address if they are not involved in the data transport.

Device Logical AddressInterface of Data source component 0x01

Generic Device of Data source component 0x04Interface of Data sink component 1 0x02

Generic Device of Data sink component 1 0x05Interface of Data sink component 2 0x03

Generic Device of Data sink component 2 0x06

ReconSigure the bus to set the subframe mode to value 19 (4/32), the Root Frequency to 24.576 MHz and the Clock Gear to 9.Initial conditions:The system is in the Unde7ined state.Stimulus:When the Framer role is handled by the TrafSic Generator, boot the bus with CG=0, RF=0 and SM=0. The boot clock frequency will be 12.288 MHz. Else, the boot conSiguration will depends on the active Framer setup.Wait 100 superframes to let the time to all the devices to report present, positively acknowledge the incoming REPORT_PRESENT messages.Assign the Logical Addresses as deSined in the table.Send a ReconSiguration Sequence to set the bus with CG=9, RF=1 and SM=19. The bus will be clocked at 12.288 MHz.-‐ BEGIN_RECONFIGURATION-‐ NEXT_SUBFRAME_MODE (SM=19)-‐ NEXT_ROOT_FREQUENCY (RF=1)-‐ NEXT_CLOCK_GEAR (CG=9)-‐ RECONFIGURE_NOW

Success Criterion:Verify that all the REPORT_PRESENT are sent without any collisions.Verify that all the ASSIGN_LOGICAL_ADDRESS messages are positively acknowledged (PACK) by all the devices.Verify that all the reconSiguration messages are positively acknowledged (PACK) by all the devices.

!


3.1.2. Data Channel CreationTest ID: IP2Test Description:Connect 1 source and 1 sink to the data channel #1.Create the data channel #1 with the following characteristics:-‐ Channel Rate: 48 kHz (SD=3140 or 0xC44, Interval=64, Offset=4)-‐ Segment Length: 4 slots (16 bit word)-‐ Transport Protocol: 0 (isochronous)The channel content is deSined as follow:-‐ Frequency Locked bit = 1-‐ Presence Rate = 3 (48 kHz)-‐ Auxiliary Bit Format = 0 (Not Applicable)-‐ Channel Link Bit = 0-‐ Data Type = 1 (LPCM Audio, Sign&Offset magnitude)-‐ Data Length = 4 (4 slots, 16 bit word)

And Activate it.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=19.Stimulus:Feed the source device with an audio signal (either digital or analog depending on the device capabilities).Connect the Data source device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x04:-‐ CONNECT_SOURCE (PN=i, CN=1)

!


Connect the Data sink device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x05:-‐ CONNECT_SINK (PN=j, CN=1)Send a ReconSiguration Sequence to conSigure and activate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=0, SD=3140, SL=4)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that the CONNECT_SOURCE message gets a PACK. It indicates that the source devices properly get its Logical Address 0x04.Verify that the CONNECT_SINK message gets a PACK. It indicates that the source devices properly get its Logical Address 0x05.Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is effective.

!


3.1.3. Add Sink Device to Active Data ChannelTest ID: IP3Test Description:Connect an additional sink device to a data channel (#1) that is already in operation. Use a CONNECT_SINK message and repeat the channel creation ReconSiguration Sequence in order to properly conSigure the data port of the new sink device. Note that this second set of conSiguration messages will not have any effect on the Data channel as they use the exact same parameters as the ones already used by the Data ports.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=19. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties.Stimulus:Connect the Data source device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x06:-‐ CONNECT_SINK (PN=j, CN=1)Send a ReconSiguration Sequence to conSigure and activate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=0, SD=3140, SL=4)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that the CONNECT_SINK message gets a PACK. It indicates that the source devices properly get its Logical Address 0x06.Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is effective on the new sink device.

!


3.1.4. Data Channel ReshufflingTest ID: IP4Test Description:The data channel is active. Its offset will be modiSied to move it in the Data space. This operation shall dot disturb the ongoing audio stream. The offset value is changed from 4 to 9. The new Segment Distribution value is equal to 3145 (or 0xC49).

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=19. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=0, SD=3145, SL=4)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

!


3.1.5. Data Channel and Subframe Mode ChangeTest ID: IP5Test Description:The data channel is active. The subframe mode will be changed to increase the bandwidth of the control space. The new subframe mode will be equal to 25 (8/32). The data channel conSiguration will not be modiSied.

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=19. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.

!


Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_SUBFRAME_MODE (SM=25)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

3.1.6. Data Channel Deactivation / ReactivationTest ID: IP6Test Description:An active data channel can simply be deactivated by a ReconSiguration Sequence. The ongoing audio streaming will be interrupted at the ReconSiguration Boundary. The data ports involved in the data transmission shall retain all information related to the data channel. The data channel can be reactivated by a reconSiguration sequence and the audio streaming will resume.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=25. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to deactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWAfter 5 seconds (10000 superframes), send a ReconSiguration Sequence to reactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is interrupted after the Sirst reconSiguration sequence.Verify that the audio streaming is reactivated after the second reconSiguration sequence.

!


3.1.7. Data Channel SuppressionTest ID: IP7Test Description:An active data channel can be completely reset by using the NEXT_REMOVE channel message. In this case, the data ports will reset their settings and the data channel will not be assigned to any data port anymore. Just sending a NEXT_ACTIVATE channel message shall not have any effect on a data stream.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=25. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to deactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_REMOVE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWAfter 1 seconds (2000 superframes), send a ReconSiguration Sequence to try to reactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio stream is interrupted after the Sirst reconSiguration sequence.Verify that the audio stream remains inactive after the second reconSiguration sequence.

!


3.1.8. Data Channel and Clock Gear ChangeTest ID: IP8Test Description:The Clock Gear can be modiSied while a data channel is on operation. The devices supporting this mode of operation shall be able to keep streaming the data without any interruption. In this test we will reduce the clock gear from 9 to 8. At the same time, the segment interval of the data channel must be divided by 2 (by changing the SD value from value 3145 to value 3113) to keep the channel rate at 48 kHz.

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=25. Data Channel #1 has been created and is in operation.

!


See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to change the clock Gear and the channel deSinition.-‐ BEGIN_RECONFIGURATION-‐ NEXT_CLOCK_GEAR (CG=8)-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=0, SD=3113, SL=4)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

!


3.1.9. Data Channel and Clock PauseTest ID: IP9Test Description:The Clock can be paused while a data channel is on operation. The devices supporting this mode of operation shall be able to keep streaming the data after pause resume.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=25. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to pause the bus.-‐ BEGIN_RECONFIGURATION-‐ NEXT_PAUSE_CLOCK (RT=2)-‐ RECONFIGURE_NOWWake up the bus after a period equivalent to 6144 clock cycles (one superframe duration). Success Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is resumed and effective on all devices.

!


3.1.10. Data Channel and Synchronization ErrorsTest ID: IP10Test Description:When a component lose the superframe sync or the frame sync, it must reset its data ports and transmit a REPORT_INFORMATION (EC=0x4008) message to the Manager.When a component sees isolated errors in the frame sync or superframe sync symbols, it shall ignore them and not disturb the audio streaming.A component losing the Message sync shall not rest its data ports.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=1 and SM=25. Data Channel #1 has been created and is in operation. See test IP2 for the data channel properties, except for SD which is equal to 3145. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Corrupt once the Frame sync symbol. Use value 0b0000.Four superframe later, corrupt once the superframe sync symbol embedded in the Framing Information. Use the punctured value 0b0X000XXX.Four superframe later, corrupt two contiguous Frame sync symbol. Use value 0b0000.After reception of the REPORT_INFORMATION (EC=0x4008) coming from the Interface devices of all the components present on the bus, reenable the audio stream by repeating the complete setup sequence.-‐ CONNECT_SOURCE (PN=i, CN=1)-‐ CONNECT_SINK (PN=j, CN=1)-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=0, SD=3145, SL=4)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that there are no REPORT_INFORMATION (EC=0x4008) message transmitted after the erroneous frame sync symbol.Verify that there are no REPORT_INFORMATION (EC=0x4008) message transmitted after the erroneous superframe sync symbol.Verify that the audio stream is interrupted after the 2 erroneous frame sync symbols.Verify that all the Interface devices are sending a REPORT_INFORMATION (EC=0x4008)message to the Manager.Verify that the audio streaming is resumed at the end of the reconSiguration sequence (at the reconSiguration boundary).

!


3.2. Pushed Transport ProtocolThe tests are proposed for a Root Frequency equal to 24 MHz. However, if another root frequency has to be used, the bus conSiguration and the data channel structure must be replaced by the values listed in the following table.

Root Frequency Segment Distribution Subframe Mode

15.36 MHz 3108 (Channel Rate = 60 kHz) 19 (4/32)

16.8 MHz 3108 (Channel Rate = 65.625 kHz) 19 (4/32)



26 MHz 3140 (Channel Rate = 50.78125 kHz) 19 (4/32)




!


3.2.1. Boot and EnumerationTest ID: PP1Test Description:Boot the bus and enumerate the different devices on the bus. If we have 2 or 3 components, we will also have 2 or 3 Interface devices. The Logical Address assignment shall be performed according to the following table. Note that all the devices of a component do not need to get a Logical Address if they are not involved in the data transport.



Generic Device of Data sink component 1 0x05Interface of Data sink component 2 0x03


ReconSigure the bus to set the subframe mode to value 18 (4/24), the Root Frequency to 24 MHz (RF=6) and the Clock Gear to 9.Initial conditions:The system is in the Unde7ined state.Stimulus:When the Framer role is handled by the TrafSic Generator, boot the bus with CG=0, RF=0 and SM=0. The boot clock frequency will be 12 MHz. Else, the boot conSiguration will depends on the active Framer setup.Wait 100 superframes to let the time to all the devices to report present, positively acknowledge the incoming REPORT_PRESENT messages.Assign the Logical Addresses as deSined in the table.Send a ReconSiguration Sequence to set the bus with CG=9, RF=6 and SM=18 (4/24). The bus will be clocked at 12 MHz.-‐ BEGIN_RECONFIGURATION-‐ NEXT_SUBFRAME_MODE (SM=18)-‐ NEXT_ROOT_FREQUENCY (RF=6)-‐ NEXT_CLOCK_GEAR (CG=9)-‐ RECONFIGURE_NOW


!


3.2.2. Data Channel CreationTest ID: PP2Test Description:Connect 1 source and 1 sink to the data channel #1.Create the data channel #1 with the following characteristics:-‐ Channel Rate: 62.5 kHz (SD=20 or 0x014, Interval=48, Offset=4)-‐ Segment Length: 5 slots (20 bit word)-‐ Transport Protocol: 1 (Pushed)The channel content is deSined as follow:-‐ Frequency Locked bit = 1-‐ Presence Rate = 3 (48 kHz)-‐ Auxiliary Bit Format = 0 (Not Applicable)-‐ Channel Link Bit = 0-‐ Data Type = 1 (LPCM Audio, Sign&Offset magnitude)-‐ Data Length = 4 (4 slots, 16 bit word)

And Activate it.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18.Stimulus:Feed the source device with an audio signal (either digital or analog depending on the device capabilities).Connect the Data source device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x04:-‐ CONNECT_SOURCE (PN=i, CN=1)

!


Connect the Data sink device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x05:-‐ CONNECT_SINK (PN=j, CN=1)Send a ReconSiguration Sequence to conSigure and activate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=1, SD=20, SL=5)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that the CONNECT_SOURCE message gets a PACK. It indicates that the source devices properly get its Logical Address 0x04.Verify that the CONNECT_SINK message gets a PACK. It indicates that the source devices properly get its Logical Address 0x05.Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is effective and -‐ Verify that the Presence bit is set when the DATA Sield contains information-‐ Verify that the STRobe bit is set when the Presence bit is set-‐ Verify that the Presence bit wide band jitter is according to the SLIMbus speciSication

!


3.2.3. Add Sink Device to Active Data ChannelTest ID: PP3Test Description:Connect an additional sink device to a data channel (#1) that is already in operation. Use a CONNECT_SINK message and repeat the channel creation ReconSiguration Sequence in order to properly conSigure the data port of the new sink device. Note that this second set of conSiguration messages will not have any effect on the Data channel as they use the exact same parameters as the ones already used by the Data ports.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties.Stimulus:Connect the Data source device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x06:-‐ CONNECT_SINK (PN=j, CN=1)Send a ReconSiguration Sequence to conSigure and activate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=1, SD=20, SL=5)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that the CONNECT_SINK message gets a PACK. It indicates that the source devices properly get its Logical Address 0x06.Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is effective on the new sink device.

!


3.2.4. Data Channel ReshufflingTest ID: PP4Test Description:The data channel is active. Its offset will be modiSied to move it in the Data space. This operation shall dot disturb the ongoing audio stream. The offset value is changed from 4 to 9. The new Segment Distribution value is equal to 25 (or 0x019).

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=1, SD=25, SL=5)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

!


3.2.5. Data Channel and Subframe Mode ChangeTest ID: PP5Test Description:The data channel is active. The subframe mode will be changed to increase the bandwidth of the control space. The new subframe mode will be equal to 24 (8/24). The data channel conSiguration will not be modiSied.

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.

!


Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_SUBFRAME_MODE (SM=24)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

3.2.6. Data Channel Deactivation / ReactivationTest ID: PP6Test Description:An active data channel can simply be deactivated by a ReconSiguration Sequence. The ongoing audio streaming will be interrupted at the ReconSiguration Boundary. The data ports involved in the data transmission shall retain all information related to the data channel. The data channel can be reactivated by a reconSiguration sequence and the audio streaming will resume.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=24. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties, except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to deactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWAfter 5 seconds (10000 superframes), send a ReconSiguration Sequence to reactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is interrupted after the Sirst reconSiguration sequence.Verify that the audio streaming is reactivated after the second reconSiguration sequence.

!


3.2.7. Data Channel SuppressionTest ID: PP7Test Description:An active data channel can be completely reset by using the NEXT_REMOVE channel message. In this case, the data ports will reset their settings and the data channel will not be assigned to any data port anymore. Just sending a NEXT_ACTIVATE channel message shall not have any effect on a data stream.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=24. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties, except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to deactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_REMOVE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWAfter 1 seconds (2000 superframes), send a ReconSiguration Sequence to try to reactivate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio stream is interrupted after the Sirst reconSiguration sequence.Verify that the audio stream remains inactive after the second reconSiguration sequence.

!


3.2.8. Data Channel and Clock Gear ChangeTest ID: PP8Test Description:The Clock Gear can be modiSied while a data channel is on operation. The devices supporting this mode of operation shall be able to keep streaming the data without any interruption. In this test we will reduce the clock gear from 9 to 8. At the same time, the segment interval of the data channel must be divided by 2 (by changing the SD value from value 25 to value 1033) to keep the channel rate at 62.5 kHz.

Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=24. Data Channel #1 has been created and is in operation.

!


See test PP2 for the data channel properties, except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to change the clock Gear and the channel deSinition.-‐ BEGIN_RECONFIGURATION-‐ NEXT_CLOCK_GEAR (CG=8)-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=1, SD=1033, SL=5)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still operational on all devices.

!


3.2.9. Data Channel and Clock PauseTest ID: PP9Test Description:The Clock can be paused while a data channel is on operation. The devices supporting this mode of operation shall be able to keep streaming the data after pause resume.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=25. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties, except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to pause the bus.-‐ BEGIN_RECONFIGURATION-‐ NEXT_PAUSE_CLOCK (RT=2)-‐ RECONFIGURE_NOWWake up the bus after a period equivalent to 6144 clock cycles (one superframe duration). Success Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is resumed and effective on all devices.

!


3.2.10. Data Channel and Synchronization ErrorsTest ID: PP10Test Description:When a component lose the superframe sync or the frame sync, it must reset its data ports and transmit a REPORT_INFORMATION (EC=0x4008) message to the Manager.When a component sees isolated errors in the frame sync or superframe sync symbols, it shall ignore them and not disturb the audio streaming.A component losing the Message sync shall not rest its data ports.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=25. Data Channel #1 has been created and is in operation. See test PP2 for the data channel properties, except for SD which is equal to 25. 1 source device and 2 sink devices are connected to the data channel.Stimulus:Corrupt once the Frame sync symbol. Use value 0b0000.Four superframe later, corrupt once the superframe sync symbol embedded in the Framing Information. Use the punctured value 0b0X000XXX.Four superframe later, corrupt two contiguous Frame sync symbol. Use value 0b0000.After reception of the REPORT_INFORMATION (EC=0x4008) coming from the Interface devices of all the components present on the bus, reenable the audio stream by repeating the complete setup sequence.-‐ CONNECT_SOURCE (PN=i, CN=1)-‐ CONNECT_SINK (PN=j, CN=1)-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=1, SD=25, SL=5)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that there are no REPORT_INFORMATION (EC=0x4008) message transmitted after the erroneous frame sync symbol.Verify that there are no REPORT_INFORMATION (EC=0x4008) message transmitted after the erroneous superframe sync symbol.Verify that the audio stream is interrupted after the 2 erroneous frame sync symbols.Verify that all the Interface devices are sending a REPORT_INFORMATION (EC=0x4008)message to the Manager.Verify that the audio streaming is resumed at the end of the reconSiguration sequence (at the reconSiguration boundary).

!


3.3. Pulled Transport ProtocolThe tests are proposed for a Root Frequency equal to 24 MHz. However, if another root frequency has to be used, the bus conSiguration and the data channel structure must be replaced by the values listed in the following table.

Root Frequency Segment Distribution Subframe Mode


16.8 MHz 3108 (Channel Rate = 65.625 kHz) 19 (4/32)







!


3.3.1. Boot and EnumerationTest ID: PU1Test Description:Boot the bus and enumerate the different devices on the bus. As we have 2 components, we will also have 2 Interface devices. The Logical Address assignment shall be performed according to the following table. Note that all the devices of a component do not need to get a Logical Address if they are not involved in the data transport.




ReconSigure the bus to set the subframe mode to value 18 (4/24), the Root Frequency to 24 MHz (RF=6) and the Clock Gear to 9.Initial conditions:The system is in the Unde7ined state.Stimulus:When the Framer role is handled by the TrafSic Generator, boot the bus with CG=0, RF=0 and SM=0. The boot clock frequency will be 12 MHz. Else, the boot conSiguration will depends on the active Framer setup.Wait 100 superframes to let the time to all the devices to report present, positively acknowledge the incoming REPORT_PRESENT messages.Assign the Logical Addresses as deSined in the table.Send a ReconSiguration Sequence to set the bus with CG=9, RF=6 and SM=18 (4/24). The bus will be clocked at 12 MHz.-‐ BEGIN_RECONFIGURATION-‐ NEXT_SUBFRAME_MODE (SM=18)-‐ NEXT_ROOT_FREQUENCY (RF=6)-‐ NEXT_CLOCK_GEAR (CG=9)-‐ RECONFIGURE_NOW


!


3.3.2. Data Channel CreationTest ID: PU2Test Description:Connect 1 source and 1 sink to the data channel #1.Create the data channel #1 with the following characteristics:-‐ Channel Rate: 62.5 kHz (SD=20 or 0x014, Interval=48, Offset=4)-‐ Segment Length: 5 slots (20 bit word)-‐ Transport Protocol: 2 (Pulled)The channel content is deSined as follow:-‐ Frequency Locked bit = 1-‐ Presence Rate = 3 (48 kHz)-‐ Auxiliary Bit Format = 0 (Not Applicable)-‐ Channel Link Bit = 0-‐ Data Type = 1 (LPCM Audio, Sign&Offset magnitude)-‐ Data Length = 4 (4 slots, 16 bit word)Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18.Stimulus:Feed the source device with an audio signal (either digital or analog depending on the device capabilities).Connect the Data source device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x04:-‐ CONNECT_SOURCE (PN=i, CN=1)Connect the Data sink device to the channel #1, use the relevant port number (depending on device description). Send the following message to the Logical Address 0x05:-‐ CONNECT_SINK (PN=j, CN=1)Send a ReconSiguration Sequence to conSigure and activate the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=2, SD=20, SL=5)-‐ NEXT_DEFINE_CONTENT (CN=1, FL=1, PR=3, AF=0, DT=1, CL=0, DL=4)-‐ NEXT_ACTIVATE_CHANNEL (CN=1)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that the CONNECT_SOURCE and the CONNECT_SINK messages get a PACK.Verify that all the ReconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is effective and -‐ Verify that the Presence bit is set when the DATA Sield contains information-‐ Verify that the Presence bit is set when the SRQ bit is set-‐ Verify that the Presence bit wide band jitter is according to the SLIMbus speciSication

!


3.3.3. Data Channel ReshufflingTest ID: PU3Test Description:The data channel is active. Its offset will be modiSied to move it in the Data space. This operation shall dot disturb the ongoing audio stream. The offset value is changed from 4 to 9. The new Segment Distribution value is equal to 25 (or 0x019).Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18. Data Channel #1 has been created and is in operation. See test PU2 for the data channel properties. 1 source device and 1 sink device are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BEGIN_RECONFIGURATION-‐ NEXT_DEFINE_CHANNEL (CN=1, TP=2, SD=25, SL=5)-‐ RECONFIGURE_NOWSuccess Criterion:Verify that all the reconSiguration messages are positively acknowledged (PACK).Verify that the audio streaming is still effective on all devices.

!


3.3.4. Data Channel and Subframe Mode ChangeTest ID: PU4Test Description:The data channel is active. The subframe mode will be changed to increase the bandwidth of the control space. The new subframe mode will be equal to 24 (8/24). The data channel conSiguration will not be modiSied.Initial conditions:The system is properly booted and the devices are enumerated. The bus is in the following conSiguration: CG=9, RF=6 and SM=18. Data Channel #1 has been created and is in operation. See test PU2 for the data channel properties except for SD which is equal to 25. 1 source device and 1 sink device are connected to the data channel.Stimulus:Send a ReconSiguration Sequence to reconSigure the data channel.-‐ BE

Date post:	30-Jan-2021
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Interop Test Plan - LnK Tools · 2012. 5. 10. · 3.3.6. Data Channel Suppression! 51 3.3.7. Data...

Documents