Machine Problem 3 -- Part 2

Distribution revised: Friday, October 18th - Minor changes to Makefile and running time of simulation.  (new files are /sim/Makefile, /sim/testbench.do)

Introduction

In part 1 of this machine problem, you implemented the preparations for packet classification. Now, you will implement 3D-Queueing based on the assigned FlowID. The FPX platform supports off-chip SRAM and SDRAM, which will be utilized in this MP. You will create a queue manager that will manage linked-list pointers in the form of SDRAM addresses in SRAM. Packet data is stored in off-chip SDRAM by the Flow Buffer with is supplied as a simulation file and .edn file. The scheduler allows 3D-queueing by providing four levels of priority and Round-Robin within each priority. The scheduler is very flexible, for example, if all packets are assigned the identical priority then the scheduler is Round-Robin. In contrast, if all packets are given different priorities then the scheduler services the highest priority first.

Background: Flow Buffer

The flow buffer stores incoming packets in SDRAM by segmenting the packet into 124 byte "chunks." The chunks are maintained as a link-list, where each chunk has a pointer to the next 124 byte segment. The last chunk of the packet has the pointer to the first chunk of the next packet.

When the queue manager gives the flow buffer the pointer to the head of the packet queue, the flow buffer reads all the chunks of the packet, buffers them in temporary storage, and transmits them as a contiguous packet. At the same time, it retrieves the pointer to the next packet and gives it to the queue manager as the head of the packet queue.

Similarly, when the queue manager gives the flow buffer the pointer to the tail of the packet queue, then the flow buffer writes the incoming packet in the form of a link-list of chunks (starting from the tail pointer). After the packet has been written completely, it gives the new tail pointer to the queue manager.

Background: Queue Manager

The queue manager is comprised of three independent functions: enqueue, dequeue, and scheduler. The queue manager maintains a head pointer,number of reads, number of writes, and tail pointer for each FlowID. Since we are allowing a 16 bit flowID, we have the potential of 64K individual flows. Given each FlowID contex consists of 4 32-bit values, how much memory is required to maintain 64K flows?

Background: The SRAM Interface

The SRAM interface provides the user with an arbitrated interface between two modules. In this machine problem, you can use one interface for the enqueue process and the other for the dequeue process. The timing diagram shown uses signal that are named from the perspective of the queue manager module. For example, SRAM_D_IN is the data that is coming into the queue manager module from the SRAM interface. The timing shown in the waveforms is accurate on the interface to the SRAM interface, if you flop your input/output signals, then you need to take that into account. The SRAM interface has 19 address pins (18 downto 0) of which we will use 18 (17 downto 0) and assign pin 18 always low.  This extra pin was to allow the FPX to accept 2MB SRAM modules instead of 1MB module.  The data bus is 36 bits wide, however we will be only using the lower 32 bits.  The additional 4 bits can be used for CRC over the data, but is not implemented in this lab.  You can assign the higher order 4 bits to be zero.

Directions:

• Part 1: Structural Changes to "wrapper_module.vhd"
  • Download the MP3 part 2 distribution. We have provided you with the structural vhdl which instantiates FlowBuffer, SRAM_interface, and Queue.vhd and connected them for you. Implement your queue manager by completing queue.vhd.
  • Copy over your wrapper_app.vhd from your MP3 part 1 directory.
  • Make any necessary changes to reconcile the interfaces in wrapper_module.vhd, such as match_vector, xmit_enable, etc.
  • NOTE: Leave the debug information (SRC_PORT = FlowID) from part 1 intact.  Check that FlowID and Flow_Valid are set for every packet (including UDP control packets).
  
  
• Part 2: Generate COREgen Components
  • Create a synchronous FIFO component for buffering FlowID (16 wide, by 32 deep).
  • Create a synchronous FIFO component for the scheduler (16 wide, by 512 deep).
  • You may create any other FIFOs that your may need in your design.
  • Place VHDL files into directory /vhdl/COREgen and update /sim/Makefile to compile the *.vhd files for the fifos.
  • Copy .edn files into the build directory /syn/rad-xcv2000e
  
  
