芯片哥：
只有6个引脚的单片机？
没错，一个单片机只有6个引脚，而且还包括2个电源引脚VDD和VSS。真正能用的功能，也仅仅只有4个普通的IO引脚PA4 ~PA7。
虽然只要4个IO引脚，但它也是一个8位的单片机，只是类型比较特殊，是OTP类型，程序只能烧录一次。内部有2个8位的定时器，每个IO引脚能输出10mA的电流。
只有6个引脚的单片机？
没错，一个单片机只有6个引脚，而且还包括2个电源引脚VDD和VSS。真正能用的功能，也仅仅只有4个普通的IO引脚PA4 ~PA7。
虽然只要4个IO引脚，但它也是一个8位的单片机，只是类型比较特殊，是OTP类型，程序只能烧录一次。内部有2个8位的定时器，每个IO引脚能输出10mA的电流。
领导看了同事写的关闭超时订单，让他出门左转！
关闭超时订单是在创建订单之后的一段时间内未完成支付而关闭订单的操作，该功能一般要求每笔订单的超时时间是一致的。
如果我们使用定时任务来进行该操作，很难把握定时任务轮询的时间间隔
时间间隔足够小，在误差允许的范围内可以达到我们说的时间一致性问题，但是频繁扫描数据库，执行定时任务，会造成网络IO和磁盘IO的消耗，对实时交易造成一定的冲击
时间间隔比较大，由于每个订单创建的时间不一致，所以上边的一致性要求很难达到
假设30分钟订单超时自动关闭，定时任务的执行间隔时间为30分钟：
第5分钟进行下单操作
当时间来到第30分钟时，定时任务执行一次，但是我们的订单未满足条件，不执行
当时间来到第35分钟时，订单达到关闭条件，但是定时任务未执行，所以不执行
当时间来到第60分钟时，开始执行我们的订单关闭操作，而此时，误差达到25分钟
经此种种，我们需要舍弃该方式。
延时队列
为了满足领导的需求，我便将手伸向了消息队列：RabbitMQ。尽管它本身并没有提供延时队列的功能，但是我们可以利用它的存活时间和死信交换机的特性来间接实现。
存活时间
存活时间的全拼是Time To Live，简称 TTL。它既支持对消息本身进行设置（延迟队列的关键），又支持对队列进行设置（该队列中所有消息存在相同的过期时间）
对消息本身进行设置：即使消息过期，也不会马上从队列中抹去，因为每条消息是否过期是在即将投递到消费者之前判定的
对队列进行设置：一旦消息过期，就会从队列中抹去
如果同时使用这两种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那么该消息就“死了”，我们把它称为 死信 消息。
消息变为死信的条件
消息被拒绝（basic.reject/basic.nack），并且requeue=false
消息的过期时间到期了
队列达到最大长度
队列设置注意事项
队列中该属性的设置要在第一次声明队列的时候设置才有效，如果队列一开始已存在且没有这个属性，则要删掉队列再重新声明才可以；
队列的 ttl 只能被设置为某个固定的值，一旦设置后则不能更改，否则会抛出异常；
死信交换机
死信交换机全拼Dead-Letter-Exchange，简称DLX。
当消息在一个队列中变成死信之后，如果这个消息所在的队列设置了x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换机上，这个交换机就称之为死信交换机，与这个死信交换器绑定的队列就是死信队列。
x-dead-letter-exchange：出现死信之后将死信重新发送到指定交换机
x-dead-letter-routing-key：出现死信之后将死信重新按照指定的routing-key发送，如果不设置默认使用消息本身的routing-key
死信队列与普通队列的区别就是它的RoutingKey和Exchange需要作为参数，绑定到正常的队列上。
生产者发送带有 ttl 的消息放入交换机路由到延时队列中
在延时队列中绑定死信交换机与死信转发的routing-key
等延时队列中的消息达到延时时间之后变成死信转发到死信交换机并路由到死信队列中
最后供消费者消费
通过调用接口，发现10秒之后才会消费消息
问题升级
由于开发环境和测试环境使用的是同一个交换机和队列，所以发送的延时时间都是30分钟。但为了在测试环境让测试同学方便测试，故手动将测试环境的时间改为了1分钟。
接着问题就来了：延时时间为1分钟的消息并没有立即被消费，而是等30分钟的消息被消费完之后才被消费了
原因就是延时队列也满足队列先进先出的特征，当10秒的消息未出队列时，后边的消息不能顺利出队，造成后边的消息阻塞了，未能达到精准延时。
我们可以利用x-delay-message插件来解决
生产者发送消息到交换机时，并不会立即进入，而是先将消息持久化到 Mnesia（一个分布式数据库管理系统）
插件将会尝试确认消息是否过期
若消息过期，消息会通过 x-delayed-type 类型标记的交换机投递至目标队列，供消费者消费
局限性
延迟的消息存储在一个Mnesia表中，当前节点上只有一个磁盘副本，它们将在节点重启后存活。
虽然触发计划交付的计时器不会持久化，但它将在节点启动时的插件激活期间重新初始化。显然，集群中只有一个预定消息的副本意味着丢失该节点或禁用其上的插件将丢失驻留在该节点上的消息。
该插件的当前设计并不适合延迟消息数量较多的场景（如数万条或数百万条），另外该插件的一个可变性来源是依赖于 Erlang 计时器，在系统中使用了一定数量的长时间计时器之后，它们开始争用调度程序资源，并且时间漂移不断累积。
关闭超时订单是在创建订单之后的一段时间内未完成支付而关闭订单的操作，该功能一般要求每笔订单的超时时间是一致的。
如果我们使用定时任务来进行该操作，很难把握定时任务轮询的时间间隔
时间间隔足够小，在误差允许的范围内可以达到我们说的时间一致性问题，但是频繁扫描数据库，执行定时任务，会造成网络IO和磁盘IO的消耗，对实时交易造成一定的冲击
时间间隔比较大，由于每个订单创建的时间不一致，所以上边的一致性要求很难达到
假设30分钟订单超时自动关闭，定时任务的执行间隔时间为30分钟：
第5分钟进行下单操作
当时间来到第30分钟时，定时任务执行一次，但是我们的订单未满足条件，不执行
当时间来到第35分钟时，订单达到关闭条件，但是定时任务未执行，所以不执行
当时间来到第60分钟时，开始执行我们的订单关闭操作，而此时，误差达到25分钟
经此种种，我们需要舍弃该方式。
延时队列
为了满足领导的需求，我便将手伸向了消息队列：RabbitMQ。尽管它本身并没有提供延时队列的功能，但是我们可以利用它的存活时间和死信交换机的特性来间接实现。
存活时间
存活时间的全拼是Time To Live，简称 TTL。它既支持对消息本身进行设置（延迟队列的关键），又支持对队列进行设置（该队列中所有消息存在相同的过期时间）
对消息本身进行设置：即使消息过期，也不会马上从队列中抹去，因为每条消息是否过期是在即将投递到消费者之前判定的
对队列进行设置：一旦消息过期，就会从队列中抹去
如果同时使用这两种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那么该消息就“死了”，我们把它称为 死信 消息。
消息变为死信的条件
消息被拒绝（basic.reject/basic.nack），并且requeue=false
消息的过期时间到期了
队列达到最大长度
队列设置注意事项
队列中该属性的设置要在第一次声明队列的时候设置才有效，如果队列一开始已存在且没有这个属性，则要删掉队列再重新声明才可以；
队列的 ttl 只能被设置为某个固定的值，一旦设置后则不能更改，否则会抛出异常；
死信交换机
死信交换机全拼Dead-Letter-Exchange，简称DLX。
当消息在一个队列中变成死信之后，如果这个消息所在的队列设置了x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换机上，这个交换机就称之为死信交换机，与这个死信交换器绑定的队列就是死信队列。
x-dead-letter-exchange：出现死信之后将死信重新发送到指定交换机
x-dead-letter-routing-key：出现死信之后将死信重新按照指定的routing-key发送，如果不设置默认使用消息本身的routing-key
死信队列与普通队列的区别就是它的RoutingKey和Exchange需要作为参数，绑定到正常的队列上。
生产者发送带有 ttl 的消息放入交换机路由到延时队列中
在延时队列中绑定死信交换机与死信转发的routing-key
等延时队列中的消息达到延时时间之后变成死信转发到死信交换机并路由到死信队列中
最后供消费者消费
通过调用接口，发现10秒之后才会消费消息
问题升级
由于开发环境和测试环境使用的是同一个交换机和队列，所以发送的延时时间都是30分钟。但为了在测试环境让测试同学方便测试，故手动将测试环境的时间改为了1分钟。
接着问题就来了：延时时间为1分钟的消息并没有立即被消费，而是等30分钟的消息被消费完之后才被消费了
原因就是延时队列也满足队列先进先出的特征，当10秒的消息未出队列时，后边的消息不能顺利出队，造成后边的消息阻塞了，未能达到精准延时。
我们可以利用x-delay-message插件来解决
生产者发送消息到交换机时，并不会立即进入，而是先将消息持久化到 Mnesia（一个分布式数据库管理系统）
插件将会尝试确认消息是否过期
若消息过期，消息会通过 x-delayed-type 类型标记的交换机投递至目标队列，供消费者消费
局限性
延迟的消息存储在一个Mnesia表中，当前节点上只有一个磁盘副本，它们将在节点重启后存活。
虽然触发计划交付的计时器不会持久化，但它将在节点启动时的插件激活期间重新初始化。显然，集群中只有一个预定消息的副本意味着丢失该节点或禁用其上的插件将丢失驻留在该节点上的消息。
该插件的当前设计并不适合延迟消息数量较多的场景（如数万条或数百万条），另外该插件的一个可变性来源是依赖于 Erlang 计时器，在系统中使用了一定数量的长时间计时器之后，它们开始争用调度程序资源，并且时间漂移不断累积。
#香山调试直播# 香山芯片调试目标完成！
记录一些流水账：
2021年6月22日，香山在RISC-V中国峰会上第一次亮相，这是当时公开的国际上性能最高的开源RISC-V处理器核设计，受到国内外的很多关注，如今在GitHub上已有近2500个Star，250多个Fork。虽然我们的报告是中文的，但却有不少英文报道，甚至还有来自俄罗斯的关注。可以说，香山成为国际上最受关注的开源芯片项目之一。
2021年7月15日，第一代香山“雁栖湖”流片。但接下来由于受到全球芯片产能影响，我们不得不经历漫长的等待期。因为许久没有回片后的消息，有一些关注香山的朋友发来小心翼翼的询问：“香山是不是流片失败了？”流片失败，就是指香山无法点亮，也就意味着它就是一块石头。
2022年1月20日，等待了整整半年，香山终于回片了。硬件调试存在很大不确定性，很可能1个bug就会需要耗上1-2个月才能解决。而硬件问题解决不了，软件调试就会受到影响。尽早发现硬件问题，此时的香山就如同刚从医院拿回来的一份尚未打开的检查报告——面对它心中充满忐忑，不知道结果是好是坏。如果要等春节假期结束后才能看报告，这个年我们会过得心里很不踏实。另外，还存在一个不确定性，就是疫情防控。前段时间北京出现疫情，导致不少同学无法回家。但另一方面，由于冬奥会、两会等一系列活动，如果其他地方出现疫情，也可能导致离京后一段时间内甚至整个2月不能返京，那就会再空耗一个月。
我们希望能尽早消除一些不确定性，否则过年心里也不踏实。时间，对于香山调试非常宝贵。于是，香山团队的多位小伙伴（徐易难、李作骏、王诲喆、勾凌睿、张紫飞、蔺嘉炜、李乾若、甄好）决定留在北京攻关调试，加上唐丹和我，组成了一支攻关调试小分队。其中有几位是因为老家疫情而留在了北京，也有本来就是北京人，除了这些这些线下的小伙伴，还有全国各地的老师和同学一起在线参与。
1月26日开始，采用香山枫叶红底色的主板陆续从深圳寄到北京。此前，1月22-24日，深圳团队的蔡晔老师、刘彤、何伟等已经在深圳焊好主板，完成了初步的调试，包括系统时钟、串口、Flash等，验证IO通路正确。
1月29日，调试攻坚战正式打响了。调试过程一开始出乎意料地顺利，虽然有些小曲折，但都很快解决。到1月30日，我们取得了不错的战果：
•CPU频率从24MHz切到1GHz；
•DDR4-2400初始化成功，并稳定运行；
•Linux正常启动进入Shell；
•CoreMark成功运行，5.3分，与仿真完全一致。
1月30日晚上，收到了中国科学院大学公共管理学院刘继安老师的消息，是她和博士后徐艳茹希望观摩香山调试。晚上9点，徐博士先来到了调试现场，拍了几张照片，然后便跟我们说，她春节也不能回去过年，希望能全程观摩香山的调试过程。我们觉得应该很快就可以结束调试了，便欣然答应。但任何事情都不要高兴太早！
1月31日，大年夜。就在我们认为可以“牛年事、牛年毕”，可以在牛年就能跑出SPEC CPU2006分值、初步完成调目标时，现实狠狠地打了我们的脸——在运行SPEC CPU2006时，DDR4-2400稳定性存在问题，会导致返回数据出现随机错误。DDR是芯片调试过程最麻烦的问题，看来我们终究还是要面对。
我们分头吃年夜饭。下午2点，唐丹老师回家和家人一起吃了顿年夜饭；下午4：30，唐老师又过来和我们一起吃了一顿年夜饭，然后回到调试作战室放松：春晚，PS5，瓜子……晚上7点，我再回家和家人又吃了一顿年夜饭。一个难忘的大年夜！
大年初一到初三，大家休息了三天。
初四，重新整装上阵。内存专家李作骏全力攻占DDR稳定性问题，其他人全力配合。全志D1-H项目负责人孙彦邦提到当时在全志时DDR调试也是难点，他推荐了在Linux下的memtester来测试内存。
初五，徐易难很快便在Linux下编译好memtester，并开始测试。初步测试访存确实不稳定，内存在作Bit Flipping时会出现8KB数据不正确。于是开始尝试修改CPU频率，1GHz提高到1.1GHz，1.26GHz，但都不稳定；那就给CPU降频，降到800MHz、600MHz，似乎访存稳定性好一些，但还是会随机出错。
唐丹老师查看DDR PHY手册，发现PHY和DIMM的VRef配置不同步，修改后稳定性得到改善，但memtester还是会出现随机访存出错，只是出现概率降低了。但是，哪怕概率再低，也不可接受——对于理论上1GHz频率下每秒可运行60亿条指令的香山来说，哪怕是亿分之一的随机出错概率，也意味着每秒会出现几十次访存数据错误，这是不可接受的。我们必须要把访存调稳定。
初六，大家继续尝试——修改DDR Trainimg参数，修改Linux启动时内存容量，改变DDR供电电压……始终无法消除DDR访存的随机出错问题。我们怀疑DDR信号完整性问题，希望看一下DDR信号的眼图。开始一通打电话借设备，我们借到了一台DDR逻辑分析仪。这这台设备和HMTT很像，也是插在DIMM槽，但它内部提供高频采样时钟，可以直接抓DDR访存数据信号。我们花了半天的时间研究如何使用，当搞清楚后，发现在DDR-2400配置下采不到预想的信号。晚上9点多，打电话给设备代理商，被告知这台设备采购时没有选支持2400的模块，现在还支持DDR-1600。燃起的希望又熄灭了。
初七，唐丹老师又开始打一轮电话，又向郝沁汾老师借来一台示波器。有人建议看一下电源是否稳定，波动幅度是否太大，可以换一下精密电源。唐老师、徐易难立刻开始测试电源稳定性，发现真的会出现上下60-80mV的波动。那时，看到这个几十毫伏的波动，似乎大家心里涌出一丝欣喜，希望这就是DDR访存不稳定的问题所在。唐丹马不停蹄地区采购精密电源，不幸的是在换电源后，我们使用最多、相对最稳定的一块板卡“牺牲”了——烧了！来不及难过，立刻又切换到另一块板卡开始测试起来。结果有点沮丧，换了精密电源后依然无法消除访存随机性问题。
李作骏通过对DDR信号进行仿真，发现DDR DQS信号的ODT参数设置存在问题，同时把所有的访存性能相关的参数调到最保守设置。大家又寄希望于这次DDR参数修改。
此时，于是另一条调试网卡的战线开始启动，由王诲喆担任主攻手：测试网卡时钟信号、调整GMAC频率，设置设备树，修改驱动——网卡很快就被识别出来了，能看到网卡能收包了，但是问题是不能发包。
初八，跑了一个晚上的memtester，连续运行了12个小时，只有一个访存出错。这次稳定性得到了极大的提高，但还没有彻底解决，运行SPEC CPU依然出错。这时，大家决定尝试一下将DDR降频到1600。DDR-1600配置下，李作骏又对DDR Training做了优化，调高了Refresh Burst数量，激动人心的时刻发生了——之前跑不过的SPEC CPU应用都能跑完了！DDR访存稳定性问题终于解决了！
从初八开始，勾凌睿便开始用SPEC CPU2006程序烤机，香山频率设置为1GHz，DDR设置为1600，连续几十个小时的运行，再也没有出现过错误了。当然，这并不是最终目标，我们知道DDR访存性能对整个香山芯片的性能至关重要，接下来我们还继续优化DDR性能。
另一条战线，王诲喆仍然在调试网卡。在香山上用tcpdump能看到从另一台机器发过来的网络包，对比发送端的wireshark，内容正确。但是发送始终存在问题，ping依然不通。
初九，跑了一天的SPEC CPU，再也没有出错了，大家开始期待香山的SPEC CPU 2006分值了。网卡调试那边，手动修改了mac地址后，香山能收到ping，但是发送依然有问题。
初十，在修复了一个串口驱动小问题后，终于得到SPEC CPU 2006分值了，香山在1GHz频率、DDR-1600配置下，分值为5.97。这个数字对于香山来说，是一个里程碑。但我们知道，这并不是香山的真实性能，因为这是把DDR-2400降频为DDR-1600后得到的结果，从数据来看，很多访存密集型应用性能受到了很大的影响。如果把DDR进一步优化，香山性能还将进一步提升。我们根据Roofline模型推演访存性能优化目标。
正月十二，王诲喆也终于将网卡调通，香山功能基本完备。有了网络，大家就可以远程访问香山了。
正月十五，李作骏对DDR-1600时序进行了初步优化，之前受DDR访存的应用性能得到了大幅提升，比如bzip2-liberty的运行时间从483s降到了265s。这也意味着SPEC CPU2006分值即使在DDR降频的情况下还可以有很大的提升。
至此，历时近3个星期的香山攻关调试取得了圆满成功。香山调试直播完毕。
衷心感谢所有关注和支持香山的朋友！后续我们仍然会向大家介绍香山后续的性能优化进展。
—————
图1：调试攻关任务清单完成！
图2：与DDR访存稳定性战斗
图3：稳定运行SPEC CPU2006程序
图4：网卡正常工作
图5：SPECCPU 2006分值与对应配置
图6：Roofline模型推演访存性能优化目标
图7-9：香山调试现场
记录一些流水账：
2021年6月22日，香山在RISC-V中国峰会上第一次亮相，这是当时公开的国际上性能最高的开源RISC-V处理器核设计，受到国内外的很多关注，如今在GitHub上已有近2500个Star，250多个Fork。虽然我们的报告是中文的，但却有不少英文报道，甚至还有来自俄罗斯的关注。可以说，香山成为国际上最受关注的开源芯片项目之一。
2021年7月15日，第一代香山“雁栖湖”流片。但接下来由于受到全球芯片产能影响，我们不得不经历漫长的等待期。因为许久没有回片后的消息，有一些关注香山的朋友发来小心翼翼的询问：“香山是不是流片失败了？”流片失败，就是指香山无法点亮，也就意味着它就是一块石头。
2022年1月20日，等待了整整半年，香山终于回片了。硬件调试存在很大不确定性，很可能1个bug就会需要耗上1-2个月才能解决。而硬件问题解决不了，软件调试就会受到影响。尽早发现硬件问题，此时的香山就如同刚从医院拿回来的一份尚未打开的检查报告——面对它心中充满忐忑，不知道结果是好是坏。如果要等春节假期结束后才能看报告，这个年我们会过得心里很不踏实。另外，还存在一个不确定性，就是疫情防控。前段时间北京出现疫情，导致不少同学无法回家。但另一方面，由于冬奥会、两会等一系列活动，如果其他地方出现疫情，也可能导致离京后一段时间内甚至整个2月不能返京，那就会再空耗一个月。
我们希望能尽早消除一些不确定性，否则过年心里也不踏实。时间，对于香山调试非常宝贵。于是，香山团队的多位小伙伴（徐易难、李作骏、王诲喆、勾凌睿、张紫飞、蔺嘉炜、李乾若、甄好）决定留在北京攻关调试，加上唐丹和我，组成了一支攻关调试小分队。其中有几位是因为老家疫情而留在了北京，也有本来就是北京人，除了这些这些线下的小伙伴，还有全国各地的老师和同学一起在线参与。
1月26日开始，采用香山枫叶红底色的主板陆续从深圳寄到北京。此前，1月22-24日，深圳团队的蔡晔老师、刘彤、何伟等已经在深圳焊好主板，完成了初步的调试，包括系统时钟、串口、Flash等，验证IO通路正确。
1月29日，调试攻坚战正式打响了。调试过程一开始出乎意料地顺利，虽然有些小曲折，但都很快解决。到1月30日，我们取得了不错的战果：
•CPU频率从24MHz切到1GHz；
•DDR4-2400初始化成功，并稳定运行；
•Linux正常启动进入Shell；
•CoreMark成功运行，5.3分，与仿真完全一致。
1月30日晚上，收到了中国科学院大学公共管理学院刘继安老师的消息，是她和博士后徐艳茹希望观摩香山调试。晚上9点，徐博士先来到了调试现场，拍了几张照片，然后便跟我们说，她春节也不能回去过年，希望能全程观摩香山的调试过程。我们觉得应该很快就可以结束调试了，便欣然答应。但任何事情都不要高兴太早！
1月31日，大年夜。就在我们认为可以“牛年事、牛年毕”，可以在牛年就能跑出SPEC CPU2006分值、初步完成调目标时，现实狠狠地打了我们的脸——在运行SPEC CPU2006时，DDR4-2400稳定性存在问题，会导致返回数据出现随机错误。DDR是芯片调试过程最麻烦的问题，看来我们终究还是要面对。
我们分头吃年夜饭。下午2点，唐丹老师回家和家人一起吃了顿年夜饭；下午4：30，唐老师又过来和我们一起吃了一顿年夜饭，然后回到调试作战室放松：春晚，PS5，瓜子……晚上7点，我再回家和家人又吃了一顿年夜饭。一个难忘的大年夜！
大年初一到初三，大家休息了三天。
初四，重新整装上阵。内存专家李作骏全力攻占DDR稳定性问题，其他人全力配合。全志D1-H项目负责人孙彦邦提到当时在全志时DDR调试也是难点，他推荐了在Linux下的memtester来测试内存。
初五，徐易难很快便在Linux下编译好memtester，并开始测试。初步测试访存确实不稳定，内存在作Bit Flipping时会出现8KB数据不正确。于是开始尝试修改CPU频率，1GHz提高到1.1GHz，1.26GHz，但都不稳定；那就给CPU降频，降到800MHz、600MHz，似乎访存稳定性好一些，但还是会随机出错。
唐丹老师查看DDR PHY手册，发现PHY和DIMM的VRef配置不同步，修改后稳定性得到改善，但memtester还是会出现随机访存出错，只是出现概率降低了。但是，哪怕概率再低，也不可接受——对于理论上1GHz频率下每秒可运行60亿条指令的香山来说，哪怕是亿分之一的随机出错概率，也意味着每秒会出现几十次访存数据错误，这是不可接受的。我们必须要把访存调稳定。
初六，大家继续尝试——修改DDR Trainimg参数，修改Linux启动时内存容量，改变DDR供电电压……始终无法消除DDR访存的随机出错问题。我们怀疑DDR信号完整性问题，希望看一下DDR信号的眼图。开始一通打电话借设备，我们借到了一台DDR逻辑分析仪。这这台设备和HMTT很像，也是插在DIMM槽，但它内部提供高频采样时钟，可以直接抓DDR访存数据信号。我们花了半天的时间研究如何使用，当搞清楚后，发现在DDR-2400配置下采不到预想的信号。晚上9点多，打电话给设备代理商，被告知这台设备采购时没有选支持2400的模块，现在还支持DDR-1600。燃起的希望又熄灭了。
初七，唐丹老师又开始打一轮电话，又向郝沁汾老师借来一台示波器。有人建议看一下电源是否稳定，波动幅度是否太大，可以换一下精密电源。唐老师、徐易难立刻开始测试电源稳定性，发现真的会出现上下60-80mV的波动。那时，看到这个几十毫伏的波动，似乎大家心里涌出一丝欣喜，希望这就是DDR访存不稳定的问题所在。唐丹马不停蹄地区采购精密电源，不幸的是在换电源后，我们使用最多、相对最稳定的一块板卡“牺牲”了——烧了！来不及难过，立刻又切换到另一块板卡开始测试起来。结果有点沮丧，换了精密电源后依然无法消除访存随机性问题。
李作骏通过对DDR信号进行仿真，发现DDR DQS信号的ODT参数设置存在问题，同时把所有的访存性能相关的参数调到最保守设置。大家又寄希望于这次DDR参数修改。
此时，于是另一条调试网卡的战线开始启动，由王诲喆担任主攻手：测试网卡时钟信号、调整GMAC频率，设置设备树，修改驱动——网卡很快就被识别出来了，能看到网卡能收包了，但是问题是不能发包。
初八，跑了一个晚上的memtester，连续运行了12个小时，只有一个访存出错。这次稳定性得到了极大的提高，但还没有彻底解决，运行SPEC CPU依然出错。这时，大家决定尝试一下将DDR降频到1600。DDR-1600配置下，李作骏又对DDR Training做了优化，调高了Refresh Burst数量，激动人心的时刻发生了——之前跑不过的SPEC CPU应用都能跑完了！DDR访存稳定性问题终于解决了！
从初八开始，勾凌睿便开始用SPEC CPU2006程序烤机，香山频率设置为1GHz，DDR设置为1600，连续几十个小时的运行，再也没有出现过错误了。当然，这并不是最终目标，我们知道DDR访存性能对整个香山芯片的性能至关重要，接下来我们还继续优化DDR性能。
另一条战线，王诲喆仍然在调试网卡。在香山上用tcpdump能看到从另一台机器发过来的网络包，对比发送端的wireshark，内容正确。但是发送始终存在问题，ping依然不通。
初九，跑了一天的SPEC CPU，再也没有出错了，大家开始期待香山的SPEC CPU 2006分值了。网卡调试那边，手动修改了mac地址后，香山能收到ping，但是发送依然有问题。
初十，在修复了一个串口驱动小问题后，终于得到SPEC CPU 2006分值了，香山在1GHz频率、DDR-1600配置下，分值为5.97。这个数字对于香山来说，是一个里程碑。但我们知道，这并不是香山的真实性能，因为这是把DDR-2400降频为DDR-1600后得到的结果，从数据来看，很多访存密集型应用性能受到了很大的影响。如果把DDR进一步优化，香山性能还将进一步提升。我们根据Roofline模型推演访存性能优化目标。
正月十二，王诲喆也终于将网卡调通，香山功能基本完备。有了网络，大家就可以远程访问香山了。
正月十五，李作骏对DDR-1600时序进行了初步优化，之前受DDR访存的应用性能得到了大幅提升，比如bzip2-liberty的运行时间从483s降到了265s。这也意味着SPEC CPU2006分值即使在DDR降频的情况下还可以有很大的提升。
至此，历时近3个星期的香山攻关调试取得了圆满成功。香山调试直播完毕。
衷心感谢所有关注和支持香山的朋友！后续我们仍然会向大家介绍香山后续的性能优化进展。
—————
图1：调试攻关任务清单完成！
图2：与DDR访存稳定性战斗
图3：稳定运行SPEC CPU2006程序
图4：网卡正常工作
图5：SPECCPU 2006分值与对应配置
图6：Roofline模型推演访存性能优化目标
图7-9：香山调试现场
✋热门推荐