Summary

This summary is not meant to be all inclusive. It is intended to point out important things to know to get started. It brings together information that is mostly in the GigaOps documentation, but that is scattered and hard to find.

The GigaOps board is installed in a PC and is made to be expandable through modules that may be added to the board. Currently, we have one module. The resulting configuration of our board includes four FPGAs, 4 MB DRAM, and 256 KB SRAM. The four FPGAs are called VMCFPGA, VLFPGA, XFPGA (or XPGA), and HFPGA (or HPGA). The VLFPGA is used to interface to the VESA bus, and the bitstream to do this is provided by GigaOps. GigaOps also provides a bitstream for the VMCFPGA which is useful. The other two FPGAs are at your disposal. This summary contains information (pinouts etc.) about the HFPGA.

Logic Design

First I discuss some issues related to the design of the logic. These are

• Part Number
• Clocks
• Bus Enables
• H_BUS
• Video Bus
• Memory

Putting it Together

Then I discuss issues related to running the GigaOps tools and compiling the C code. These are:

• XLINK
• Host C code
  

Part Number

The part number for the FPGA needs to be specified somewhere. It is easily done on the schematic in ViewLogic by placing an attribute called PART with a value of 4010PQ208-5

Return to top

Clocks

The section on clocks in the big binder is found on page 24-1. There are four clock signals that come onto the HPGA. The following table shows their names and pins.

Clock Signals

Name	Pin	Alternate Name
YBUS_CLK	4	yclk1
YBUS_CLK2	204	yclk2
HBUS_CLK	57	hclk1
HBUS_CLK2	47	hclk2

The sources for these clock signals can be chosen by setting the CLKMODE in the .lnk file (the .lnk is dicussed later). The common clock mode for video applications is mode 14. This causes the clocks to have the following sources and clock rates.

Clock Definitions

Clock Name	Source	Period (ns)	Rate (MHz)	Note
HBUS_CLK	vl/2	60.6	16.5	vl = VESA local bus clock
HBUS_CLK2	vl	30.3	33
YBUS_CLK	grab	81.5	12.2727	grab = grab clock
YBUS_CLK2	yf6	40.7	24.5	yf6 = YBUS_FUNC_6

The pixel clock is YBUS_CLK. This is the clock that specifies when a new pixel is present. It is the clock that the video_bus module uses.

Return to top

Bus Enables

There are several buses that needed to be enabled from the HFPGA. The enable lines are low asserted so they need to be set low to enable the buses. The signals have the following names and pins (on the HFPGA):

Bus Enable Signals

Signal	Pin
pq_addr_e_	89
pq_data_e_	91
xbus0_e_	92
xbus1_e_	93
xbus2_e_	94
xbus3_e_	95

Return to top

H_BUS

The h_bus provides the interactive communication between the HPGA and the host computer. The h_bus protocol is documented in the GigaOps tutorial starting on page 4-1. There is a .xnf macro provided by GigaOps that interfaces with the h_bus. It is called hif_444. It is documented in the GigaOps tutorial starting on page 4-9. If you use this macro, you don't have to worry about the h_bus protocol. The macro does the worrying for you. One important note for ViewLogic users: the way that GigaOps labels bus signals in the .xnf file doesn't conform to the ViewLogic method. If you create a symbol for hif_444.xnf and label buses with names such as data[15:0], ViewLogic tries to match those lines with signals in the .xnf file called data15, data14, etc. The problem is, the GigaOps .xnf file calls its signals data<15>, data<14>, etc. There is an altered hif_444.xnf file with signal names that match ViewLogic labeling method. It is in c:\goco\byulib or it is available to hif_444.xnf here.
Return to top

Video Bus (YBUS)

Video data comes onto the FPGA via a bus called YBUS. If you use the .bit file that GigaOps provides for the VMC FPGA (called hvl320c.bit, and located in c:\goco\byulib), it sets up a bus protocol called (not surprisingly) the YBUS video protocol. The YBUS protocol is documented in the GigaOps tutorial starting on page 5-1. There is a .xnf macro provided by GigaOps that interfaces with the YBUS. It is called vif_y0.xnf. It is documented in the GigaOps tutorial on page 5-9. It is also discussed on page 3-10. I have also created a ViewLogic module that does many of the same things. It is discussed here. Again, if you use the GigaOps macro or my module, you don't have to worry about the YBUS video protocol.

