Working Altera Byteblaster compatible design published under GPL

Hi Folks,

I had published some info about Altera USB Blaster protocol about a
year ago (march 2005)
http://wiki.openchip.org/index.php/Altera_USB_Blaster

but I did not finish the project of making USB Blaster clone - there
are since that 2 different companies offering USB Blaster either as
standalone or as add-on function on FPGA board, but now there is also a
working solution published
under GPL license available from

http://www.ixo.de/info/usb_jtag/

there are 2 flavors one uses FT245 + 64 macrocell PLD the other option
emulates the FT245 and PLD with general purpose USB microcontroller. In
the download archive is firmware for Cypress FX2 but its relativly easy
to port to other USB MCU as well. As example it would fit into 4k code
limit of the KEIL compiler supplied with SiLabs USB MCU's

C8051F326 as example is very low cost USB MCU (2.36USD qty 1 !) - I
have not fully ported it to SiLabs but initial testing is ok

Antti

sorry the title was wrong - its USB Blaster, not Byteblaster of course

Antti

Antti wrote:
> sorry the title was wrong - its USB Blaster, not Byteblaster of course
> 
> Antti
> 

Or use the Amontec JTAGkey as new USB - JTAG adapter, and write open 
source software.

JTAGkey is already supporting all ARM7 and ARM9 via the OpenOCD jtag server.

JTAGkey has the advantage to accept a wide range of JTAG IO voltages 
from true 5V to 1.4V.

We are now working on the support of Altera, Xilinx, Lattice FPGA / CPLD 
via a powerfull JTAGkey SVF player (should be dispo in the next month).

Have a look at JTAGkey :
  -> http://www.amontec.com/jtagkey.shtml

Regards,
Laurent

unfortunatly FPGA companies do not support 3rd party programming cables
:(

so as example if you want to evaluate nios or use signalTap then you
need altera supported cable

Antti

Antti wrote:

> unfortunatly FPGA companies do not support 3rd party programming cables
> :(
> 
> so as example if you want to evaluate nios or use signalTap then you
> need altera supported cable
> 
> Antti
>

Yes you're right.

But this could change in a near future !

Laurent

Antti wrote:
> unfortunatly FPGA companies do not support 3rd party programming cables
> :(
> 
> so as example if you want to evaluate nios or use signalTap then you
> need altera supported cable

But can't you get an SVF stream out of the vendor tools then
use a generic SVF player to actually run the program operation?
This wouldn't work for the fancy stuff (like auto-detecting a
chain) but won't it work for the basic operation of doing a
prom program, etc?

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

the answer is almost always: Yes/No

all the in-system-programming and JTAG stuff is not as much standard as
it could be.

there have been many attempts to develop vendor neutral or at least
multi-vendor technologies but all attempts have failed so far.

its seems that big boys have big issues playing it nicely in a (common)
sandbox, so almost all vendors have some 'special' things making the
'generic' things not fully useable.

xilinx has XSVF a binary version of SVF, some Xilinx parts can not be
programmed with standard SVF,
lattice has SVF-Plus
altera has its own flavors of JAM/STAPL
actel has its own flavors of STAPL

if you think a SVF player is a SVF player is a SVF player, then no it
isnt,
same for JAM/STAPL

there are small things that make some the all stuff not fully
compatible.

sure for some cases it works, works also cross vendor, but there is
absolutly no guarantee.

as example for Lattice XP you need VME player (VME is converted from
SVF) version 11 or above, similarly some xilinx PLDs may require some
special version of XSVF player to work, etc...

there are lots of small things...

Antti

Antti wrote:
> the answer is almost always: Yes/No
> 
> all the in-system-programming and JTAG stuff is not as much standard as
> it could be.
> 
> there have been many attempts to develop vendor neutral or at least
> multi-vendor technologies but all attempts have failed so far.
> 
> its seems that big boys have big issues playing it nicely in a (common)
> sandbox, so almost all vendors have some 'special' things making the
> 'generic' things not fully useable.
> 
> xilinx has XSVF a binary version of SVF, some Xilinx parts can not be
> programmed with standard SVF,
> lattice has SVF-Plus
> altera has its own flavors of JAM/STAPL
> actel has its own flavors of STAPL
> 
> if you think a SVF player is a SVF player is a SVF player, then no it
> isnt,
> same for JAM/STAPL

So the issue is not whether one count send a properly formatted
SVF file stream through a generic player and get a PROM/FPGA to
become programmed, but that one can't easily get that SVF string
in the first place.

Bear with me, I really don't know. I just have in front of me a
printout of "Serial Vector Format Specification" and some wishful
thinking.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

"Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag 
news:FPidnYNfX-iWE8_ZRVn-hA@giganews.com...
> Antti wrote:
>> the answer is almost always: Yes/No
>>
>> all the in-system-programming and JTAG stuff is not as much standard as
>> it could be.
>>
>> there have been many attempts to develop vendor neutral or at least
>> multi-vendor technologies but all attempts have failed so far.
>>
>> its seems that big boys have big issues playing it nicely in a (common)
>> sandbox, so almost all vendors have some 'special' things making the
>> 'generic' things not fully useable.
>>
>> xilinx has XSVF a binary version of SVF, some Xilinx parts can not be
>> programmed with standard SVF,
>> lattice has SVF-Plus
>> altera has its own flavors of JAM/STAPL
>> actel has its own flavors of STAPL
>>
>> if you think a SVF player is a SVF player is a SVF player, then no it
>> isnt,
>> same for JAM/STAPL
>
> So the issue is not whether one count send a properly formatted
> SVF file stream through a generic player and get a PROM/FPGA to
> become programmed, but that one can't easily get that SVF string
> in the first place.
>
> Bear with me, I really don't know. I just have in front of me a
> printout of "Serial Vector Format Specification" and some wishful
> thinking.
>
Hi Steve,
its only wishfull thinking, :(
compare the different source code revisions of xilinx xsvfplayer and 
svf2xsvf
and lattice svf2vme and ispVM and you will understand, as with actel/altera
and jam-stapl its not much better.

there are of course fpgas and cases where 'generic SVF' would be ok,
but all fpga vendors have devices where pure generic svf+player would
not work :(

antti

Stephen Williams wrote:

> Antti wrote:
> 
>>the answer is almost always: Yes/No
>>
>>all the in-system-programming and JTAG stuff is not as much standard as
>>it could be.
>>
>>there have been many attempts to develop vendor neutral or at least
>>multi-vendor technologies but all attempts have failed so far.
>>
>>its seems that big boys have big issues playing it nicely in a (common)
>>sandbox, so almost all vendors have some 'special' things making the
>>'generic' things not fully useable.
>>
>>xilinx has XSVF a binary version of SVF, some Xilinx parts can not be
>>programmed with standard SVF,
>>lattice has SVF-Plus
>>altera has its own flavors of JAM/STAPL
>>actel has its own flavors of STAPL
>>
>>if you think a SVF player is a SVF player is a SVF player, then no it
>>isnt,
>>same for JAM/STAPL
> 
> 
> So the issue is not whether one count send a properly formatted
> SVF file stream through a generic player and get a PROM/FPGA to
> become programmed, but that one can't easily get that SVF string
> in the first place.

Hmm.. I read what Antti said as more
"Not all SVF strings are created equal.."


> Bear with me, I really don't know. I just have in front of me a
> printout of "Serial Vector Format Specification" and some wishful
> thinking.

Also, if the vendor uses non-binary SVF themselves, then you can expect
valid files, but if they export SVF as some tick-box option, then
expect lower yields...

-jg