CLOCK__SIGNAL constraint! pls help

[Alistair Lamb]

Hi,
I'm doing my final uni project in VHDL using the xilinx spartan 2
pegasus FPGA board but have hit a small snag. When I synthesize my
VHDL code i get an error in the timing report that tells me that 3
signals are seen as clock signals when in actula fact only one of them
is.

TIMING REPORT
Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
_n0070(_n00701:O) | NONE(*)(PISO_load_output_17)| 54
|
ADC_EOC | BUFGP | 37 |
sync_pulse | BUFGP | 2 |
_n0149(_n01491:O) | NONE(*)(line_count_1) | 9 |
_n0153(_n01531:O) | NONE(*)(SRAM_addr_4) | 19 |
-----------------------------------+------------------------+-------+
(*) These 3 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.

This problem prevents me specifying pins for the 2 non-clock signals.
I have tried using the clock signal constraint as follows but this
doesn't work.
attribute clock_signal: string;
attribute clock_signal of GCLK: signal is "yes";
attribute clock_signal of sync_pulse: signal is "no";
attribute clock_signal of ADC_EOC: signal is "no";
Can anyone pls pls help me. Today is the final day of practical work
for my project and I want to have it working! any help is much
appreciated!
Regards
Alistair

 

[Tim Good]

Hi,


You probably already know this but I'll include it just in case:

All the D-flip flops (FD) on the xilinx FPGAs have both a clock pin
(CLK) and a clock enable (CE). The most common error I see is where the
VHDL used to infer register behavior is not phrased correctly. To avoid
such "gated clocks" adopt a syntax something like the example below
(note the clock is effectively identified by checking for an event and
the CE by being only evaluated inside the clock if. A latch is inferred
by the lack of an else clause).

signal clk : std_logic;
signal some_latched_signal, some_other_signal
: std_logic_vector( some_range);

-- ...

if clk'event and clk='1' then
if some_enable_signal = '1' then
some_latched_signal <= some_other_signal;
end if;
end if;

-- ...

The "_n1245..." signals are automatically generated by XST when a latch
is required but not explicitly defined (as above) this sometimes happens
without the designers intent when you have lengthy process statements
containing complex case statements.

In my view, the "clock_signal" attribute normally is not necessary
except in a few rare circumstances where there is no other alternative
to describe which signal is the clock and which the gate/enable.

If you want a more detailed answer you will need to post some snippets
from your code!

Enjoy,

Tim