FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-27-2006, 09:18 AM
Antti
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #2 (permalink)  
Old 04-27-2006, 09:20 AM
Antti
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published under GPL

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

Antti

Reply With Quote
  #3 (permalink)  
Old 04-28-2006, 03:19 PM
Amontec, Larry
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

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
Reply With Quote
  #4 (permalink)  
Old 04-28-2006, 03:29 PM
Antti
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published under GPL

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

Reply With Quote
  #5 (permalink)  
Old 04-28-2006, 03:37 PM
Amontec, Larry
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

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

Reply With Quote
  #6 (permalink)  
Old 04-28-2006, 07:56 PM
Stephen Williams
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

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."
Reply With Quote
  #7 (permalink)  
Old 04-28-2006, 08:37 PM
Antti
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published under GPL

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

Reply With Quote
  #8 (permalink)  
Old 04-28-2006, 11:50 PM
Stephen Williams
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

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."
Reply With Quote
  #9 (permalink)  
Old 04-29-2006, 12:53 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published under GPL

"Stephen Williams" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
> 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









Reply With Quote
  #10 (permalink)  
Old 04-29-2006, 01:31 AM
Jim Granville
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

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


Reply With Quote
  #11 (permalink)  
Old 04-29-2006, 07:27 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL


"Jim Granville" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
> 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
>

nops - even vendor generated ASCII SVF/STAPL are not compatible

Antti






Reply With Quote
  #12 (permalink)  
Old 04-29-2006, 08:56 PM
Eric Smith
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

"Antti Lukats" <[email protected]> writes:
> nops - even vendor generated ASCII SVF/STAPL are not compatible


Are you saying that they aren't actually compliant with the standard?

If so, it seems like submitting bug reports to the vendors to get this
fixed would be a good idea.
Reply With Quote
  #13 (permalink)  
Old 04-29-2006, 09:47 PM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL

"Eric Smith" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
> "Antti Lukats" <[email protected]> writes:
>> nops - even vendor generated ASCII SVF/STAPL are not compatible

>
> Are you saying that they aren't actually compliant with the standard?
>
> If so, it seems like submitting bug reports to the vendors to get this
> fixed would be a good idea.


that would not help. SVF is not complete standard, and some things that
are needed to program flash devices, serial proms, plds, just arent so
much doable with pure SVF as per SVF specification, this is where
the vendors step away to use files that can work on their silicon.

as of ram-fpga there are almost no issues using pure generic SVF but
with anything that has non-volatile its not so nice anymore.

same thing goes for STAPL what is an actual standard - if you use
Actel flavor of STAPL that was downloadable at the time PA3
was released, then voila - there was release notes saying the
STAPL player supports PA+ devices only. when I tried it
with Actel generatedPA3 STAPL files then I got parsing errors!
After fixing the STAPL player to not fail on parsing the Actel
STAPL (that is JAM) player reported succes in programming
and verifying an PA3 device using a STAPL file generated by
Actel software.

There was one gotcha - the silicon was programmed and
player reported verify succes, but the silicon did not work
(fpga did not get configured) - using the same STAPL file with
actel new programmed yielded the silicon being programmed
and configured.

similar things can be expected when working with Xilinx
config memories or PLD's using SVF files, or when trying
to program lattice devices using too old and incompatible
version of their VME player (they use SVF -> VME -> VMEplayer)

So there is no point of reporting issues - all the vendors are going
to reply: use the methods that are intended for the programming
eg XSVFplayer in case of Xilinx or
ispVME in case of Lattice or
correct version of STAPL player in case of Actel or
correnct version of JAM player in case of Altera

none of the vendors will add an magic option:
"generate valid generic SVF for all our silicon devices"
to their software - for one simple reason - they can not.

So no point of asking the impossible.

Please note that with RAM based FPGA there are almost no
(or shouldnt be) any issues using plain generic SVF, there
are some seldom exceptions - as example there are cases
where Xilinx Impact software can not configure S3e over
JTAG but software from Xilant Technologies still works -
this is because of some errata with mode pins - our software
uses a board specific workaround that use NOR Flash CFI
interface to place the ext flash in Query ID mode for the
time of JTAG configuration that prevents the FPGA to
see valid bitstream header (that prevent Impact from
from proper configuration) - this is an extreme case, but
ther are really cases where generic JTAG tools (like
Impact) fail in 'native' eg not SVF mode, so if in such
case an SVF is generated then it would also fail. Sure
in this example our software could generate plain
vanilla SVF that uses the CFI trick, and theoretically
could impact do that too - but it doesnt. Asking
Xilinx to fix that - they will not do (and for good
reason - they fixed the silicon).

To my knowledge this issue should not happen any
more with actual S3e production silicon, but there
is still some ES silicon around that under some
circumstances requires that CFI trick (or change
of mode pins as xilinx suggest as workaround).

Antti

PS folks belive me, I know what I am talking, I have
been struggling with in-system flash programming for
very long time, some links to my early works can still be
found with google search: "PIP02 programming software"
it supported many different
programmer (most of what I have never seen) and in many
cases worked with them better than the original software
from the programmer vendors. I am using the same low
level hardware abstraction layer PINAPI(tm) in our
current JTAG software, what again is thanks to that
completly separated from the 'cable driver' that is
all of our software would work with any jtag cable
given there is a very simple low level driver (basically
pin bit-bang driver)

