XSVF: use svf_add_statemove()

XSVF improvements:

 - Layer parts of XSVF directly over SVF, calling svf_add_statemove()
   instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
   requirements (which it doesn't).

   This should improve XSTATE handling a lot; it removes most users of
   jtag_add_statemove(), and the comments about how it should really do
   what svf_add_statemove() does.

 - Update XSTATE logic to be a closer match to the XSVF spec.  The main
   open issue here is (still) that this implementation doesn't know how
   to build and submit paths from single-state transitions ... but now
   it will report that error case.

 - Update the User's Guide to mention the two utility scripts for
   working with XSVF, and to mention the five extension opcodes.

Handling of state transition paths is, overall, still a mess.  I think
they should all be specified as paths not unlike SVF uses, and compiled
to the bitstrings later ... so that we can actually make sense of the
paths.  (And see the extra clocks, detours through RUN, etc.)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

1 files changed, 1 insertions, 23 deletions

diff --git a/src/jtag/jtag.h b/src/jtag/jtag.h
index 5085445f..7253c3ea 100644
--- a/src/jtag/jtag.h
+++ b/src/jtag/jtag.h
@@ -536,29 +536,7 @@ extern void jtag_add_pathmove(int num_states, const tap_state_t* path);
  * @return ERROR_OK on success, or an error code on failure.
  *
  * Moves from the current state to the goal \a state.
- *
- * This needs to be handled according to the xsvf spec, see the XSTATE
- * command description.  From the XSVF spec, pertaining to XSTATE:
- *
- * For special states known as stable states (Test-Logic-Reset,
- * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
- * predefined TAP state paths when the starting state is a stable state
- * and when the XSTATE specifies a new stable state.  See the STATE
- * command in the [Ref 5] for the TAP state paths between stable
- * states.
- *
- * For non-stable states, XSTATE should specify a state that is only one
- * TAP state transition distance from the current TAP state to avoid
- * undefined TAP state paths. A sequence of multiple XSTATE commands can
- * be issued to transition the TAP through a specific state path.
- *
- * @note Unless @c tms_bits holds a path that agrees with [Ref 5] in the
- * above spec, then this code is not fully conformant to the xsvf spec.
- * This puts a burden on tap_get_tms_path() function from the xsvf spec.
- * If in doubt, you should confirm that that burden is being met.
- *
- * Otherwise, @a goal_state must be immediately reachable in one clock
- * cycle, and does not need to be a stable state.
+ * Both states must be stable.
  */
 extern int jtag_add_statemove(tap_state_t goal_state);