今天来谈谈SpinalHDL中StreamCCByToggle组件设计不足的地方。
前言
在之前的文章里，曾经有过一篇就StreamCCByToggle的具体细节原理展开过介绍：
模块设计很巧妙，从原理分析的角度来讲挺完美的。但是，百密一疏，这个模块在设计时，对于两侧时钟域复位信号的处理，作者并未有妥善的考虑。
现象分析
先来看下面这个example和其测试代码：
我么来看下其对应的仿真波形：
可以看到，对于dataIn接口，其valid只拉高了一次，只传输了一个任务。我们在途中时刻1，时刻2处分别对clkA，clkB时钟域做复位，然而dataOut在时刻4、时刻5收到了两个任务，凭空多出来一个任务！！！
对于不同时钟域的复位信号而言，很难做到两侧时钟域复位信号同时拉起，同时释放。而这里问题的导致就是复位信号引起的。
关于StreamCCByToggle的原理，可参照前文所提到的文章，这里不再做过多赘述，小伙伴们也可以自行去阅读SpinalHDL的源代码。我们看下面的波形：
在刚开始dataIn发送了一个任务，导致pushArea\_target、popArea\_hit信号均变为高电平。随后clkA时钟复位先被拉起，此时pushArea\_target在途中时刻1处变为低电平，经时钟同步后popArea\_target在时刻2处也变为低电平。而此时popArea\_hit仍为高电平。这也就导致了问题出现的原因。在StreamCCByToggle的实现原理里，clkB处的stream接口valid拉高的处理条件为：
stream.valid := (target =/= hit)而此时由于复位的不同步导致了valid被多拉了一拍，从而dataOut出现了一个不该出现的任务。
归结起来，StreamCCByToggle的实现完全依赖于target、hit两个信号的电平状态，每到来一个任务，两个信号电平都会反转一次。而当两个信号都为高电平时，若此时两侧时钟域出现复位拉起不同步现象，便会产生导致该现象的发生。而这种问题在上板测试时一旦出现想要找到根因还是要颇费功夫的。
回归跨时钟域握手处理
发现问题而不解决无异于耍流氓，StreamCCByToggle的设计机制对于上面的场景无能为力，那么还是采用经典的处理形式进行封装还是比较靠谱。先给出代码：
熟悉跨时钟域处理握手机制的小伙伴对上面的代码并不陌生。当pushArea检测到有任务请求时会拉高taskPending，在popArea侧时钟域同步taskPending为req。检测到req上升沿时popArea发起任务，待任务接收后拉起ack。pushArea侧同步popArea侧ack。检测到ack上升沿后释放taskPending。而在popArea侧检测到req变为低电平后也拉低ack。pushArea侧检测到ack为低电平即可处理新的任务。
写在最后
关于跨时钟域处理在处理上相对来讲还是一个易错点，其处理也是新学者需要好好把握的。SpinalHDL中的源代码还是很值得一读的。一方面，SpinalHDL中的代码质量还是相当之高的，阅读他的源代码，对于自己平时代码设计能够带来一些新的思路。很多人都觉得SpinalHDL难学。一开始我使用SpinalHDL也是按照之前写Verilog的思路来写的，随着对Scala语法的了解渐多(虽然现在和专业玩儿Scala的人员相差十万八千里，但对于我目前的开发工作来讲已经足够使用了)，以及对SpinalHDL lib源代码的阅读理解，从其中逐渐掌握了很多之前写Verilog时不曾想过的电路抽象规则。哪怕有一天老板不让我用SpinalHDL了，而这些设计思想却是一直受用的。
若有一天，SpianlHDL成为设计潮流，那么个人很喜闻乐见的。而现在我想做的，就是说服老板推广(这个目标已达成)，和诸君一同“引领”这个潮流。当年Verilog一步步取代了原理图式的设计，那么这种更潮的设计模式，何不一同去推波助澜呢。
从事这个行业，学历想必都不低。不要说SpinalHDL难入门，Scala难学，这只是紧抱Verilog的借口罢了。
☆ END ☆
作者：玉骐
原文链接：https://mp.weixin.qq.com/s/bxReKTYs3uIgJ8K5XoyK6g
微信公众号：
推荐阅读
更多SpinalHDL技术干货请关注Spinal FPGA专栏。
