[Openocd-development] Getting XSVF XRUNTEST from SVF RUNTEST

[Dick H. <di...@so...>]

I don't know how xilinx got from RUNTEST to XRUNTEST.   XRUNTEST does 
not translate from RUNTEST, according to their respective specs.   There 
is a table in the XSVF spec that suggests this is so, but it is not so.

RUNTEST tries to hedge its bets about whether you want a certain number 
of clocks or a certain amount of delay time.  It can provide both 
arguments just in case.   So kudos to the SVF guys, no problem there.   
But when XRUNTEST gets this, there is only one "time value/clock count" 
argument, and there is no state information.   So XRUNTEST is ill 
conceived, ambiguous, troublesome, and causing good people bad problems, 
period.

XWAIT is nicer, since it lets you wait at one of the stable states, but 
it does not let you fire the clock while waiting.  There are a few 
states where the clock can be fired without incurring a state 
transition, but there is no solid way to generate an XSVF file than 
handles what the SVF designers intended.

For this reason, I would offer up a new XSVF command called XWAITSTATE, 
which does directly translate from SVF RUNTEST, basically identically.   
I have this coded in my SVF to XSVF translator, but it is commented out 
pending API support for it in jtag.c.   I also have this largely 
implemented in xsvf.c so that all you have to do is uncomment and call 
the new API function.


Until that time I feel that RUNTEST is best translated to XWAIT.   But 
this comes without clocks, just time delay, so it will not work for all 
chips.


I am tracking down one last bug.   I am getting to line 20417 of a 20429 
line SVF file without error, can you believe that?     This is less than 
10 lines to go out of 20,429.  Sheesh.   This is erase, program, verify 
on a decent sized FPGA from lattice.


I will put my stuff here, hopefully later today:


http://freehg.org/u/dickelbeck/open_ocd  &   xsvf_tools


We're forked now.


Dick