To Produce a Configuration File for the FPGA

Software:

To proceed, Xilinx, Altium Designer 6 and Opal Kelly FrontPanel must be installed on the computer being used.

To produce a configuration file for the FPGA:

Create an FPGA project in Alitium.

In order for the project to synthesize properly, Altium must be using the Xilinx compiler. Go to Project->Project Options and select the “Synthesizer” tab. Change the synthesizer to “XST Synthesizer.” The default is Altium.

Include the files okHostInterface.vhdland OpalKellyFPGA.IntLib in the project.

Include the okHostInterface module in the top schematic. Make sure that hi_clk, hi_cs, hi_rdwr, and hi_addr are connected to input ports, hi_bsy and hi_irq are connected to output ports, and hi_data is connected to a bidirectional port. Include outputs i2c_sda, i2c_scl and hi_muxsel; hi_muxsel should be grounded. (It is easiest to copy these parts from another schematic that already has them.) If needed, add the section containing the desired clock (sysclk1, 2, or 3) from the FPGA.

Also include the appropriate constraint file. For the XEM3010-1500, a copy of the basic constraint file can be found attached to previous projects. If not, a constraint file for the XEM3010-1000 can be used by changing the TargetID from XEM3010-1000* to XEM3010-1500*. The asterisk indicates a series of characters following the main part of the ID that should not be changed. Blank constraint files with appropriate headers can be found in the Opal Kelly files. Edit the constraint file to match desired pins. A pin map should be available near the end of the user’s manual for the specific FPGA. To make sure the constraint file is used, go to Project->Configuration Manager. Your constraint file should be listed under “Constrain filename.” If not, make sure it is included in the project, and then return to this step. Click the “Add” button next to the “Configurations” label. Give the configuration a name. A clear name should be used, such as “XEM3010.” This will add a column with the configuration’s name and a check box beneath it. After adding this configuration, check the box next to the name of the constraint file to use it in the configuration.

Opal Kelly files with the .ngc ending for each Opal Kelly component used must be placed in the ProjectOutputs\Configuration directory, where Configuration is the name of the configuration from the Configuration Manager. (This should besomething obvious, like XEM3010.) The exception is the okHostInterface module. In all cases, the file that must be added is okHostCoreInterface.ngc. All other modules have matching names (okWireIn requires okWireIn.ngc, etc). It is usually simpler to include all the Opal Kelly .ngc files, in case other modules are added later, but is not necessary so long as all the modules used have equivalent .ngc files present.

To compile the project and produce a .bit configuration file, go to the home page. This can be reached by clicking the signpost in the upper right-hand corner. Click on “Devices.” Make sure the “Ignore FPGA source” and “Ignore Software” boxes in the upper left-hand corner are checked.

There should be a list of open projects in the lower half of the window. Right-click on the desired project, and selected the desired FPGA. If the FPGA is not listed, go to “Browse” and select the FPGA. After choosing a chip, it should appear in the upper half of the window,and the name of the FPGA being used should be beneath the image of the chip. Beneath that will be a select box including the name of the project and theconfiguration. If more than one project or configuration is compatible, more than one may be selected. However, if there are none, then the message “No Compatible Project Configurations Found” appears, nothing compatible has been found, and the program will not be able to produce a .bit file. This message usually indicates that there is some sort of problem with the constraint file or configuration setup. Make sure that the constraint file has the name of the chip as the TargetID, and that it is included in a possible configuration. Once a compatible configuration is available, you may select it in the box beneath the chip, and the chip will be highlighted.

To produce a .bit file, first make sure that all parts of the project are saved. Then click the “Compile” button on the “Devices” page. This will cause the project to compile, and will replace the previous compilation. Later steps in producing the .bit file will work from the last time the project was compiled. While compiling, wait until the messages stop and the circle next to “Compile” is green. [Note that you can ignore all of the yellow warnings. Only if an orange “Error” appears is this a sign for concern. This usually means that there is a problem with the schematic, but the message should be read for details. This also applies to the Synthesize and Build steps.] Once the project is compiled, the circles next to “Synthesize” and “Build” steps should be yellow. Click “Build.” This runs all the steps up to and including producing the .bit file. If anything fails during this process, the process will stop, and the circle next to the step that failed will turn a pink color. Check the messages for what error occurred. Generally, any failures will occur no later than the “Synthesize” step. Be patient – the whole process takes a few minutes.

The configuration file with the .bit extension will be located in the ProjectOutputs\Configuration directory, where Configuration is the configuration used to make the file. The correct configuration file will be named project_cclk.bit, where project is the project’s name. Do not use the project.bit file – the FPGA won’t configure.

FPGA configuration:

