Design is too slow

kaz:

--- Quote Start ---

Your second process is heavily combinatorial and is unlikely to pass timing. I personally use one process state machine always. That way I declare one state signal of type say s0,s1,s2,s3,s4, ...etc. and assign next state as follows: if...state <= s0, if... state <= s1 and so on. The change of state is always on the clock edge so are any conditions and assignments. To keep functionality you will need to redesign for latency effect.

--- Quote End ---

tricky:

--- Quote Start ---

Does the spec actually say in the specification "You MUST use two processes" or is it just that you cant get it to work with a single process state machine? I would be very surprised if it was the former.

--- Quote End ---

This shows a bias against two-process state-machines, claiming one-process states-machines are better which is without any proof or justification. A two-process state-machine does perform equally as a one-process state-machine. A two-process state machine allows you to generate additional combinatorial outputs, without having to resort to a additional combinatorial process to decode these outputs, or having to "redesign for latency effect".

The correct advice is to look at the critical paths in TimeQuest, as hargeo effectively did, and rework the logic.