problem with the clock and ise

[Timo Moesgen]

Hi!
I have a problem with my code and can't figure out the problem. I wanted
to write an fpu in vhdl with several modes for ieee754. By now, all
seems to run fine, but I get an error synthesize my code:

Clock Information:
------------------
-----------------------------------------------------------+------------------------------+-------+
Clock Signal | Clock
buffer(FF name) | Load |
-----------------------------------------------------------+------------------------------+-------+
clk | IBUF+BUFG
| 109 |
vergleichen/eq_0_cmp_eq0000(vergleichen/eq_0_cmp_eq00001:O)|
NONE(*)(vergleichen/output_1)| 4 |
-----------------------------------------------------------+------------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.
INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically
buffered by XST with BUFG/BUFR resources. Please use the buffer_type
constraint in order to insert these buffers to the clock signals to help
prevent skew problems.

I don't really understand what ise tries to tell me. All other modules
have no problem with the clock mapped to them. As you can see below,
there is only one clock-signal.

Here is the code of fpu.vhd

---


component compare
port(
clk : IN std_logic;
reset_h : IN std_logic;
infloat1 : IN float;
infloat2 : IN float;
output : OUT std_logic_vector(1 downto 0);
cpmode : IN std_logic_vector(2 downto 0);
incalcmode: IN std_logic_vector(2 downto 0)
);
end component;

vergleichen: compare
Port map(
clk => clk,
reset_h => reset,
infloat1 => float1,
infloat2 => float2,
output => cresult,
cpmode => compmode,
incalcmode => calcmode
); -- end port map
---

Here the code of compare.vhd:

---
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use WORK.i387.ALL;

-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;

entity compare is
port(
clk : IN std_logic;
reset_h : IN std_logic;
infloat1 : IN float;
infloat2 : IN float;
output : OUT std_logic_vector(1 downto 0); --definiere 01 als
unordered, 11 als "wahr", 00 als "falsch"
cpmode : IN std_logic_vector(2 downto 0); --mode, was gemacht
werden soll: =,<,>
incalcmode: IN std_logic_vector(2 downto 0)
--definiere 001 als =
--definiere 010 als <=
);
end compare;

architecture Behavioral of compare is

begin
process(clk)
Variable eq : boolean;
Variable lt : boolean;
Variable nan : boolean;

begin
if incalcmode = "011" then
if (reset_h = '1') then
eq := false;
lt := false;
nan := false;
elsif ( clk = '1' ) then

if ( NOT infloat1.exp = 0 and NOT infloat1.mant = 1 ) or
( NOT infloat2.exp = 0 and NOT infloat2.mant = 1 ) then
-- float1 ist NaN
nan := true;
end if;

-- equal
if nan = false and ( cpmode="001" or cpmode="010" ) then

if infloat1.exp & infloat1.mant = 1 and infloat2.exp & infloat2.mant
= 1 then

if infloat1.sign = infloat2.sign then
nan := true;

else
eq := false;
end if;


elsif infloat1 = infloat2 then
eq := true;


elsif infloat1.exp & infloat1.mant = 0 and infloat2.exp &
infloat2.mant = 0 then
eq := true;

else
eq := false;
end if;

end if; -- gleichheit


-- smaller
if nan = false and ( cpmode = "010" )

if (infloat1.sign < infloat2.sign) then
lt := false;

elsif (infloat1.sign > infloat2.sign) then
lt := true;
else
-- exp1 groesser
if (infloat1.exp > infloat2.exp) then
lt := false;
-- exp2 groesser
elsif (infloat1.exp < infloat2.exp) then
lt := true;

else
if (infloat1.mant > infloat2.mant) then
lt := false;
else
lt := true;
end if; -- mant
end if; -- exp
if infloat1.sign = '1' then
lt := NOT lt;
end if;

end if; -- sign
end if; --mode = "010"


if nan = true then
output <= "01";
-- frage auf gleichheit
elsif cpmode = "001" and eq = true then
output <= "11";
-- frage auf "<="
elsif cpmode = "010" and ( eq = true or lt = true ) then
output <= "11";
else
output <= "00";
end if;

end if; -- reset/clk
end if; --incalcmode
end process;
end Behavioral;

 

