Adjusting the clock in the Arty's XDC

[wanderso]

I have the sample constraint file for my Arty board. I notice that where it says a clock signal is created in the file, it specifies a specific port that the clock is found on, specifically PACKAGE_PIN E3. 

set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { CLK100MHZ }]; #IO_L12P_T1_MRCC_35 Sch=gclk[100]

create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {CLK100MHZ}];

This creates a 100 MHz clock for the Arty. However, my current project needs a 20 MHz clock.

I lack the FPGA knowledge to know whether these two lines of code are *describing* a clock that already exists at E3 on the Verilog board, or *creating* it. The "create clock" implies that it's creating, but the way the rest of the constraint file is formatted - with a list of the pins that exist on the Arty and their locations - suggests that it's only describing.

Is it safe or even possible to make a 20 MHz clock by simply changing the number after -period to 50.00 for a 50 ns 20 MHz clock? Is there a way I can also keep the 100 MHz clock at the same time?

[artvvb]

@wanderso

The safest way to create a slower clock for use in your HDL code or block design will be to derive it from the 100MHz system clock. I'd recommend looking into the Xilinx Clocking Wizard IP core found in Vivado's IP Catalog (under Project Manager in the Flow Navigator). This IP can be used in your designs and deals with configuring the FPGA's clocking resources, such as MMCMs and PLLs correctly. There are also fairly easy ways to ensure that your logic is only updated once per 5 clock cycles in HDL code, you could look into how to create a clock divider or enable flag.

It's hard to get into more detail without a better idea of the specific needs of your project. What are you trying to do with this clock?

Thanks,

Arthur

[wanderso]

I'm looking to create a Verilog interface for the Digilent PmodMIC3, since the provided IP core has been too slow to get a 48KHz sample rate (the problem isn't actually with the IP core, but with the interrupt service routines, each of which seems to take at least 120 cycles).

The datasheet says the maximum safe serial clock rate for the PmodMIC3 's onboard microphone is 20MHz. I want to create some sample Verilog programs that directly read the PMod off the jumper port ('jd' if it's relevant), and that'll mean creating a 20 MHz clock that connects to jd[4]. Does that make sense? 

[D@n]

@wanderso,

I'm not sure I follow your thoughts regarding the jumper port.  Do you mean directly from the device using Verilog?  Shouldn't be a problem.  As opposed to what?

I've now worked with many different SPI devices, and I have yet to need to generate a clock via MMCM for a SPI device (SDRAM on the other hand is a different story).  SPI devices are usually really easy to run off of logic generated from the system clock, and the software is a whole lot simpler to do so.  Just ... don't try to trigger off of the positive edge of this logic-generated clock within your design.  If your timing is really tight, then use an ODDR module to send the clock to the output port.  (You might need to scope this to see what's going on if things don't work ...)  Still ... SPI timing is rarely that tight.  Even more, the SPI clock rate on this device isn't connected to the decoder rate.

You can find a straight verilog example of how to interface with the MIC3  here, although I'll be honest: I haven't had time to actually test it on my board (yet).  (I've been too busy with HDMI video)  Still, the repo has a test suite integrated into it, "proving" it works ... whatever that means for code that hasn't touched hardware.  While it'd be fun to hook it up to an FM transmitter hack that I've got, ... I'd be worried about getting feedback between the two that would then destroy my fun.  Still ... I'm off topic.

As built, the wbpmic module will divide the 100MHz Arty clock to generate a logical strobe at a rate that is any integer division of 100MHz.  Since dividing 100MHz by 2083 only gets you close to 48kHz, you might wish to use a fractional divider instead.  Adjusting it for fractional division shouldn't be difficult at all.  My plan was always to run the output into a fractional, reprogrammable resampling circuit ... I just haven't gotten that far with my device.

Dan