ISE = Intelligent Synthesis Expectable :-)

Dec 09, 2005 6 Replies

Hi folks, I just stumbled over something funny:



I usually write FSMs with registered outputs similar to this example:


--



-- $Id:



-- ARCHITECTURE behavioral OF DEC_Controller_Modi IS



TYPE DCM_state IS (Wait4Activation, Run_ECB, Run_CBC, Run_CFB, Run_OFB, Run_CTR); SIGNAL DCM_CurrentState : DCM_state; SIGNAL DCM_NextState : DCM_state;



BEGIN -- ARCHITECTURE behavioral



-- purpose: StateRegister for DEC_Controller FSM -- type : sequential -- inputs : Clock, Reset, DCM_NextState -- outputs: DCM_CurrentState DCM_sync : PROCESS (Clock, Reset) IS BEGIN -- PROCESS DCM_sync IF Reset = '0' THEN -- asynchronous reset (active low) DCM_CurrentState


A single line with the default, right before the case statement in DCM_comb, should do it:

DCM_NextState

Hi Jan, You are right. I also thought about that, but somehow I expected it to create latches as well. Strange, since I'm using the defaults-before-case style a lot. Fooled by too much routine possibly :-)

But still, ISE created a latch free result before that change. Maybe one could complain about a missing warning. And even after the proposed correction ISE created a smaller and faster result than Precision RTL. (Synopsys dc also created something latchfree but again the FSM extraction failed, so further optimisation wasn't possible)

How comes that the simpler(?) tool does the better job?

Enlightened, but still wondering :-)

Eilert

Eilert -

I think your asking the wrong question when you ask

'How comes that the simpler(?) tool does the better job?'

You should ask 'which tools are doing the correct job?'

What if you were delibrately coding to create latches? Would you say it was doing a better job?

Just my $0.02

John Providenza

Perhaps it doesn't, unfortunately. It may be that you are seeing a bug that happens to do the right thing in this particular case.

Let's consider the combinatorial part separately, and suppose the control conditions are such that the default applies. With the default assigment, next state will combinatorially follow current state. But without it, as in your original code, it should keep its old value, as per VHDL semantics. So you need memory elements.

Now, you can argue that the memory elements are the flip-flops in the feedback loop of the overall circuit. And that current state cannot change unless the control conditions are such that the default does *not* apply. If ISE uses that info to avoid the latches, it is more intelligent indeed.

But my guess is that that's not what happening. To test this, synthesize the combinatorial part on it own. ISE cannot know how it is used now. Does it now infer latches or issue a warning? It not, then that's a bug and you were just lucky in the original case. Otherwise, we would like to know!

BTW, the truly intelligent thing to do would be to refuse to infer latches and issue an error. The latch control logic will be so glitchy that such a circuit cannot possibly work reliably in practice.

Jan

Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com

johnp schrieb:

Hi John, good point. I posed my question from the FSM designers point of view.

In any other case you are right. see the next postings...

best regards

Eilert

Jan Decaluwe schrieb:

-- snip--

Hi Jan, I did as you proposed (for ISE only) and the good news is that it indeed can create latches when synthesizing the combinatorical part without the defaulting line before the case. Of course the latches will be "welcomed" with a warning in the synthesis report :-)

So for FSM designers using ISE the way is free to create crappy code without a warning, which becomes painful for those who want to use that code with other synthesios tools. A little warning in the report would be nice. Something like:

"Incomplete specified FSM-feedback detected. Creating latch-free logic."

This would give at least a clue that danger is ahead of the road. Your proposal might even be better, since it forces designers to create latchfree, portable sourcecode. Is anyone from Xilinx reading this? Maybe it's worth to put it on the todo-list for ISE8.1 SP1 :-)

best regards Eilert

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required