老莫

蛋疼的位宽扩展……兼论C2H

0
阅读(23021)

 最近在写点小论文,又捡起了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快,就是好的。