1. Home
  2. Field-Programmable Gate Arrays
  3. ISE = Intelligent Synthesis Expectable :-)

ISE = Intelligent Synthesis Expectable :-)

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

Reply to
backhus
Loading thread data ...

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

DCM_NextState

Reply to
Jan Decaluwe

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

Reply to
backhus

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

Reply to
johnp

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
Reply to
Jan Decaluwe

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

Reply to
backhus

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

Reply to
backhus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.