Jump to content
  • 0

Nexys4DDR Clock Speed


pmprog

Question

Hi,

 I bought the Nexys4DDR a while ago, but never seem to get a lot of time to get stuck into it. I have managed to produce from VGA signals and other simple tasks.

One thing I was wondering, on the reference site (https://reference.digilentinc.com/reference/programmable-logic/nexys-4-ddr/start), it refers to having an internal clock of "450MHz+"

All the board files provide a 100MHz clock signal, using the following

set_property -dict { PACKAGE_PIN E3    IOSTANDARD LVCMOS33 } [get_ports { CLK100MHZ }]; #IO_L12P_T1_MRCC_35 Sch=clk100mhz
create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {CLK100MHZ}];

So, a couple of questions:

  1. Could I set this to 400MHz, or 200MHz?
  2. If so, is it just changing the "period" field? and would period be 5 or 20 for 200MHz? I'd have guessed at 5, but thought I'd ask
  3. Also, if a higher clock is possible, could I still add a secondary clock at 100MHz, or would I just do this in my VHDL? I suspect it's the latter, but again, just asking

Thanks

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

3 hours ago, pmprog said:

I bought the Nexys4DDR a while ago, but never seem to get a lot of time to get stuck into it.

Making time is one of the demands of playing with your Nexys4.

3 hours ago, pmprog said:

All the board files provide a 100MHz clock signal, using the following

No. The lines you quote are from the constraints. The actual clock signal frequency is set by the external clock module component physically soldered onto your board. To change this frequency you have to change the physical part. The good news is that you can have almost any clock rate(s) that you want in your FPGA design by using one of the MMCM modules in the FPGA device. You can do this by using the Xilinx IP in a block design or better yet use the IP generated Verilog of VHDL templates to instantiate it in your HDL code. You can also instantiate it as a primitive in either HDL. Constraints don't produce clocks. Constraints let the FPGA tools know what clocks your design has and the frequency and duty cycle of those clocks.

The first number is the frequency specification of your clock and refers to the clock period in nanoseconds. I'll leave t to you to verify with a calculator that a 100 MHz clock has a period of 10 ns. The second set of numbers indicates the duty cycle and phase shift of your clock. You need to read UG903 to understand constraints.

Clocks that come out of your MMCM are derived clocks and you tell the IP what frequency, duty cycle and phase offset each derived clock coming out of it should be.

Look around the Digilent Project Vault for HDL examples of instantiating MMCMs or look through Digilent demo projects for board design examples.

Good luck and make that committment to spending time with your you new endeavor.

 

Link to comment
Share on other sites

2 hours ago, zygot said:

No. The lines you quote are from the constraints. The actual clock signal frequency is set by the external clock module component physically soldered onto your board. To change this frequency you have to change the physical part. The good news is that you can have almost any clock rate(s) that you want in your FPGA design by using one of the MMCM modules in the FPGA device. You can do this by using the Xilinx IP in a block design or better yet use the IP generated Verilog of VHDL templates to instantiate it in your HDL code. You can also instantiate it as a primitive in either HDL. Constraints don't produce clocks. Constraints let the FPGA tools know what clocks your design has and the frequency and duty cycle of those clocks.

The first number is the frequency specification of your clock and refers to the clock period in nanoseconds. I'll leave t to you to verify with a calculator that a 100 MHz clock has a period of 10 ns. The second set of numbers indicates the duty cycle and phase shift of your clock. You need to read UG903 to understand constraints.

Clocks that come out of your MMCM are derived clocks and you tell the IP what frequency, duty cycle and phase offset each derived clock coming out of it should be.

Look around the Digilent Project Vault for HDL examples of instantiating MMCMs or look through Digilent demo projects for board design examples.

Good luck and make that committment to spending time with your you new endeavor.

Thanks for the reply.

I must admit, I did get a bit confused when you said there is an external clock module, but also that the FPGA can produce (almost) any clock rate.

My understanding on the constraint was that it describes what's on which pin, in this case E3 contains a 100MHz clock, and all the examples I've seen uses this 100MHz, and also describes it as an input on the top entity. I couldn't find any examples where a Nexys4DDR board had a clock different - but if this is an external source, it can't be anything other than.

