我不想一个人，孤独的感觉很可怕。

老不更新，大家都不高兴了。

准备以后用这个space贴工作记录，在网上留个备份，也让大家高兴高兴。

 

2006.10.13
    今天在仿真过程中被几个问题困扰。
    第一个是在c的解码程序中读入的编码输出和我硬件仿真中的用到的好像不是一个码，我将二者的iter_ram_wdb,cnu初始输入，第一次迭代输出全都打出来了，全都不一样，这如何来对比？
    第二个是关于负零的问题，初始输入中很小的输入（软输入对数值为3.9375，经过tanh值为零）被量化为正零和负零，在cnu计算中，负零对和没有影响，但对符号位是肯定有影响的，因为输出符号是所有输入符号的乘积，负零值虽然很小，但一定要考虑其符号位，而在vnu中，所有运算是用补码来计算的，输出符号是就是总和的符号，因此负零对最终符号的影响应该可以忽略，因为不经量化其值很小。我的问题是在cnu—vnu—cnu的迭代过程中，负零这样的处理累计误差是否应该考虑，应如何考虑。
    今天还想了想LDPC+HARQ软件仿真的问题，确实还存在很多困惑的地方，一是如何跟据码率选取生成矩阵和校验矩阵，我拟定为（3，6）形式的ldpc规则码，码率为1/2，大多数论文中都是这样选取的；二是跟据信噪比选取信道模型或噪声模型的问题，这方面就一点经验都没有了；三是选择何种调制方式，拟定为BPSK，这种方式最简单，四是编码和解码的算法的选取，是否仍采用张同论文中的算法，有没有简便一些的，因为根据刘老师的意思，这一仿真的主要目的是检验一下在LDPC码中运用HARQ这种后向纠错方式的性能，具体参数自定，我认为应该尽量在参数和算法选取上简便一些，这样便于突出主要矛盾。由于硬件解码的工作正在收尾，论文我还没有仔细看过，很多问题估计研究过论文后能得到解决，还有一些要找赵岭商量，等有时间了好好做一个工作计划

 

2006.10.14
    通过对比，现在总结一下软件仿真与硬件仿真在数据量化上的转换问题。
    在软件中，初始的对数比率，小数位4比特量化（先乘以16，取整后再除以16，即0.0625），整数位3比特量化（7），最大到7.9375，在cnu，和vnu中，整数位2比特，小数位4比特，最大到3.9375。在硬件仿真中，统一将数据右移4比特，即乘以16，这样前两者就分别变为整数7比特（127）和6比特（63），因此，在硬件查表中，输入值是实际值乘以16后的值，所得到的值也是实际值乘以16后的结果，因此在与软件仿真对比时，应将软件结果先乘以16，再对比，这样两者就一致了。
    关于负零问题，通过今天仿真得到结论，和最初设想的一致，即在cnu计算中保持负零的符号位，而在vnu中，负零就处理为零，理由如前面分析所述，在迭代计算的过程中是没有误差的。
    今天把硬件仿真做完了，开始检验了前两次的迭代输出，和软件结果一致，然后把程序整个跑了一遍，验证同样是29次迭代后校验和全为零，与软件一致，但最后输出却有错，通过对比，发现错误全都在127的整数倍处，有50几个。跟赵岭说明情况后，他分析可能是输出模块上有问题，于是我检查了data_out_cnl模块，发现问题果然出在这里，纠正后，程序最后输出结果与软件输出完全一致，令人振奋！
    现在资源（LE）总占用率是39%，最初为43%，通过修改cnu和vnu，以及删去了127位的hard_dec_checkout，资源占用节约了4%，以后应避免使用大位数的数据运算，这样很耗资源。目前ldpc7k08_dec_top仍然占用资源很多（4067个le），赵岭的只用了2600多个，内容还要比我的多，因此应该还有减少资源占用率的空间，程序还需进一步完善，目标是35%。

 

 

 

 

 

 

有句话问：“这四年，是我上了大学，还是大学上了我？”
回想这狼狈的经过，自己始终被套牢着不得脱身，
不得不承认，是大学上了我，
还不爽~~
但再一想，自己~~
                               能做的都做了，
                               该有的都有了，
                               想碰上的不想碰上的也都碰上了，
                               就算是大学上了我，
                               也不算白上了。   

回北京了

二十天没上过一回网，也没觉得有什么

 

这二十天宛如一场梦

幸福，快乐，彷徨

 

我该怎么办？