Barto B170/MAPLD2005 Page 1 Verification of Moderate Complexity IP: Case Study, MIL-STD- 1553B Interface Rod Barto NASA Office of Logic Design
Jan 05, 2016
Barto B170/MAPLD2005 Page 1
Verification of Moderate Complexity IP:
Case Study, MIL-STD-1553B Interface
Rod Barto
NASA Office of Logic Design
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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?– Don’t want to “reverse engineer” the interface to figure
out how it works
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 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.
Barto B170/MAPLD2005 Page 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
Barto B170/MAPLD2005 Page 13
FIFO Symbol and Signals• DATA[15:0] – input• Q[15:0] – 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
Barto B170/MAPLD2005 Page 14
AFULL and EMPTY flagsSource: Actel RTAX-S Data Sheet
Write address is delayed before comparison with read address on writes, delaying empty flag falling on writes but not delaying its rising on reads
Subtraction and comparison with threshold (AFVAL) is not delayed, so AFULL flag is not delayed on writes or reads
AEMPTY and FULL flags are ignored in design
Barto B170/MAPLD2005 Page 15
Verification Plan:Run FIFO Simulations
• Actel doesn’t 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
Barto B170/MAPLD2005 Page 16
FIFO Test Bench Code FIFO_read_write : process variable nout: unsigned(15 downto 0); begin rclock <= '0'; -- only wclock is used aclr <= '1'; -- set clear, active high nout := (others => '0'); -- data generator data <= std_logic_vector(nout); for i in 1 to 5 loop wait until rising_edge(wclock); end loop; ACLR <= '0'; -- release clear re <= '1'; -- read enable, active low we <= '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 <= '0' after 5 ns; end if; wait until rising_edge(wclock); wait for 5 ns; we <= '1'; -- turn off write nout := nout + 1; -- generate next data value data <= std_logic_vector(nout); for j in 1 to 5 loop -- delay loop wait until rising_edge(wclock); end loop; end loop;
;
we <= '1'; -- FIFO read section wait until rising_edge(wclock); for i in 1 to 40 loop -- write loop wait until rising_edge(wclock); re <= '0' after 5 ns; wait until rising_edge(wclock); re <= '1' after 5 ns; end loop; wait; end process
Barto B170/MAPLD2005 Page 17
FIFO Write and Read
• Scale 1 usec/div
Reset FIFO
first write is 0
Empty Flag falls
Last write is 31, further writes suppressed by AFULL flag rising and being checked
Start of read cycles
EMPTY flag rises
Last value read out is 31
Barto B170/MAPLD2005 Page 18
First Write Details
• Scale 10 nsec/div
Value of 0 written on this clock edge when we is low Note empty flag fall delayed one
clock edge
Barto B170/MAPLD2005 Page 19
Last Write Details
• Scale 20 nsec/div
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.
Barto B170/MAPLD2005 Page 20
First Read Details
• Scale 50 nsec/div
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 doesn’t fall through the FIFO and appear as valid data on the output, at least not in the simulation
Barto B170/MAPLD2005 Page 21
Last Read Details
• Scale 50 nsec/div
Read of value 31 occurs on this clock edge with RE low
Empty flag rises immediately
No further reads occur
Barto B170/MAPLD2005 Page 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