![]() |
|
|
|
#1 |
|
Hi all,
I am new to hierarchical FSM design. Is there any paper or guideline for design hierarchical FSM? Any suggestions will be appreciated! Best regards, Davy Davy |
|
|
|
|
#2 |
|
Posts: n/a
|
"Davy" <> wrote in message
news: ups.com... > Hi all, > > I am new to hierarchical FSM design. > Is there any paper or guideline for design hierarchical FSM? > > Any suggestions will be appreciated! > Best regards, > Davy > Google. Ken Ken Taylor |
|
|
|
#3 |
|
Posts: n/a
|
Davy wrote:
> I am new to hierarchical FSM design. > Is there any paper or guideline for design hierarchical FSM? > Any suggestions will be appreciated! I would suggest that if your state machine needs a hierarchy, there is likely a simpler logic description possible, using multiple process variables, not all of them enumerated. -- Mike Treseler Mike Treseler |
|
|
|
#4 |
|
Posts: n/a
|
Mike Treseler wrote:
> Davy wrote: > > > I am new to hierarchical FSM design. > > Is there any paper or guideline for design hierarchical FSM? > > Any suggestions will be appreciated! > > I would suggest that if your state machine > needs a hierarchy, there is likely a simpler > logic description possible, using multiple > process variables, not all of them enumerated. > > -- Mike Treseler It depends on the nature of the state machine (SM). Sometimes it is helpful to take advantage of the inherent parallelism available in a FPGAs and ASICs by having multiple state machines operating at once while a "master" SM coordinates their activities. However, this typically implies only two levels of hierarchy (the master machine, and the servant machines) That said, there are few circumstances that call for true hierarchy in state machine design, and I would recommend also that you reexamine the problem. Often, a problem can be more easily solved with an external (to the SM) counter, pipeline register, or signal than by adding additional states. As a hint, try to limit the number of outputs each SM generates. This will force you to partition the problem better, and should result in a cleaner design. For example, rather than implement a full microprocessor for a test application, I wrote two state machines that were attached to an internal UART model. One state machine handled incoming data, while the other acted as a message generator. By partitioning in this way, each machine became much simpler, and performance improved greatly. Note, there are some graphical tools on the market (Mentor Graphics' HDL Designer, and Xilinx' StateCAD) that allow you to implement hierarchical state machines graphically - allowing them to be understood more easily. However, if you examine the output, you will find that the SM has almost invariably been flattened to just one (in either two or three processes depending on what you specified in the options) radarman |
|