alvieboy Posted August 28, 2011 Report Share Posted August 28, 2011 Hi, I was kinda bored this morning, so I decided to think and implement a indirect JTAG programmer for Papilio One. The objective is to present regular JTAG signals (TDI/TDO/TCK/TMS) at some preconfigured wing, and allow "butterfly loader" or any other FTDI-based JTAG programmer to address this device. Primary reason for this is to resume my work on C/WING and other JTAG devices without having to use my old S3E eval board (which allows, using the hirose connector, to connect other devices to JTAG chain). The principle here is quite simple, and operates at a very high speed. We use the BSCAN component on S3E, which exports 2 user chains. The first chain is used to select one of these three modes: CONFIG, TMS and TXRX. To access these modes one must shift the appropriate mode number into USER1 chain. After selecting the mode, USER2 chain behaves as follows: if mode is CONFIG, a 33-bit register/sub-chain can be accessed. This register uses 32-bits for TXRX size, plus one bit to signal end of shift (TMS up) if mode is TXRX, the TDI is mapped into device TDO, while holding TMS low - however, after we shift N bits, and N matches the 32-bit TXRX size we set on CONFIG, TMS will be set according to the 1 bit end-of-shift signal. This mimics the operation of the JTAG/IO interface in butterfly loader code. if mode is TMS, the TDI is mapped into device TMS, which allows us to change TAP state. In TXRX/TMS modes the TCK input clock is mapped also as output clock. Right now I'm updating the software to use this "indirect jtag" approach, but looking at waveforms in simulation it's quite clear that this must work (and up to high frequencies - the design can withstand 200MHz according to synthesis). You think this might be useful ? Want me to publish this ? Best, Álvaro Link to comment Share on other sites More sharing options...
ben Posted August 28, 2011 Report Share Posted August 28, 2011 For another approach, you can have a look at what I have done using an soft AVR8 and a C client to push the data through UART. http://www.gadgetfactory.net/gadgetforum/index.php?topic=277 It certainly won't work with butterflyloader or any JTAG-based program, but XSVF is easy to generate, and the client app is really simple -- especially since all the config options are hard-coded in this beta version... Can't say which of the two approaches would give best results. I should have thought that generating the TDI/TMS/TCK signals insisde the papilio would be faster than sending them through USB, but XSVF is really verbose (although it's nothing compared to SVF) and the AVR program is not optimized, so yours might be faster. A though for Jack: why not add a jumper on the papilio board to switch between a closed JTAG chain (normal conf) and an open chain with TDI/TDO pads to allow the plugging of other devices ? then, we could use papilio-prog directly to program the device, without even uploading a bit file to the papilio fpga. Link to comment Share on other sites More sharing options...
Jack Gassett Posted August 29, 2011 Report Share Posted August 29, 2011 Well this is great to have these options! I like the XSVF player because you can script commands like a reset and such. But I do really like the idea of being able to use the existing papilio-prog approach to program the C/RAM Wing and other devices. It's also nice to program a bit file directly without having to generate xsvf with impact. So I'd say this will be great to publish. Thanks, Jack. Link to comment Share on other sites More sharing options...
Guest AtomSoft Posted September 1, 2011 Report Share Posted September 1, 2011 hows this coming along? Im about to order some parts to build that parallel cable PC3 i think its called from Xilinx... i need it to program some CPLDs i want to order also. I was thinking this should be able to replace the PC3 and i wouldnt have to build it at all ! SO if this is actually working already it would be nice to know so i can take the parts out of my list and just order more CPLDs. If you think i should build the parallel programmer cable anyway then ill leave the parts in the list. Its only like $8 but thats like 2-4 cplds Link to comment Share on other sites More sharing options...
alvieboy Posted September 2, 2011 Author Report Share Posted September 2, 2011 Hi, Yes, the JTAG interface seems to be working, but I don't have a means to replay XSVF into the CPLD. Perhaps ben can help me on this This was actually trickier than I first thought. There's a lot of resynchronization going inside the BSCAN component which prevented proper TDI/TDO interaction. Right now it's working OK it seems, I can shift in/out in proper order. So expect a JTAG debugger for ZPUino soon. Ben: if you read this - I saw a lot of "progalgxcf" implementations for the current papilio loader (xs3cprog), but none seems to work. All I have is a mean to change TAP state (shift out TMS) and shift out+in the TDI/TDO thing in bursts. Your XSVF replayer looks very nice, but I cannot use the serial port because I want reprogramming with live systems - otherwise your tool (which is a very useful one) would suffice for me. Think debugging an internal processor with an already implemented TAP+CHAINS. I am not sure who maintains xs2cprog. Jack: do you have any idea ? Álvaro Link to comment Share on other sites More sharing options...
ben Posted September 3, 2011 Report Share Posted September 3, 2011 Ben: if you read this - I saw a lot of "progalgxcf" implementations for the current papilio loader (xs3cprog), but none seems to work. All I have is a mean to change TAP state (shift out TMS) and shift out+in the TDI/TDO thing in bursts. Your XSVF replayer looks very nice, but I cannot use the serial port because I want reprogramming with live systems - otherwise your tool (which is a very useful one) would suffice for me. Think debugging an internal processor with an already implemented TAP+CHAINS. the 'firmware' part of my XSVF player, which actually translates the XSVF commands into TAP commands, is a AVR C program. I'm pretty sure you can have it to compile on a PC and use your BSCAN interface. That is actually how I made a prototype, using a AVR firmware that updated a port according to bytes received on a UART -- a poor man's bscan interface, really. I switched to a smarter firmware because UART was way to slow for that, unlike the FTDI 2232 bitbang mode, obviously. Link to comment Share on other sites More sharing options...
Jack Gassett Posted September 7, 2011 Report Share Posted September 7, 2011 The xc3sprog code is maintained on sourceforge: http://sourceforge.net/projects/xc3sprog/ I took a look at it recently to see about using the latest version instead of papilio_prog but it has diverged quite a bit. Looks like it will be some effort to switch to it and get it to do what we need. Jack. Link to comment Share on other sites More sharing options...
alvieboy Posted September 12, 2011 Author Report Share Posted September 12, 2011 the 'firmware' part of my XSVF player, which actually translates the XSVF commands into TAP commands, is a AVR C program. I'm pretty sure you can have it to compile on a PC and use your BSCAN interface. That is actually how I made a prototype, using a AVR firmware that updated a port according to bytes received on a UART -- a poor man's bscan interface, really. I switched to a smarter firmware because UART was way to slow for that, unlike the FTDI 2232 bitbang mode, obviously ben: I'm still trying to do that. After a few byte order struggling I think I managed most of it, but I'm still having some troubles to program the thing. Do you happen to have a successful debug log for XC9527 (aka C/RAM CPLD) ? I'm wondering if my part is somehow broken... or I might miss something. Alvaro Link to comment Share on other sites More sharing options...
ben Posted September 12, 2011 Report Share Posted September 12, 2011 Yes, I did program successfully a c/ram cpld. Actually, the only difficult step (but quite a step...) was to get a correct answer for the 'id' command (the first real command of the xsvf) Then, you know you've got the xir/xdr commands working, and it's a matter of.correcting silly mistakes (you rely on my code there, I did make and correct more than my share) The cpld seemed to work fine on the first successful program cycle (ie without tdo mismatch) if you are not too lazy (I am), you can have impact generate a verify xsvf and run it. Link to comment Share on other sites More sharing options...
alvieboy Posted September 12, 2011 Author Report Share Posted September 12, 2011 The cpld seemed to work fine on the first successful program cycle (ie without tdo mismatch) if you are not too lazy (I am), you can have impact generate a verify xsvf and run it. Everything kinda looks ok, but (note tihs is my own debug code, not yours) if fails on erase (if I don't erase it, programming seems to actually be done, but fails somewhere at the end). Note that binary values in TDI/TDO debug are depicted L->R (first bits on left, either for TDO and for TDI): JTAG chainpos: 0 Device IDCODE = 0x29504093 Desc: XC9572 XREPEAT TX TMS: 11111 TX TMS: 0 XRUNTEST XSIR 0xfe TX TMS: 1100 TX TDI: 01111111 (+TMS1) XSDRSIZE 32 XTDOMASK ff ff ff ff XSDRTDO 00 00 00 00 expect 29 50 40 93 TX TMS: 10100 TX TDI: 00000000000000000000000000000000 (+TMS1) RX TDO: 11001001000000100000101010010100 HEX: 93 40 50 29 0 : 29 29 [actual 29 expected 29 mask ff] 1 : 50 50 [actual 50 expected 50 mask ff] 2 : 40 40 [actual 40 expected 40 mask ff] 3 : 93 93 [actual 93 expected 93 mask ff] Read: ff XSIR 0xff TX TMS: 101100 TX TDI: 11111111 (+TMS1) XSIR 0xe8 TX TMS: 101100 TX TDI: 00010111 (+TMS1) XSIR 0xec TX TMS: 101100 TX TDI: 00110111 (+TMS1) XRUNTEST XSDRSIZE 27 XTDOMASK 00 00 00 00 XSDRTDO 06 a9 57 fe expect 00 00 00 00 TX TMS: 10100 TX TDI: 011111111110101010010101011 (+TMS1) RX TDO: 001111111111111111111111111 HEX: fc ff ff 07 0 : 00 00 [actual 07 expected 00 mask 00] 1 : 00 00 [actual ff expected 00 mask 00] 2 : 00 00 [actual ff expected 00 mask 00] 3 : 00 00 [actual fc expected 00 mask 00] XRUNTEST XSIR 0xed TX TMS: 101100 TX TDI: 10110111 (+TMS1) XRUNTEST XSDRTDO 00 3f ff fe expect 00 00 00 00 TX TMS: 10100 TX TDI: 011111111111111111111100000 (+TMS1) RX TDO: 101111111110101010010101011 HEX: fd 57 a9 06 0 : 00 00 [actual 06 expected 00 mask 00] 1 : 00 00 [actual a9 expected 00 mask 00] 2 : 00 00 [actual 57 expected 00 mask 00] 3 : 00 00 [actual fd expected 00 mask 00] XTDOMASK 00 00 00 03 XSDRTDO 00 3f ff fe expect 00 00 00 03 TX TMS: 10100 TX TDI: 011111111111111111111100000 (+TMS1) RX TDO: 101111111111111111111100000 HEX: fd ff 3f 00 0 : 00 00 [actual 00 expected 00 mask 00] 1 : 00 00 [actual 3f expected 00 mask 00] 2 : 00 00 [actual ff expected 00 mask 00] 3 : 03 01 [actual fd expected 03 mask 03] SDR failed -- trying again (31 left) And it stays here, fails this last SDR always with same value (0x1 instead of 0x3) That's why I'd like so see a debug dump from yours. This is the ISC_ERASE phase. Link to comment Share on other sites More sharing options...
alvieboy Posted September 12, 2011 Author Report Share Posted September 12, 2011 ben: sorry to be such a PITA, but I wonder if you could try yours C/RAM wing with your player, but change it to print the IR shift out at least on the beginning. I suspect something is wrong (read/write protection on my device). If I generate a plain SVF file, I can see this there: //Check for Read/Write Protect. SIR 8 TDI (ff) TDO (01) MASK (e3) ; This is not in the XSVF file (not sure why, but appears in both SVF and STAPL). Anyway, I am getting "0x81" and not "0x01" when I shift any IR. The "write protect override" only comes after this check, which is also weird. I have no Xilinx cable, so it's not easy for me to use this part with Impact. Álvaro Link to comment Share on other sites More sharing options...
ben Posted September 12, 2011 Report Share Posted September 12, 2011 And it stays here, fails this last SDR always with same value (0x1 instead of 0x3) That's why I'd like so see a debug dump from yours. This is the ISC_ERASE phase. This part gave me headaches as well -- re-reading my earlier post, I realized I have a selective memory... Did you implement the runtest delay *with the clock cycles* ? the spec says you should wait for at least x us, and run at least x clock cycles, x being the runtest value -- I run x TCK cycles at a low clock (<1MHz). I'd recommend trying with values way beyond the spec to make sure that this isn't the issue. I'll try to find some time to dump the values some time, but I cannot promess when -- my schedule is unpredictable at these times. And, finally, I don't know about the read/write protect. Link to comment Share on other sites More sharing options...
alvieboy Posted September 13, 2011 Author Report Share Posted September 13, 2011 Thanks for your tips, you were right. The timings were not correct, however they are per XSVF spec. I had to add additional delays. XC9500 programming datasheet says RUNTEST "n" should wait "n" milissecconds (no actual need to pulse TCK). However if I do follow these timings I have errors. Something like 3 times that value seems to work (I wonder if this is due to FTDI latencies also). So it's working right now, but it's not very fast either. Erasing + programming + verifying takes 1m15s, mostly due to those delays on erase, plus having to check all transactions (and additional delays): $ time ./xc9500prog file.xsvf JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E JTAG chainpos: 0 Device IDCODE = 0x29504093 Desc: XC9572 real 1m15.331s Can you program it faster ? Link to comment Share on other sites More sharing options...
ben Posted September 13, 2011 Report Share Posted September 13, 2011 From memory, a simple program operation took around 1'40. I couldn't say if verify was included or not. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.