BENCHMARK FORMAT QUESTIONS.

High Level Circuit Descriptions

• Should RTL level circuits be described in VHDL, Verilog, some other language, or either?
• What is the best format for vector sets? Verilog testbench? Other?
• What library should be used for synthesis? Is there a public-domain library that can be shipped with the benchmarks?

Gate Level Circuit Descriptions:

• What netlist format should be used? The ISCAS '89 circuits used a simple format and shipped a translator for it. Possibilities are Verilog, EDIF or VHDL net lists.
• Should a generic standard cell library be defined, or are primitive gates adequate?
• In either case, a standard set of flip-flop and latch primitives must be defined. What features should these include? Here is a first cut at a feature set:
  • Positive and negative edge triggered FFs.
  • Positive and negative level sensitive latches
  • Latches and FFs with synchronous and asynchronous clears and presets, both positive and negative.
• What other cells should be in the library? Again, here is a first suggestion:
  • A set of tristate drivers, with both enable high and low control signals.
  • A standard set of I/O buffers, including bidirectionals.
  • A set of memory cores, including:
    • Single port static RAM
    • Dual port static RAM
    • ROM - it is permissible to replace the real contents with random contents.
    • Content Addressable Memory (CAM).
    Are there others that people would like to see?
• How can we define a protocol for these that would be both universal and easy to understand?
• Will we have to modify circuits not adhering to this protocol, or can we define one that is universal enough to handle all reasonable examples?
• Does anyone have a favorite template to describe memories?
• Does anyone have a suggested format for ROM data files?
• Do we need models of scan FFs and latches? My first thought is no, since we want to let benchmark users to use any type of DFT.

Custom Design Level:

• Is the same netlist proposed for the gate level good enough to describe transistor level structures?
• What is a set of transistor level primitives adequate to represent the set of structures we wish to consider?
• Should there be a different fault model for custom logic?

BENCHMARK REQUIREMENTS

• Fault coverage for tests created at the RTL level must be reported using gate level fault simulation. It is of course also acceptable to report fault coverage with higher level fault models, however we do not adopt any particular higher level model as the standard.
• Assumptions on fault insertion at the gate level must be clearly stated, especially for structures such as memories, busses, and I/O buffers. Uncollapsed fault coverage should be reported if possible, if not, the collapsing algorithm should be reported.
• We might provide fault lists for the gate level version of the circuit. However, since new gate level versions can be created if DFT is done at the higher level, this list will not be adequate in all cases.
• If boundary scan is included in the design, compliance with 1149.1 must be assured, a BSDL file for the device must be available, and a description of private instructions must be available.
• There must be design verification vectors for each benchmark circuit. These do not have to provide any significant level of fault coverage, but are necessary to verify that transformations to the circuits have been made correctly. Any special conditions required to apply these vectors must be documented.
• The RTL must be synthesizable.
• The benchmark must come with a short description of its functionality.
• The benchmark must include no DFT except boundary scan. Waivers might be granted in certain cases (for instance if memory BIST is included.)
• The circuits must be freely available to be copied without NDAs or copyright agreements.
• RTL benchmarks must be shipped with a netlist, to be useful for those not working at the RTL level.

OPTIONS

• RTL level names may be converted to meaningless character strings (A, B, C, etc.) to help disguise functionality.
• If there are sensitive circuit regions, they may be removed, so long as the resulting circuit matches the accompanying DV vectors. The I/Os to the missing blocks can be converted to primary inputs or outputs, or sources to the block can be connected to its destination. Unconnected, floating leads are not permitted.
• The details of cores need not be provided. Either a vector set (in which case the result of test creation is a method's effectiveness in applying these vectors to the core and getting the result to an observable point,) or information on internal scan chains must be provided. However, soft and firm cores are preferred.