We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for
Did you mean:
Highlighted
Visitor
1,779 Views
Registered: ‎05-08-2018

## Clock as LUT input (Spartan-6)

What is the recommended way to use a clock signal as a LUT input?

I am trying to implement a Quad-port BlockRAM (as described in XAPP228) on Spartan-6, where a BlockRAM is clocked at double speed (clkx2 generated by a DCM). The reference design (intended for Virtex-2) derives a "logic available clock" like this:

notclk <= not clk;
clk_lacff : fdc port map (c => clkx2, d => notclk, clr => rst, q => clk_lac);

The output clk_lac is equivalent to clk, but it's a logic signal that can be used as a LUT input. However, this cannot be implemented on Spartan-6 since clock signals can no longer be used as a logic signal and even the first line causes an error.

In my attempt to solve this, I am just toggling a flipflop on and off at clkx2, to generate a logic signal equivalent to clk:

signal clk_lac : std_logic := '0';

lac: process(clkx2) begin

if clkx2'event and clkx2 = '1' then

clk_lac <= not clk_lac;

end if;

end process;

This works in simulation. However, I am worried that I might get a phase-inverted clock if for some reason during the initialization of the DCM, the clkx2 and clk do not align and the flipflop just happens to be low when clk is high. Is this the right way to go at all?

1 Solution

Accepted Solutions
Xilinx Employee
2,560 Views
Registered: ‎11-03-2016

## Re: Clock as LUT input (Spartan-6)

Building on jmc's answer, I'll quote ug383 on status logic of the DCM:

The status logic indicates the current state of the DCM via the LOCKED and STATUS
output signals. The LOCKED output signal indicates whether the DCM outputs are in
phase with the CLKIN input. The STATUS output signals indicate the state of the DLL and
PS operations.
The RST input signal resets the DCM logic and returns it to its post-configuration state.
Likewise, a reset forces the DCM to reacquire and lock to the CLKIN input.

So remember that while LOCKED is not asserted, clk and clk2x are not guaranteed to be phase aligned and at the right frequency (especially true when using PLLs).
Unlike jmc, I wouldn't recommend using your toggling FF as a clock enable for the rest of you logic. Unless you give the right constraints to ISE (multicycle paths), your timing margins are halved. Also, let's not forget the terrible fanout of such a flip-flop and how horribly ISE is likely to deal with such a problem.
Regards,
YL
8 Replies
Scholar
1,766 Views
Registered: ‎02-24-2014

## Re: Clock as LUT input (Spartan-6)

It's about the only way you can go.  For your peace of mind, the DCM reset does synchronize the phase of the outputs on startup.   If you reset your toggle flip flop along with the DCM, you should be able to get a consistent and reliable startup with consistent phase between your flop and the DCM clk output.    Or you could dispense with the CLK altogether, and just use the clk2x by itself, and use the toggle flop as a clock enable whenever you needed transactions at half the rate.

Don't forget to close a thread when possible by accepting a post as a solution.
Xilinx Employee
2,561 Views
Registered: ‎11-03-2016

## Re: Clock as LUT input (Spartan-6)

Building on jmc's answer, I'll quote ug383 on status logic of the DCM:

The status logic indicates the current state of the DCM via the LOCKED and STATUS
output signals. The LOCKED output signal indicates whether the DCM outputs are in
phase with the CLKIN input. The STATUS output signals indicate the state of the DLL and
PS operations.
The RST input signal resets the DCM logic and returns it to its post-configuration state.
Likewise, a reset forces the DCM to reacquire and lock to the CLKIN input.

So remember that while LOCKED is not asserted, clk and clk2x are not guaranteed to be phase aligned and at the right frequency (especially true when using PLLs).
Unlike jmc, I wouldn't recommend using your toggling FF as a clock enable for the rest of you logic. Unless you give the right constraints to ISE (multicycle paths), your timing margins are halved. Also, let's not forget the terrible fanout of such a flip-flop and how horribly ISE is likely to deal with such a problem.
Regards,
YL
Visitor
1,745 Views
Registered: ‎05-08-2018

## Re: Clock as LUT input (Spartan-6)

So that means if I tie the flipflop to its initial state until the locked output of the DCM goes high, then I will always have a predictible behavior and I can rely that what I see in the simulation is actually going to happen in hardware?

Scholar
1,741 Views
Registered: ‎02-24-2014

## Re: Clock as LUT input (Spartan-6)

Yes

Don't forget to close a thread when possible by accepting a post as a solution.
Xilinx Employee
1,734 Views
Registered: ‎11-03-2016

## Re: Clock as LUT input (Spartan-6)

Unless you have caused other misdeeds, yes, though I wouldn't trust simulators all that blindly. That comes with experience I guess.
Historian
1,711 Views
Registered: ‎01-23-2009

## Re: Clock as LUT input (Spartan-6)

There is a more foolproof way (please excuse the Verilog)

always @(posedge clk1x)

toggle1x <= !toggle1x;

always @(posedge clk2x)

old_toggle1x <= toggle1x;

assign first_phase = toggle1x ^  old_toggle_1x;

[edit: Corrected logic for first_phase]

first_phase will be a logic signal that is asserted on the phase of the 2x clock that corresponds to the one right after the rising edge of the 1x clock. This is self-synchronizing, so doesn't depend on any startup relationship between the outputs of the DCM.

Avrum

Visitor
1,520 Views
Registered: ‎05-08-2018

## Re: Clock as LUT input (Spartan-6)

@avrumw This is a very interesting solution, thank you. But I think it should be

assign first_phase = toggle1x xor old_toggle1x

Historian
1,514 Views
Registered: ‎01-23-2009