Problem: design complexity advances in a pace that far exceeds the pace in which verification technology advances. More accurately: (verification complexity) > sqr(design complexity)

Disadvantages of current verification techniques RTL-level verification is slow, while many tests are irrelevant to the system-level verification needs. RTL-based verification can start only after the RTL model is available. RTL-level has it’s own complexity, reflected by high debug effort.

Proposed solution: !ESL verification (ESL = Electronic system level) Use verification models directly on the abstract model – Early verification! Use the abstract model to better describe the goal – more accurate specifications! If possible, use synthesizable abstract models – make the connection between TLM and RTL

Advantages: High quality specifications. TLM bugs are debugged earlier (no need for RTL to be ready) and in their natural context. Earlier development of test benches and debug collaterals. Wider verification capabilities – it’s possible to apply testing scenarios that are impractical for RTL simulation. More levels of abstraction. Bug PREVENTION in the TLM later on reduces the need for bug DETECTION in the RTL.

If synthesizable models are used : Use RTL-based verification methods in tandem with the previously described methods. Use a mix of RTL modules and synthesized TLM modules. Re-use checker for the RTL simulation.

:Bottom line More levels of abstraction allows better, faster and earlier verification.

Down to the details: Choosing a modeling technique It should be simple enough to allow one-to-one correspondence. It should be formal enough to enable automated analysis and test generation. It should be powerful enough to capture a wide variety of TLM specifications. CPN!! (Colored Petri Nets)

CPN example NOP n = n + i p1 p3 p4 p2 If i<100 then i + 1 If i<100 then (n,i) (n,i) If i>=100 then n If i<100 then n n t1 t2

Translates to this SystemC code: n = 0; for (int i = 0; i < 100; i++){ n = n + i; }

Example: a CPN for a router

The development arsenal: ( Ordered from the most abstract (up) to the least abstract ) SystemC UnSynthesizable portion of System Verilog Synthesizable portion of System Verilog Verilog (RTL) Standard C BlueSpec

RTL disadvantages: Large conceptual gap. Time consuming to verify. Difficult and time consuming to create. Accommodating specification changes is difficult. Evaluating alternative implementations is difficult. Implementation specific (FPGA vs. ASIC)

The proposed solution: Design, develop and synthesize from a higher level of abstraction. High-level synthesis is now taking shape. Next are two exemplary methods for implementing HLS. Each example represent one of two approaches to the challenge.

Requirements from future HLS designs ~50 Million gates at 2010 Correctness of construction. Predictable performance. Predictable functionality. While keeping time-to-market constraints, power, Area, verification, etc. Getting harder and harder!! Quality close to hand-written.

The BlueSpec methodology In a nutshell: use “Guarded atomic actions” instead of dead- on C-style functional description, and let the compiler handle the creation of any needed control circuitry. BlueSpec represent the approach in which the programmer designs the model in an extremely high-level language, and the implementation is created automatically.

How it works: The developer specifies all the needed modules/instances (registers, FIFO’s, Queues, etc.) The complier fills in automatically all the necessary control circuitry. Any conflict between “actions” is resolved by that circuitry, by means of Muxing, etc. System behavior is defined by using “Guarded atomic actions” or “rules”. The developer need not attend to things like mutual access to resources, as long as he keeps the actions “atomic”. Notice an important characteristic: every possible legitimate behavior of the system can be characterized as a series of atomic actions on the state.

Actions to hardware: First approach – correct but inefficient Rule R : when π (s) sⁿ :=δ(s) while (some π is true) do 1) select any R, s.t. π(s) is true 2) sⁿ := δ(s)

Actions to hardware: Second approach – much better ( more parallelism ) Compute predicates for each rule Compute next state for each rule STATESTATE Scheduler Selector (Mux’s and priority encoders) Read Update

Rules: example (router) In0: when (True) { req0 = port0.pop; sharedPort.enq(req0); fifo.enq(Tag0); { Out0: when (fifo.first == Tag0) { resp0 = sharedPort.pop; fifo.deq; port1.enq(resp0); {

Catapult C-based synthesis The conceptual gap

An ideal next-gen design flow

Mentor Graphic’s solution Differentiate the “intelligence” part from the design. The developer creates only the implementation-independent portion of the design. Catapult’s C engine adds the rest. Advantages Swift swaps from one implementation to another. Changes are maid to the Catapult engine in a very short time. C modeling advantages (ease of development, flexibility, speed of verification, etc. Quick learning of the system by developers (~ 3 weeks, instead of months)

Mentor Graphic’s Catapult C-based synthesizer

Catapult C represents the approach in which the developer uses a more standard language (C in that case), and the implementation is created in a user-aided process.

Summary Key point: use more, higher, levels of abstraction. Take advantage of the new richness of abstraction levels. Gain more speed, flexibility, quality and efficiency in both development AND verification of digital designs.