- To understand the concepts behind system interfacing
- To understand how to communicate with an asynchronous device (SRAM)
In terms of the serial control, this project has the exact same functionality as the SerialString project; characters are read in from hyper-terminal until ‘Enter’ is pressed and then they are written back to the hyper-terminal. The key difference is the use of external asynchronous SRAM rather than internal FPGA memory to save the string as it is being typed. The SerialCtrl module will have a couple of extra states because the memory controller takes two cycles to read and write values.
CY7C1019CV33 block diagram
Design and Wire the SRAM Interface
Here is the SRAM datasheet and the pinouts for the FPGA . The memory controller is fairly simple. To read a value from memory, the 17 bit address input has to have its value latched in a register at the same time or before the rq_sram_read signal is driven high. The same holds for the address and 8 data bits on a write. The rq_sram_read/write signal should only be driven high for one clock cycle, although, they can be held high continuously. The result is that a new value is read every two cycles or a new value can be written every two cycles. When reading data from memory, the data being read should be latched at the end of the second cycle.
Detailed timing diagrams can be viewed in the data sheet for the memory. Writing a memory that operates at three cycles per read/write can be achieved with a simple state machine. The first cycle would be used to set up the data and address, the second cycle would be used to drive the control signals to the memory, and the third cycle would be used to read data from memory or give the data being written some extra padding before the next write cycle. Our preferred memory controller is slightly more complicated and allows two-cycle back-to-back reads or writes. It uses the first half of the first cycle to set up the data and address, from half-way through the first cycle to half-way through the second cycle to drive the control signals to the memory, and the second half of the second cycle to provide padding between consecutive reads/writes. We achieve this by using the negative edge of the clock for the memory control signals.
A couple of important things to note are:
Here is a new ucf file: serialsram.ucf . Use the pin assignments in this file for wiring your SRAM. You'll also have to connect your SRAM to power and ground according to the datasheet, and account for all pins. Have a TA check you work before you apply power. Be certain that your SRAM is connected to the correct voltage.
Here is a working bitfile you can use to test your SRAM. It is an implementation of Part II below.
Questions you should be able to answer:
Create a new workspace in ActiveHDL and add these files:
This project has all of the same components as the serialstring echo project, and adds a component that defines the SRAM interface. We've broken the SerialCtrl module by removing some assignments and the guts of the state machine. You need to complete the file; we've indicated in comments what should be done.
The function is similar to Lab 2, Part 3. Rather than reading and writing into FPGA memory, characters are read and stored in SRAM; then a whole string of characters is written back when the ‘ENTER’ key is pressed.
To accommodate this, data should be written into the SRAM as it is read from the uart. Each time a new character is read, the serial controller checks to see if it is the ‘ENTER’ character. If it’s not, the new value is written to the SRAM and the memory pointer is incremented. If it does match the ‘Enter’ character, all the values stored in SRAM are transmitted back to the hyper-terminal, and the memory pointer is reset to 0. Since, it is possible to write characters faster than they can be transmitted, it is important to check the TX_Buffer_Full signal before writing to the TX fifo.