cawhitley

DCM not working on P-One

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.  :)

Share this post


Link to post
Share on other sites

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.  :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now