• Part 3: Implement the Scheduler
  • HINT: Create a separate entity for the scheduler and instantiate it in queue.vhd. This will break your design into more manageable components.
  • FlowID(1 downto 0) contains the packet priority. Packets with a priority of "11" have the highest priority and "00" have the lowest priority. The scheduler consists of the four instances of the 16x512 FIFO where each FIFO contains FlowIDs with a given priority. Use the FIFOs empty signals to determine which FIFO has the next FlowID for dequeuing.
  • A possible implementation for the scheduler: Enqueue and dequeue FSM could have its own data_in and write_en input ports. The scheduler would add the write requests to a service list which would be serviced in the order the requests were received. The FlowIDs in the service list would be decoded by priority and written to the corresponding priority queue. The output ports would consist of a read_en, data_out, and empty port. The empty signal would simply be the logical AND of all the priority queues (16x512 FIFOs). The data_out port would reflect of the output of the highest priority FIFO with backlogged flows. This is one on many possible implementations and any scheduler design that works is acceptable.
  
  
• Part 4: Implement the Queue Manager
  • Instantiate the FIFO to buffer the incoming FlowID. You need to wait until after Initialize goes low to begin buffering the FlowIDs. This is because the FlowBuffer discards packets during initialization.
  • Be aware that a race condition exists between the enqueue and dequeue FSM. Make sure when reading internal registers that the contents match the values in SRAM.
  • SRAM INTERFACE: Address width is (18 downto 0) only use (17 downto 0) and set bit 18 low.  Data width is (36 downto 0) only use (31 downto 0) and set rest to zero.
  • Create a process to store incoming FlowIDs based on your FSM designed in part 1 of MP3. Intialize SRAM as outlined in the lecture notes for FlowIDs 0 through 64. This is a time saving measure for simulations in which we limit ourselves to FlowIDs 64 and below. Be sure to initialize all of SRAM before synthesizing your design. The SRAM should be relinquished between tail_valid and new_tail_valid being asserted so the dequeue function can access SRAM. If the number_of_writes equals number_of_reads then place the FlowID into the scheduler only after new_tail_valid is high.
  • Create a process to dequeue (retrieve) FlowIDs from the scheduler based on your FSM designed in part 1 of MP3. The SRAM should be relinquished between head_valid and new_head_valid being asserted so the enqueue function can access SRAM. If the number_of_writes does not equals number_of_reads then place the FlowID into the scheduler only after new_head_valid is high. If signal xmit_en is not asserted then the dequeue process should be halted until xmit_en is set high.
  • HINT: SRAM request signals must be asserted during the whole memory transaction (until the value returns from memory). If you encounter problems with simulations, especially a read instruction followed by a write, extend the read to two clock cycles. This is due to violation of hold time for the read/write signal. The SRAM WILL NOT return values until it has been initialized... aka. Initialize your SRAM before designing the FSMs.  
  
  
• Part 5: Demonstrate Your Circuit
  • Setup a simulation that classifies five packets with the following attributes (FLOWID,PAYLOAD): a packet that is dropped (x0000,xDEADBEEF), two packets that don't match any CAM (x0001,x11111111) and (x0001,xFFFFFFFF), a packet that is a higher priority (x000A,x22222222), and a highest priority packet (x0007,x33333333). A control packet should be created to classify these packets with the tx_enable set to zero. The packets should be injected into your circuit it the order shown above. Create a second control packet with tx_enable set to one to begin outputing cells. Capture the requested waveforms.
  • Synthesize your circuit and generate the bitfile.  Be sure to include any vhdl files you create (except for fifo.vhd files) to the Synplicity project file, /syn/wrapper_app.prj. Every fifo used in your design should have a corresponding .edn file in the fifo prior to building your design.  Upload your bitfile to the CS536 batch test server.

   

