Working Altera Byteblaster compatible design published under GPL

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 : ->

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

Yes you're right.

But this could change in a near future !

Laurent

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

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

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

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

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

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.

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

Amontec, Larry schrieb:

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

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

Sure it is.

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

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

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)

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

Antti Lukats Xilant Technologies