View Single Post
  #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