Return to top

Memory

Our board as presently configured has 4 MB DRAM and 256 kB SRAM. There are data sheets in the GigaOps Hardware Reference Documents binder for these memories. The pins on the HFPGA that go to the memory are as follows:

Memory Control Signals

Name	Function	Signal Name on DRAM	Pin
hmem_se_	0=SRAM 1=DRAM		5
hmem_ras_	row address strobe	ras	6
hmem_cas_	upper & lower column address strobe	ucas & lcas	203
hmem_wr_	write enable	wr	202
hmem_rd_	output enable	oe	201

Memory Address Pins

Signal Name	Name on DRAM	Pin		Signal Name	Name on DRAM	Pin
hmem_addr_15	n/a	7		hmem_addr_7	A7	16
hmem_addr_14	n/a	8		hmem_addr_6	A6	18
hmem_addr_13	n/a	9		hmem_addr_5	A5	19
hmem_addr_12	n/a	10		hmem_addr_4	A4	20
hmem_addr_11	A11	11		hmem_addr_3	A3	21
hmem_addr_10	A10	12		hmem_addr_2	A2	22
hmem_addr_9	A9	13		hmem_addr_1	A1	23
hmem_addr_8	A8	15		hmem_addr_0	A0	24

Memory Data Pins

Signal Name	Name on DRAM	Pin		Signal Name	Name on DRAM	Pin
hmem_data_15	I/O15	27		hmem_data_7	I/07	35
hmem_data_14	I/O14	28		hmem_data_6	I/06	36
hmem_data_13	I/O13	29		hmem_data_5	I/05	38
hmem_data_12	I/O12	30		hmem_data_4	I/04	39
hmem_data_11	I/O11	31		hmem_data_3	I/03	40
hmem_data_10	I/O10	32		hmem_data_2	I/02	41
hmem_data_9	I/O9	33		hmem_data_1	I/01	42
hmem_data_8	I/O8	34		hmem_data_0	I/00	43

Return to top

XLINK

The GigaOps tool called XLINK is one of the great things about the GigaOps development system. It performs a couple of operations that are very useful. First, it bundles the data that is to be downloaded to the FPGAs into a single assembly file. Second, it creates a C file that contains function and variable declarations that access registers on the FPGA. This means that you can write a C program for the host computer that interacts with the FPGA via simple function calls and writes or reads to variables. When you compile and link your C code with the assembly and C code that XLINK generates, the result is a single executable file that contains everything.

The files that XLINK needs to be able to do its stuff are:

• .bit (bitstream) files for all four FPGAs
• .ach (architecture) file which describes the configuration of the board
• .pro (prototype) files which map variables to FPGAs
• .lnk (link) file which tells XLINK the names of the above files and a few other things

One FPGA is used for VESA bus communication. The .bit file is provided by GigaOps. It is c:\goco\bit\hvl320c.bit. GigaOps also provides a .bit file for the VMC FPGA which sets up the YBUS video protocol. It is c:\goco\byulib\uflo640.bit. If you want the XFPGA to do nothing but pass the video data through, there is a .bit file to do this. It is c:\goco\byulib\xthru10.bit.

The .ach file never changes from project to project since it depends only on the board configuration. The .ach file that is correct for our system is c:\goco\byulib\byu.ach.

A .pro file is required for both the XFPGA and the HFPGA. The .pro file can be empty if there is nothing to put in it, but it still has to be there. A sample .pro file for the HFPGA is in c:\goco\byulib.

The best way to figure out how to do a .lnk file is to open c:\goco\byulib\tutorial.lnk and read the comments.

XLINK is invoked by typing

xl file

where file is the .lnk file.

Return to top

Host C Code

Make sure you compile the C code with the large memory model. If you are using the video capabilities, make the necessary function calls. These calls are shown in the host C code in c:\goco\byulib\pass.c. This file also shows how to write to variables to send data to the FPGA.
Return to top

Tutorial, Summary

Reconfigurable Logic Home Page, ECEn Home Page