1 / 47

ECE 551 Digital System Design & Synthesis

ECE 551 Digital System Design & Synthesis. Lecture 13: Life After Verilog. Picking a Language. New lecture – Alternatives to Verilog Things used to be so simple Just VHDL vs Verilog These days the market for digital design tools and languages is getting more diverse

jafari
Download Presentation

ECE 551 Digital System Design & Synthesis

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECE 551Digital System Design & Synthesis Lecture 13: Life After Verilog

  2. Picking a Language • New lecture – Alternatives to Verilog • Things used to be so simple • Just VHDL vs Verilog • These days the market for digital design tools and languages is getting more diverse • Competitors to the entrenched HDLs are becoming more attractive • Hardware Verification Languages (HVLs) • Proprietary Modeling Languages • High-Level Model-to-Gates Converters

  3. Oh, Verilog • Now that you’ve had a some time to get used to Verilog-2001 you’ve probably noticed a few flaws. • What do you dislike about Verilog?

  4. Personality Problems [1] • It’s not always clear what will/won’t synthesize • While loops, divide/modulo operators, implicit state machines, complex for loops, etc. • Sometimes it would be nice if you could just say what you intended, instead of having to imply it. • Make this always block combinational • Make this infer a flip-flop / make this infer a latch • Make this case statement parallel** • Make this case statement have priority** ** Without relying on “hidden” synthesis pragmas!

  5. Personality Problems [2] • It’s easy to get into trouble if you’re not careful • Inferring latches • Mixing blocking & non-blocking statements • Mixing synchronous & asynchronous triggers in sensitivity lists • Some things are just misleading • I can call something a “reg” but it’s not necessarily a register?

  6. Personality Problems [3] • Some things are inconvenient • Why can’t I use multi-dimensional arrays of wires as inputs & outputs? • Wouldn’t it be nice if it had… • Language features like TYPEDEF, STRUCT, ENUM • Better synchonization features for parallel operation in testbenches, like semaphores and FIFOs • Built-in object-oriented programming for testbenches • Easier integration with C programs

  7. Where do you go from here? • “Verilog just needs a tune-up” • SystemVerilog • “Verilog needs stricter rules” • VHDL • “Actually, we need something even more abstract” • BlueSpec • “I need something that is easier to plug in to my high-level system model” • SystemC

  8. SystemVerilog – The ‘new’ Verilog • New IEEE Standard introduced in 2005 • “Successor” to Verilog – merged into Verilog-2009 • Mostly the same syntax/semantics • Backwards compatible with most Verilog code • A lot of new features for Verification (testbenches) • Tweaks to existing Verilog constructs to make them easier to use • New datatypes

  9. SystemVerilog – Datatypes [1] • New variable types: LOGIC, BIT • Logic can be used • As left side in Behavioral block • As left side in continuous assignment • As output of a structural module • No more worrying about declaring wirevsreg! • Less confusing – the name doesn’t trick people into thinking it is always a register, like reg does. • bit – Like logic, but cannot have x or z values

  10. SystemVerilog – Datatypes [2] • TYPEDEF – C-style defined data types typedef pixel logic[23:0]; pixela_pixel; pixel[1920:1][1080:1] my_display; • Why not just do this with a macro? • Typedefs do not have the global scope problem of macros. • Typedefs can be evaluated during Syntax Check rather than during Elaboration, so they are easier to debug.

  11. SystemVerilog – Datatypes [3] • ENUM – Enumerated types typedef enum logic[2:0] {RESET, COMPUTE1, COMPUTE2, SEND, ERROR} states_t; states_t current_state, next_state; … if(current_state == COMPUTE1) next_state = COMPUTE2; …

  12. SystemVerilog – Datatypes [4] • Structures & Unions typedef struct packed { logic [2:0] packet_type; logic [3:0] dest_addr; logic [47:0] data_payload; } router_packet; case(my_packet.packet_type) DATA3: if(my_packet.dest_addr == MY_ADDR) … …

  13. SystemVerilog – Always Constructs [1] • Always Blocks – can specify what you’re trying to do! • Combinational Block: always_comb begin //Can omit sensitivity list! a = b; //Tool adds it like @(*) c = ~d; end

  14. SystemVerilog – Always Constructs [2] always_ff@(posedge clk) //still need sensitivity list state <= next_state; //for flip-flops. Why? always_latch if(en) d_out <= d_in; This can’t “force” the synthesis tool to synthesize flip flops if you describe latch-like behavior However, it can warn you that what you described didn’t match what you said you wanted!

  15. SystemVerilog – Control Constructs[1] • Case and If/Else have priority by default in Verilog. • To match this behavior in synthesis, we need a cascade of muxes. • Designers commonly use synopsys parallel_case to force the synthesizer to make a single mux instead. • Synthesizer pragmas give different information to the synthesis tool than to the simulator. • This is fundamentally bad. We want synthesis tool and simulator to have the same information!

  16. SystemVerilog – Control Constructs[2] • unique keyword modifier unique case (sel) CASE1: … CASE2: … CASE3: … endcase • unique tells the synthesizer and simulator that one, and only one, case will be selected – ignore priority so you can synthesis a single parallel mux! • Also works with if: unique if(…) …

  17. SystemVerilog – Control Constructs[3] • priority keyword modifier priority case (sel) CASE1: … CASE2: … endcase • priority tells the synthesizer and simulator that at least one of the cases will always match. If this doesn’t happen in simulation it will warn you. • Also works with if: priority if(…) … • Easy way to avoid accidental latches!

  18. SystemVerilog – Interfaces • Can use multi-dimensional arrays in I/O module(input [1:0] a[9:0][3:0], output b); • Can define interfaces separately from modules • Allow an interface to be re-used in multiple modules interface intf; logic a, b; modport in (input a, output b); modport out (input b, output a); endinterface

  19. SystemVerilog – Verification • Most of SystemVerilog’s new features are in non-synthesizable constructs for testbenches • SystemVerilog is sometimes referred to as an “HVL” – Hardware Verification Language. • New verification features include • Dynamic & associative arrays, Classes • FIFOs, semaphores, mailboxes • Assertions and time sequencing • Built-in support for computing test coverage • Extended support for easy generation of random test vectors

  20. SystemVerilog – Current State • SystemVerilog is already widely used in industry for designing testbenches • So why, you ask, did we learn Verilog-2001 instead of SystemVerilog/Verilog-2009? • Unfortunately, many companies are using not yet adopting SystemVerilog for synthesis • Main problem: Tool Support is Lacking • Ex: Xilinx ISE still does not support SystemVerilog at all. • Most companies cannot migrate until their full toolchain supports the language

  21. VHDL – Introduction • VHDL was introduced in the 1980s as a true Hardware Description Language • Meant to describe existing circuits • Not originally meant as a design tool • As a result, VHDL is very verbose and strongly-typed; this is both its greatest strength and weakness • Because it has been around so long, VHDL still enjoys great support from design tools.

  22. VHDL – Compared to Verilog • VHDL and Verilog are not radically different. • Both have 3 levels of abstraction • Structural / Gate • RTL • Behavioral • Both have built-in parallelism and the concept of sensitivity lists • Both have some constructs that synthesize and others that are meant for verification • Both have If/Else, Case, For, Generate

  23. VHDL – Sample Code library ieee; use ieee.std_logic_1164.all; ENTITY compare8 IS PORT( x, y: ;IN std_logic_vector(7 DOWNTO 0) ; res: ;OUT std_logic ); END compare8; ARCHITECTURE struct OF compare8 IS BEGIN res <= '1' WHEN (x = y) ELSE '0'; END struct;

  24. Verilog – Same Functionality module compare8(input [7:0] x, y, output res); assign res = (x == y); endmodule • VHDL is a lot more verbose than Verilog in general. Some people like this, because it forces them to more explicitly describe each circuit • Like Verilog-2009, VHDL allows (actually requires) you to separately define your interfaces. • VHDL also allows you to form packages and libraries to help design re-use.

  25. VHDL – Strict Typing • Variables in VHDL are strictly typed • Verilog is more loosely typed • For example, in Verilog you can • Assign a value from a variable to an array of wires • Assign the value of a 4-bit wire to a 6-bit wire (Verilog will automatically extend the value) • Assign the value of a 6-bit wire to a 4-bit wire (Verilog will automatically truncate the value). • VHDL requires you to explicitly convert variables to the same type or it will give an error.

  26. VHDL – Conclusion • Second most popular HDL after Verilog • Very good tool support (maybe better than Verilog) • Stylistically, some people may prefer a more verbose, strongly-typed language • Most comparisons have shown that people are more productive with Verilog. • Verilog is better for verification, since it is easier to simulate and has better verification constructs. • VHDL is still trying to catch up to some of the additions to Verilog-2009/SystemVerilog

  27. Bluespec – Introduction • Extension to SystemVerilog – Bluespec SystemVerilog (BSV) – but uses a much different design paradigm than Verilog • Bluespec uses its own compiler to convert from Bluespec SV to an RTL Verilog description • Goal: Create increased abstraction between design description and implementation • Key Concept: Let the Bluespec compiler do the heavy lifting rather than the synthesis tool! • What are the pros/cons of a proprietary language and compiler?

  28. Bluespec – Proprietary Compiler • Have very smart people design a good compiler that automates common HDL design tasks • Let average** people take advantage of the automation and save time • This can be better than including it as part of the Verilog synthesis standard because • Don’t have to wait for tool vendor support (years!) • Don’t have to wait for IEEE standardization (years!) • Can be responsive to current trends in design **Engineering average

  29. Bluespec – Major Concepts • Originally created as an internal language to make router/switch design more efficient. • Idea: Often we spend a long time coding interfaces. • Particularly true as more designs need to support USB, eSATA, BaseX Ethernet, etc. • Add features geared towards making it easier to design interfaces • Add in the concept of atomic operations to handle resource contention -> No race conditions • Automate FIFO queues, ready/enable signals • Force compliance so the designer can’t screw up.

  30. Bluespec – Sample Code [1] • Describing a simple Counter in Bluespec • Bluespec uses a functional interface to modules. • Call module functions rather than connecting to ports • Keep in mind that the Bluespec compiler will convert this all to standard Verilog in the end interface Counter; method Bit#(8) read(); methodAction load(Bit#(8) newval); method Action increment(); endinterface

  31. Bluespec – Sample Code [2] (* synthesize *) module mkCounter(Counter); Reg#(Bit#(8)) value <- mkReg(0); method Bit#(8) read(); return value; endmethod methodAction load(Bit#(8) newval); value <= newval; endmethod method Action increment(); value <= value + 1; endmethod endmodule //What’s missing that you would expect?

  32. Bluespec – Abstraction • Things like clock and reset signals are implicit in Bluespec • Although no clock was ever mentioned, creating a register implies a clock. The compiler takes care of making sure that the counter only increments on clock cycles. • Muxes – such as the one needed to do Load vs Increment – are also hidden from the user. • Bluespec methods are designed to always be atomic; you can try to load and increment in the same clock cycle. The compiler will set up the necessary priority logic.

  33. Bluespec – Future • Is Bluespec a challenger to Verilog? A supplement? I’m not really sure yet. • Some pro designers have told me that Bluespec is great. Others have different opinions… • It provides a much different type of abstraction that may be a lot easier for programmers without hardware experience to use • One big hurdle: It isn’t free. You must license the Bluespec compiler if you want to use it at all.

  34. SystemC – Introduction • SystemC is not really a proper HDL • It is a framework for the C language that allows you to model hardware-like behavior • Advantage – Makes it easy to model a full system; can simulate other elements in C. • Can test software algorithms in C side-by-side with their hardware models • Can be used to verify HDL code efficiently • Disadvantage – Not designed to be synthesized. • Some companies are working on synthesis of SystemC, but not ‘mainstream’ quite yet.

  35. SystemC – Implementation • Fundamentally, SystemC is just a library you can use in C. • How does a software implementation in C need to be extended to properly model cycle-accurate hardware? • Concurrency, race conditions, delays, timing requirements, event-driven updates/edges • Resolving multiple drivers, 4-value logic • It must be possible since this is what the simulators are doing internally!

  36. SystemC – Sample Code [1] #include "systemc.h" SC_MODULE (first_counter) { //counter design example sc_in_clk clock ; //module I/O interface sc_in<bool> reset , enable; sc_out<sc_uint<4>> counter_out; sc_uint<4> count; voidincr_count () { //method to increment count if (reset.read() == 0) { count = 0; counter_out.write(count);} else if (enable.read() == 1) { count = count + 1; counter_out.write(count); cout<<"@" << sc_time_stamp() <<" :: Incremented Counter " <<counter_out.read()<<endl; } }

  37. SystemC – Sample Code [2] //counter example continued SC_CTOR(first_counter) { //constructor for counter class cout<<"Executing new"<<endl; SC_METHOD(incr_count); sensitive << reset.neg(); //add to sensitivity list sensitive << clock.pos(); } }

  38. SystemC – Current State • SystemC is getting pretty popular as an intermediate hardware modeling step. • It provides a bridge between algorithm development (in C) and implementation (in HDLs) • SystemC synthesis tools are beginning to become mainstream. • MentorGraphics shipped Catapult C in 2010. • Smaller companies like Forte, Bluespec, SystemCrafter • OSCI is working on a synthesis standard

  39. Other Projects • The idea of skipping HDL authoring altogether is gaining steam among some • Many recent products that attempt to convert from C, MatLab, and Dataflow Graphs • The jury is still out on whether these tools can achieve similar levels of performance, power, and area efficiency as direct HDL implementation. • But in some cases, improved productivity is more important than an efficient hardware design.

  40. Wrapping Up

  41. Digital Design & Synthesis • The goal of this course is to give you most of the skills needed to take a design from an idea to a product • At this point you should be capable of handling many different phases of the design project while working solo and in a team • These are real job skills! Put them on your CV and talk about them in job interviews.

  42. Planning • What platform should I use for this project? • Standard Cell, Custom ASIC, MPGA • FPGA, PLD • ROM • Software? • What HDL / tools should I use? • Verilog, VHDL, SystemVerilog • Bluespec, SystemC

  43. Design Entry • How should I architect this design? • Hierarchy • Abstraction level (structural, RTL, behavioral) • How do I describe specific types of logic? • Datapaths • Control logic • State Machines • How can I design for re-use? • Parameterization • Generated Instantiation

  44. Functional Test • Architecting Testbenches • File-based testing • Self-checking / Automated testbenches • Designing Test Patterns • Exhaustive Testing vs Non-Exhaustive Testing • Selecting tests and writing a test plan • Identifying corner cases • Debugging a Design • Reading waveforms • Identifying problems

  45. Synthesis • Setting up Design Rules and Constraints to meet my design goals • Timing, Area • How do I read synthesis reports? • Identifying when constraints are met / un-met • Identifying the critical path, finding slack time • How do I control synthesis optimizations? • Top-down vs Bottom-up • Logic restructuring, ungrouping, effort levels

  46. Post-Synthesis Validation • What sort of potential problems should we anticipate? • Inferring Latches • Multiple Drivers • Timing differences • How do we fix these problems? • What should we look for on a post-synthesis waveform? • X’s, Z’s • Timing delays

More Related