：大型状态机的分解，哪有相关资料或例子
[求助]：大型状态机的分解，哪有相关资料或例子
个人认为分割开反而容易出问题。
[求助]：大型状态机的分解，哪有相关资料或例子
我觉得1)可以使用Mealy型机比Moore机状态少得多;2)建模时减少冗余的状态;3)可使用格雷码,直接在HDL里面写上状态编码指示,37状态应不算多,6个(位)寄存器寄存;4)根据我的过去经验,只要不出现latch,pcb考虑得好,是可以经受24小时连续工作考验的.(甚至在含有latch时往往部分功能还是很稳定的)
对了,我觉得最重要的就是直接让它工作,连续24或者48小时,其它都不是直接的证据.
[求助]：大型状态机的分解，哪有相关资料或例子
大有大得好,小有小得好.
是否将一个大状态机分成若干个小状态机,取决于,设计的速度.是否会不断有新的要求加进来,是否由多个人合作开发,是否便于维护,等等.
如果你的设计不太快,而且,要求不会老是变化,不打算添加新状态,那么,一旦可以工作,那么就不必要改了.
如果,可能会改动其中的一部分,当然要做适当的分割.或者,对不同的状态机路径,已经有了认识,处理某种数据,就那么几个状态,而其他类优势另外的一些状态.那么,应该将不同的功能适当地分开,以使得测试容易.通过的,就不要动了.没通过的就逐个Debug,比较容易.
[求助]：大型状态机的分解，哪有相关资料或例子
从验证的角度,还是分成多个比较好.尤其是作Coverage的时候,小的状态机比较好看出各种转移的实际意义,可以适当的加入Default,使其可以防止落入未知的状态.只要在RTL上通过了验证,到实际中是很可靠的.这时候验证的难度小,而且往往是一些板子走线的问题,或者,噪音之类的问题,但是,状态基本是很可靠的.
小的状态机,扩充比较容易.于是,甚至可以加入一些附加状态,以利于上板实测.大状态机,就不太好加,一看几十个状态,有牵一发而动全身的担忧,于是不加也罢.
[求助]：大型状态机的分解，哪有相关资料或例子
[这个贴子最后由jingli888ca在 2005/07/23 02:57pm 第 1 次编辑]
但是如何分割,如何通讯?是个很讲究的过程.
首先,需要设计者本人,对状态机所描述的对象有深入了解.
其次,对Timing / Waveform有清楚地定义.
再次,对一个设计要求,要能有几个实现的办法,互相比较,于是,对内部的控制过程很了解.
于是,就看出来,哪一些是比较孤立的,哪一些是联系比较紧密地.孤立的就可以分出来.
接着,考虑状态机之间的通讯.
最简单的当然是,主状态机启动子状态机,子状态机完成返回主状态机.
稍微难一些的是,主启动子,并同时给与一些数据和控制flag,这就要问自己,它们之间的时序是怎样的,同时还是迟一个时钟?迟几个时钟?
再难一些的是,主对子,在某个特定的状态给过去.这要算好,子是不是总能按时拿到?
更难一些的是,主对子,子对主,都是在各自某个特定的状态个对方,那就更要计算清楚,否这就要失同步了.
最麻烦的是,两个状态机之间cycle-by-cycle accurate,一个cycle都不能错.这就要预取和Buffering,更为复杂---如果到这种情况,不分也罢.
总之,一个好的状态机或状态机群,是要动一番脑子的.但是,不管多简单,多复杂,能工作的就是好状态机.