Table 1: Symbol Key

Of Interest	Modify	Synthesizable

Table 2: Contents of MP3.tar.gz

	MP3_Part2/sim/ Simulation Folder
		/testbench/
			testbench.vhd	The testbench for this FPX module.
			clock.vhd	The clock for this FPX module.
			fake_NID_in.vhd	The fake input from the NID
			fake_NID_out.vhd	The fake output from the NID
		INPUT_CELLS.TBP		Testbench Script for generating the incoming IP packets.
		testbench.do		The Modelsim macro files.
		wave.do		Another Modelsim macro files.
		Makefile		Example make file used to automate compilation and simulation
	MP3_Part2/syn/ Synthesis Folder
		/rad-xcv2000e/
			fpx.ucf	The FPGA chip pin constraints file
			bitgen.ut	The BITGEN option file.
			build	The backend script for executing the Xilinx backend tools
			*.edn	The EDIF Macro files for synthesis with the Xilinx backend tools.
		wrapper_app.prj		The project files for Synplicity Pro. It tells Synplicity Pro which vhdl files should be included for synthesis.
		Makefile		Example make file used to automate synthesis
	MP3_Part2/vhdl/ VHDL Source Folder
		wrappers/
			cellproc_sim.vhd	The vhdl file for simulating the Cell Processor.
			frameproc_sim.vhd	The vhdl file for simulating the Frame Processor.
			ipproc_sim.vhd	The vhdl file for simulating the IP Processor.
			udpproc_sim.vhd	The vhdl file for simulating the UDP Processor.
			framewrapper.vhd	The vhdl file for the Frame Wrapper. It instantiates the Cell Processor and the Frame Processor and connects them together.
			ipwrapper.vhd	The vhdl file for the IP Wrapper. It instantiates the Frame Wrapper and the IP Processor and connects them together.
			udpwrapper.vhd	The vhdl file for the UDP Wrapper. It instantiates the IP Wrapper and the UDP Processor and connects them together.
		/rad_loopback/ The Rad_Loopback Package Folder
			blink.vhd	he vhdl file for the blink component. It controls the blinking of the LED on the FPX.
			loopback_module.vhd	The vhdl file for the loopback_module that is instantiated by the rad_loopback_core
			rad_loopback_core.vhd	The vhdl file for the rad_loopback_core component. It instantiates the wrapper_module at the ingress and the loopback_module at the egress.
			rad_loopback.vhd	The vhdl file for the top-level design of the rad_loopback.
		regex_app_sim.vhd		The vhdl file for simulating the Content Matching Module.  Use this file to copy the regex_app interface.
		wrapper_module.vhd		The vhdl file for the FireWall_module.
		<wrapper_app.vhd>		The vhdl file for the FireWall_module. This needs to be copied from MP3 part 1.
		queue.vhd		Partial VHDL file for Queue Manager
		flowbuffer_sim.vhd		the vhdl file for simulating the FLow Buffer.

Things to Turn In:

Here is a checklist of the things you need to turn in:

• Part 3&4: Implement the Queue Manager
  • Turn the following vhdl source code:
    • queue.vhd (35pts)
    • If the scheduler is a separate vhdl file include this as well
• Part 5: Test Simulation
  • Turn the simulation waveforms (roughly 7 - one per packet) which implement part 5 (28 pts)
    • As always, include a txt file describing any waveform.
    • Submit your TBP file you used for creating the test cells.
  • Synthesize the firewall
    • Extract resources used section of the mapping report. (wrapper_app.par in the syn directory) (1pt)
    • Extract timing in MHz from the timing report. (wrapper_app.twr in syn directory) (1pt)
  • Test your bitfile on the CS536 test server. (35pts)

• Submit your waveforms, the .TBP files, queue.vhd, scheduler.vhd (if separate), txt file, and a timing summary to the Electronic Homework Server.