Add-On Boards
Reference designs, breakout boards, and other peripherals are available for many of our FPGA modules.
Add-On Boards
Reference designs, breakout boards, and other peripherals are available for many of our FPGA modules.
ImpulseC CoDeveloper (archived)
Note: This page is no longer supported and is here only for archival purposes.
Impulse C CoDeveloper allows C-language applications to be compiled into optimized FPGA logic. Using the Impulse CoDeveloper™ tools, you have the power to accelerate algorithms by orders of magnitude (as much as 300X) over traditional processor implementations.
Impulse Accelerated Technologies, Inc. was formed in October of 2002 to serve the needs of embedded systems designers through the development and distribution of software-to-hardware compilation and verification tools, through user education and through ongoing customer support.
Opal Kelly has been working with Impulse to build an integrated board support environment allowing you to target Opal Kelly modules from within ImpulseC. Together, this makes the Opal Kelly FrontPanel-enabled devices a very low-cost integration platform for users of ImpulseC.
To ease utilization of the ImpulseC CoDeveloper C-to-FPGA synthesis tool with Opal Kelly products, a complete architecture within CoDeveloper has been implemented that will generate and organize all HDL wrapper files necessary for complete compilation in the Xilinx ISE. Files are also included to perform simulation in ModelSim.
okWire
components, and 16-bit and 32-bit co_streams are supported by modules constructed with FIFO’s mated to okBlockPipe
components. The details of this implementation are handled by an included Library wrapper file, okImpulseLibrary.vhd
.Within CoDeveloper, navigate to Options→Generate→Platform Support Package and select Opal Kelly FrontPanel USB (VHDL). Now, once the HDL is exported, the hardware build directory will be populated with the following files:
A top-level wrapper file, (name)_fp_wrapper.vhd, is generated automatically by the Opal Kelly FrontPanel 3 Architecture installed with CoDeveloper. This wrapper file brings together all of the underlying components and is the top-level file for synthesis. It has several other components as well:
okWireIn
modules is present for each output co_stream created. This module brings in a value from the PC that tells the HDL code how large output blocks of data will be. This will be explained more below.
okTriggerIn
module is present with bit 0 at endpoint address 0x40 combined with a global reset from a DCM. If the DCM DLL is locking only a clock, or if the user triggers this bit from the PC, a global reset to all CoDeveloper modules will occur.The file okImpulseLibrary.vhd defines some key modules constructed from Xilinx and Opal Kelly component with a bit of added logic:
simple_dcm
: A very basic DCM implementation on the incoming clock signal. The LOCKED DCM signal is outputted as a global system resetokImpulsePipeIn16
: An ISE Coregen created first-word-fall-through 16 bits x 8192 deep FIFO mated to an okBTPipeIn
(Opal Kelly Block Throttled Pipe In) module. There are two state machines:
okBTPipeIn
module of at most 1024 bytes, if room in the FIFO allows, the module is given a Readysignal. Otherwise, the module is told to wait and data is throttled automatically (if pending).okImpulsePipeIn32
: Identical in form and function to okImpulsePipeIn16
, but the FIFO received up to 16 bits x 8192 of incoming data and converts it to 32 bits x 4096 for the stream input.okImpulsePipeOut16
: An ISE Coregen created standard 16 bits x 8192 deep FIFO mated to an okBTPipeOut
(Opal Kelly Block Throttled Pipe Out) module. There is also an input of blockSize from the top-level wrapper and two state machines:
blockSize
value comes from an okWire in module in the top-level and tells the state machine described below when enough data is ready for a block transfer.okBTPipeOut
module is given a Ready signal. Otherwise, the module is told to wait and the transfer out is throttled automatically (if pending) until enough data is present in the FIFO.okImpulsePipeOut32
: Identical in form and function to okImpulsePipeOut16
, but the FIFO received up to 32 bits x 4096 of stream data and converts it to 16 bits x 8192 for output through a standard okBTPipeOut
.This is a general overview of how functions should be called to communicate with a FrontPanel 3 connected CoDevloper Project.
You must check the wrapper file to find out what the endpoint address for the various components have been assigned to. The starting address for okWireIn
modules is 00h, for okBTPipeIn
modules it is 80h (assigned in the okImpulsePipeInXX
block), and for okBTPipeOut
modules it is A0h (assign in the okImpulsePipeOutXX
block).
ActivateTriggerIn(0x40, 0) // endpoint, bit
okImpulsePipeInXX
with the command:
WriteToBlockPipeIn(0x80, 32, 32, bufin) // endpoint, length, block size, unsigned char array
okImpulsePipeIn16
, the data will come out as 16, 16-bit words. If the module at endpoint 80h is okImpulsePipeIn32
, the data will come out at 8, 32-bit doublewords. High bit/high byte first.SetWireInValue(0x00, 1024, xffff); // xffff is a data mask UpdateWireIns(); // send all updated Wire values to device
ReadFromBlockPipeOut(0xA0, 1024x32x24, 1024, bufout); // endpoint, length, block size, unsigned char array)
Below is a brief step-by-step description of the steps necessary to build and synthesis all files necessary for the Mandelbrot_1 example for an Opal Kelly XEM3010. Virtually all the steps provided here apply to any CoDeveloper/FrontPanel 3 project.
(name)_wrapper.vhd
, (name)_comp.vhd
, (name)_top.vhd
, and okImpulseLibrary.vhd
to the project. Make sure, (name)_wrapper
is the top-level file.okLibrary.vhd
. Copy these somewhere to the project (your ISE folder perhaps) and modify the UCF file as needed. You can view the signals required in the (name)_wrapper.vhd
file (for instance, the name of the clock in the UCF file you should be renamed clk_in) and add them as sources.okImpulseLibrary.vhd
.You should now be ready to select the top-level file and generate a programming file. If you haven’t already built the FIFO components, you will be asked sequentially to generate the files. Any random errors during or after generation of the FIFO’s is most likely caused by Xilinx IP mismatches. Recustomize the IP as described above.
Release
.Use Multi-Byte Character Set
.cpp
and .h
files from the project.okFrontPanelDLL.h
and okFrontPanelDLL.cpp
to the root example directory where the other source files are located.mand.h
and okFrontPanelDLL.h
to your header files. Also add mandelbrot.c
and okFrontPanelDLL.cpp
to source files.okFrontPanel.dll
to the Release
folder. Also, copy the *.bit
file you generated in ISE here as well and rename the file to mandelbrot.bit
.executable_name.exe 40
You should see your Mandelbrot.bmp file in the Release
folder when done.
Before starting with simulation, make sure you are familiar with Opal Kelly FrontPanel simulation in general. There is an online tutorial here to help. In the very least, you will need to have the FrontPanel simulation libraries installed in ModelSim.
sim
folder in the root project directory.hwsim
to this new simulation folder.*.vhd
. Copy those 4 files to you new simulation folder.simulation_tf.vhd
file to tailor it to your project.
mand_fp_wrapper
.simulation.do
should be almost setup to compile the impulse
library, a local work
library with all other files, and initialize the simulation. You will need to open the file first and change the top-level entity in the vsim command. In the example file, this top-level is Simple_Test
.Open ModelSim, change the work directory to you new sim
folder, and type do simualtion.do
. The files should be compiled and the simulation will be initialized.
From the FrontPanel 3 Users Manual:
“Pipes are the fastest way to transmit or receive bulk data. Due to overhead, performance is best with long transfers. Each time you perform a pipe transfer, several layers of setup are required including those at the firmware level, APIlevel, and operating system level. Therefore, it is best to design around using long transfers, if possible. This generally means using large buffer sizes on the FPGA and relying on external memory when possible.”
Performance with Block Throttled Pipes is greatly improved with longer transfers of larger block sizes. For instance, with an few megabyte transfer with 1024 byte blocks, the user may see 38 MB/s read and write performance to the FPGA.
The wrapper library file okImpulseLibrary.vhd
is designed to work well with 1024 byte block sizes (the largest), but the total FIFO space is small (defaults to 16384 bytes). If your design could feed in data into the FIFO, have the data processed in your Impulse CoDeveloper module, and then output into another FIFO, you could transfer in 32768 bytes of data and then transfer out that same amount. However, the last byte in any standard FIFO implementation my be lost in the hardware implementation so please design for this.
However, to achieve the greatest performance, you will not be able to solely rely on the finite FIFO space of the FPGA. Most Opal Kelly FPGA modules come with embedded SDRAM and we have a simplified SDRAM controller in our Ramtester
example that works with blocks of data and is readily attached to a standard FIFO. By combining small FIFO’s with an SDRAM controller, a more sophisticated okImpulseLibrary.vhd
could be developed that utilizes the large SDRAM as large pseudo input and output FIFO. This will facilitate very large and very fast transfer sizes.
Of course, if your Impulse CoDeveloper module is FPGA processing bound, the system as currently designed may suit your needs.
Each FrontPanel module must have an endpoint address. These are partitioned into groups of addresses depending on the type of module.
As you build your CoDeveloper application, co_streams and co_registers will be automatically linked to FrontPanel Block Throttled Pipes and Wire modules respectively.
After exporting your CoDeveloper project to HDL, open your generated xxxx.fp_wrapper.vhd
that will be located in the hw
folder. You will need to verify the choosen endpoint addresses here before writing code for a PC application to communicate with the design. In the Mandelbrot example, the following addresses are typically made by the tool:
config_stream
, which is a 32-bit input co_stream is located at endpoint 0x80.pixel_stream
, which is a 32-bit output co_stream is located at endpoint 0xA0. It has an associated okWireIn
module at endpoint 0x00. Writing a value of 1024 to this okWireIn
module will mean that data block sizes of 1024 bytes should be streamed out of this port.Receive general announcements and product lifecycle updates.
We'll never spam or give this address away.
Copyright © 2004-2025 Opal Kelly. All rights reserved.