DCM not working on P-One

[cawhitley]

I have tried various ways to get a higher clock speed than 32 MHz on the Papilio One. I generated the DCM VHD file using the Core generator. I tried it with and without feedback. In all of my testing, I never got anything except a 32 MHz clock output, which I sent to a P-1 pin, so that I could check it.

 

Can anyone please tell me how to get the DCM to function correctly, to output a high-speed clock? I tried the standard 288 MHz one from the library, but it did not work, either.

 

Bottom line, I cannot get a 288 MHz clock, only a 32 MHz clock.

 

Please help! Thanks.

 

clk_288_mhz_w_fb.vhd

[alvieboy]

entity YOURENTITY is

port (

clkin: in std_logic;

rstin: in std_logic

-- other sigs

);

end entity;

-- architecture here...

signal clk, rst, rst1, clko, locked, clkfb, clkin_ibuf: std_ulogic;

begin

ib: IBUFG port map ( I => clkin, O => clkin_ibuf );

fbb: BUFG port map ( I => clko, O => clkfb );

mydcm: DCM

generic map (

CLKFX_DIVIDE => 1,

CLKFX_MULTIPLY => 9,

CLKIN_PERIOD => 31.25

)

port map (

CLK0 => clko,

CLKFX => clk,

LOCKED => locked,

CLKFB => clkfb,

CLKIN => clkin_ibuf

);

process(rstin, locked, clk)

begin

if rstin='1' or locked='0' then

rst<='1';

rst1<='1';

elsif rising_edge(clk) then

rst<=rst1;

rst1<='0';

end if;

end process;

-- USE clk and rst

[alvieboy]

Your mistake is using CLK0, not CLKFX. CLK0 will always be the same as clock input (except if using DIVCLK, then it can be lower).

 

Alvie

[cawhitley]

Thank you aliveboy! I do recall that in one iteration of my trials, I used CLKFX, but things still did not work; however, it may be that they did not work for some other (unknown to me) reason. Once I tried using CLK0, the rest is history; I would never have the proper clock output after that point. So, I will give your advice a try.

 

Thanks again. 

[cawhitley]

Alvie, your advice worked. Thank you. One thing that I still don't understand is why I could not send the 288 MHz signal directly out one of the output pins, so that I could o-scope it. I had to divide it down, and then scope the divided clock. According to the Spartan 3E doc, the i/o should support up to 622 MHz, but apparently it does not. I am not an EE, but an embedded programmer, so I'm not sure about why I could not measure the 288 MHz clock.

 

In any case, there is a fast internal clock now. 

[james1095]

What kind of scope are you using? It takes some pretty fancy equipment to scope a 288 MHz signal, my 465B is good up to around 100MHz and that's better than most of the hobby oriented instruments out there. At work we have a 500MHz DPO and that was around $15k. Even with that you have to be very careful in how you set it up and connect the probe(s) and grounding to actually measure such high frequency signals.

[cawhitley]

James, I am using an SDS200, which is a USB scope. Someday, I need to get a "real" scope. That one can run up to 5 GHz for sampling, but I am unsure of its maximum displayable speed in MHz. When I divided down the 288 MHz clock to 72 MHz, I could see the wave. Have not tried anything higher (other than 288 itself). I was just verifying that the DCM was working.

[james1095]

That's a 200 MHz scope and that spec is probably optimistic, so it's no surprise you weren't able to see a 285 MHz signal with it. If the specs are remotely accurate then that looks like a decent instrument, certainly better than the typical hobbyist oscilloscope. Beyond around 200 MHz prices go up sharply.

[offroad]

Hi,

 

here's an idea: Route the 200+ MHz off the board via one pin. Feed it back in via another pin, using a short jumper cable.

Divide down by 27 and drive a LED (or divide by four and view on scope).

 

It's a fairly common strategy, use the FPGA to debug itself.

[cawhitley]

Thanks, offroad. I already did divide it by 16, 8, and 4, and verified that I could see the clock on the scope. I am now beyond that one issue, on to deeper stuff in my VHDL application.