To configure the FPGA, plug in the power and USB2 to the FPGA. Start FrontPanel. Either use the configure option and browse for the configuration file, or drag the configuration file over the leftmost button (It has a green arrow pointing to a capital sigma).

If the FPGA fails to configure, try again first. Sometimes it fails for no apparent reason, then works fine afterwards. Make sure the USB is connected and the *_cclk.bit file is being used. If using code, double-check that your bit file is in the expected location and has the correct name. If this does not fix the problem, there may be some other problem with the .bit file.

Code:

To set up a console application to work with the FPGA, create a new Visual C++ project. Copy the okFrontPanel.lib from the Front Panel software to a directory accessible to the program. Go to Project->MyProject Properties. Go to Configuration Properties->Linker->Input. Add the okFrontPanel.lib lib to the additional dependencies. Go to C/C++ and add the directory with the okFrontPanel.lib file to the Additional Include Directories. If you didn’t copy that file, then you can use C:\Program Files\Opal Kelly\FrontPanel\API as the directory you need.

If large files are going to be sent, the program may need access to more memory. Go to Configuration Properties->C/C++->Command Line. Add /F#, where # is the number of bytes desired. This also needs to be done for Linker->Command Line, except that /STACK:# should be used.

All C++ code interacting with an FPGA must have “#include okCUsbFrontPanel.h”.

The FrontPanel API is reasonably useful for looking up commands, but gives few details. The main ones that will be needed are those for interacting with the Opal Kelly modules, and are fairly straightforward.

The code on Desolation at in DynExch.cpp includes both a routine for configuration the FPGA and a section in the main code for looping through sending/receiving data through the FPGA. Modifications may need to be made to addresses and commands if the configuration of the FPGA is changed. The InOut.exe file in the Release directory at this location is produced by the OutTest project and DynExch.cpp.

The pipes have some features worth noting. First, the information sent must be sent in characters. The buffered pipes can hold 4095 characters. Each has a flag for empty and full, and stat. Stat gives four bits of information on how full the pipe is.

The communications with the FPGA via USB are not as fast as may be desired. This may be due to the setup of the buffered pipes by Opal Kelly. In any case, this should be taken into account when sending and receiving data. Make sure that the original schematic includes WireOuts that send out information regarding how full the buffered pipes are, and send an error if the BufferedPipeIns are emptied or the BufferedPipeOuts are filled. Either event will almost certainly result in loss of data. Corrections involve limiting communications with the FPGA as much as possible while transferring data, and adjusting the clock speed and decimation as necessary. The fastest possible clock rate without decimation or frequent errors is 25 MHz. This depends both on the schematic and the code.

For the current setup, one error on the output buffer is normal; it is empty when first checked, and therefore no data is read until the next time through the while loop. Occasionally, there may still be a problem with data input or output, resulting in additional errors, for no clear reason, then works fine the next time the program is run. I am not certain why; it may have something to do with background operations on the computer.

Additionally, if your code includes configuration of the FPGA, makes sure enough time elapses between the completion of the configuration and beginning other interactions with the computer. For instance, if the FPGA requires a few seconds to synchronize with an external clock, make sure the program waits. In the case of the setup as of August 18, 2006, the time needed is ten seconds, including a margin for error. For this setup, the computer should not start other communications with the FPGA until the four error count LEDs have all turned off, indicating that the FPGA is synchronized.

Board:

BNC connectors to the board are labeled 1-8. When connected to the DAC output, channels labeled 2, 4, 6, and 8 are really DAC channels 4, 3, 2, and 1, respectively.

Where to find everything:

At the moment, almost everything I’ve done is on Desolation in C:\Documents and Settings\EE\My Documents\FPGA_Biquad. When I refer to something later on, unless mentioned otherwise, it is in this directory.

ADCcheck: This contains the FPGA project ADCcheck, which works properly on both the ADC and DAC sides. Data is decimated 8x. It does not use averaging of the ADCs, but selects one channel based on an okWireIn command.

ADCcheck1: The FPGA project in this directory is exactly the same as ADCcheck, except that averaging the ADCs is used instead of picking one channel.

Cxx: This contains the code that I’ve been using.

contDA, InOut, PowAvg, RAMTestera, respplot, Tester and WireTest are all old bits of code that I was working with. contDA and InOut are old versions of the code used to communicate with the FPGA. Specifically, InOut was intended to be both DAC and ADC; contDA was intended to DAC output only, for an arbitrary length of time. However, both InOut and contDA have issues with word/byte order that were resolved in OutTest. WireTest was for checking WireIn and WireOut operation, but I don’t think I finished it. PowAvg averages in the power spectrum, taking amplitude input and giving amplitude output. The rest are test code.

