Re-using the JTAG.. core

Development Boards MicroMod
1

Hi,

I am interested in modifying OpenOCD so it can program Xilinx FPGAs (well, Spartan 3’s anyway). There is already a stand-alone program (xc3sprog) that does this, but to my mind it makes sense to reuse existing JTAG driver code instead of re-inventing the wheel.

I tried building OpenOCD (on FreeBSD - I patched it a bit) and running it but I get this…

[inchoate 16:03] ~/projects/FPGA/openocd/trunk >./src/openocd -d -f foo
Info:    openocd.c:86 main(): Open On-Chip Debugger (2006-06-25 23:00 CEST)
Debug:   jtag.c:1145 jtag_init():
Warning: parport.c:242 parport_init(): parport_init() called
Debug:   parport.c:192 parport_reset(): trst: 0, srst: 0
Debug:   jtag.c:229 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:229 jtag_call_event_callbacks(): jtag event: 1
Error:   jtag.c:1100 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch

Unfortunately I don’t have much JTAG clue and I haven’t delved into the code (no time just yet)… Anyone have an opinion as to the feasibility?

I note that OpenOCD has an XSVF player and the Xilinx FPGA tools can generate those for programming the FPGA (or flash memory) so it would be nice if at least that would work.

2

Extending the XSVF player to Spartan and Virtex devices is on my todo list, but it’s low priority and I haven’t had time yet.

It’s certainly feasible, but you’d have to look at the programming algorithms of the respective chips. What type of input does xc3sprog take? The .bit file?

As far as I know OpenOCD should build on FreeBSD. The 2006-06-25 version is rather old - you should grab the latest code from SVN to make sure you have all the latest fixes (these include portability patches).

Regards,

Dominic

3

Darius,

The best will be to work on the SVF format.

SVF is generated by Lattice, Xilinx, Altera FPGA CPLD anti-fuse …

BUT, the tricky using SVF is that all FPGA makers are missing to include the FREQUENCY (TCK) in the SVF.

The time base of Xilinx SVF is 1MHZ, but many of Xilinx devices can up their JTAG chain to 16MHz ! Than if you run the SVF as-it-is at 16MHz there are many change to genrate a wrong JTAG chain).

Your have to rework some contents of the SVF. :shock:

Also, some devices need to re-run x times the same DATA SCAN if it is not checked successfully … This is not a feature of SVF :shock:

Anyway, SVF will be better than to work directly on the binary content of the FPGA (.bit file). Using SVF you do not need to know so much about the architecture of the FPGA and their JTAG chain !

Laurent

http://www.amontec.com

4

Anyway, SVF will be better than to work directly on the binary content of the FPGA (.bit file). Using SVF you do not need to know so much about the architecture of the FPGA and their JTAG chain !

I could use the Xilinx tools to generate xsvf files so I think I wouldn’t need special support, however I think it would be nice if OpenOCD could read .bit files directly for convenience.

Extending the XSVF player to Spartan and Virtex devices is on my todo list, but it’s low priority and I haven’t had time yet.

Ah well I’m happy to do the coding :slight_smile:

What is needed to extend it?

It’s certainly feasible, but you’d have to look at the programming algorithms of the respective chips. What type of input does xc3sprog take? The .bit file?

Yes, xc3sprog reads .bit files.

As far as I know OpenOCD should build on FreeBSD. The 2006-06-25 version is rather old - you should grab the latest code from SVN to make sure you have all the latest fixes (these include portability patches).

My SVN clue is low too so I guess I checked it out incorrectly :slight_smile:

5

I checked out the latest rev (82) and have modified parport.c so that it can use /dev/ppi (the FreeBSD equivalent of Linux’s /dev/parport) I submitted it as patch 1301.

I still get the “IR mismatch” error though.

6

I put -D_DEBUG_JTAG_IO_ in CFLAGS, recompile, re-ran and got this

[inchoate 15:40] ~/projects/FPGA/openocd >./src/openocd -f foo -d

Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-01 12:00 CEST)

Debug: jtag.c:1180 jtag_init():

Debug: parport.c:321 parport_init(): opening /dev/ppi0…

Debug: parport.c:337 parport_init(): …open