[Brian Drummond]

On Thu, 31 Jul 2008 11:15:45 +0200, Timo Moesgen <timo.moesgen@gmx.net>
wrote:

Hi!
I have a problem with my code and can't figure out the problem. I wanted
to write an fpu in vhdl with several modes for ieee754. By now, all
seems to run fine, but I get an error synthesize my code:

Clock Information:
------------------
vergleichen/eq_0_cmp_eq0000(vergleichen/eq_0_cmp_eq00001:O)|
NONE(*)(vergleichen/output_1)| 4 |
-----------------------------------------------------------+------------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.

Here is the code of fpu.vhd

architecture Behavioral of compare is

begin
process(clk)

begin
if incalcmode = "011" then
if (reset_h = '1') then
....
elsif ( clk = '1' ) then
[the actual work]
end if; -- reset/clk
end if; --incalcmode
end process;
end Behavioral;

I can't see the precise problem, but here you have a dependence on both
incalcmode AND clk, ... aah yes I can ...and no edge detection on clk.

So when clk = 1 and incalcmode changes, ... which is the clock signal?
incalcmode... Incidentally this cannot pass a proper simulation
testbench because incalcmode isn't in the sensitivity list.

Use a standard synthesis template

-- -- process(clk)
-- an asynch reset is OK BUT add it to the sensitivity list!
process(clk,reset)

begin
if (reset_h = '1') then
....

-- elsif ( clk = '1' ) then
-- This gives a combinational clock ...
-- not completely wrong, but inappropriate for FPGA synthesis
elsif rising_edge ( clk ) then

if incalcmode = "011" then
-- HERE you test the other inputs "incalcmode" etc

[the actual work]

end if; -- reset/clk
end if; --incalcmode
end process;

Anything else may be legal VHDL and do something resembling your design
intent in simulation, but only this (and a few similar related
templates) can be correctly translated into FPGA logic. Which is what
the synthesis errprs are telling you.

Some people may quibble with the asynch reset; they are not wrong; you
can easily convert to a synchronous reset...

if rising_edge ( clk ) then
if (reset_h = '1') then
....
elsif incalcmode = "011" then
....
end if; -- reset etc
end if; -- clk

Much cleaner, no?

- Brian

 

[Timo Moesgen]

Brian Drummond wrote:

Some people may quibble with the asynch reset; they are not wrong; you
can easily convert to a synchronous reset...

Well, the asynchronous reset is, well... it was intentionally. The fpu
is to be plugged to FIFOs and this design also has the asynchronous
reset. But I will look into this... thanks for the advice.

if rising_edge ( clk ) then
if (reset_h = '1') then
...
elsif incalcmode = "011" then
...
end if; -- reset etc
end if; -- clk

Much cleaner, no?

I think I know get the point to this - hardware "development" is full of
pitfalls. The problem is to "think" in hardware.
Thank you very much, without your help, I wouldn't have seen (well,
realized) this problem.

Best regards,
Timo

 

[Brian Drummond]

On Fri, 01 Aug 2008 13:54:39 +0200, Timo Moesgen <timo.moesgen@gmx.net>
wrote:

Brian Drummond wrote:
Some people may quibble with the asynch reset; they are not wrong; you
can easily convert to a synchronous reset...

Well, the asynchronous reset is, well... it was intentionally. The fpu
is to be plugged to FIFOs and this design also has the asynchronous
reset. But I will look into this... thanks for the advice.

Maybe later. Asynch reset works perfectly well under most circumstances.
You can get timing errors if the delay on the reset network is greater
than a clock cycle, as will be the case with some FPGA families.

But in a coprocessor, unless you are activating it on the cycle
immediately after reset,that doesn't matter. At this stage, decide for
yourself if the problem matters to you; and if it doesn't, ignore it.

(IMO an asynchronous reset and a couple of cycles delay before activity
is as good a solution as any; you may need to constrain the reset timing
on the delay counter, but nothing else)

I think I know get the point to this - hardware "development" is full of
pitfalls. The problem is to "think" in hardware.

Indeed. The full expressive power of the language is good to use for
simulation testbenches, and reference models to compare with the
hardware implementation; but you need to impose a different discipline
when writing the actual hardware itself.

- Brian