SimonQian wrote: > Hi, > When try to convert svf file to xsvf, i got this: > -------------------------------------------------- > H:\MyProject\Versaloon\test>python --version > Python 3.0 > H:\MyProject\Versaloon\test>python svf2xsvf.py temp.svf temp.xsvf > Error in file 'temp.svf' at line 29 near token 'TRST' > Unknown token 'TRST' > -------------------------------------------------- > svf file is in the attachment. it's generated by Quartus II Web Edition. > I remove the programming part. > 'TRST' is a valid command in svf, but there is no corresponding > command in xsvf.
Simon, True about TRST. But now we are in control of the XSVF format that we want to support, as a result of being able to generate the XSVF file. Our support can be a superset of Xilinx's, it already is. It is possible to add opcodes to the XSVF file as needed. We are fully in control of our own destiny here. Let me know your thoughts on this. As I read the SVF spec, the description of TRST with ABSENT is clear and unambiguous. After that, for other values of "trst_mode", some clarity is helpful. Do you read it to mean that if trst_mode is "ON", then we are to "set to zero/low" the TRST line at that point in the execution stream? And if the argument is "OFF", then we are to "set to one/high" the TRST line at that point in the execution stream? What about trst_mode equal to "Z". Does our cable API even support a high Z state for the TRST line? If not, what should we do then? Regarding your other posting about verbosity of the XSVF programming operation: We can add a "quiet" argument to the command for you. I personally do not want to have to turn on debug logging to get the output that is currently in there, because then the logging format changes and it is intermingled with other output. I personally do not mind that it scrolls off the screen. I prefer to see progress being made during what can be a long operation. I will prepare a patch or two for you once we agree on a direction. Thanks for your feedback, Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
