LLAMA Group's Research into getting programming and configuration
information onto your target device.
Craig Joly
Wendy Benbow
Rob Behm
In Max+Plus II, you usually create type your VHDL file, get it to
compile then use the Programmer to download the SOF file to your
target device. However, if you look around in the menus, under the
File menu, there's an option called "Convert SRAM Object Files..."
What could you possibly want to convert SOFs to and why?
You can convert SOFs to POF, HEX, SBF, TTF, RBF, JAM and JBC formats.
Each of these allow allow a different configuration/programming
scheme.
SOF - SRAM Object File
This is Altera's native format that is created when you compile a
project. You need Max+Plus II and a BitBlaster or ByteBlaster because
as the SOF file is being transferred, the software adds extra
information not included in the file.
POF - Programmer Object File
These are also automatically created by Max+Plus II. These are used
with
Altera's PROMs for programming a device when it powers up. The
UP1 board supports Altera's EPC1 PROM.
HEX - Hexadecimal (Intel-Format)
This is a format that is used by many third party programmers to
program devices in either parallel or serial mode.
SBF - Serial Bitstream File
An Altera only format that can be used with a BitBlaster cable to
configure/program from the command line for FLEX devices only.
The SBF file can be simply copied to the correct serial port. Page 10
and 11 of Altera's BitBlaster
Datasheet offers a bit more information.
TTF - Tabular Text File
The TTF file is again, only supported by Altera. The TTF file can be
included with source code to a microprocessor that handles
programming/configuration of the device. This scheme would be used if
there is no dedicated storage device for holding configuration files.
RBF - Raw Binary File
The RBF stores configuration bits sequentially. It can be used for
passive serial, passive parallel synchronous and passive parallel
asynchronous programming of FLEX 6000, 8000 and 10K, and APEX 20K
devices.
In all modes, the nconfig pin of the target device is
asserted high to put the target device into configuration mode.
When the device is finished configuring, it will assert it's
config_done pin high and expect 10 pulses on it's dclk
pin to initialize itself, after which it will assert init_done
high. If there is ever a problem, it will pull nstatus low.
In passive serial mode, the bits are shifted onto the data0
pin of the target device, least significant bit of each byte first.
The dclk pin is pulsed for each bit. Both MSEL0 and
MSEL1 on the target device must be tied to ground. On the UP1
board, all necessary pins can be accessed through the EPC1 slot.
In passive parallel synchronous mode, an entire byte is shifted onto
pins data0 through data7, with the least significant bit
on pin data0. dclk must be pulsed eight times for each
byte. All other pins are the same. On the UP1 board data1
through data7 are accessed through FLEX_EXPAN_C. They become
user U/O pins after configuration is complete.
Passive parallel Asynchronous mode can only be used with the FLEX
6000 device.
JAM
This is a text file in the Jam programming language. It can be used
with any IEEE 1149.1 compatible device. They are meant for use with
Max+Plus II or an embedded processor.
JBC - Jam ByteCode
This is a compressed, byte code version of the JAM file. It is a
control file for a virtual machine, known as the Jam Player. The JBC
file is broken into 4 main parts: a pointer table to set up
information, an action table to specify which parts of the file do
what (program, verify, blank, etc), an instruction area and a data
area. The Jam Player is meant to sit on a microprocessor and treat
parts of the JBC file as data cache and instruction cache after the
desired action is chosen. For more information, see the Jam ISP website.
Some Code
For our project, after a failed attempt with the JBC format, we
eventually settled on the RBF format with the passive serial
configuration scheme. We chose RBF because it doesn't require the use
of a BitBlaster, or any other external devices. We chose the passive
serial configuration because all necessary pins can be accessed in one
place (the EPC1 slot) on the UP1 board, so we could make a convenient,
easy to use connector and nothing would have to be connected to the
board after configuration if pins on the FLEX_EXPAN_C header were
required. Also, it requires the same amount of cycles as the parallel
mode anyway and only adds the requirement of a shift register after a
byte has been obtained from memory.
The included code does not contain the shift register since it was
generated by a Max+Plus II wizard. It is a right-shift register with
an enable for shifting out data and a synchronous load. It is the
write_out component in rbf_control.vhd.
The was written to work with our memory system, with means it will
request memory usage then wait for an acknowledgement that it has
exclusive use of memory. It also does not calculate memory addresses.
The starting memory address was chosen by the UI and while the memory
lock is held, each memory request retrieves the next byte in memory.
This is why, when the module receives an error from the target (
nstatus pulled low), it releases memory, then requests it again.
pins:
sys_clk - the UP1 on board clock (25.125MHz)
start - signal to begin target device configuration
stop - abort signal - emergency stop - use if module gets into a
error/reconfigure loop
status - information about the state of the module
mem_req - request exclusive use of the memory system
mem_ack - acknowledgement from memory that I can use it
fetch_byte - request to memory for the next byte
byte - the next byte from memory
data - connected to target's data0 pin
nconfig - goes high to put target into configuration mode
dclk - pulse to target for each bit on data
nstatus - connected to target and should be pulled high with a 1k
resistor. target will pull low on a configuration error.
conf_done - target will assert high when it has received all of the
configuration bits - memory is released and no new information is
shifted onto data
init_done - target will assert high when initialization is complete -
dclk stops pulsing
rbf_control.vhd
rbf_get_byte.vhd
created by Craig Joly