1. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 1 ECE 406 – Design of Complex Digital Systems Lecture 16: Introduction to Buses and Interfaces Spring 2009 W. Rhett Davis NC State University with significant material from Paul Franzon, Bill Allen, & Xun Liu

2. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 2 Announcements l HW#7 Due Tuesday

3. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 3 Mentor Moment l Your Career choice should be the intersection of your » passions » abilities » resources l In my case: » passions: analog & digital circuit design, programming, digital signal processing » abilities: digital design, software development » resources: software, semiconductor manufacturing, analog & digital circuit design » end result: computer-aided design (CAD i.e. software) for digital circuit designers

4. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 4 Today’s Lecture l Introduction Buses & Interfaces l Bus Design » Synchronous » Asynchronous l Bus Performance

5. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 5 Interfaces l To this point, we have used a single signal (clock) to coordinate transfers of data between blocks l Today, we’re introducing the concept of how to coordinate transfers of data between blocks without a synchronizing (global) clock using interfaces.

6. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 6 Why do we care? l Most of what limits computing performance today is the speed at which data can be moved l Most of the new digital systems that need to be designed are the interfaces that move the data Processor Network Disk-Drive DRAM

7. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 7 Terminology l What is an Interface? l What is a protocol?

8. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 8 Examples of Protocols l What are some examples of protocols in everyday life? Answering the phone Passing a Knife Others? - Hello, this is Rhett Davis - Hello, Dr. Davis, can you make Project #2 easier? - I’ll have to think about it. - Present knife, blade pointing towards yourself - Other person takes a hold of knife, says “Thank you” - Let go of knife

9. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 9 Key Question in Interface Design l What are the consequences of not following the protocol? - Project #2 is actually harder - Someone gets cut by the knife - Data is lost in the transfer

10. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 10 Example of Interface l Bus structure » Shared communication link between devices » Use a single set of wires to connect multiple devices » Bus protocol determines how data is transferred Device 0Device 2 Device 1 16bits

11. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 11 Bus Signals l Two groups: control and data. » Control: –clock –bus request and grant –command (e.g., read vs. write) » Data: –data to be transferred –address of data to be transferred

12. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 12 Protocol Classifications l Timing » Synchronous: with a common clock » Asynchronous: without a common clock l Response » Whether assertion of a coordinating signal receives a response (responsive) or not (non-responsive) » Two signals to perform the handshaking are referred to as a responsive pair. l Initiator » Which module initiates the transfer: sender or receiver l Control level » Whether the signal is coordinating the transfer of a single element of data (transfer control) or a block of data (flow control).

13. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 13 Synchronous Bus l A clock is part of the control signal. l All devices time their actions based on common clock. » NOTE: This is NOT the same as the processor clock. l Transactions take a fixed number of clock cycles. » Control is simple: (1) Ask for something. (2) Wait for a fixed number of cycles. (3) Complete the transaction. l Useful when skew between clocks is unknown l Generally faster than asynchronous

14. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 14 Synchronous Bus Transaction A protocol example: 1. Processor raises “Read Request” signal; this signal stays high until the request is complete. No other device gets the bus while “ReadReq” is high. 2. At the same time, the processor places the address on the data lines; the address must stay on the bus for two clock cycles. 3. After the address, the memory takes four cycles to access data. 4. The memory places the data on the bus and keeps it there for two clock cycles. 5. The processor drops the Read Request signal.

15. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 15 Synch. Bus Timing Diagram clock request data receiversender data request clock address 2 cycles data 2 cycles 4 cycles

16. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 16 Classification of this Protocol l Timing l Response l Initiator l Control Level

17. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 17 Asynchronous Bus l No clock signal. l Devices use “responsive handshake” to coordinate » Move to next protocol step when both parties agree. l Accommodates a wide variety of devices. » Varying latency ok. » Easier to make bus longer, because timing is not as precise.

18. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 18 Asynch. Bus Transaction A protocol example: 1. Device places address on bus and raises ReadReq; memory raises Ack to indicate that it has seen the request and that it has read the address. 2. Device sees Ack, drops ReadReq and address. 3. Memory drops Ack when it sees ReadReq dropped. 4. When data ready, memory places on bus and raises DataRdy signal. 5. Device sees DataRdy, reads data from the bus, and raises Ack. 6. Memory sees Ack, drops data and DataRdy. 7. Device drops Ack.

19. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 19 Asynch. Bus Timing Diagram ack request data receiversender data request addressdata drdy ack drdy

20. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 20 Classification of this Protocol l Timing l Response l Initiator l Control Level

21. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 21 Today’s Lecture l Introduction Buses & Interfaces l Bus Design » Synchronous » Asynchronous l Bus Performance

22. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 22 Protocol Implementation l Both sender and receiver need to follow the protocols » Perform the right operation(s) at the right time (or under the right input stimulus) l What architecture should be used? » Controller: Finite State Machine » Other necessary logic

23. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 23 Synch. Bus Timing Diagram clock request data receiversender data request clock address 2 cycles data 2 cycles 4 cycles

24. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 24 Receiver Design in Synchronous Bus l Since the protocol is non-responsive and the receiver is the initiator: 0 1234 765 If (data needed) 8 If (data not needed)

25. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 25 Receiver Functional Logic always @ (*) begin if(state!=0) request<=1; else request<=0; if(state==1 || state==2) data <= addr; else data <= 16’hz; end always @ (posedge clock) begin if(state==7) nextdata <= data; end

26. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 26 Sender Design in Synch. Bus l Sender responds to the request from the receiver. l Assume that interconnect delay is 1 clock cycle l Assume that the clock signals are aligned 0 1234 765 if (request==1) 8 if (request!=1)

27. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 27 Timing Diagram clock request data addressdata request clock addressdata 12654387 12654387 state Receiver Sender

28. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 28 Sender Functional Logic always @ (*) begin if(state==4 ||state==5) data <= nextdata; else data <= 16’hz; end always @ (posedge clock) begin if(state==0 && request==1) addr <= data; end

29. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 29 Today’s Lecture l Introduction Buses & Interfaces l Bus Design » Synchronous » Asynchronous l Bus Performance

30. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 30 Asynch. Bus Timing Diagram ack request data receiversender data request addressdata drdy ack drdy

31. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 31 Receiver Design in Asynch. Bus l Use finite state machine to implement responsive protocols 0 1 3 2 StateOutputs 0 1 2 3

32. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 32 Verilog Code for Receiver always @(posedge clock) case(state) 0: if (data needed) state <= 1; 1: if (ack) state <= 2; 2: if (drdy) begin state <= 3; nextdata <= data; end 3: if (!drdy) state <= 0; endcase

33. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 33 Verilog Code for Receiver always @(state) case(state) 0: begin request<=0; data<=16’hz; ack<=1’bz; end 1: begin request<=1; data<=addr; ack<=1’bz; end 2: begin request<=0; data<=16’hz; ack<=1’bz; end 3: begin request<=0; data<=16’hz; ack<=1; end default: begin request<=0; data<=16’hz; ack<=1’bz; end endcase

34. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 34 Sender Design in Async Bus l State Transition Graph: 0 1 4 23 StateOutputs 0 1 2 3 4

35. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 35 What do I expect you to know? l In the next two lectures, you should learn how to write the following Verilog modules: » Sender Interface » Sender Test-Bench » Receiver Interface » Receiver Test-Bench l Why do we need a test-bench for each? Why not simply simulate both together?

36. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 36 Today’s Lecture l Introduction Buses & Interfaces l Bus Design » Synchronous » Asynchronous l Bus Performance

37. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 37 Synch. Bus Performance l Find max. bandwidth with the following assumptions » Clock period is 50 ns. » Each bus transmission takes 1 clock cycle. » Memory latency is four clock cycles. » Data transfer is 4 bytes. (Bus width is 32 bits) Period: 50*(1+4+1)=300 ns Throughput: 4/300 = 13.3 MBps

38. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 38 Asynch. Bus Performance l Find max. bandwidth with the following assumptions: » Each handshake takes 40 ns. » Memory latency is 200 ns. » Data transfer is 4 bytes. Period: a) 40(request→1) b) 40 * 2(ack→1,request→0) c) 200 d) 40 * 3(drdy→1,ack→1,drdy →0) overall: a + max(b,c) + d = 360 ns Throughput: 4/360 = 11.1 MBps

39. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 39 Increase Bus Performance l Wider bus » Transfer more data per bus cycle. l Separate address and data lines » During write, can present address and data together. » Read ? l Block transfers » Transfer multiple data words without presenting address or releasing bus » Fewer transactions, less overhead l Split transaction bus » Allow multiple transactions to be in progress » During memory latency, could be presenting next address

40. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 40 Bus Sharing l Some devices are “masters” » able to initiate a bus transaction l Some are “slaves” » can only respond to bus requests l When multiple masters, must arbitrate for bus » Priority: Each device has a priority, which gives preference to one device over another. » Fairness: Every device that wants the bus will get it, eventually.

41. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 41 Simple Arbitration: Daisy Chain l Shared bus request line l Bus grant line runs from highest to lowest priority device » Device sees grant. If not requesting, passes it on. » Cannot guarantee fairness. arbiter Device 0Device 1Device n … request release grant

42. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 42 More Complex Arbitration l Centralized arbiter » Looks at all requests, selects one » Can become a bottleneck l Self-selection » Each device looks at the request lines, determines whether it’s the highest priority l Collision detection » Try to use the bus independently » Some mechanism determines when multiple devices have acquired the bus