PPS the JTAG programming should be plain simple
and always work, but there are many cases where
strange things are observed - like S3 board that
will get configured with either Cable IV (original)
or Platform cable. However when platform flash
config is enabled then the S3 starts up with bad
bitstream - done=1 but impact gives verify
error, also when platform is erased, but only
when using the Cable IV !! when using the
USB Cable it all works. The S3 is not bad
the thing can be observed any several boards.

If impact fails with Cable IV and succeeds with
USB cable then SVF player would fail, or
at least would not guaranteed to succeed. This
issues is not related to bad board or JTAG
signal quality. Similary there is 'minimum clock
requirement' for some revision of platform
flash, as SVF player that is standard compliant
doesnt have to maintain any minimum TCK
then those config memories would never get
programmed using SVF.



















Reply With Quote
  #14 (permalink)  
Old 05-01-2006, 08:08 AM
Amontec, Larry
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published underGPL


>
> there are lots of small things...
>
> Antti
>


It is very easy for vendors to be SVF compilant.
SVF is well documented, and easy to understand.
A JTAG stream based on SVF is very stable.

The only small things where troubles are coming from vendor is :
- in the FREQUENCY definition in the SVF files,
- in the need to repeat the last scan (SDR SIR) command if it failed.

Our SVF player will have options to auto-detect the frequency, and to
allow the repeat of a scan if it failed.

My long experience with JTAG topic let me say you, it is not so hard to
provide/write a generic SVF Player.

From my experience Xilinx, Altera Lattice generate good SVF files. All
vendor have just advantage to respect SVF specification.

Laurent
www.amontec.com
Reply With Quote
  #15 (permalink)  
Old 05-02-2006, 07:21 PM
Antti
Guest
 
Posts: n/a
Default Re: Working Altera USB-Blaster compatible design published under GPL

Amontec, Larry schrieb:
> >
> > there are lots of small things...
> >
> > Antti
> >

>
> It is very easy for vendors to be SVF compilant.


Yes, it is. And no it isnt. And they are'nt.
It would be easy for vendors to be more SVF compliant,
but not to support ___ALL___ their products with
plain vanilla SVF

> SVF is well documented, and easy to understand.


Yes it is.
Still it's not a formal standard and less standard
as STAPL (what is 'standard')

> A JTAG stream based on SVF is very stable.


Sure it is.

> The only small things where troubles are coming from vendor is :
> - in the FREQUENCY definition in the SVF files,
> - in the need to repeat the last scan (SDR SIR) command if it failed.
>


Exactly - there are small problems, thats what I have said as well.

> Our SVF player will have options to auto-detect the frequency, and to
> allow the repeat of a scan if it failed.
>

And that SVF player will be able to use SVF generated by Vendor tools,
and
program amongst others:
1) Xilinx XC95, XC18, XCF
2) Lattice machXO, XP, all PLDs, ispClock, ..
3) Altera MAX2
4) Actel PA3

?!
If you do a very very good job (involving some AI built into the
player)
then I belive your player will program some chips from the list, but
not all as SVF is not provided at all by all vendors, and SVF for the
parts listed has special vendors things for the small things...

> My long experience with JTAG topic let me say you, it is not so hard to
> provide/write a generic SVF Player.
>


Dear Laurent,

AGREE.
100 % percent.
It' very easy to provide/write generic SVF player.
It really is.

So I wonder why the Amontec SVF player is announced
for so long time with no date of release known?
If it is so easy why isnt it available for Amontec customers?

As of support for Coolrunner programming inside the Amontec
Chameleon last I checked the configuration software from
Amontec wasnt able to use XSVF files generated from last release
of Xilinx tools, so Amontec 'invented' Amontex SVF, (file extension
*.ASVF) that is actually just Xilinx XSVF generated with some out
date and obsoleted XSVF tool?

We have modified the XSVFplayer from Xilinx (updated version!)
to support PINAPI(tm) drivers, and we have a driver to access
the Coolrunner config jtag on Chameleon so we can configure
Amontec Chameleon with 'standard XSVF' from Xilinx tools,
whereis Amontex onw software can not do that (at least did
not when I last checked)

> From my experience Xilinx, Altera Lattice generate good SVF files. All
> vendor have just advantage to respect SVF specification.
>


Yes they have (would have) advantage using plaind standard generic SVF
but as the big boys really dont like the community sandbox so is the
support of generic SVF also not nearly as good as it could be.

Altera uses JAM/STAPL as primary, sure - they invented it, so no
wonder they are not much interested in SVF or anything they did not
invent.

Actel uses STAPL as it capable to handle the flash programming without
'vendor extensions' - but unfortunatly they are doing that also not
confirm, so the Actel STAPL is dedicated for Actel only

Lattice has SVP+Plus and will keep using it, it's not standard, and no
one else will be using it. For end users they have VME that provides
all the necessary functions for flash devices, so chances to see
full generic SVF from lattice (for all products) are nil as well.

Xilinx defenetly doesnt want to deal with standards introduced by
Altera (JAM/STAPL) so they are using their own derivate of SVF to
support their flash devices. Again as SVF alone is not sufficent
for the flash and Xilinx already has XSVF that no-other vendor will
use then seeing full generic SVF for all Xilinx devices also not
possible


> Laurent
> www.amontec.com


Antti Lukats
Xilant Technologies

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Altera ByteBlaster II schematic Leon Heller FPGA 12 01-29-2008 07:16 PM
Altera ByteBlaster II vs ByteBlaster MV [email protected] FPGA 1 08-26-2005 12:13 AM
Design question (Working with Altera EPXA1F484C1) Panic FPGA 1 10-06-2003 11:11 PM


All times are GMT +1. The time now is 08:46 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved