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 _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
