JISP Player / Encoder Pseudocode
System Programming -- more popularly, ISP -- is gaining popularity today.
More and more products are built that can be reprogrammed in system,
making firmware upgrades inexpensive and convenient - over the internet,
for example. The main idea in ISP is that there is a host machine, which
generates a stream, which is consumed by a player on the target product.
This player causes the product to be
reprogrammed. The data to be programmed may be microcode, or an FPGA
If one is planning a range of products that need to be programmable
in system, typically, one would like to build an ISP interface once
and reuse it for all one's products, thereby reducing costs. The JISP
Player/Encoder describes a way to increase the portability of ISP across
a product range, providing that the products are capable of being programmed
The traditional JTAG programming format, SVF, is built for consumption
by relatively complex machines (like testers). However, ISP solutions
for products need to be as
inexpensive as possible. Many of the traditional solutions for simplifying
ISP either take away the portability of JTAG, or blow up the data size,
or require a significantly complex player. The scheme presented here
is portable across devices and is flexible enough to accommodate special
requirements of programming components.
following are the most common causes of problems associated with SVF
we know the system we are programming, we can simplify the player so
that it can be implemented very inexpensively by moving most of this
computing to before we generate the programming stream. Here is the
encoding of the stream. The main aims are to:
- large memory requirement: the svf bits are all in
the JTAG chain order: reverse of what is required to be shifted in.
This means that the player has to store the whole data in memory and
shift it out in reverse. If there is data to be compared as it is
being shifted out of the TDO pin, the memory requirement is double
the size of the data
requirements: svf has instructions which require the player to wait
for some time. This requires the player to keep track of time and
be able to pause the input stream for the duration of the delay
controller knowledge: svf requires the player to be knowledgeable
about the JTAG TAP controller. Instructions such as ENDIR, require
the player to go to a specific state of the TAP controller.
JISP Data Format is based on the following Instruction Table. An '(optional)'
in the table indicates that the instruction can be left out and you
will still have a functionally complete (but less efficient stream encoding).
- reduce the computing power and memory requirements
- limit the increase in the stream size to prevent
TDI bits - no checking
01IIIOOO 3 TDI bits - checking
0011IIII 4 TDI bits - no checking
0010IIOO 2 TDI bits - checking
00011IMO 1 TMS, 1 TDI - checking
000101MM 2 TMS
000100IM 1 TMS, 1 TDI - no checking
0000111I 1 TDI no checking
0000110M 1 TMS
00001010 VERSION <followed by 1 byte version>
0000011I Repeat 16 TDI bits - no checking (optional)
0000010I Repeat 16 TDI bits - check same
ebit to E (optional)
each JTAG clock, the player can do one or more of these actions:
accommodate this, the instructions allow:
- clock in a bit on the TDI pin
- clock in a bit on the TMS pin
- clock out a bit on the TDO pin and compare
data clocked out of TDO. This is represented as O in the instructions.
If there is no O in the instruction, it means that the output from TDO
- clock in data into TDI. The only data is the bits
clocked into TDI. This is represented as I in the instructions
- clock in data into TMS. The only data is the bits
clocked into TMS. This is represented as M in the
all instructions the bit to be shifted out first is the most significant
bit in the instruction.
NOOP instruction is a no operation. The player is required to do nothing
when it gets this instruction. This is important. If the data rate to
the player is fixed and the player cannot pause the input, then the
stream generator inserts as many NOOPs as required to cause a delay
in the programming sequence.
VERSION is a rudimentary check that the player and the receiver are
in sync, so that incompatibilities can be flagged. The two Repeat instructions
are there, in case the programming stream has lots of repeated bits.
This will reduce the size of the programming stream. This adds a restriction
that the player be able to clock out sixteen bits in the period that
one stream byte comes in.
ebit instructions are for the player to be able to set or reset an external
bit, e.g. to toggle the reset on the target board, or to power cycle
If you want to add more instructions, you could use 0 as the first byte
and decode another byte.
The downloadable pseudo code for the JISP player can easily fit into
the on-chip code memory of a simple micro-controller. The data memory
requirement of the player itself is just a few bytes. The download also
includes an encoder which will use SVF based API to generate a JISP
stream. >> Download