Compilation Warning

--- Quote Start ---

If this is a test build then you might want to drive your outputs from the FSM outputs to ensure the FSM isn't optimized away!

Or you could use the "Preserve Fan-out Free Register Node" assignment on the signals you want to keep. (Maybe you plan to view them in SignalTap)

See the online help for more info on this assignment

--- Quote End ---

thanks alot. i will try to see what can i do about it. by the way, what does it mean by optimized away?

Optimisation is a whole load of various attempts to make the logic smaller (or faster). For example where two lumps of logic perform the same function, these can be combined to use fewer logic elements overall; if you have a multiplexer which always has the select input tied high then it will always output the same signal so the multiplexer can be removed; if you have a lump of logic which drives a signal which doesn't go anywhere then from the point of view of the outside world, this logic can be stripped out without having any noticable effect.

In your case, whatever the FSM and other logic does, the outputs remain fixed. So Quartus has realised that it can optimise the design (i.e. make it smaller) by stripping out the FSM and other logic, without having any impact on the outputs - i.e. the logic is "optimised away".

It sounds like your case is (a not uncommon) one of wanting to look at a partial design. If you hack a bit of code to pull your FSM outputs to the device pins then you should be able to get it to synthesise OK.

I sometimes do a similar thing just to get an idea of design size - this may mean that you have to set the device to a huge package (which you are not going to use) just to get the compilation running. Once you get your design finished and you don't have huge numbers of test outputs then you can set the device properly.

Hope this helps

batfink

--- Quote Start ---

Optimisation is a whole load of various attempts to make the logic smaller (or faster). For example where two lumps of logic perform the same function, these can be combined to use fewer logic elements overall; if you have a multiplexer which always has the select input tied high then it will always output the same signal so the multiplexer can be removed; if you have a lump of logic which drives a signal which doesn't go anywhere then from the point of view of the outside world, this logic can be stripped out without having any noticable effect.

In your case, whatever the FSM and other logic does, the outputs remain fixed. So Quartus has realised that it can optimise the design (i.e. make it smaller) by stripping out the FSM and other logic, without having any impact on the outputs - i.e. the logic is "optimised away".

It sounds like your case is (a not uncommon) one of wanting to look at a partial design. If you hack a bit of code to pull your FSM outputs to the device pins then you should be able to get it to synthesise OK.

I sometimes do a similar thing just to get an idea of design size - this may mean that you have to set the device to a huge package (which you are not going to use) just to get the compilation running. Once you get your design finished and you don't have huge numbers of test outputs then you can set the device properly.

Hope this helps

batfink

--- Quote End ---

actually I do have some outputs from the FSM but it is towards the last few states the FSM. should I get outputs from each state of FSM to get the compilation works?

--- Quote Start ---

actually I do have some outputs from the FSM but it is towards the last few states the FSM. should I get outputs from each state of FSM to get the compilation works?

--- Quote End ---

Hi,

depends on what you would like to achieve. When you would observe the behaviour of the FSM state at your output pins, you have to define all your states as output pins.

Kind regards

GPK