我有一些VHDL文件，我可以在Debian上用 ghdl 编译 . 一些人已经为ASIC实现调整了相同的文件 . 有些人想要编写更多的实现，但为了评估它们，我需要能够比较不同实现需要多少区域 .
ghdl
我想在不安装任何专有编译器或获得任何硬件的情况下进行评估 . 足够的评估标准是对GE（门等效）面积的估计，或某些FPGA实现所需的逻辑片数 .
首先计算触发器（FF） . 它们的编号（几乎）由您编写的RTL代码唯一定义 . 根据一些经验，您可以通过检查代码获得此数字 .
通常，＃FFF与总体区域之间存在良好的相关性 . 一个古老的经验法则是，对于许多设计，组合区域将与连续区域大致相同 . 例如，假设触发器的面积计数是门阵列技术中的10个门，那么 #FFs * 20 将给出初始估计 .
#FFs * 20
当然，设计特征具有重大影响 . 对于面向数据路径的设计，组合区域将相对较大 . 对于面向控制的设计，情况正好相反 . 对于标准单元设计，顺序区域可能更小，因为FF更有效 . 对于时序关键设计，由于综合工具的时序优化，组合区域可能要大得多 .
因此，剩下的问题是找出适合您的设计类型和目标技术的良好倍增因素 . 策略可以是进行一些实验，或者查看先前的设计结果，或者询问其他人 . 从那时起，估算是将代码中已知的#FFs与该因子相乘的问题 .
我想在不安装任何专有编译器或获得任何硬件的情况下进行评估 .
检查会给你一个粗略的想法，但是在综合过程中发生的所有优化都可能会发现这个精度水平与最终结果相差甚远 .
我建议你重新检查一下你避免"proprietary compilers"进行评估的原因 . 我不知道VHDL的任何非专有综合工具（虽然它有been discussed） . 流行的FPGA供应商为Windows和Linux提供免费版本的软件，您可以使用它们来获取准确的资源使用情况 . 将FPGA资源使用转换为对您的目标技术更有意义的东西应该是可行的 .
我对ASIC世界不太熟悉，但可能还有免费（但专有）的工具可供您使用 .
2 回答
首先计算触发器（FF） . 它们的编号（几乎）由您编写的RTL代码唯一定义 . 根据一些经验，您可以通过检查代码获得此数字 .
通常，＃FFF与总体区域之间存在良好的相关性 . 一个古老的经验法则是，对于许多设计，组合区域将与连续区域大致相同 . 例如，假设触发器的面积计数是门阵列技术中的10个门，那么
#FFs * 20将给出初始估计 .当然，设计特征具有重大影响 . 对于面向数据路径的设计，组合区域将相对较大 . 对于面向控制的设计，情况正好相反 . 对于标准单元设计，顺序区域可能更小，因为FF更有效 . 对于时序关键设计，由于综合工具的时序优化，组合区域可能要大得多 .
因此，剩下的问题是找出适合您的设计类型和目标技术的良好倍增因素 . 策略可以是进行一些实验，或者查看先前的设计结果，或者询问其他人 . 从那时起，估算是将代码中已知的#FFs与该因子相乘的问题 .
检查会给你一个粗略的想法，但是在综合过程中发生的所有优化都可能会发现这个精度水平与最终结果相差甚远 .
我建议你重新检查一下你避免"proprietary compilers"进行评估的原因 . 我不知道VHDL的任何非专有综合工具（虽然它有been discussed） . 流行的FPGA供应商为Windows和Linux提供免费版本的软件，您可以使用它们来获取准确的资源使用情况 . 将FPGA资源使用转换为对您的目标技术更有意义的东西应该是可行的 .
我对ASIC世界不太熟悉，但可能还有免费（但专有）的工具可供您使用 .