+++ David Brownell [2009-10-20 19:58 -0700]: > On Tuesday 20 October 2009, David Brownell wrote: > > This layers parts of XSVF directly over SVF, to handle XSTATE better, > > instead of expecting jtag_add_pathmove() to conform (it doesn't).
Thanx for working on this. > I'm going to commit this even though I can't test it. I'll test this imminently. SVF/XSVF has been completely broken since r1614 when the set of permitted transitions was reduced to be 'more compliant'. The practical result of this was that any SVF/XSVF file generated by the Xilinx tools (for our target device at least - Xilinx coolrunner CPLD) was deemed invalid by openocd. I recently tried using the python (3.0!) converter which allegedly converts 'illegal' xilinx xsvf files into kosher xsvf files, but I still found that all I got was 'illegal transition' errors, just a few lines later than without that translation. My understanding of the sordid details is still fuzzy but I desperately want to move beyond r1614 and can't until SVF/XSVF can be made to work somewhow. That either needs a way of generating XSVF files that openocd is happy with, or a way of telling it to accept the ones it accepted up until r1613 (they work just fine, and come straight out of Xilinx's tools so I find myself skeptical of the 'this is not valid and shouldn't be allowed' claim). More soon. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
