bluespec talk
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

bluespec talk

  • 2,601 views
Uploaded on

Bluespec is a language based on haskell for designing VHDL and verilog hardware.

Bluespec is a language based on haskell for designing VHDL and verilog hardware.

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,601
On Slideshare
2,584
From Embeds
17
Number of Embeds
3

Actions

Shares
Downloads
47
Comments
0
Likes
2

Embeds 17

http://www.cs.brown.edu 7
https://www.linkedin.com 6
http://www.linkedin.com 4

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Synthesis of Synchronous Assertions with Guarded Atomic Actions MIT && Bluespec, Inc. guys Presented by: Suman Karumuri Andy Bartholomew
  • 2. Life Cycle of a chip
  • 3. Quarks to Parallel Universes …
    • PFET/NFET
    • Transistor ( 2 FETS)
    • NAND / OR / NOT gates.
    • Circuits
    • Modules
    • Integrated Circuits (IC)
    • ASIC’s / Chip
  • 4. Birth of a chip
    • Requirements
    • Design
    • Coding
    • Testing and simulation.
    • Formal verification.
    • Synthesis
    25 % time 75 % time
  • 5. Birth of a chip
    • Requirements
    • Design
    • Coding
      • HDL, RTL.
      • Verilog HDL
      • VHDL
        • System (transistor level)
        • Behavioral (expressions)
        • Structural (functions)
        • OO (Regular Languages)
      • SystemC
      • Lava, Bluespec (High level languages).
    • Testing and simulation
    • Formal verification.
    • Synthesis
  • 6. Birth of a chip
    • Requirements
    • Design
    • Coding
    • Testing and simulation
      • Software
      • Hardware
    • Formal verification
      • Model Checking
      • Proving programs
    • Synthesis
    3% of test space This paper Turing Award 2008
  • 7. Birth of a chip
    • Requirements
    • Design
    • Coding
    • Testing and simulation
    • Formal verification
    • Synthesis (Burn the design on FPGA)
      • Chip Area
      • Power consumption
      • Minimal number of transistors
      • Speed
  • 8. Blue spec
  • 9. Motivation
    • SystemC lessons
      • Single assignment.
      • No state.
      • No destructive assignment.
      • Chaining of states.
      • Weak Type system.
    • Lava lessons.
      • Haskell. ( Functional, Monads, Polymorphic Type inference).
      • Modules.
    • Bluespec
      • Full fledged language instead of haskell modules.
      • “ Behavioral model is atomic actions with guards on state”.
        • Data flow model
      • OO for Reuse.
  • 10. Bluespec -> Chip Extended Haskell TRS Verilog Or C RTL Synthesis Concurrency and atomicity Correct Programs TRS: Term Rewriting system RTL: Register transfer language.
  • 11. Bluespec Language
    • Extended Haskell + Bit Vectors (Data types)
    • No clocks.
    • Modules for OO.
      • Rules
      • Methods
      • Scheduler
    • Data Flow language.
      • Guarded atomic actions.
  • 12. Rules
    • Atomic Expressions.
    • Execute when the guard is true.
    • Run for 1 clock cycle.
    • Local to a module (private methods).
    • Can call methods.
    • rule sync_cache(state == Synchronize);
    • case (cache[index]) matches
    • tagged Valid {.tag, .data, .isDirty}:
    • if (isDirty) begin
    • writeToMemory({index, tag}, data);
    • end
    • default:
    • noAction;
    • endcase
    • endrule
    Guard Method Call
  • 13. Methods
    • Set of commands invoked by a rule or other methods.
    • Public methods in C++.
    • Perform an Action, Value or ActionValue.
    • method Action get_data(Address addr)
    • if (state == Ready);
    • Index i = get_index(addr);
    • case (cache[i])
    • tagged Valid {.tag, .data, .isDirty}:
    • if (tag == get_tag(addr))
    • sendToProc(addr, data); //hit
    • else //conflict miss
    • getFromMemory(addr);
    • endcase
    • endmethod
    Another way of adding guards
  • 14. Modules
    • Consists of Interfaces, Rules and Method implementation.
    • Enables Reuse.
    • interface CacheController;
    • method Action get_data(Address addr);
    • method Action write_data(Address addr,Value v);
    • method Action sync();
    • method Action flush();
    • endinterface
  • 15. Summary: Bluespec All state (e.g., Registers, FIFOs, RAMs, ...) is explicit. Behavior is expressed in terms of guarded atomic actions on the state: Rule: condition  action Rules can manipulate state in other modules only via their interfaces. interface module
  • 16. Scheduler
    • Generates a static schedule by looking at guard conditions on rules and methods.
    • Ensures atomicity.
    • Runs non-conflicting rules concurrently.
    • Rules are scheduled locally.
    • Methods are scheduled globally.
  • 17. Compiler model Compiler generates a scheduler to pick a non-conflicting subset of “ready” rules Muxing for each state element  1  n Modules (Current state) Modules (Next state) Rules      n  n guard action Scheduler  1  n  1  n “ CAN_FIRE” “ WILL_FIRE”
  • 18. SVA + Blue spec = BSV
  • 19. System Verilog Assertions (SVA)
    • A temporal logic.
    • Validate behavior of a design.
    • Uses: test benches, formal verifiers , simulation.
    • Sequences, Properties.
  • 20. Sequence
    • Simple Sequence
    • sequence seq;
      • (x ##1 y)
      • or
      • (x ##1 y ##1 z);
    • endsequence
  • 21. Sequence
    • Simple Sequence
    • sequence seq;
      • (x ##1 y)
      • or
      • (x ##1 y ##1 z);
    • endsequence
    • True on CC1.
  • 22. Sequence
    • Simple Sequence
    • sequence seq;
      • (x ##1 y)
      • or
      • (x ##1 y ##1 z);
    • endsequence
    • True on CC2.
  • 23. Complex Sequence
    • sequence reqack;
    • req && data_in == 0
    • ##1 data_in > 0 [*3:5]
    • ##1 ack && data_in == 0;
    • endsequence
    First clock cycle Starting Second Clock Cycle for the next 3-5 clock cycles Finally data_in is low when we get an ack.
  • 24. Properties
    • Made up of sequences.
    • Implication operator |-> .
    • sequence |-> property
    • property goodbuffer;
    • (req ##1 data_in > 0)
    • |-> !fifo_in.full;
    • endproperty
    • sequence |=> property
  • 25. Assertions
    • Properties are checked via assertions.
    • always assert property (goodbuffer);
  • 26. Bluespec System Verilog(BSV)
  • 27. Challenges
    • SVA model is clocked.
    • Bluespec model is not.
    • Some schedules will not be valid; designer intervention required.
      • Achieved through scheduler configuration.
  • 28. Compiling assertions
    • Sequences and properties are compiled into FSMs.
    • An assertion is turned into a module.
    • Assertions are run as rules.
    • We can use the same Bluespec compilation techniques as before.
  • 29. Compiling sequences
    • x ##1 y
    x y end
  • 30. Assertions in hardware
    • Properties can run across multiple clock cycles.
    • In software, we just spawn a concurrent thread to check the assertion.
    • You can’t do that in hardware.
    • Instead we create multiple copies of the same FSM along the length of the sequence.
  • 31. Assertions in hardware
    • always assert x ##1 y
    or t=0 x y end x y end x y
  • 32. Assertions in hardware
    • always assert x ##1 y
    or t=1 x y end x y end x y
  • 33. Assertions in hardware
    • always assert x ##1 y
    or t=2 x y end x y end x y
  • 34. Composing sequences
    • Simple booleans can be generalized into a sequence module.
  • 35. Other combinations
  • 36.  
  • 37.  
  • 38.  
  • 39. General model of an assertion
  • 40. Coverage
    • A bunch of productions in SVA are not covered in BSV
    • Recursion
      • Solve halting problem to generate FSMs.
      • Can be used when recursion depth can be statically determined.
    • Disable iff and other properties.
  • 41. Case study
  • 42. functional assertion
    • “ On a write request only one cache-way is written”
    • property goodWriteRequest;
    • write_request |=>
    • if (cache_tag_resp.next_evict_way0)
    • isWrite(way0_req)
    • && !isWrite(way1_req)
    • else isWrite(way1_req)
    • && !isWrite(way0_req);
    • endproperty
  • 43. Performance assertion
    • “ When a cpu request is made a cache memory read is made in the same cycle. For read requests, either main memory is read or result returned in next cycle.”
    • property cpu_read_perf;
    • read_request |->
    • isRead(way0_req)
    • && isRead(way1_req)
    • && isRead(tag_req)
    • ##1 isRead(c2memory_req)
    • || isRead(c2p_data);
    • endproperty
  • 44. Statistic-gathering assertion!
    • You couldn’t do this before!
    • Counting read hits
    • property count_read_hits;
    • read_request |=>
    • isValid(c2p_data);
    • endproperty
    • always assert property (count_read_hits)
    • read_hits <= read_hits + 1;
    • else
    • read_misses <= read_misses + 1;
  • 45. Advantages
    • Code Reuse. High level semantics.
    • High-level programming constructs from Bluespec + the temporal logic ala SVA.
    • More tests. Hardware simulation is a lot faster (1000x) than software simulation.
    • Dynamic testing.
    • Statistics gathering.
  • 46. Misgivings
    • Ad-hoc design (from a theoretical view point)
    • Guards may reduce concurrency.
    • Correct concurrent behavior can’t be guaranteed.
    • No public docs.
    • Tweaking scheduler for clocked model can be problematic.
    • Subset of SVA is supported.
  • 47. Extensions
    • BSV could be extended to assertions checked at specific times instead of always.
    • Further coverage of SVA
    • Constraint-guided scheduler.
  • 48. Compiling Guards
    • Before compilation
    • rule r1 (fifo1)
    • … do r1
    • … call r2
    • rule r2 (fifo2)
    • … do r2
    • After Compilation
    • rule r3
    • (fifo1 and
    • fifo2)
    • … do r1
    • … do r2
  • 49. Better model
    • rule r1
    • (if fifo1)
    • … do r1
    • (if fifo2)
    • … do r2
    Now another rule can use fifo1 while fifo2 is being used by r1.
  • 50. Guards
    • No correctness guarantees.
    • Reduced concurrency.
    Solution: Transactions in Bluespec.
  • 51. Questions?
  • 52. BSV code compliation function Vector#(64, Complex) ifft (Vector#(64, Complex) in_data); //Declare vectors Vector#(4,Vector#(64, Complex)) stage_data; stage_data[0] = in_data; for (Integer stage = 0; stage < 3; stage = stage + 1) stage_data[stage+1] = stage_f (stage,stage_data[stage]); return (stage_data[3]); Stage_f can be inlined now. But the number of transistors has tripled. stage_data[1] = stage_f (0,stage_data[0]); stage_data[2] = stage_f (1,stage_data[1]); stage_data[3] = stage_f (2,stage_data[2]);
  • 53. Folding
    • Reuse a block over multiple cycles
    we expect: Throughput to Area to decrease – less parallelism Speed up clock to compensate  hyper-linear increase in energy decrease – reusing a block f g f f g
  • 54. 802.11a Transmitter Synthesis results (Only the IFFT block is changing) TSMC .18 micron; numbers reported are before place and route. All these designs were done in less than 24 hours! 1.0 MHz 04 4.91 Combinational 12 MHZ 6.0 MHz 3.0 MHz 1.5 MHz 1.0 MHz 1.0 MHz Min. Freq Required 48 24 12 06 04 04 ThroughputLatency (CLKs/sym) 1.84 SF(2 Bfly-4s) 2.45 SF(4 Bfly-4s) 5.25 Pipelined 1.52 3.69 3.97 Area (mm 2 ) SF (1 Bfly4) Super-Folded (8 Bfly-4s) Folded (16 Bfly-4s) IFFT Design The same source code