Nios II系统在Quartus II编译后Timing requirements for slow timing model timing analysis were not met. See Report window for details
前言：
在DE2-70，随便一个Nios II系统在Quartus II编译后，几乎都会遇到1个critical warning：“Critical Warning: Timing requirements for slow timing model timing analysis were not met. See Report window for details.”，该如何解决呢?
说明：
使用環境：Quartus II 8.1 + Nios II EDS 8.1 + DE2-70 (Cyclone II EP2C70F896C6N)
在研究Nios II系统的过程中，在从DE2平台转移到更强大的DE2-70平台时，有一个很恼人的问题，随便一个Nios II系统，编译几乎都会有1个critical warning：
Quartus II的warning尚可忽略，但critical warning就没办法再装做不看到了吧?虽然Nios II执行结果正确，但看到这个critical warning总是很碍眼。
经仔细研究发现，原来是经过Quartus II合成后，时序无法满足要求。
原本以为是自己的code有问题，可是将DE2-70 CD 4个包含Nios II系统的范例拿来编译，除了DE2_70_SD_Card_Audio_Player正常外，其他3个范例也都有critical warning。
DE2_70_NET
DE2_70_NIOS_DEVICE_LED
DE2_70_NIOS_HOST_MOUSE_VGA
DE2_70_SD_Card_Audio_Player (正常)
看到连DE2-70 CD的范例本身都有这个问题时，可以确定不是自己的code有问题。
“为什么这个时序无法满足的需求，在DE2都不会遇到呢?而且在Quartus II也增加了constraint，希望Quartus II能合成出Fmax为100MHz的系统，但是Quartus II怎么也合不出需要的100MHz？”
Pipeline Bridge与Altera提出的架构，可以解决这个恼人的问题。
Pipeline Bridge是什么东西?
Bridge的观念是Quartus II 7.1之后才提出的，就是为了解决Nios II系统Fmax低落的问题，由上图可知，一些较慢的slave都透过Pipeline Bridge与master沟通，而不像传统一样，每个master都与slave有专属的通道。
为什么这样就能增加Fmax呢?
主要有两个原因：
1.传统的master与slave因为有专属通道，所以有最大的concurrency，只要master不要同时存取同一个slave即可，但也增加了系统的复杂度，所以Fmax拉不高，若系统对于慢速的slave没有大量concurrency的要求，使用bridge可以降低系统的复杂度，并且提高Fmax。
2.Pipeline Bridge对于Avalon Bus的信号，如address、writedata、write、read、byteenable、chipselect、burstcount、readdata、readdatavalid与waitrequest都加上了pipeline register，所以可以拉高Fmax。
这只是最初步的解释而以，更详细的解释可以在Quartus II Handbook 8.1 vol.4的Chap.11 Avalon Memory-Mapped Bridges找到。
最后Fmax达到102.44MHz，critical warning也不见了。
原来没有使用pipeline bridge，尽管constraint已经调到100MHz，但Quartus II最后只能合成出68.35MHz
“哇!!竟然一行code都没改，Fmax就从68.35MHz变成102.44MHz，真是太神奇了”。
结论：
Bridge是个很有弹性的东西，巧妙的使用bridge架构整个系统，将有助于整体效率，在的ch.6，也提到Bridge使用的一些guideline，又兴趣的人可以参考。
