On Wed, 2009-10-21 at 22:43 +0100, Wookey wrote: > +++ David Brownell [2009-10-21 10:05 -0700]: > > On Wednesday 21 October 2009, Wookey wrote: > > > 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. > > > > What tools do you refer to? I didn't think the two Python 3.0 > > scripts in the "tools" directory did either of those things... > > Those tools. My understanding is, as I said, somewhat vague, and in > this case filtered through a colleague here who read the openocd > list and did some poking and concluded that Dick Hollenbeck's original > patch to make openocd XSVF stricter went with his python SVF->XSVF converter > which filled in the missing transitions in the original. If we are > mistaken about that then it's no wonder it doesn't help... > > > The conversion I know about was SVF to XSVF. If you can use > > that, and aren't using the extensions from Lattice, I'd kind > > of expect you might be able to use SVF directly... > > Programming from SVF fails in much the same way as XSVF (but > complaining about a different specific line/command.
It sounds probable that there may be more than one bug, so could we produce some simple SVF/XSVF test cases to help identify them? With this approach, we could: a) tackle the remaining problems in more discrete chunks, and b) prevent regressions like yours from happening again. I need to climb the SVF/XSVF learning curve, so I am not sure about how to contribute to this myself.... Any ideas for how to go about it? Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
