Verification of moderate complexity ip case study mil std 1553b interface
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

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

  • Uploaded on
  • Presentation posted in: General

Verification of Moderate Complexity IP: Case Study, MIL-STD-1553B Interface. Rod Barto NASA Office of Logic Design. Review Questions for a 1553 IP Core. Has the core passed a 1553 verification test? Is the internal design sufficiently robust for space usage?

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Verification of moderate complexity ip case study mil std 1553b interface

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

Rod Barto

NASA Office of Logic Design


Review questions for a 1553 ip core

Review Questions for a 1553 IP Core

  • 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


Method of review

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


1553 verification

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


Design robustness

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




  • 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


Conclusions regarding ip

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


What documentation should the user request

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.


Example actgen rtax s fifo

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


Afull and empty flags

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


Verification plan run fifo simulations

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


Fifo write and read

FIFO Write and Read

  • Scale 1 usec/div

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


First write details

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


Last read details

Last Read Details

  • Scale 50 nsec/div

Read of value 31 occurs on this clock edge with RE low

No further reads occur

Empty flag rises immediately


First read details

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




  • 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


  • Login