| 是否将一个大状态机分成若干个小状态机,取决于,设计的速度.是否会不断有新的要求加进来,是否由多个人合作开发,是否便于维护,等等.
如果你的设计不太快,而且,要求不会老是变化,不打算添加新状态,那么,一旦可以工作,那么就不必要改了.
如果,可能会改动其中的一部分,当然要做适当的分割.或者,对不同的状态机路径,已经有了认识:处理某种数据,就那么几个状态,而其他类又是另外的一些状态.那么,应该将不同的功能适当地分开,以使得测试容易通过.一旦通过了,就不要动了.没通过的,就逐个Debug,比较容易.
从验证的角度,还是分成多个比较好.尤其是作Coverage的时候,小的状态机比较好看出各种转移的实际意义,可以适当的加入Default,使其可以防止落入未知的状态.只要在RTL上通过了验证,到实际中是很可*的.这时候验证的难度小,而且问题往往是一些板子走线的问题,或者是噪音之类的问题.状态机基本上是很可*的.
小的状态机,扩充比较容易.于是,可以加入一些附加状态,以利于上板实测.大的状态机,就不太好加,一看几十个状态,有牵一发而动全身的担忧,于是不加也罢.
但是如何分割,如何通讯?是个很讲究的过程.
首先,需要设计者本人,对状态机所描述的对象有深入了解.
其次,对Timing / Waveform有清楚地定义.
再次,对一个设计要求,要能有几个实现的办法,互相比较.结果是对内部的控制过程非常了解.
于是,就可以看出来,哪一些输出是比较孤立的,哪一些输出是联系比较紧密地.孤立的就可以分出来.
接着,考虑状态机之间的通讯.
最简单的情形当然是,主状态机启动子状态机,子状态机完成返回主状态机.
稍微难一些的是,主启动子,并同时给与一些数据和控制flag,这就要问自己,它们之间的时序是怎样的,同时还是迟一个时钟?迟几个时钟?
再难一些的是,主对子,在某个特定的状态给过去.这要算好,子是不是总能按时拿到?
更难一些的是,主对子,子对主,都是在各自某个特定的状态个对方,那就更要计算清楚,否则,就要失同步了.
最麻烦的是,两个状态机之间cycle-by-cycle accurate,一个cycle都不能错.这就要预取和Buffering,更为复杂---如果到了这种情况,不分也罢.
总之,一个好的状态机或状态机群,是要动一番脑子的.但是,不管多简单,多复杂,能工作的就是好状态机. | 
