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

Clock as LUT input (Spartan-6)

Jump to solution

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?

0 Kudos
1 Solution

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

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

View solution in original post

8 Replies
Highlighted
Mentor
Mentor
1,972 Views
Registered: ‎02-24-2014

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.
Highlighted
Xilinx Employee
Xilinx Employee
2,767 Views
Registered: ‎11-03-2016

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

View solution in original post

Highlighted
Visitor
Visitor
1,951 Views
Registered: ‎05-08-2018

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?

0 Kudos
Highlighted
Mentor
Mentor
1,947 Views
Registered: ‎02-24-2014

Yes

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,940 Views
Registered: ‎11-03-2016
Unless you have caused other misdeeds, yes, though I wouldn't trust simulators all that blindly. That comes with experience I guess.
0 Kudos
Highlighted
Guide
Guide
1,917 Views
Registered: ‎01-23-2009

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

 

 

Highlighted
Visitor
Visitor
1,726 Views
Registered: ‎05-08-2018

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

 

assign first_phase = toggle1x xor old_toggle1x

Highlighted
Guide
Guide
1,720 Views
Registered: ‎01-23-2009

@dbemmann

 

Thanks for pointing out the error! I have fixed the original post.

 

Avrum

0 Kudos