<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=.)
--------------------------------------------------------------

On Nov 18, 9:10=A0pm, "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

On Nov 24, 9:27=A0am, <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. =A0Xilinx and Lattice use SVF with Xilins
> > offering support for a compressed version called... XSVF of course.
> > Altera uses JAM. =A0JAM 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. =A0Was there a problem with
> > using the version the company developed? =A0I'm assuming the industry
> > version came first and the JEDEC version came later. =A0Or is that
> > wrong? =A0It won't be too much trouble to support both, but I don't get
> > why both standards exist.
>
> > How do you program production devices? =A0I know in large facilities
> > they pay big bucks for JTAG hardware and software that will work
> > across the spectrum including test and diagnosis. =A0I'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. =A0Any 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?". =A0As 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. =A0I'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. =A0I'll le=
t
> you know if we ever get it working...
>
> In summary, if you want a standalone JTAG Flash programmer, =A0you'll
> probably have to make your own. =A0We may end up doing this ourselves, bu=
t
> 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

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 21, 9:10=A0am, "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. =A0Was there a problem with
> > using the version the company developed? =A0I'm assuming the industry
> > version came first and the JEDEC version came later. =A0Or is that
> > wrong? =A0It 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: =A0http://www.opera.c=
om/mail/
> (Remove the obvious prefix to reply.)

lol

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.)

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

On Nov 18, 9:10=A0pm, "AMD...@gmail.com" <amd...@gmail.com> wrote:
> On Nov 18, 4:14=A0pm, 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. =A0Xilinx and Lattice use SVF with Xilins
> > offering support for a compressed version called... XSVF of course.
> > Altera uses JAM. =A0JAM 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. =A0Was there a problem with
> > using the version the company developed? =A0I'm assuming the industry
> > version came first and the JEDEC version came later. =A0Or is that
> > wrong? =A0It won't be too much trouble to support both, but I don't get
> > why both standards exist.
>
> > How do you program production devices? =A0I know in large facilities
> > they pay big bucks for JTAG hardware and software that will work
> > across the spectrum including test and diagnosis. =A0I'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. =A0Any 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. =A0These 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. =A0We 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. =A0You 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

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