Strange fitter result.

F

Fred Bartoli

Guest
Hello,

I've almost finished my first design. To make it enter in the small
resources of my CPLD I had to adapt my design to use structures that
minimize the product terms and routing usage, i.e. use wherever possible the
clock enable capabilities of the MCs and "tweak" the usual "case... end
case" description of fsm to use it.

Now I've something that simulate well and gives me the expected results :)

To obtain this I had to hard look into the fitter report netlist to
understand the reasons why it didn't fit.

.... and I noticed something rather bizarre : a DFF that has it's async reset
permanently set.


Here's the vhdl contruct :


----------------------------------------
if (Gating_State = Hold_St) or (Gating_State = Count_St) or (Gating_State
= WaitTrig_St) then
HoldAll := '1';
elsif rising_edge(CpldExecPulse) then
if (Opcode = op_PresetReady) or (Opcode = op_MeasRead) or (Opcode =
op_LoadPresetChannel) or (Opcode = op_IncPresetChannel) then
if (Opcode = op_PresetReady) then
HoldAll := '0';
else
HoldAll := '1';
end if;
end if;
end if;
----------------------------------------

which is, I believe, a valid clock enable definition.


And here's the fitter netlist excerpt :

----------------------------------------
!HoldAll.D = (Opcode_5.Q & Opcode_7.Q & Opcode_4.Q & !Opcode_6.Q);
XXL_476 = ((Opcode_7.Q & !Opcode_4.Q & !Opcode_6.Q) # (!Opcode_7.Q &
!Opcode_5.Q & Opcode_4.Q & !Opcode_6.Q));
!XXL_499 = (!Gating_State_1.Q & !Gating_State_0.Q);
HoldAll.C = CpldExecPulse.Q;
HoldAll.AR = 1; <=============??????????????
HoldAll.AP = XXL_499;
HoldAll.CE = ((!Opcode_6.Q & Opcode_5.Q & Opcode_7.Q) # XXL_476);
----------------------------------------


I can't understand how this could have a chance to work.
Could it be a fitter bug ?
Is my vhdl code OK ? I don't see anything wrong.

Any advice is welcomed.

Thanks,
Fred.
 
Fred Bartoli a écrit:
Hello,

[...]
... and I noticed something rather bizarre : a DFF that has it's async reset
permanently set.
Click to expand...
Are you sure it's not an active low reset?

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
"Nicolas Matringe" <matringe.nicolas@numeri-cable.fr> a écrit dans le
message news: 4046E42B.4010301@numeri-cable.fr...
Fred Bartoli a écrit:
Hello,

[...]
... and I noticed something rather bizarre : a DFF that has it's async
reset
permanently set.

Are you sure it's not an active low reset?

--
Click to expand...

Yes. Unused resets/presets/... are not even mentionned in the netlist.
I'm still puzzled...


Thanks,
Fred.
 
"Fred Bartoli" <fred._canxxxel_this_bartoli@RemoveThatAlso_free.fr_AndThisToo> wrote in message news:<40467a1b$0$4682$626a14ce@news.free.fr>...
Hello,

I've almost finished my first design. To make it enter in the small
resources of my CPLD I had to adapt my design to use structures that
minimize the product terms and routing usage, i.e. use wherever possible the
clock enable capabilities of the MCs and "tweak" the usual "case... end
case" description of fsm to use it.

Now I've something that simulate well and gives me the expected results :)

To obtain this I had to hard look into the fitter report netlist to
understand the reasons why it didn't fit.

... and I noticed something rather bizarre : a DFF that has it's async reset
permanently set.


Here's the vhdl contruct :


----------------------------------------
if (Gating_State = Hold_St) or (Gating_State = Count_St) or (Gating_State
= WaitTrig_St) then
HoldAll := '1';
elsif rising_edge(CpldExecPulse) then
if (Opcode = op_PresetReady) or (Opcode = op_MeasRead) or (Opcode =
op_LoadPresetChannel) or (Opcode = op_IncPresetChannel) then
if (Opcode = op_PresetReady) then
HoldAll := '0';
else
HoldAll := '1';
end if;
end if;
end if;
----------------------------------------

which is, I believe, a valid clock enable definition.


And here's the fitter netlist excerpt :

----------------------------------------
!HoldAll.D = (Opcode_5.Q & Opcode_7.Q & Opcode_4.Q & !Opcode_6.Q);
XXL_476 = ((Opcode_7.Q & !Opcode_4.Q & !Opcode_6.Q) # (!Opcode_7.Q &
!Opcode_5.Q & Opcode_4.Q & !Opcode_6.Q));
!XXL_499 = (!Gating_State_1.Q & !Gating_State_0.Q);
HoldAll.C = CpldExecPulse.Q;
HoldAll.AR = 1; <=============??????????????
HoldAll.AP = XXL_499;
HoldAll.CE = ((!Opcode_6.Q & Opcode_5.Q & Opcode_7.Q) # XXL_476);
----------------------------------------


I can't understand how this could have a chance to work.
Could it be a fitter bug ?
Is my vhdl code OK ? I don't see anything wrong.

Any advice is welcomed.

Thanks,
Fred.
Click to expand...
Fred,

I am puzzled about this code fragment:

if (Opcode = op_PresetReady) or (Opcode = op_MeasRead) or (Opcode
=
op_LoadPresetChannel) or (Opcode = op_IncPresetChannel) then
if (Opcode = op_PresetReady) then

Why would you have "if Opcode = op_PresetReady (ORed with 3 other op
codes)" followed by "then if Opcode = op_PresetReady"? Logically this
is like (a or b or c) and a. Since a and a = a, you have a or (a and
b) or (a and c) which is always a. However, this does not explain
your problem. You do not say how the opcodes are defined--are they
defined as the state of a set of flip-flops (opcode4.Q, opcode5.Q,
....) or is each opcode an alias for one flip-flop?. If it is the
former, you have to be careful to account for all possible states of
the set of flops or you may not get the intended results. The same
thing goes for the gating states. These are more likely to be at the
root of the problem since they are involved with the asynchronous
control of holdall.

If I were trying to use a d flip-flop in this manner, I would use a
component d-flop having all of the inputs and outputs needed, and
would supply the logic for each input as required. In fact, I have
such a component in a library. The default inputs to its AR and AP
inputs are '0', for example, so if the fitter made the AR input '1'
when I did not have an equation for that input, i.e., the input was
not used in the instantiated component, I could be certain that the
fitter has a problem (assuming my component had been thoroughly tested
before being put into the library).

Charles.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top