XVC(Xilinx Virtual Cable) 是Xilinx推出的基于TCP/IP协议的远程调试方法,可用于Xilinx FPGA的远程下载和调试,具体介绍可见Xilinx官方文档编号XAPP1251。
先讲目前的开发结果,在Vivado 2019.1环境下,目标FPGA为xc7v690t,加载的bit文件大小为28M左右,实际JTAG bit数(TCK个数)为229859840,结果见下表,除去异常的某一点,显而易见的XVC性能已远远高于官方下载器Platform Cable USB II。
环境 | 加载方式 | TCK频率(HZ) | 消耗时间(s) | 等效TCK频率(Hz) | 效率(%) |
ubuntu 19.10 | XVC | 6M | 44 - 47 | 5.11M | 85.2 |
ubuntu 19.10 | XVC | 10M | 24 | 9.58M | 95.8 |
ubuntu 19.10 | XVC | 12M | 20 | 11.42M | 95.2 |
ubuntu 19.10 | XVC | 12.5M | 19 | 12.10M | 96.8 |
window 7 | XVC | 6M | 102 - 124 | 2.03M | 33.8 |
window 7 | XVC | 10M | 24 | 9.58M | 95.8 |
windows 7 | XVC | 12M | 20 | 11.42M | 95.2 |
windows 7 | XVC | 12.5M | 20 | 11.42M | 91.4 |
ubuntu 19.10 | Platform Cable USB II | 6M | 80s | 2.87M | 47.8 |
ubuntu 19.10 | Platform Cable USB II | 12M | 47s | 4.89M | 40.8 |
windows 7 | Platform Cable USB II | 6M | 81s | 2.84M | 47.3 |
windows 7 | Platform Cable USB II | 12M | 47s | 4.89M | 40.8 |
一切的开始也同样始于XAPP1251,这份应用笔记提供了一种基于ZYNQ的XVC服务器实现方法,注意该文档P18中提到
The reference design was measured to have a performance of approximately 3.2 Mb/s while programming the AC701. This measurement was made with a TCK frequency of 6.25 MHz and the ARM processor running at 667 MHz
官方参考设计的TCK比特效率为51%左右,而我又是如何优化设计使得比特效率提高至90%以上,接下来慢慢道来。
首先分析该文档P18处(Performance Considerations),以下内容均为分析该部分:
- Reduce TCK ratio(减小TCK分频)
减小TCK分频可以提高TCK频率,这是最直接的提速方法。但要注意到的是,参考设计使用的IP核AXI-Lite to JTAG(P5, figure 4),其TCK频率为。TCK分频相关代码位于jtag_proc.v,分析源码可知,C_TCK_CLOCK_RATIO作为IP配置参数,必须为2的倍数,且大于等于4。而XVC协议中`settck`命令要求TCK频率可由软件配置,在这一点上参考设计有所缺失。
always @(posedge CLK)
begin
if (RESET == 1'b1)
begin
tck_count <= 0;
...
end
else
begin
if (enable_red == 1'b1)
begin
tck_count <= 0;
...
end
else if (tck_en == 1'b1)
begin
if (tck_count == (C_TCK_CLOCK_RATIO / 2) - 1)
begin
tck_count <= 0;
end
else
begin
tck_count <= tck_count + 1;
end
...
end
end
end
assign tck_pulse = (tck_count == (C_TCK_CLOCK_RATIO / 2) - 1) ? 1'b1 : 1'b0;
always @(posedge CLK)
begin
if (RESET == 1'b1)
begin
tck_i <= 1'b0;
...
end
else
begin
...
if (enable_red == 1'b1)
begin
tck_i <= 1'b0;
...
end
else if (tck_en == 1'b1)
begin
if (tck_pulse == 1'b1)
begin
tck_i <= ~tck_i;
...
end
end
else
begin
...
end
end
end
assign TCK = tck_i;
- Ensure a 1 Gigabit Ethernet connection(千兆网)
对于ZYNQ这一点基本都是可以做到的
- Create a larger software buffer size
这里的软件缓冲区,指的是`getinfo`中<maximum vector length>,而这又指代的是缓冲区深度,并不是JTAG的传输长度。经过实测,`shift`命令中<length>段,恒小于<maximum vector length>*8,该参数对XVC传输影响非常大。
- Increase vector length -- AXI4-Lite to JTAG controller
- Add interrupts -- AXI4-Lite to JTAG Controller.
这两点合起来分析。首先vector length指的是该IP核,一次JTAG传输可移位的最大TCK个数。参考设计中该值为32,即一次传输至多有32个TCK时钟。增加中断,即JTAG传输完成中断(PL-to-PS),可免去CPU轮询控制寄存器CTRL中传输完成状态位,减少总线占用。但两点改进并不好,原因如下:
1 启动JTAG传输之前需要CPU通过GP总线将TMS/TDI数据从内存搬运至寄存器中去,JTAG传输完成后需要将TDO数据从寄存器中搬运回内存。除去JTAG传输的时间,CPU两次写AXI-Lite总线和读一次AXI-Lite总线所消耗时间不可忽略,这是因为ZYNQ的GP(Master)总线为AXI3总线,连接至AXI-Lite总线时必须增加一个AXI协议转换。因此对于ZYNQ来说,读写挂载于GP总线上的外设延时都相当大,实测该时间为数百ns至数us。
2 增大vector length相应的AXI传输次数会增加,并没有减少时间消耗。这是由AXI-Lite总线特性所决定的,AXI-Lite总线传输burst length 恒为1,即一次只能输出一个总线数据宽度的数据量。
根据以上分析,应该意识到参考设计所提供的AXI-Lite转JTAG IP核对XVC传输效率有很大的影响,下一步将是……
(不定时更新,随时会鸽,别问源码)