沁恒CH32V307这个单片机相信很多人都见过了，14块钱就能拥有内置PHY的USB HS，性价比拉满。前一段时间沁恒开源了一个基于它的高速USB转JTAG下载器项目，并适配了openocd。根据官方文档，该项目使用了硬件SPI优化JTAG信号输出，JTAG时钟可以达到36MHz，也就是约3.3M/s的下载速度，在这个价位下基本是无敌的存在，于是前几天就尝试了一下，过程简略记录如下。
首先在Github上下载项目openwch/usb-jtag-spi，将项目里的固件写入到CH32V307-EVK中（CH32V307/V305芯片均可），安装对应的驱动（项目中自带的驱动打不上的话可以去官网下载新版），此时设备管理器中将出现一个USB To Jtag/SPI的设备，代表驱动安装成功。
下一步根据项目中文档的引脚说明，将单片机的指定引脚连接到FPGA的JTAG引脚上。我手上目前只有xc7k325，因此没有测试其他FPGA或者单片机。随后进入到项目中自带的openocd目录下，在openocd.exe所在的路径下使用终端执行下列命令。
PS C:\Users\12484\Desktop\usb-jtag-spi\bin\WIN APP\openocd\bin>
.\openocd.exe -f .\usb20jtag.cfg -f ..\scripts\cpld\xilinx-xc7.cfg -c "init; xc7_program xc7.tap; pld load 0 led.bit" -c exit
Open On-Chip Debugger 0.11.0+dev-00631-g6c9dd1c6b-dirty (2022-04-28-20:19)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
xc7_program
Info : This adapter doesn't support configurable speed
Info : JTAG tap: xc7.tap tap/device found: 0x43651093 (mfg: 0x049 (Xilinx), part: 0x3651, ver: 0x4)
Warn : gdb services need one or more targets defined
loaded file led.bit to pld device 0 in 0s 104245us
Info : Close the USB20JTAG.实测结果是完全可以达到36MHz的速度，使用一个更大的比特流文件测试也得到了同样的结果。对比之下，我手上使用ft232h芯片的digilent-hs3只能跑到约24MHz的速度，实力不可谓不强悍。不过hardware manager并不会认这个下载器，因此无法在vivado中使用，目前只能用来下载比特流。希望手上有单片机的朋友也能测试一下调试和下载单片机的情况。
当然，这个项目目前还有一些缺点，比如名字（USB20JTAG）就取得很不好，一点辨识度都没有。此外，由于是使用SPI优化的原因，JTAG频率貌似是写死的36MHz无法调整，如果从机反应慢或者接线情况不好可能就会出现问题，希望沁恒能够尽快改善并推送到openocd上游，加快普及基于USB2.0 HS的下载调试器。
离线
理论上可以用XVC Server连接到各种调试器。这周末我试下，看看这种情况下的性能咋样😋
离线
其实没啥用处，调试器很多时候都得降频使用。FS的速度也足够应对绝大多数场景。
离线
其实没啥用处，调试器很多时候都得降频使用。FS的速度也足够应对绝大多数场景。
咋可能没用，大FPGA的比特流动辄几十M，下载器当然是高速才好用。单片机方面H7这类高性能单片机固件达到几M也是很正常的事情
离线
@LYF0630
你也说了是大FPGA才几十M，大多数都是中小容量FPGA。并且使用USBFS的调试器比如USB-Blaster把带宽用满速度并不慢，瓶颈并不在USBFS。
至于MCU，实际成熟项目中更新固件大多数都是通过bootloader进行的。根本不需要调试器。
离线
其实没啥用处，调试器很多时候都得降频使用。FS的速度也足够应对绝大多数场景。
问题的关键是全速USB是否会成为FPGA下载的瓶颈。对于高云这种限制了JTAG烧录速度的FPGA来说确实用处不大（因为JTAG时钟频率上限低于12Mbps的一半），但是如果FPGA支持更高的时钟频率的话，还是有帮助的。
有个人给过我一个数据，说是CH32V307下载7K325T能到3MB/s以上的速度，这个速度显然就超过全速USB的上限了。不过这个数据我还没验证过，不知道实际上能否达到（对应的JTAG时钟频率得超过24MHz了）。
离线
单片机做调试器的第一步，看SPI，CH32V307这个芯片的SPI最小传输bits是8或16，这就说明它最多只能让JTAG跑的比较快（还要配合IO模拟），跑SWD的速率必然比较拉跨。【此处假定用SPI加速，若有其他牛逼外设，当我没说】
以我接触过的HME芯片为例，FPGA编程的JTAG读写命令能支持到连续256字节，这种长命令随便用什么SPI都能跑出很好的速度。
最关键的还是常用IDE环境，IDE决定了数据格式，调试器只能按照IDE下发的命令去执行，进而产生了巨大的损耗。商业化的j-link自带上位机驱动，在这方面就产生了非常大的优势。
离线
Sipeed github上有一个软件模拟FT2232D的项目，可惜受限于mcu，只能支持到FS，有兴趣的大佬可以考虑移植到WCH的芯片上
https://github.com/sipeed/RV-Debugger-BL702
另外，WCH自己也出了一个CH347转接芯片，只是比较难买
https://www.wch.cn/products/CH347.html?
离线
@metro
以我优化USB-Blaster的经历，USBFS的12M理论速度对这些调试器都足够了。瓶颈不在USBFS。最典型的例子就是CY7C68013版本的USB-Blaster，空有480M的USBHS，速度完全不行。
常见的MCU闪存容量都在1MB以内，FPGA配置芯片很多也都是几个MB而已，实际bitstream使用的更少。
离线
@echo
所以我理解还是和需求有关系。CH32V307官方演示的是用OpenOCD烧XC6SLX9，下载速度确实是超过全速USB的上限了，但由于bitstream太小（300KB+），实际上只用了0.1s左右的时间，这个确实体现不出高速USB的优势（0.1s到1s的感知不强，毕竟其它操作本来就需要一些时间）。估计得到XC7K325T（bitstream在10MB+）及以上级别的FPGA才会有比较明显的感觉。
离线
@echo
另外，即使都是高速USB，相互之间也是有比较明显的性能差距的，这个可能和具体的实现有关，我这里不是很了解，这里有一些相关数据：https://blog.csdn.net/rui22/article/details/107814146 。DLC9和Digilent的方案的对比应该是比较多的。
（当然，最典型的反面例子就是只用CY7C68013A不用CPLD的方案，这种方案的IO速度受到CPU的限制，实际上确实不如新的USB全速方案，但是用GPIF或者Slave FIFO的方案理论上来说要好一些。）
说到底，我觉得最大的问题是高速USB对于纯下载用途而言确实应用面比较窄（原因如你所说，大容量芯片本身就是偏专业向的用途，和开源社区目前关注的方向不是很合拍），而可以发挥其优势的用途（如大容量FPGA下载，片上逻辑分析仪等）又容易受到上位机的制约（通常只支持特定型号的下载器，对开源方案不友好），估计需要多做一些工作才能达到期望的效果。
最近编辑记录 metro (2022-07-17 02:12:59)
离线
@metro
这些10MB+的bitstream本来就是极少的场景。调试器上完全派不上用场。SignalTapII这类片上逻辑分析仪用USBFS也足够了，我用CH552做的USB-Blaster也可以胜任。这些调试器一边是USB，另外一边是JTAG或者SWD，也是单端串行时钟，并且要使用杜邦线或者排线连接，TCK时钟频率不可能太高，十几M最多几十M撑死了。频率越高兼容性可靠性越差，用户越容易骂娘。使用480M的USBHS完全就是大炮轰蚊子，没有任何必要。
另外TCK和SWCLK这边如果软件IO模拟时序，那速度完全不行，要喂饱USBFS必须硬件SPI+DMA来优化，这个还是有一定难度的，做得好的并不多。
高速USB的最佳应用是各种USB逻辑分析仪，这些设备对USBHS的带宽使用比较充分。
最近编辑记录 echo (2022-07-17 10:18:48)
离线
CH32V305FBP6通过WCH-LINK无法刷入固件，换CH32V307RCT6后直接USB可以更新固件，目前我自己尝试只能刷BIT，还不知道如何刷BIN。
刷BIT文件，FPGA板掉电重启后固件就会丢失。
我的命令如下：
“openocd.exe -f ./usb20jtag.cfg -f ../scripts/cpld/xilinx-xc7.cfg -c "init;xc7_program xc7.tap; pld load 0x0 ./test.bit" -c exit”
离线
@KooLee
有大佬跟我说过，这个固件实际上是为307编译的，305由于硬件与307不完全相同，需要自行编译305的版本。
另一个大佬说目前沁恒提供的OpenOCD还不支持bin的烧录，这个没验证过，不知道是否属实。
离线
@KooLee
有大佬跟我说过，这个固件实际上是为307编译的，305由于硬件与307不完全相同，需要自行编译305的版本。
另一个大佬说目前沁恒提供的OpenOCD还不支持bin的烧录，这个没验证过，不知道是否属实。
已经联系上沁恒负责CH347T的刘工，他负责帮忙验证。
我目前是使用FT2232H配合https://github.com/quartiq/bscan_spi_bitstreams实现openocd刷Bin到FPGA的FLASH芯片。
离线