XSV
Board 1.0 – VHDL Interfaces and Example Designs

PC to SRAM Interface
Project Supervisor - Peter Sutton
School of Computer Science and Electrical Engineering
University of Queensland, Brisbane, Australia.
Last Modified: 23 February
2001
2.0 The stand-alone design vs. the VHDL module
2.1 The stand-alone PC-to-SRAM interface
2.2 The PC-to-SRAM interface VHDL module
3.0 Files needed for the stand-alone design
4.0 Files needed for the VHDL module
5.0 CPLD requirements for the PC-to-SRAM interface
6.0 Using the PC-to-SRAM interface module in a user design
6.2 Requirements for using the module
6.3 Converting a design to use “sraminterfacewithpport” instead of
“sraminterface”
7.0 Communication protocol overview
8.0 Communication protocol details
8.1 Initialising the PC-to-SRAM interface
8.2 Performing the set address operation
8.3 Performing the write operation
8.4 Performing the read operation
8.5 Performing the apply settings operation
This design provides an interface for a PC to access the SRAM on the XSV board through the board’s parallel port connection. When this interface is programmed into the Virtex FPGA, a connected PC can read from and write to any location in one bank of the SRAM. This document describes two designs that implement this PC-to-SRAM interface – a stand-alone design and a VHDL module.
The author would like to acknowledge a similar design for the XS40 board (also from XESS Corp.) developed by Universidad de Sevilla. Their design was a source of ideas for the design presented in this document for the XSV board. See http://www.xess.com/projects/xs_pc_intfc.pdf and http://www.xess.com/projects/xs_pc_intfc.zip for the Universidad de Sevilla design.
This design contains a top-level entity and can be directly implemented on the Virtex FPGA. When the FPGA is configured with this design, a PC has complete read and write access (through a parallel cable) to the left bank of SRAM on the XSV board.
Note that the PC-to-SRAM interface can be used to give access to either bank of SRAM. However, the bank used must be specified in the top-level entity and UCF. Currently the top-level and UCF together specify that PC is given access to the left bank of SRAM.
Once the stand-alone design has been implemented and its bit file generated, this bit file can be used at any point as a debugging tool. Suppose that you are developing a design for the XSV board and at some point wish to view the contents of one of the SRAM banks. Simply configure the FPGA with the bit file of this stand-alone PC-to-SRAM interface. The content of the SRAM is unaffected by the configuration process. Once the interface is programmed into the FPGA, a utility programme on the PC can be used to view (and even change) the SRAM contents. A Visual Basic programme that provides these features, “XSVSRAMUtility.exe” is included with this resource collection. See the document called “XSV SRAM PC Utility”, which describes the programme.
In addition to the stand-alone version of the PC-to-SRAM interface, there is a reusable VHDL module that provides the same functionality. This module is called “sraminterfacewithpport” and is defined in the file “sraminterfacewithpport-sv01.vhd”. Note that this module itself contains other internal modules. As a consequence, several VHDL files need to be added to a user design when the “sraminterfacewithpport” module is going to be used. Note that “sraminterfacewithpport” is referred to in this document as the “top-level” of the module, but it is not a top-level entity in the true sense of the word. This VHDL entity is simply the highest-level entity of the module.
To understand this module, you first need to be familiar with the SRAM interface module (the VHDL entity called “sraminterface”) in this resource collection. The SRAM interface provides a user design with a simple interface to a bank of SRAM. The module is described in the document called “SRAM Interface”.
The PC-to-SRAM interface VHDL module is designed as a replacement for the (plain) SRAM interface VHDL module. Wherever a user design uses the SRAM interface module, it can instead use the PC-to-SRAM interface module. The PC-to-SRAM interface module provides the same direct access capabilities to SRAM that the SRAM interface module provides. Additionally, however, the PC-to-SRAM interface module also allows a PC to access the SRAM.
Using the PC-to-SRAM interface module, rather than the stand-alone design, makes viewing (and changing) the SRAM contents from a PC a much simpler process. Suppose a user design has correctly embedded the PC-to-SRAM interface module. The user design’s bit file has been generated and used to configure the Virtex FPGA. When the time comes to view the contents of an SRAM bank, no new bit file needs to be downloaded to the FPGA, because the user-design’s bit file already includes the circuitry necessary to communicate with the PC. A utility programme on the PC can be used straight away to view and change the contents of SRAM.
Thus the advantage of the PC-to-SRAM interface module over the stand-alone design is that no new bit files need to be downloaded once the module is embedded in the user design.
· pctoleftsramtoplevel-sv02.vhd (Contains the top-level entity “pctosramtoplevel”)
· pctosraminterface-sv06.vhd
· sram512kleft16bit50mhzreadreq-sv05.vhd (or sram512kleft16bit50mhzreadreq-sv05c.vhd)
· UCF is :"Y pport, Y debug, Y timing, Y IOB outputs, N input delay, Y fast slew.ucf"
The “svXX” suffix on the filenames stands for “source version XX”. Previous versions of these files are obsolete and have not been released.
This file contains the top-level entity for the design, which is called “pctosramtoplevel”. This entity connects the PC-to-SRAM interface to the left bank of XSV SRAM.
This VHDL module is responsible for implementing the communication protocol that is used between the PC and the XSV board. It translates requests from the PC into signals for the SRAM interface module and vice-versa.
This is an SRAM interface module, which provides the actual access to the SRAM bank. For more information on this module, see the document describing the “SRAM Interface” design.
The SRAM interface in this file uses a 2 clock cycle read. If you wish to use a 1 clock cycle read then the file “sram512kleft16bit50mhzreadreq-sv05c.vhd” can be used in place of this file.
· sraminterfacewithpport-sv01.vhd (This is the top-level (or highest-level) of the VHDL module).
· sram512kleft16bit50mhzreadreq-sv05.vhd (or sram512kleft16bit50mhzreadreq-sv05c.vhd)
· memorymultiplexor-sv01.vhd
· pctosraminterface-sv06.vhd
This file contains the actual PC-to-SRAM interface VHDL module called “sraminterfacewithpport”. Although this entity is the highest-level entity of the module, it internally uses other VHDL modules. That is why the other files below must also be added to any user design that uses the PC-to-SRAM interface module.
The PC-to-SRAM interface module internally uses the SRAM interface module in this file to provide the direct SRAM access capabilities. See section 2.0, “The stand-alone design vs. the VHDL module” above.
The SRAM interface in this file uses a 2 clock cycle read. If you wish to use a 1 clock cycle read then the file “sram512kleft16bit50mhzreadreq-sv05c.vhd” can be used in place of this file.
The VHDL entity “memorymultiplexor” in this file multiplexes the connections to the SRAM interface module. At any point in time, the SRAM interface is either to be connected to the user design (allowing the design normal SRAM access) or to the “pctosraminterface” entity (allowing a PC access to the SRAM). This VHDL file takes care of switching these connections as necessary.
This VHDL module is responsible for implementing the communication protocol that is used between the PC and the XSV board. It translates requests from the PC into signals for the SRAM interface module and vice-versa.
The PC-to-SRAM interface design requires the Virtex FPGA to connect to the XSV board’s parallel port connector. The XSV board is such that the FPGA is able to connect to the parallel port connector only through the CPLD. That is, the CPLD must be configured with a design that connects some of the FPGA pins, through the CPLD, to the pins of the parallel port connector.
For the stand-alone PC-to-SRAM interface FPGA design, the CLPD must be configured so that the following connections are made between the Virtex FPGA pins and the pins of the parallel port connector:
|
This Virtex FPGA
pin… |
…must connect
(through the CPLD) to this parallel port connector pin: |
|
P177 |
D0 |
|
P167 |
D1 |
|
P163 |
D2 |
|
P156 |
D3 |
|
P145 |
D4 |
|
P138 |
D5 |
|
P134 |
D6 |
|
P124 |
D7 |
|
P132 |
S3 |
|
P133 |
S4 |
|
P139 |
S5 |
|
P141 |
S6 |
For the PC-to-SRAM interface module, technically different Virtex FPGA pins could be specified, provided that a corresponding change was made to the CPLD design. However, for simplicity, it is recommended that the same Virtex FPGA pins listed in the above table be used.
The following are examples of CPLD designs that connect the pins in the manner listed in the above table:
· The default SVF file for the CPLD that comes with the XSV board, called “dwnldpar.svf”. Configuring the CPLD with this SVF file allows the PC-to-SRAM interface to be used.
· The CPLD design associated with the IP Stack FPGA design in this collection. The source file for this design is called “cpldnet.vhd”. The UCF for the CPLD for this design is called “cpldpins.vhd”. Configuring the CPLD with this design will also allow the PC-to-SRAM interface to be used.
Any other CPLD design can be used, providing it makes the pin connections listed in the table above.
While using the PC-to-SRAM interface stand-alone design is relatively straight forward, using the module version of the design is a little more involved.
The PC-to-SRAM interface module is a VHDL entity called “sraminterfacewithpport”.
The “sraminterfacewithpport” entity includes all the ports found in the “sraminterface” entity. These ports are :
|
Inputs: |
Outputs: |
Birdirectional: |
|
CLK |
readData(15:0) |
SRAMLeftData(15:0) |
|
Resetn |
canRead |
|
|
doRead |
canWrite |
|
|
doWrite |
CELeftn |
|
|
writeAddr(18:0) |
OELeftn |
|
|
writeData(15:0) |
WELeftn |
|
|
readAddr(18:0) |
SRAMLeftAddr(18:0) |
|
These ports are used by “sraminterfacewithpport” in exactly the same way as for the “sraminterface” entity, as described in the “SRAM Interface” document.
The “sraminterfacewithpport” entity contains two extra ports in addition to the above ports. These two extra ports are as follows:
|
Port name: |
Direction: |
Description: |
|
ppdata(7:0) |
Input |
Must be connected to the data pins of the parallel port connector. |
|
ppstatus(6:3) |
Output |
Must be connected to the status pins of the parallel port connector. |
Using the PC-to-SRAM interface module (i.e. the “sraminterfacewithpport” entity) in a user design simply involves meeting the following requirements in regard to the module’s ports.
The ports that are identical to the SRAM interface ports (i.e. the ports of the “sraminterface” entity) are to be connected in exactly the same way as they are for that interface. These connections are described in the “SRAM Interface” document.
The two ports “ppdata” and “ppstatus” must have their connections directly propagated all the way up to the top-level of the user design, as follows:
· Bits 7 to 0 of the “ppdata” input must be connected to the FPGA pins that correspond to pins D7 to D0 respectively of the parallel port connector on the XSV board.
· Bits 6 to 3 of the “ppstatus” output must be connected to the FPGA pins that correspond to pins S6 to S3 respectively of the parallel port connector on the XSV board.
For an explanation of how to ensure that the correct connections are made from the FPGA, through the CPLD, to the parallel port connector, see section 5.0, “CPLD requirements for the PC-to-SRAM interface”.
Any user design that uses the “sraminterface” module to provide access to a bank of SRAM can be easily modified to use instead the “sraminterfacewithpport” module. Making this modification will allow the user design normal access to an SRAM bank, while also allowing a PC to access the same SRAM bank.
The following changes need to be made to an existing user design to change from the “sraminterface” module to the “sraminterfacewithpport” module:
· Add the extra necessary files to your design, as listed in section 4.0 “Files needed for the VHDL module”.
· Change all declarations of an “sraminterface” component to declarations of an “sraminterfacewithpport” component. Make the same name changes to the corresponding component instantiations.
· Add the “ppdata” and “ppstatus” signals to the port listings of the above component declarations. Add the signals to the port mappings of the corresponding component instantiations.
· Add the “ppdata” and “ppstatus” signals to the ports of the user design’s top-level entity.
· Add pin constraints to the design’s UCF ensuring that the “ppdata” and “ppstatus” signals are connected to the correct FPGA pins, as listed in the table in section 5.0, “CPLD requirements for the PC-to-SRAM interface”.
This section provides an overview (from a PC programme’s perspective) of the protocol used by the PC-to-SRAM interface. The information in this section and section 8.0 can be used to write a PC utility programme that communicates with the PC-to-SRAM interface to access the SRAM on the XSV board. (Note that a Visual Basic programme that does this, “XSVSRAMUtility.exe” is included with this resource collection. See the document called “XSV SRAM PC Utility”, which describes the programme).
The PC-to-SRAM interface gives complete access to one bank of SRAM. The address and data size details are therefore as follows:
|
No. of addressable locations: |
512 * 1024 = 524 288 = 512K (Addresses are 19 bits wide). |
|
Width of data at each location: |
16 bits (2 bytes) |
|
Total capacity of one SRAM bank: |