Verification of Moderate Complexity IP: Case Study, MIL-STD-1553B Interface

1
Verification of Moderate Complexity IP Case
Study, MIL-STD-1553B Interface

• Rod Barto
• NASA Office of Logic Design

2
Goals of Paper

• Discuss the process by which IP was reviewed for
  a project
• Show an example of the details of an IP
  investigation
• No IP details will be revealed beyond data sheet
  information

3
Project Goal

• Create an easy to use 1553 interface for
  instruments
• Provide the user with some simple built-in
  interfaces
• Digital inputs and outputs
• Memory load and readout
• Event counters
• Make user interface as easy to use as possible

4
Major Design Portion Interface to 1553 Bus

• Decision to use 1553 core IP to speed design
• Two IP cores considered
• Company X (XCo)
• Company Y (YCo)
• Both cores were reviewed in detail to determine
  whether their designs were appropriate for space
  use

5
Review Questions

• Has the core passed a 1553 verification test?
• Is the internal design sufficiently robust for
  space usage?
• Treatment of illegal state machine states
• Sensitivity to noise in incoming bit stream
• How well is the user interface documented?
• Dont want to reverse engineer the interface to
  figure out how it works

6
Method of review

• Read spec and supporting documentation
• Review verification report
• Read through VHDL
• Run VHDL simulations as necessary
• Synthesize modules and review netlist schematic
  as necessary

7
1553 Verification

• Assumption passing verification shows front end
  design to be logically correct
• Verification does not validate user interface
• XCo had passed verification, but
• Not at frequency the core would be run at
• Significant changes had been made to the core
  after the verification test, including to the
  decoder
• XCo agreed to re-run the test
• YCo had passed verification, but
• Only in Xilinx FPGA, while project target was
  Actel
• YCo agreed to re-run the test

8
Design Robustness

• XCo
• Safe attribute not used
• Decoder showed sensitivity to bit errors, and
  would require pre-filtering
• YCo
• Safe attribute used
• Decoder incorporated pre-filtering and was
  otherwise by design less sensitive to bit errors

9
Documentation

• Documentation Standard TI Data Book
• Truth tables, timing diagrams, etc., always
  provided
• Never any confusion about how a TI part worked
• Never had to call tech support to resolve
  ambiguities
• Neither core met this standard
• Both XCo and YCo had to be contacted to resolve
  documentation deficiencies

10
Conclusions Regarding IP

• Use of proven IP cores can reduce the time
  required to produce a proven design, but
• Users should be skeptical about how well proven
  the core is
• Users should be skeptical that the design meets
  their robustness requirements
• Vendors should raise the quality of their
  documentation
• No IP reviewed to date meets the overall quality
  standard set by the vendors of SSI/MSI/LSI parts

11
What Documentation Should the User Request?

• Full data sheet and any user guides, application
  notes, etc.
• Verification reports
• Every piece of IP should have been subjected to
  some formal verification test by the vendor
• Change and verification history
• VHDL or other circuit description
• IP vendors are reluctant to release this
• Can obtain some information in other ways, e.g.,
• Ask direct questions
• Review synthesis reports for information about
  state machine handling, asynchronous design
  techniques, etc.

12
Example ACTgen RTAX-S FIFO

• Candidate FIFO for 1553 backend circuitry
• Uses RTAX RAM and FIFO resources
• Generated by ACTgen, so it really is IP
• FIFO is logically 16 bits by 32 words deep
• FIFO is actually 18 bits by 128 words
• FULL flag used is actually AFULL (Almost Full)
  flag set with a threshold of 32 words
• Means you can write to the FIFO when full
• Must be checked against in controller
• EMPTY flag is true empty

13
FIFO Symbol and Signals

• DATA150 input
• Q150 output
• WE write enable (active low)
• RE read enable (active low)
• WCLOCK write clock (rising edge)
• RCLOCK read clock (rising edge)
• ACLR reset (active high)
• AEMPTY almost empty (active high)
• AFULL almost full (active high)
• FULL full flag (active high)
• EMPTY empty flag (active high)

Note AEMPTY and FULL flags are ignored in design
14
AFULL and EMPTY flags
Source Actel RTAX-S Data Sheet
Subtraction and comparison with threshold (AFVAL)
is not delayed, so AFULL flag is not delayed on
writes or reads
Write address is delayed before comparison with
read address on writes, delaying empty flag
falling on writes but not delaying its rising on
reads
AEMPTY and FULL flags are ignored in design
15
Verification PlanRun FIFO Simulations

• Actel doesnt provide any verification results
• So, IP verification task falls to user
• Verification plan write test bench
• Resets FIFO
• Writes 35 words, values 0 to 34
• AFULL flag should rise after value 31 written
• Logic checks the AFULL flag, only values 0 to 31
  should be written
• Reads 40 words
• Only values 0 through 31 should come out, empty
  flag should rise after 31

16
FIFO Test Bench Code

• FIFO_read_write process
• variable nout unsigned(15 downto 0)
• begin
• rclock lt '0' -- only wclock
  is used
• aclr lt '1' -- set clear,
  active high
• nout (others gt '0') -- data
  generator
• data lt std_logic_vector(nout)
• for i in 1 to 5 loop
• wait until rising_edge(wclock)
• end loop
• ACLR lt '0' -- release
  clear
• re lt '1' -- read
  enable, active low
• we lt '1' -- write
  enable, active low
• for i in 1 to 5 loop -- just a
  delay
• wait until rising_edge(wclock)
• end loop
• for i in 1 to 35 loop -- FIFO write
  loop
• wait until rising_edge(wclock)
• if afull '0' then -- check
  AFULL, write only when low

• we lt '1' -- FIFO read
  section
• wait until rising_edge(wclock)
• for i in 1 to 40 loop -- write loop
• wait until rising_edge(wclock)
• re lt '0' after 5 ns
• wait until rising_edge(wclock)
• re lt '1' after 5 ns
• end loop
• wait
• end process

17
FIFO Write and Read
Last write is 31, further writes suppressed by
AFULL flag rising and being checked
Reset FIFO
Start of read cycles
Empty Flag falls
first write is 0
EMPTY flag rises
Last value read out is 31

• Scale 1 usec/div

18
First Write Details
Value of 0 written on this clock edge when we is
low
Note empty flag fall delayed one clock edge

• Scale 10 nsec/div

19
Last Write Details
Write of value 31 occurs on this clock edge
Note AFULL flag rises immediately. It is still
possible, however, to write to the FIFO because
the AFULL flag is not the true FULL flag. The
controller logic must check the AFULL flag and
suppress further writes.

• Scale 20 nsec/div

20
First Read Details
Data appears on this clock edge when RE is low.
AFULL flag falls immediately on the same clock
edge
Note that Q output is indeterminate before the
first read, i.e., the first value written doesnt
fall through the FIFO and appear as valid data on
the output, at least not in the simulation

• Scale 50 nsec/div

21
Last Read Details
Read of value 31 occurs on this clock edge with
RE low
No further reads occur
Empty flag rises immediately

• Scale 50 nsec/div

22
Conclusion

• Investigation shows idiosyncrasies of IP
• Empty flag rise/fall inconsistency could be
  inferred by reviewing RTAX-S documentation, but
  simulation shows it clearly
• Indeterminate Q output before Read was a surprise
• Better to take a skeptical approach to IP than to
  accept it blindly