Hi Rick,\n\nOn 03/10/2013 05:24, rickman wrote:\n[QUOTE]\nThat *is* the problem. The second procedure sees the next state rather\nthan the current state.[/QUOTE]\n\nThat's the reason why the order of procedures matter. I let the higher\nFSM (the one that supposedly 'controls' everything) be the last to start\nand then respectively the second in rank and so on...\n[QUOTE]\nI thought they were all registers? If not, they aren't state variables.[/QUOTE]\n\nThey *are* registered. What I meant is that if you write this:\n\n<code>\na := a + 1;\n</code>\n\nthen 'a' is used before it is assigned, leading to a register. This is\nwhat happens in my fsm procedure, whether the procedure has a single\ncase-switch which rolls over the state value, using it before assigning it.\n\n[QUOTE]\nAnd therein lies the problem. When using a single variable like this,\nif some state variable have been updated but not others, the FSM gets\nvery complex.[/QUOTE]\n\nI don't get this. My state variable at each state depends on several\nconditions, some of them been states of another FSM (like you would have\nwith a counter), where is the problem?\n[QUOTE]\nThe isolated procedures for updating each state variable\nin your FSM have to be aware of one another and the order in which they\nare invoked. This greatly complicates the code and understanding of it.\nI would find that to be impossibly difficult to use. I don't consider\nthis to be useful decomposition.[/QUOTE]\n\nSee the following snippet of code:\n\n<code>\n-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\nprocedure writ_read (\nstate_v : inout state_t;\nmstate_v : in mstate_t;\nnstate_v : in nstate_t) is\nbegin\ncase state_v is\nwhen IDLE =>\nif mstate_v = START_READ or nstate_v = START_READ then\nstate_v := READ_BGN;\nelsif mstate_v = START_WRITE or nstate_v = START_WRITE then\nstate_v := WRITE_BGN;\nend if;\nwhen READ_BGN =>\nstate_v := READ_END; -\- this is one clock cycle\nnRD_v := not nRD_v;\nwhen READ_END =>\nstate_v := IDLE;\nnRD_v := not nRD_v;\nDATA_v := DATA;\nwhen WRITE_BGN =>\nstate_v := WRITE_END; -\- this is one clock cycle\nnWR_v := not nWR_v;\nwhen WRITE_END =>\nstate_v := DONE;\nnWR_v := not nWR_v;\nwhen DONE =>\nstate_v := IDLE;\nDATA_v := (others => 'Z'); -\- release the bus\nwhen others => null;\nend case;\nend procedure writ_read;\n</code>\n\nthe 'awareness' you refer to is in the IDLE state case, where the 'if'\nbranch reacts on the others' state variables... Being the author of this\ncode I certainly cannot see the 'complication' that lies behind it, but\nplease advise on how to write it *more* clear than this .\n\n[QUOTE]\nYes, Mealy and Moore are not often used in a strict sense, but the point\nis access to the *next* value of the state rather than the current\nvalue. This lets you get registered outputs out on *this* clock edge\nrather than having them wait a clock cycle.[/QUOTE]\n\n'this' or 'that' clock cycle does not really matter to me, latency apart\nI get the same throughput.