Display.xpf: This is an XML file meant to be used with FrontPanel. If you open FrontPanel, and load this file as a FrontPanel Profile, this can be used to send/receive data through the various wires and triggers in the configuration files for the FPGA. It is set up specifically for the FPGACLK schematic, prior to ADCcheck and ADCcheck1; however, I believe it will also work with these, since there has been no change to the wires and triggers.

okFrontPanel.lib: Just the library that is needed for C++ to use Opal Kelly commands.

OutTest: Contains the main code and almost all data. Skip to the end for more information, since this is a pretty big directory.

Docs: Contains major documents, like my abstract and final report. Finaloldref.doc is the same as Final.doc, but includes a different reference format (with more information). The Plots directory has, well, plots. They are mostly from when I was trying to get something to work on my Mac, and so are in various formats. Most in Plots\Old are pdf files of the major plots. NOTCH.pdf is a schematic of the notch filter.

FPGACLK: Old schematic directory. Contains the FPGACLK Altium project. It works fine… except that it has glitches in both ADC and DAC output due to the word/byte order problem that was solved in ADCcheck.

Other files and directories are old stuff – the old IIR project and associated files, various other files, test projects, etc.

The biggie:

C:\Documents and Settings\EE\My Documents\FPGA_Biquad\Cxx\OutTest

C++ code: Contin.cpp is similar to contDA in purpose. Dyn_Exch_works.cpp is an old version of the code currently used; it does not have corrections for the word/byte order problem. Dyn_Exch.cpp is the current code, and works fine with the current FPGA configuration, word/byte order and all. The project used is OutTest.vcproj. The executable is Release\InOut.exe.

Release:

InOut.exe uses the command line and takes in 5 arguments. They are time, frequency, amplitude, ADC channel, and test enable. Time is how long to run, in seconds; it will take up to ~110 s, and, above that level, will give a warning, then run for the maximum time. Frequency is the frequency in Hz of the one-tone output through the DACs. Amplitude is the amplitude of the DAC output, as a fraction of full scale. It goes up to .99 before producing glitches in the DAC output. ADC channel is the channel from which input will be read, and should be 1, 2, 3, or 4. The default channel, if some erroneous value is entered, is channel 1. With the averaging configuration, the WireIn used to set this value goes nowhere, and so does not affect anything. Test Enable toggles the test enable option. 0=disabled. Otherwise, the test is enabled and the front end is bypassed. When running, make sure the configuration file is in the correct location. At the moment, the location of the file used is set by the CONFIGURATION_FILE variable. It produces four files in the directory where it is run. Output.txt contains the output from the ADCs; intput.txt has the digital sine sent to the DACs; istatus.txt has the status of the BufferedPipeIn; ostatus.txt has the status of the BufferedPipeOut. Istatus.txt and ostatus.txt output four bits of information; 15=full, 0=empty, and values go in sixteenths. Output.txt and input.txt are in counts. Output.txt and input.txt can be very large files, especially for longer times.

.bit files: onechannel.bit and ADCaverage.bit are the main configuration files. Onechannel.bit uses one ADC channel; ADCaverage averages all four. They correspond to ADCcheck and ADCcheck1. adcchecknf.bit runs the ADCs without the filter, but the DAC will probably have glitches. DACcheck_cclk.bit runs through the DAC without a filter (I think), but does not have the DAC corrected. Other .bit files are in the oldconfigs directory. I doubt they will be of use.

ADdat.m: Runs InOut.exe for an 18 s period, ADC channel 1, with test enabled. Output is probably set to 1kHz and .99 magnitude, but is fairly arbitrary and easy to change. The main point is that it also loads output.txt and produces a time-series (in counts) plot of a large section of the data.

specamp.m: Takes a vector like “output” which is scaled in counts and returns [Amp, f]. Amp is the amplitude spectrum; f is the corresponding frequency values. It also produces a log plot of Amp v. f.

.txt files: Pieces of data, for the most part. The InOut.exe produced files are whatever I last ran InOut.exe for. Gndnnotch.txt and gndwnotch.txt are the ADC time series with 50 ohm resistor for input, without and with the notch filter. The rest are other input, labeled.

3kHz, 3kHz-oldnotch, 150Hz, 150Hz-oldnotch: ADC data here was taken with the DS360, and the old (worse) notch where noted. Anything with “nn” in the name was taken without the notch filter.

3kHz-othersp, 100Hz-othersp: ADC data here was taken with input from the Audio Precision SYS-2722. The titles are based on the input 8 Vpp, etc. The same goes for the figures. Spectra.mat has the amplitude spectra, in variables. They’re either something like amp1, amp2, etc, or amp1a, amp1b, etc. In any case, the higher number/letter is the higher amplitude, and reflects the data in the directory. Gnd should be the values with the 50 ohm resistor and notch; f is the frequency.