Re: [Xc3sprog-users] XC2C384: it _almost_ works but doesn't quite

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Egnor,

For some more speed, you can safely use 1<<11.

The explanation of what is going on is somewhat complicated but it works
and kind of makes sense from a cpld implementation point of view.

Regards,
Raul
Am 01.09.2012 17:38 schrieb "Dan Egnor" <eg...@of...>:

> (Re-adding xc3sprog-users, since this is getting interesting...)
>
> Changing
>
> #define XPC_A6_CHUNKSIZE (1<<13)
>
> to
>
> #define XPC_A6_CHUNKSIZE 4
>
> makes my problem go away!
>
> (It also makes programming somewhat slower not surprisingly.)
>
> I think this adds a lot of support to your hypothesis.  I read through the
> threads you linked to and I come away with the notion that nobody seems to
> quite know exactly what's going on?  Are you pretty confident in your
> understanding of the situation?  Maybe basically the modifications you made
> within opencores (?) should be ported to xs3prog?  And I guess urjtag is
> also broken but the CHUNKSIZE=4 means they never see the problem?
>
> Probably I should just use a different JTAG adapter?  The XPC is annoying
> in other ways too!  (Silly "fxload" business to get it working...)
>
> -- egnor
>
> On Sat, Sep 1, 2012 at 4:19 AM, Raul Fajardo <rfa...@gm...> wrote:
>
>> This might be related to an issue with the xpc_usb cable implementation.
>> But I have no guarantees for it.
>>
>> While porting the cable's implementation to another system, I noticed
>> that the assumption of bursts of more than 32 bits to be aligned is false
>> as long as the burst is not multiple of 32 (64 is ok but 63 has to be
>> realigned).
>>
>> I assumed that it happens seldom, possibly because the application does
>> not use bursts on non-32-multiple numbers. But there might be an exception.
>> Take a look on the port where I commented it:
>> http://sourceforge.net/mailarchive/message.php?msg_id=28809703
>>
>> Some followups:
>> http://sourceforge.net/mailarchive/message.php?msg_id=28824266
>>
>> Maybe this helps some.
>> Regards,
>> Raul
>>
>> On Sat, Sep 1, 2012 at 2:34 AM, Dan Egnor <eg...@of...> wrote:
>>
>>>  Hi, I have an XC2C384 ("CoolRunner-II"), which I'm trying to program
>>> using xc3sprog.
>>>
>>> As the subject says, it almost works.  Actually it does work but
>>> verification fails.  First of all, if I try to erase, it complains:
>>>
>>> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data
>>> ./xc3sprog -c xpc -e
>>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ OS: Linux
>>> Free software: If you contribute nothing, expect nothing!
>>> Feedback on success/failure/enhancement requests:
>>> http://sourceforge.net/mail/?group_id=170565
>>> Check Sourceforge for updates:
>>> http://sourceforge.net/projects/xc3sprog/develop
>>>
>>> Not erased in block 1 byte 232 value 0xf0
>>>
>>>
>>> I modified the code to not stop after the first blank check failure, and
>>> that always fails in the same place:
>>>
>>> ...
>>> Not erased in block 2 byte 232 value 0xf0
>>> Not erased in block 3 byte 232 value 0xf0
>>> Not erased in block 4 byte 232 value 0xf0
>>> Not erased in block 5 byte 232 value 0xf0
>>> Not erased in block 6 byte 232 value 0xf0
>>> ... and so on ...
>>>
>>>
>>> If I try to actually program, I get verification failures:
>>>
>>> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data
>>> ./xc3sprog -c xpc myfile.jed:w
>>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ OS: Linux
>>> Free software: If you contribute nothing, expect nothing!
>>> Feedback on success/failure/enhancement requests:
>>>         http://sourceforge.net/mail/?group_id=170565
>>> Check Sourceforge for updates:
>>>         http://sourceforge.net/projects/xc3sprog/develop
>>>
>>> Verify: Row   1
>>> Verify mismatch row 1  byte 1860 cal file 1 device 0
>>>
>>>
>>> Again, with a hack to make it keep verifying after the first failure,
>>> additional similar failures are found:
>>>
>>>
>>> ...
>>> Verify mismatch row 1  byte 1861 cal file 1 device 0
>>> Verify mismatch row 1  byte 1866 cal file 1 device 0
>>> Verify: Row   2
>>> Verify mismatch row 2  byte 1857 cal file 1 device 0
>>> Verify mismatch row 2  byte 1858 cal file 1 device 0
>>> Verify mismatch row 2  byte 1859 cal file 1 device 0
>>> Verify mismatch row 2  byte 1861 cal file 0 device 1
>>> Verify mismatch row 2  byte 1864 cal file 1 device 0
>>> Verify mismatch row 2  byte 1866 cal file 0 device 1
>>> Verify mismatch row 2  byte 1867 cal file 0 device 1
>>> Verify: Row   3
>>> ... and so on ...
>>>
>>>
>>> Interestingly, after this "failed" programming run, if I go ahead and
>>> tell iMPACT to verify against the same .JED file, verification succeeds!
>>>  Also the opposite: if I program with iMPACT, I get the same verification
>>> errors with xc3sprog.  So actually I think xc3sprog's programming is
>>> working O.K..  My suspicion is that there's some "don't care" bits in the
>>> bitfile, and xc3sprog doesn't know to ignore those when doing a
>>> verification or blank check.  Does this sound plausible?
>>>
>>> I'm using a Platform Cable USB II, but given that I'm getting this far,
>>> I'm pretty sure the JTAG adapter is working just fine.  The part gets
>>> detected successfully, no issue there:
>>>
>>> % ./xc3sprog -c cpc
>>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ OS: Linux
>>> Free software: If you contribute nothing, expect nothing!
>>> Feedback on success/failure/enhancement requests:
>>> http://sourceforge.net/mail/?group_id=170565
>>> Check Sourceforge for updates:
>>> http://sourceforge.net/projects/xc3sprog/develop
>>>
>>> JTAG loc.:   0  IDCODE: 0x16d5c093  Desc:                  XC2C384_TQ144
>>> Rev: A  IR length:  8
>>>
>>>
>>> -- egnor
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Xc3sprog-users mailing list
>>> Xc3...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users
>>>
>>>
>>
>