EECS150 Fall 2008 Network on Chip UCB Page 1 Networks on Chip The Network on Chip (NoC) has recently become popular as a way to transport data in VLSI systems. The basic idea is that given M inputs, be able route data from any input to any of N outputs. Data arrives in packets. Given information in the “header” of a packet, a NoC should be able to select what output the data should be sent to. A high level block diagram is shown below: Crossbar SwitchInput BuffersOutput BuffersPacket FilteringScheduler In the above diagram, the input and output buffers are FIFOs featuring the Ready/Valid interface we have been using this semester. You can think of them as FIFORAMs. The packet filter is a series of simple sequential and combinational logic elements that decipher incoming packets so that the NoC knows which output to send them to. The Crossbar switch is a wire network that routes the inputs to the outputs. The Scheduler makes sure that if two different inputs are bound to the same output, they are sent one after the other instead of accidentally at the same time. More generally, the Scheduler directs which input should be directed to which output at any given time. Your job in this problem is to implement these blocks.EECS150 Fall 2008 Network on Chip UCB Page 2 A. Packet Filtering Our first task in building the NoC is to implement the packet filter. The input buffers (which are 32 bits wide) contain data in the form of packets. The packets all have the following format: Word 1: Output Buffer #Word 2: Data TypeWord 3: Data Since our input buffer is a FIFO, the first word you will see at the output is “Word 1,” the next is “Word 2,” etc. Words 1 and 2 are the packet header. The Output Buffer # specifies which of the output buffers the data attached to this packet should be sent to. Data Type specifies that the data is one of two types (“good” or “bad”). “Good data” is represented by 32’h0. “Bad data” is anything but 32’h0. The Data is the actual data (and will always be exactly one word). The packet filtering block must accomplish the following: a. Only keep “good” data. b. Strip off the header and present data in the following format: {Output Buffer #, Data}. (given an N output NoC, we will only allocate enough bits to the “Output Buffer #” as is necessary to identify each of the output ports). To increase throughput of system, we will allow intermediate buffers to hold the filtered data after it has passed through the packet filtering scheme. Thus, the packet filter will look something like the following (for each input buffer): FilterInput BuffersIntermediateBuffers where the input buffer is less wide than the output buffer to account for the bits that are appended to each data word at the output. Your task: Implement the “Filter” cloud of the packet filter. Assume that there are 4 input buffers and 4 output buffers (to the NoC as a whole: the output buffers are the FIFOs after the Crossbar switch – they are NOT the same as the intermediate buffers). Be sure to specify the width of the intermediate buffers.EECS150 Fall 2008 Network on Chip UCB Page 3 Space for your implementation of the packet filter:EECS150 Fall 2008 Network on Chip UCB Page 4 B. The Crossbar Switch The crossbar switch is a network of busses that are each 32-bits wide. The only requirement of the crossbar switch is to be able to route any of M inputs to any of N outputs. The crossbar switch sees the output of the packet filter (namely the output of the intermediate buffers which you designed in part A) and control signals from the Scheduler which you will design in part C. Below is an interface specification: Crossbar SwitchThe outputs of the intermediate buffers from part A. Remember, they are of the format: {Output Buffer #, Data}The outputs of the Crossbar and the inputs to the output buffers, which constitute the output of the NoC. This data should contain only the data from the packet filter (NOT the Output Buffer # which was appended to the words in the intermediate buffers).Control signals from the Scheduler (as many as you need)Signals to the Scheduler (assume that whatever data the Crossbar Switch sees can also be seen by the Scheduler) Your task: Implement the crossbar switch (assume that you have 4 inputs and 4 outputs). There is one restriction: a. You cannot use muxes. When you are specifying the control signals that are coming to/from your controller, you should indicate what those control signals do. You do not have to indicate how they are implemented in this part. Remember the job of the Scheduler: to avoid collisions between two inputs and a single output and directing inputs to outputs.EECS150 Fall 2008 Network on Chip UCB Page 5 Space for your implementation of the crossbar switch:EECS150 Fall 2008 Network on Chip UCB Page 6 C. The Scheduler The final piece of the NoC that you are to implement is the Scheduler. The Scheduler’s job, again, is to: a. Decide which input (more precisely: intermediate buffer) is routed to which output buffer at any given time. b. Ensure that no two+ intermediate buffers route to the same output buffer at a single time (which is really just a detail that you have to keep in mind when satisfying the first requirement). Literally, the Scheduler is just a collection of control signals that must be driven at different times. You can assume that the scheduler can see any wire from the rest of the system. Also assume that the Scheduler can talk to any other piece outside of it in the system. Remember: all the buffers in this system are Ready/Valid FIFOs. Your Task: Implement the Scheduler. Assume, as before, that the NoC has 4 inputs and 4 outputs. Don’t worry about the time efficiency of the Scheduler: it can take as long as it needs to route input data to the output buffers. Assume that modules external to the NoC will make sure that the input and output buffers get filled/emptied as they need to
View Full Document
Unlocking...