HIGH LEVEL DESIGN SYNTHESIS AND VERIFICATION Problem design

HIGH LEVEL DESIGN SYNTHESIS AND VERIFICATION

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-level has it’s own complexity, reflected by high debug effort. RTL-based verification can start only after the RTL model is available.

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: More levels of abstraction. High quality specifications. Earlier development of test benches and debug collaterals. TLM bugs are debugged earlier (no need for RTL to be ready) and in their natural context. Wider verification capabilities – it’s possible to apply testing scenarios that are impractical for RTL simulation. 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. Re-use checker for the RTL simulation. Use a mix of RTL modules and synthesized TLM modules.

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 powerful enough to capture a wide variety of TLM specifications. It should be formal enough to enable automated analysis and test generation. CPN!! (Colored Petri Nets)

CPN example p 1 n p 2 t 1 NOP If i<100 then (n, i) p 3 (n, i) t 2 If i<100 then i + 1 n=n+i If i>=100 then n p 4 If i<100 then n

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

Example: a CPN for a router

High level synthesis

The development arsenal: (Ordered from the most abstract (up) to the least abstract) Standard C Blue. Spec System. C Un. Synthesizable portion of System Verilog (RTL)

RTL disadvantages: Large conceptual gap. Difficult and time consuming to create. Time consuming to verify. Evaluating alternative implementations is difficult. Accommodating specification changes 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 functionality. Predictable performance. Quality close to hand-written. While keeping time-to-market constraints, power, Area, verification, etc. Getting harder and harder!!

The Blue. Spec methodology In a nutshell: use “Guarded atomic actions” instead of deadon C-style functional description, and let the compiler handle the creation of any needed control circuitry. Blue. Spec 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. ) 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”. The complier fills in automatically all the necessary control circuitry. Any conflict between “actions” is resolved by that circuitry, by means of Muxing, etc. 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) Update S T A T E Compute predicates for each rule Scheduler Read Compute next state for each rule Selector (Mux’s and priority encoders)

Rules: example (router) In 0: when (True) { req 0 = port 0. pop; shared. Port. enq(req 0); fifo. enq(Tag 0); } Out 0: when (fifo. first == Tag 0) { resp 0 = shared. Port. pop; fifo. deq; port 1. enq(resp 0); }

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. Quick learning of the system by developers (~ 3 weeks, instead of months) C modeling advantages (ease of development, flexibility, speed of verification, etc.

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.