using 24mhz on board oscillator clock on bemicro CV board

--- Quote Start ---

when I power up the board I do not see any clock going into the design

--- Quote End ---

Do you mean there's no clock going to pin M9 or that your design doesn't do anything?

Assuming the latter - the 'set_location_assignment' is all you need to ensure your design knows where to source it's clock from. Arguably you should also tell Quartus what signalling standard of the clock (2.5V for this clock on this board), although not adding this won't stop it working.

I think it's more likely that you haven't got something connected up correctly in your design. Is it written in verilog or VHDL? Can you post some code?

Cheers,

Alex

Hi Guys

Thanks for your replies

I have checked in the pin planner and the clk pin was indeed routed to pin_M9

I have declared the following constraint in the qsys file

set_location_assignment PIN_M9 -to clk

set_instance_assignment -name IO_STANDARD "3.3-V LVCMOS" -to clk

The code is written in verilog. It is a simple I2C master.

However when I tried changing the clock pin to a header pin and I passed an external clock it started working .

But it is extremely noisy and hence I still want to use the on board oscillator clock.

Minor point but those constraints are found in the Quartus Settings File (qsf), rather than the qsys file.

It does sound like there's a possible board fault. However, this oscillator source is also used by the on-board USB-Blaster. Does that work or are you using the JTAG chain header to program the FPGA?

Try driving the clock out of one of the pins in a user header. In your code simply 'assign' a spare I/O pin, that goes to the header, the 24MHz clock.

Cheers,

Alex

--- Quote Start ---

Minor point but those constraints are found in the Quartus Settings File (qsf), rather than the qsys file.

It does sound like there's a possible board fault. However, this oscillator source is also used by the on-board USB-Blaster. Does that work or are you using the JTAG chain header to program the FPGA?

Try driving the clock out of one of the pins in a user header. In your code simply 'assign' a spare I/O pin, that goes to the header, the 24MHz clock.

Cheers,

Alex

--- Quote End ---

Hi Alex

I meant the qsf file not qsys, my bad.

You are right since it is shared by the USB blaster and I have used that to program the board , clk has to be working, unless something is wrong with the trace connecting it to the cyclone FPGA.

I used the .jic file to program the board, does it use a different clk?

I tried assigning the clk to one of the header pins but the synthesis tool warns that the debug clock output is tied to a zero.

Something like:

input clk;

output dbg_clk;

assign dbg_clk = clk;

I am thinking this means that the tool just optimized it out?

How can I avoid this?

Yes, there could be a fault with the trace to the FPGA. However, I think probably not.

The Quartus warning is more relevant. Your code looks about right and Quartus has no idea whether the pin is tie low on your board. So, Quartus clearly knows that 'dbg_clk' is static and low.

Can you post your .qsf file? I suspect the answer lies in there.

Cheers,

Alex

Not specifying a rise/fall time will not cause this problem, no. You doubt you need worry about the difference between 24MHz & 25MHz either - assuming you haven't got many/any ridiculously long combinatorial paths in your design. Anyway, you've constrained your clock more tightly - 25MHz - than the one you're actually using. So, no. don't worry about that.

You don't actually say but, having lost the 'tied to zero' warning, does your debug clock appear? I guess not. There's nothing in the qsf entries you posted that will cause you this problem...

Cheers,

Alex