Debug: parport.c:210 parport_reset(): trst: 0, srst: 0

Debug: jtag.c:240 jtag_call_event_callbacks(): jtag event: 1

Debug: bitbang.c:219 bitbang_execute_queue(): statemove end in 0

Debug: jtag.c:240 jtag_call_event_callbacks(): jtag event: 1

Debug: bitbang.c:233 bitbang_execute_queue(): scan end in 0

Debug: jtag.c:957 jtag_build_buffer(): fields[0].out_value: 03

Debug: jtag.c:988 jtag_read_buffer(): fields[0].in_value: 01

Error: jtag.c:1131 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch

7

Thanks for the patch, I’ve added it to the SVN repository in revision 83.

What config file settings did you use, and what device(s) did you test with? The jtag_device lines have to describe the actual JTAG scan chain found on your board, i.e. the size of the IR register and the value expected during an IR scan.

Regards,

Dominic

8

ahh silly me I haven’t done that!

Of course all the stuff is at work and I’m at home so I can’t test it :roll:

Here is what I’ll try when I get the chance…

interface parport

parport_port 0

parport_cable dlc5

jtag_speed 0

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 6 0x1 0xf 0x0141c093

jtag_device 6 0x1 0xf 0x05045093

I know the length and ID codes are correct, I’m not sure about the other 2 values though.

Thanks for the help.

9

No luck…

[inchoate 10:18] ~/projects/FPGA/xc3sprog >./detectchain
IDCODE: 0x05045093      Desc: XCF02S    IR length: 8
IDCODE: 0x0141c093      Desc: XC3S400   IR length: 6

[inchoate 10:18] ~/projects/FPGA/openocd >cat foo
interface parport
parport_port 0
parport_cable dlc5
jtag_speed 0

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 8 0x1 0xf 0x05045093
jtag_device 6 0x1 0xf 0x0141c093

[inchoate 10:18] ~/projects/FPGA/openocd >./src/openocd -f foo -d
Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-08-01 12:00 CEST)
Debug:   jtag.c:1180 jtag_init():
Debug:   parport.c:321 parport_init(): opening /dev/ppi0...
Debug:   parport.c:337 parport_init(): ...open
Debug:   parport.c:210 parport_reset(): trst: 0, srst: 0
Debug:   jtag.c:240 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1070 jtag_reset_callback():
Debug:   jtag.c:1070 jtag_reset_callback():
Debug:   bitbang.c:219 bitbang_execute_queue(): statemove end in 0
Debug:   jtag.c:240 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1070 jtag_reset_callback():
Debug:   jtag.c:1070 jtag_reset_callback():
Debug:   bitbang.c:233 bitbang_execute_queue(): scan end in 0
Debug:   jtag.c:957 jtag_build_buffer(): fields[0].out_value: ffff
Debug:   jtag.c:988 jtag_read_buffer(): fields[0].in_value: c075
Error:   jtag.c:1122 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch
10

Your IR mask values are wrong. That parameter describes which bits of the IR capture value should be checked against the value captured in the Capture-IR state and scanned out in Shift-IR.

The JTAG standard only guarantess b…01, i.e. the least significant bits b01, while the meaning of the other bits is up to the vendor. A safe setting that works with all IEEE 1149.1 compliant devices would be jtag_device 0x1 0x3 .

The BSDL file for the XC3S has the following information:

attribute INSTRUCTION_CAPTURE of XC3S400_BARE : entity is

– Bit 5 is 1 when DONE is released (part of startup sequence)

– Bit 4 is 1 if house-cleaning is complete

– Bit 3 is ISC_Enabled

– Bit 2 is ISC_Done

“XXXX01”;

So you can’t count on anything but the first two bits to be b01.

Regards,

Dominic

11

Ahh I see… As you may have guessed my JTAG knowledge is minimal :frowning:

Unfortunately it doesn’t appear to make a difference - there’s no difference in output if I change to the ‘safe’ setting.

12

Hmm, it should have made a difference.

Could you paste the debug output and the jtag_device config you’ve used?

Edit:

Ah, you also have to make sure the order of the devices match. The first one listed is the one closest to TDO.

Regards,

Dominic

13

Ahah! It lives!

Thanks for persisting :slight_smile: