Production Programming of Flash for FPGAs and MCUs

R

rickman

Guest
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about. Was there a problem with
using the version the company developed? I'm assuming the industry
version came first and the JEDEC version came later. Or is that
wrong? It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices? I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis. I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades. Any thoughts?

Rick
 
2011-11-18 23:14, rickman skrev:
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about. Was there a problem with
using the version the company developed? I'm assuming the industry
version came first and the JEDEC version came later. Or is that
wrong? It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices? I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis. I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades. Any thoughts?

Rick
Programming procedure for programming a bare at91sam9 board.
1. Insert SD-Card
2. Press reset
3. Wait until LED blinks
4. Remove SD-Card
5. Press Reset
Application boots...

Procedure for updating the linux kernel in a preprogrammed board.
1. Connect board to host PC using USB.
2. Reset the board in the USB Mass Storage mode.
3. Wait until FAT partition window appears on the host PC.
4. Clíck on the new kernel version, drag and drop it on the FAT window
5. Reset the PC into normal linux boot sequence.



--
Best Regards
Ulf Samuelsson
 
On 18 Nov., 23:14, rickman <gnu...@gmail.com> wrote:
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used.  Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM.  JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about.  Was there a problem with
using the version the company developed?  I'm assuming the industry
version came first and the JEDEC version came later.  Or is that
wrong?  It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices?  I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis.  I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades.  Any thoughts?

Rick
I know where I've been we always ended up building our own board with
MCU on
it for the production testing. Usually involving bit-
banging(everything from JTAG to PCI)
a bootloader or test program into the dut and programming a flash via
uart/spi or
something like that

the code to be programmed was usually store on flash on the board, so
unless you
needed to add serial numbers and such it could be used standalone,
just plug it into
the dut and push the program button and done

We did at one point try some jtag hw, but it could never really do
what we wanted

-Lasse
 
On Nov 18, 4:14 pm, rickman <gnu...@gmail.com> wrote:
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used.  Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM.  JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about.  Was there a problem with
using the version the company developed?  I'm assuming the industry
version came first and the JEDEC version came later.  Or is that
wrong?  It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices?  I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis.  I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades.  Any thoughts?

Rick
IEEE 1532 is something that is a bit newer, I believe both xilinx and
altera
support it, not sure 'bout the others. http://grouper.ieee.org/groups/1532/

(we are primarily Xilinx users...)

As for programming, it depends on the system. These days we usually
have a PC in the test fixture for all but the simplest of boards, so
we use
a Xilinx cable for the initial load. We usually have the Xilinx part
as a coprocessor
with other devices, so even if the xilinx boots first, we have other
devices that
can do updates to the memory already on-board.

Even if you don't have a CPU, it's not hard to put in a picoblaze core
and do a
loader to update a SPI flash via bit-banging. You could probably do
one with
access to raw SD/MMC cards without too much trouble.
 
On 18/11/11 23:14, rickman wrote:
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about. Was there a problem with
using the version the company developed? I'm assuming the industry
version came first and the JEDEC version came later. Or is that
wrong? It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices? I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis. I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades. Any thoughts?

Rick
It depends on the devices in question.

Many larger microcontrollers have a bootloader in ROM that you can use
to program them over a serial link or perhaps USB. Smaller
microcontrollers can often be programmed easily using a JTAG or other
debugging port, or an SPI-like interface (such as AVR devices).
Typically that means using the manufacturer's own JTAG debuggers and
software, but these are always far cheaper than the JTAG test equipment
and software you describe.

I have also used the JTAG or BDM port of bigger microcontrollers,
combined with a cheap hardware interface and gdb, to script programming
and testing setups. For ARM devices you can use OpenOCD or Urjtag in a
similar fashion.

For devices that can boot from a serial flash, the easiest method is
often to make these pins available on a header, along with the "boot
mode" control pins for the device. Then you can make a little card with
a serial flash device that you plug into the board for initial bootup -
this software can then test the board and program the real code into the
main memory.

If you have a serial flash on the board as the main memory, then you can
have a similar header that lets an off-board device hold the processor
or FPGA in reset while it programs the serial flash. You can make such
a device using an FTDI 2232H module and a few wires.
 
rickman <gnuarm@gmail.com> wrote:

Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

How do you program production devices? I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis. I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades. Any thoughts?
I try to stick with devices which can be programmed over a standard
serial port. A programmer is nothing more than a USB to serial
converter. Very convenient.

If I need in system programming I use a standard programmer with a
cable. IC socket to put in the programmer at one end, a special
connector on the other end.