But thank you for the reference to UG903, I found this document about clocks.Though this implies under the Virtual Clocks that you can create a custom clock unattached in the constraint file (unless I misunderstand what it's saying), and that these are different from Generated Clocks (which is where you mentioned MMCMs)

I downloaded all the examples for the Nexys4DDR board. Nexys4DDRVGAMouseOverlay seems to have a custom clock at 108MHz, that I presume is generated, but I'd have to look at that further.

It does baffle my head how you could take make a faster clock from a slower one.

Cheers

Link to comment
Share on other sites

1 hour ago, pmprog said:

My understanding on the constraint was that it describes what's on which pin, in this case E3 contains a 100MHz clock

So, most FPGA development boards have at least one external clock module available for FPGA internal clocking.

Your first steps are to dedicate some time to reading about the FPGA device on your board. But before that you need to have a minimal ability to read the schematics for your board. Fortunately, Digilent does provide them. The schematic for your board shows IC9 as a 100 MHz clock module with a single-ended clock going to pin E3 on the FPGA.

Forget about Virtual clocks for now. You need to understand your device. At a minimum read the User's Guides for Series7 SelectIO and Clocking. Also read through the VIvado tools User Guide, especially about the available design flows and how the tools support them.

There is a well worn method for creating a clock with one frequency out of a different clock having another frequency. They are the Phase Lock Loop. There are two general varieties ( at least for the purposes of this discussion ) analog and digital. The MMCM uses those techniques. You can derive a clock having almost any frequency from the 100 MHz external clock from IC9 with a lower, higher or the same frequency. You can also define the phase offset between the original clock and the derived clocks. This is a basic feature of programmable devices that make them so flexible. The PLL in a myriad of forms has been around for well before programmable devices were created.

Use the Xilinx Document Navigator and read, read, and then read some more. Don't expect to absorb everything at once. It'll take some time and many re-reads for the details to sink in.

BTW while you don't have to understand PLL techniques it does help to have a basic understanding of the types, how they work, and the trade offs for deciding on your output clock parameters relative to your input clock depending on how it is derived. The subject is complex enough to make a whole career out of... and more than a few people have done just that.

As a break from all of that reading take some time to open the Vivado IP clocking wizard and run through setting up a derived clock that you want. There's a user's manual for all of the Xilinx IP to help understand what you are doing. The wizard will create instantiation templates in the whatever HDL the project settings are to help use it. Only people who really understand what they are doing should use HDL primitives for using clock resources. I almost always use the wizard unless there isn't a suitable one available for my device. The tools and your design will just get along better that way. You do have to understand what the wizards are doing and not assume that it's what you want to do.

Also, since we are talking clocks it's a good idea to read the datasheet AC switching specifications for your FPGA device and speed grade so that you don't do something stupid.

 

Link to comment
Share on other sites

47 minutes ago, zygot said:

Your first steps are to dedicate some time to reading about the FPGA device on your board.

I'll have read through some more. I think part of my problem is that I'm more a software developer than electronics engineer; so some of the stuff I just don't understand (which is why some of these questions might be a bit dumb); but I shall endevour to read on

Thank you for all your help.

Link to comment
Share on other sites

This FPGA development stuff is complex. You can't just jump in with naive assumptions. Being a software developer is somewhat of a disadvantage as you're likely to make bad assumptions about designing logic an HDL. It isn't software, though some procedural practices apply to both endeavors. If you can approach it as a text based logic design then you will progress more rapidly. Most important do the preliminary work of understanding how FPGA devices work, how the tools work, and some basic concepts about logic design. There's actually a lot of information provided by the FPGA vendors. Too much information, so you need to speed read through lots of documents, probably many times, and develop the basics, building as you go. Don't rush, unlearning misconceptions is harder than learning what you need to succeed. Picking up a book on Verilog or VHDL syntax is generally a bad idea as few books that I know of give proper treatment to the differences between HDL for simulation and HDL for synthesis.

Link to comment
Share on other sites

Thanks for the advice.

I have stopped my overarching "project", and turned it into several tiny sub-projects, each testing a single thing at a time whilst I try and understand each component. But as you say, more reading required

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...