最近在写点小论文，又捡起了Verilog来用用。
但是发现了很蛋疼的事情……出来的结果总是不对~~~~~
由于这是一种新的算法，所以我不太确定到底是我系统架构上有什么缺陷，还是说本身代码有什么问题，疑惑是都有问题……
一开始老是想搞点频谱分析、求个冲击响应什么的。这样搞了两天……突然开窍了，如果代码本身有什么问题的话，做这些有什么价值呢~真是搞虚的东西搞多了以后想问题的方法就开始飘了。
于是想了一个办法，输入端输入一个常数，那么输出也应该是常数。而且中间节点的信号状态也应该是定值，可以预知的。这样反过去查哪些状态和预设的不一致，就可以把问题定位出来。
一开始定位出了几个书写错误，比如忘记取反、复制了以后忘记改位宽之类的错误。但是后来发现还是不对，于是下来好好分析一下。
把中间节点打开分析下——好在中间节点不多——就发现问题了。在我咋个设计中涉及到了加法器的位宽扩展，也就是两个1bit的数相加，保留2bit的结果。为了图方便，我是直接用的+号把两个1bit的数加起来，然后就赋值给了左边2bit的wire型变量。但我发现位宽扩展时并不是像我想象的那样高位补0，而是当成了有符号数来扩展。这样原来我期望的1+0=01，就变成了11+00=11。
于是为了保险起见，我就把所有的都用拼接符号{}先高位补0了再运算，在经过了辛勤的劳动之后，终于大功告成……
阿弥陀佛……
最近Xilinx和Altera都在卖力的销售C2H的概念，无论是Vivado的All Progamming 还是Altera倡导的OpenCL，又在描述从C直接综合到硬件逻辑的美好前景。
其实如果不考虑效率的话，C2H是没有什么问题的。以我今天这个为例。在C语言中，能够支持任意位宽的操作么？不能。C语言的数据类型就那么几种。换言之只能把1bit的数当8bit的甚至16bit的数来算。C2H可以做到C语言到硬件模块的映射，但是要如此灵活的调整数据通路的宽度，恐怕是很难做到的。
因此，C2H到底还是给那些非专业人士用的，降低他们使用FPGA的门槛。对于原来只会在PC上编程的程序员，只要FPGA跑起来比PC快，就是好的。