In order to program large numbers of devices I once build a special
rig with 8 Jtag and 8 serial ports. The devices to be programmed where
designed to be plugged into this programmer. There is a lot you can do
at the design stage to make programming easier & faster. A cheap
device may cost more in the end if the programming takes more time &
effort. Time is expensive in many places.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
In comp.arch.embedded rickman <gnuarm@gmail.com> wrote:
How do you program production devices?
One option that hasn't been mentioned yet is to buy your devices
pre-programmed from the distributor. There are of course plenty of
perfectly valid reasons why this may not be an option for you, but if they
do not concern you, there's also a lot to be said for transforming this
into Someone Else's Problem.

-a
 
rickman wrote:
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
You can access the flash for FPGAs from the FPGA itself when configured,
at least for the Altera Cyclone parts. So initially you need something
like JTAG for programming it, but updates can be done from the FPGA
itself. I've implemented update procedures from NIOS and for other
projects with pure VHDL, with a I2C slave for receiving the update data
and reading back the flash for verifying. You can use the rbf file for
programming the flash (bitorder is important), which can be sent from a
microcontroller when its flash was updated with a new firmware.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
 
On Nov 18, 9:10 pm, "AMD...@gmail.com" <amd...@gmail.com> wrote:
On Nov 18, 4:14 pm, rickman <gnu...@gmail.com> wrote:









Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used.  Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM.  JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about.  Was there a problem with
using the version the company developed?  I'm assuming the industry
version came first and the JEDEC version came later.  Or is that
wrong?  It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices?  I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis.  I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades.  Any thoughts?

Rick

IEEE 1532 is something that is a bit newer, I believe both xilinx and
altera
support it, not sure 'bout the others.http://grouper.ieee.org/groups/1532/

(we are primarily Xilinx users...)

As for programming, it depends on the system.  These days we usually
have a PC in the test fixture for all but the simplest of boards, so
we use
a Xilinx cable for the initial load.  We usually have the Xilinx part
as a coprocessor
with other devices, so even if the xilinx boots first, we have other
devices that
can do updates to the memory already on-board.

Even if you don't have a CPU, it's not hard to put in a picoblaze core
and do a
loader to update a SPI flash via bit-banging.  You could probably do
one with
access to raw SD/MMC cards without too much trouble.
I tried to download the 1532 standard draft, but I need a user id and
password. I've found other draft standards from the IEEE that are
available. Any idea where this one can be found?

Rick
 
Hi,

someone mentioned the FT2232 based JTAG adapters. I guess they're common
usage (by now) are the reason why noone really has to pay big bucks
anymore for factory programming.
We had originally designed our own FTDI based JTAG (called ICEbear) for
Blackfin and modified various open source tools to work with it.
Some examples to program Xilinx devices:
- xc3sprog
- xilprg

They're linuxish and command line tools, but do the job, they can be
interfaced with expensive ICT hardware easily. Moreover, the ICTs are
somewhat fading out on newer hardware, because we do all the system
tests over the same JTAG port using test scripts.

I guess the problem with the device programming issues is, that chip
vendors have confusing retentive policies when it comes to JTAG and
cling on selling their expensive and mostly unflexible tools. This can
be partially understood, because JTAG is such a darn powerful tool for
reverse engineering chip architectures. However, this wall will break
sooner or later as well...

Greetings,

- Martin
 
Op Fri, 18 Nov 2011 23:14:55 +0100 schreef rickman <gnuarm@gmail.com>:
I'm curious why two standards came about. Was there a problem with
using the version the company developed? I'm assuming the industry
version came first and the JEDEC version came later. Or is that
wrong? It won't be too much trouble to support both, but I don't get
why both standards exist.
http://xkcd.com/927/



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
 
On Nov 21, 9:10 am, "Boudewijn Dijkstra"
<sp4mtr4p.boudew...@indes.com> wrote:
Op Fri, 18 Nov 2011 23:14:55 +0100 schreef rickman <gnu...@gmail.com>:

[...]

I'm curious why two standards came about.  Was there a problem with
using the version the company developed?  I'm assuming the industry
version came first and the JEDEC version came later.  Or is that
wrong?  It won't be too much trouble to support both, but I don't get
why both standards exist.

http://xkcd.com/927/

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
lol
 
In article <90ab17f7-1ece-4eb7-b511-bea1a5c38610@
4g2000yqu.googlegroups.com>, gnuarm@gmail.com says...
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about. Was there a problem with
using the version the company developed? I'm assuming the industry
version came first and the JEDEC version came later. Or is that
wrong? It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices? I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis. I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades. Any thoughts?

Rick
I asked the same question on here, a few years ago, and most of the
answers that came back were along the lines of "why would you want to do
that?". As you say, there doesn't seem to be any stand-alone device
available.
As our product is based on an embedded PC with a parallel port, we built
a copy of the Altera ByteBlaster on our last board (basically a 74HC244
and a few other parts), and used the reference code from Altera to do
the programming.
Others have mentioned using a bootloader in the FPGA code, and using
this to do the re-programming. I'm wary of doing this as there is no
way AFAIK to separate the bootloader functionality from the rest of the
code in the EEPROM bitstream and only erase / re-program the sectors
needed, so if there is a power failure in the middle of the update the
user has a bricked machine.
We are currently moving to a platform which has no parallel port and
trying to get the Altera JTAG JAM player working, using a PIC18F4550
(which was on the board anyway and has a few spare pins) as a bit-banged
controller, with the JAM file downloaded from the PC via UART. I'll let
you know if we ever get it working...

