CoValidation Environment for Memory Card Compatibility Test: A Case Study

1
Co-Validation Environment for Memory Card
Compatibility Test A Case Study

• Chanik Park, Seungmo Cho,
• Jaewook Lee and Hyungjun Park
• Samsung Electronics Co.,
• South Korea

2
Introduction (1/2)

• Compatibility problem in producing MMC ver 3.1
• standard MMC (MultiMediaCard) Ver. 3.1
• we identified them as specification-conformance
  problems
• Source of problems Ambiguities
• definitions of terms
• ex "transfer end" vs. "operation complete"?
• interactions between operations of commands
• ex what if another WRITE_BLOCK command comes,
  when the card is already in the middle of
  processing one?
• Formal, executable modeling will resolve the
  problems!!

3
Introduction (2/2)

• Uniqueness of external memory cards
• operate on special-purpose hardware
• co-design and co-validation are needed
• not safety-critical
• time-to-market is more important
• poorly layered
• basic unit of communication is bit, not message.
• ex. "the data transmission stops two clock cycles
  after the end bit of the stop command"
• Contributions
• a lightweight specification-based testing method
• modeling MMC host using Esterel and C
• testing of our MMC cards in SeamlessTM environment

4
MMCSpecification
MMC Host
MMC Card
CLK
command
response
CMD
data (write)
data (read)
DAT
MMC System
5
Our Method
C Verilog
Esterel C
Seamless
6
Design Decisions

• Modeling the environment, not the system under
  testing
• formal model takes the role of test harness and
  test oracle
• Using a formal language Esterel
• can be learned easily by field engineers
• cycle-based execution model fits well with HDL
• Using SeamlessTM
• commercial simulation environment
• enables co-validation of hardware (Verilog) and
  software (C)
• Test execution methods
• constrained random execution
• test oracle included

7
Example 1

• TRAN state
• CMD25 (open-ended)
• after writing the first block, when DAT line is
  busy,
• CMD12
• DAT Line becomes high impedance immediately,
  while MMC is actually in PRG state

Error
8
Example 2

• TRAN state
• CMD24 (Single block write)
• in 1500, 3000, 4000 clock after the response
• CMD12
• Infinite Busy signal on DAT Line

Error
9
Conclusion (1/2)

• Achievements
• behavioral modeling of MMC host is feasible
• small (30KB, Esterel) model separation of
  control and data part
• testing
• random testing couldn't be executed enough
• But, errors were detected by relatively short
  executions
• Unique benefit of simulation approach
• early validation is possible
• investigating the error situation becomes easy
• Comparison with other approaches
• test with real MMC hosts biased test patterns
• building testbench in C can't test various
  timings accurately
• BNC does not test fully general host behavior

10
Conclusion (2/2)

• Remaining problems
• simulation speed due to RTL-level simulation
• too many specification violations
• not enough attention is paid to the official
  specification
• avoiding detected error behaviors took much time
• weak tool supports
• weakness of freely-distributed version of xev
  (Esterel simulator)
• Promising future work
• test language for embedded systems similar to
  TTCN
• speed-up of simulation using SystemC
• providing "golden reference model" of MMC
  specification