+++ David Brownell [2009-10-27 11:30 -0700]: > On Tuesday 27 October 2009, Wookey wrote: > > > Does that SVF version work OK? > > > > No, but then I wouldn't expect it to in this case. The xsvf command > > allows the specification of a tap which means that an XSVF file > > nominally created for a single JTAG port still works with chained > > ports (magically - I wasn't expecting openocd to be that clever). The > > svf command doesn't have that option so the svf probably shouldn't > > work. I need to re-arrange hardware in order to do the direct > > side-by-side single-port test and/or generate files for chained-port > > use. > > Too bad; but understandable. That was another reason to > create XSVF, as I understand: not just smaller programming > files, but ones that didn't always need to be rewritten for > each different scan chain.
Apparently. I see that SVF specifies a head and tail for the bypassed devices, whilst XSVF gives the whole bitfield every time. I don't yet understand why that is functionally different, as it seems to amount to the same thing. But I am only on page 14 out of 25 :-) > > > The deal is that until someone (maybe me) writes code > > > to more or less morph sequences of XSTATE opcodes into > > > a pathmove() command, the SVF code can do pathmoves > > > while XSVF can't. > > > > OK. Could you elaborate a bit on why it used to work, but now the > > above is needed. > > As I understand now -- I wasn't paying attention to this > stuff back when this changed! -- the core issue is that > the JTAG primitives we used back then got changed. > > There are now basically two primitives for passing through > the JTAG stage machine: (a) statemove, which moves from > one "stable" state to another using a standardized path, > and (b) pathmove, which does so using a caller-specified > series of transitions. > > Previously, I think the "between stable states" constraint > wasn't consistently enforced. Ergo rude errors, and the > change. The issue with XSVF is that it expects either a > flavor of (a) or else a third way to move, (c) from one > state to an adjacent one. That's sort of what statemove > used to do, sometimes. > > Thing is, that XSVF adjacent-states motion is used as an > encoding shorthand for (b)... and I checked the xsvfdump > output of your XSVF file, so you're not being a rude > exception to such a rule. In fact it looks like your file > is mostly using it for (a) too ... if there's a config > option not to expand the state transitions like that, > you might not need this bug fixed yet. Hmm, I can look in the webpack but this the 'standard' output so that's what I'd expect most people to be using. Interesting this is the exact opposite of what I thought the problem was (the xilinx XSVF is too detailed about the state transitions - I thought it was too vague (from openocd's point of view) :-) > So if I whack together a patch turning XSVF's (c) into > the (b) which is supported, you could test it and maybe > fix any goofs? Yes, I think so (fighting chance at least). 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