In summary, if you want a standalone JTAG Flash programmer, you'll
probably have to make your own. We may end up doing this ourselves, but
it's not a high-priority project at the moment.
 
On Nov 24, 9:27 am, <n...@rblack01.plus.com> wrote:
In article <90ab17f7-1ece-4eb7-b511-bea1a5c38610@
4g2000yqu.googlegroups.com>, gnu...@gmail.com says...









Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used.  Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM.  JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

I'm curious why two standards came about.  Was there a problem with
using the version the company developed?  I'm assuming the industry
version came first and the JEDEC version came later.  Or is that
wrong?  It won't be too much trouble to support both, but I don't get
why both standards exist.

How do you program production devices?  I know in large facilities
they pay big bucks for JTAG hardware and software that will work
across the spectrum including test and diagnosis.  I'm thinking there
is a market for a more limited device that is just used to program the
non-volatile memory in embedded systems in an efficient manner for
production and field upgrades.  Any thoughts?

Rick

I asked the same question on here, a few years ago, and most of the
answers that came back were along the lines of "why would you want to do
that?".  As you say, there doesn't seem to be any stand-alone device
available.
As our product is based on an embedded PC with a parallel port, we built
a copy of the Altera ByteBlaster on our last board (basically a 74HC244
and a few other parts), and used the reference code from Altera to do
the programming.
Others have mentioned using a bootloader in the FPGA code, and using
this to do the re-programming.  I'm wary of doing this as there is no
way AFAIK to separate the bootloader functionality from the rest of the
code in the EEPROM bitstream and only erase / re-program the sectors
needed, so if there is a power failure in the middle of the update the
user has a bricked machine.
We are currently moving to a platform which has no parallel port and
trying to get the Altera JTAG JAM player working, using a PIC18F4550
(which was on the board anyway and has a few spare pins) as a bit-banged
controller, with the JAM file downloaded from the PC via UART.  I'll let
you know if we ever get it working...

In summary, if you want a standalone JTAG Flash programmer,  you'll
probably have to make your own.  We may end up doing this ourselves, but
it's not a high-priority project at the moment.
That is what I am thinking of, but for boards that don't have an
embedded micro. Often the embedded micro is embedded into the FPGA
rather than being a chip on the board.

I was surprised to find that there are at least two main lines of
standards for this. But they seem to be very similar, just more code
to debug is all. Then they both have ASCII text versions as well as
compressed binary versions. I haven't found a draft copy of the JAM
spec. I could work from the code and reverse engineer that, but I'd
prefer to have a peek at the spec. I guess I'll have to shell out the
$100.

Rick
 
On Nov 18, 9:10 pm, "AMD...@gmail.com" <amd...@gmail.com> wrote:
IEEE 1532 is something that is a bit newer, I believe both xilinx and
altera
support it, not sure 'bout the others.http://grouper.ieee.org/groups/1532/
I took a look at this link and it requires a password even though it
is for a draft copy of the spec. Any idea where to get the user id
and password?

Rick
 
<news@rblack01.plus.com> wrote:

In article <90ab17f7-1ece-4eb7-b511-bea1a5c38610@
4g2000yqu.googlegroups.com>, gnuarm@gmail.com says...
Someone on Linkedin asked about a stand alone device for programming
the flash for FPGAs in the field or in a production environment.
There doesn't seem to be anything currently available like this.
Looking at the big three manufacturers I see at least two formats for
the files that might be used. Xilinx and Lattice use SVF with Xilins
offering support for a compressed version called... XSVF of course.
Altera uses JAM. JAM seems to be a JEDEC standard while SVF appears
to be a defacto industry standard developed by a company.

code in the EEPROM bitstream and only erase / re-program the sectors
needed, so if there is a power failure in the middle of the update the
user has a bricked machine.
We are currently moving to a platform which has no parallel port and
trying to get the Altera JTAG JAM player working, using a PIC18F4550
(which was on the board anyway and has a few spare pins) as a bit-banged
controller, with the JAM file downloaded from the PC via UART. I'll let
you know if we ever get it working...

In summary, if you want a standalone JTAG Flash programmer, you'll
probably have to make your own. We may end up doing this ourselves, but
it's not a high-priority project at the moment.
OpenOCD is a good start when it comes to Jtag. However I strongly
prefer using an SPI solution instead of jtag. I avoid jtag like the
plague.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 

Welcome to EDABoard.com

Sponsor

Back
Top