对于“题目二：基于ARM的CRC算法和基于FPGA的算法性能比较”评分标准提出的疑问

sdoyxb

题目二比赛结果出来了，但我对评委的评分标准以及结果有些质疑，请安富利公司的评委们作出解释：

1. 赛前语言会议中我明确提问了数据包从PS传输到PL端的时间是否计入PL计算时间，当时评委当场给出答案是：不计入。VVZVV没有弄清题目要求。

2. VVZVV的128组数据是在PL端自己生成的，严重违反了题目二中第二条规则。

3. 大家都知道数字电路实现CRC校验一个时钟周期完成一组，VVZVV的128组数据用了1920240ns，评委们也觉得正常吗？

      我只是就事论事，不对针对任何个人，请VVZVV选手谅解。另外，我建议评分标准应该按照题目要求所列出的点为准，而不是个人臆断，否则题目中给出的标准是做什么用的？

      作为一个参赛选手，我期望得到公平、公开的评分结果。

liubenyuan

回复 1# sdoyxb


   我看了下你们两个的，

• vv的128组数据每组是多大的包没有说清楚，但是显然如果fpga跑100MHz（10ns）的时钟的话，计算周期是很长了。估计每组是在PL内部生成一个较大的数组做的。
• sdoyxb的报告写的是很详细，我看了一遍感觉收获也挺大的，楼主忘记传代码了，我没有看到代码。单纯从报告和评估上来说，sdoyxb是略好的。因为从zynq的本质上来说，单独编写PS的程式和FPGA代码，都有现成的，难度会降低很多。只有当PS/PL协同评估时才是有价值的。在我之前的FPGA程序中，数据传输一直都是选型设计的瓶颈（到了zynq反而变成乘法器了。。。。），怎样在zynq上解决这个问题，计算加速比是最有意义的。
• 其实我觉得这样讨论也挺好的，楼主和当事人都不要介意。同时，版主和举办者看到后的解释和反应，反而对促进zynq很有用的。我在竞赛后买了一个microzed breakout carrier IO和两个视频采集的CMOS（双目视觉），准备把我的视频采集和opencv在zed上用，以后也会多来这里分享：）

jackzhang

我觉得sdoyxb的确实做的很认真仔细，当然vv做的也很好，本次评选，我们EETOP只是提供一个平台，作为第三方不会提出任何干预，具体结果有安富利给出，应该也有他们的考虑，两个人的设计都在伯仲之间，可惜每组一等奖名额只有一个。
希望大家理解，

sdoyxb

我知道举办这次比赛站长付出了许多时间和精力，所有的参赛选手、举办方、网友都会铭记在心。EETOP论坛在比赛过程中确实起到了公平、公开作用，您对结果不提出任何干预是正确的。
      因为一场比赛的结果必须、也只能由安富利公司评委人员来决定。您说他们是有考虑的，这我也相信，专家评委们一定是动脑考虑过了才会得出比赛结果的，但好像缺少了点认真、职业的态度。
      现在，我想说的是这是一场面向社会性质的比赛，举办方和参赛选手都必须要付起足够的责任，最好能为将来举办的每一场类似性质的比赛做出模范性的作用。而如今的比赛结果无法让参赛选手信服，原因在于这个比赛的结果缺少一个公开、明确的评分标准以及评分过程和结果，这是涉及到一个比赛公平性的原则性问题。
      这种时刻我只是期望站长您能站出来，跟安富利公司的评委说清楚，他们的评分规则缺乏一定的科学性和说服力，而不是让您对比赛的结果进行干预。我相信安富利公司的评委知道这件事以后一定会公开对我、对大家有个满意的解释，我相信专家评委们是能够做到这一点的，毕竟安富利公司在业内也是有一定实力和信誉的。
      还是那句话，作为一名参赛选手，我只是想要一个公平、公开的结果。

sdoyxb

以下是本次挑战赛中题目二的Vivado工程和SDK的workspace，代码都在里面，以供评委审查，感兴趣的朋友们也可以看一下。另外，挑战结果在视频中已经演示的很详细了，跟代码描述的完全一致，期待评委给出一个公正的结果。
microzed_v0.zip (6.79 MB, 下载次数: 18 )

2014-10-16 09:43 上传

点击文件名下载附件
Vivado

workspace.zip (7.19 MB, 下载次数: 20 )

2014-10-16 09:44 上传

点击文件名下载附件
SDK

jackzhang

以下是安富利的评委给出的解释，望理解： （感觉到评委还是很认真的）

1. 赛前语言会议中我明确提问了数据包从PS传输到PL端的时间是否计入PL计算时间，当时评委当场给出答案是：不计入。VVZVV没有弄清题目要求。

      
当时回答不计入，因为计入则需要DMA，
DMA的性能又与数据包的大小相关，如果限制数据包的长度，则设定具体的数据包规范，这个题目相当复杂了，竞赛的目的是希望参赛者在有限的时间内走完流程，体会到Zynq开发的乐趣。在评分中，不管计入还是不计入都没有考虑这个因素。

2. VVZVV的128组数据是在PL端自己生成的，严重违反了题目二中第二条规则。
      
我也认为VVZVV的做法与规则有一点点冲突，画蛇添足，但是，他在添足之前毕竟画了一条蛇。而且他还有一个解释，“实际情况中不会有人把接收到的数据从上层软件再传回底层硬件计算CRC校验吧？一般都是硬件完成CRC校验之后把数据传给上层软件”，假设一个场景，Zynq的Ethernet接口在PL，一种处理方式是在PL上完成CRC，另一种方式把数据传输给PS，在PS上完成CRC，那么在PL上完成CRC也算是加速。所以，如果因为这一点而扣VVZVV的分，VVZVV可能也有看法。

       VVZVV还有一个非常好的地方，硬件加速未必能加速，因为真实的设计一定考虑数据传输时间，尽管这儿没有做要求。VVZVV的9359250ns，尽管这个数据不佳，它体现了真实的设计过程。

3.大家都知道数字电路实现CRC校验一个时钟周期完成一组，VVZVV的128组数据用了1920240ns，评委们也觉得正常吗？

      
这两个人的数据格式不同，测试过程不一样，计时标准不一样，如果以加速比例来判断谁的性能更胜一筹，谁的算法更加精妙，不是看看论坛上的帖子就能做到的，毕竟不是大学里面的设计竞赛。

        
结论：两个人都完成了,做的都还很不错,但是一等奖只有一个.比较而言, VVZVV做得数据更详细,过程更清楚。