Using a 25MHz external clock instead of the 12Mhz on a Cmod S7

[Larry]

I have checked this forum and other locations and not found any information concerning this problem on a Cmod S7. 

To maintain synchronization in my system I would like to substitute the on board 12MHz with a 25 MHz clock. The on board clock is feed to the FPGA though pin M9 (an MRCC input on bank 14). I was planning to feed the new 25 MHz clock through Pmod pin J7 (also a MRCC input on bank 34). I was not planning to disconnect after connecting the new clock. After connecting the new clock I believe that I must make some changes to the Constraint File so the board recognizes and uses the 25 MHz clock. 

Thank-you for your help.

[zygot]

1 hour ago, Larry said:

After connecting the new clock I believe that I must make some changes to the Constraint File so the board recognizes and uses the 25 MHz clock. 

Yes, so your new constraints file must identify the new external clock input with a pin location associated with whatever your 25 MHz clock is named in your design. You should also add a timing constraint. You can use the default constraints as a guide. If your design has a clock input named clk25m it would look something like this:

set_property -dict { PACKAGE_PIN XXX   IOSTANDARD LVCMOS33 } [get_ports { clk25m }];
create_clock -add -name new_clk_pin -period 40.00 -waveform {0 20.00} [get_ports {clk25m}];

Just be sure to comment out the original pin location constraint you are associating your new clock name to. And be aware that now you may have 2 clock domains to contend with if you are still using anything connected to the original 12 MHz input clock.

Was there a question in your post that I missed?

[Larry]

Thanks for your quick response. I believe you answered all my questions. I was more concerned about adding the second clock to another pin. From your response it

sounds like I should disconnect the original 12 MHz clock, from the FPGA, as it would simplify the system.  Unfortunately the Cmod S7 schematics do not show the crystal frequency source ( I believe it is IC5 ) or how else it is used on the board. From the information that is provided removing R75 should disconnect the 12 MHz clock from the FPGA.

Thank-you for you help. The next step would be to try it and see what problems develop.   

[zygot]

1 hour ago, Larry said:

I should disconnect the original 12 MHz clock, from the FPGA

No, don't do that. You can have multiple external clock sources, and your designs can use, or ignore, any of them. The 12 MHz clock is necessary for USB connectivity for configuration and a UART channel. I do think that assigning two of the GPIO pins as RxD and TxD as connections to a separate USB TTL UART is a very good idea. It will give you a communications channel that doesn't get used by Vivado Hardware Manager. You can't use it with an ILA but you can use it with you own debug code, and very often this is a better way to debug FPGA designs.

What I meant by commenting out location assignments in your constraints file is that you can't assign pins to multiple design references. There is a number of ways to handle this. You can create a project specific constraints file that just has the pins you are using or you can change the vendor supplied master constraints file by changing the "get_ports" reference to match your design names. I sometimes copy the location assignment lines and comment out the original one, then change the "get_ports" reference to reflect the design reference in a project.  That's one way to keep track of my changes to the master constraints file. For very complex designs it's better to put timing constraint in a separate file than location, IOSTANDARD, slew, etc constraints and limit pin references to just those being used. Figure out what works best for you and your project.

[Larry]

That was the original design of not disconnecting the 12MHz clock. I thought that was used for the USB and other peripheral circuits. Without a complete set of schematics it is hard to know what is connected to what. 

The master constraint file is always a good starting point. Using a separate file for complex designs is a good idea. 

Thank-you for your suggestions and pointing out possible problems with variations of the design.

   

[zygot]

2 hours ago, Larry said:

The master constraint file is always a good starting point.

I forgot to mention this but always compare pin LOCATION and IOSTANDARD constraint assignments to the schematic as a verification step. Yes, this is a problem when pin connections aren't shown on the published schematic. Unfortunately, since moving to the FTDI devices Digilent has decided to hide this information. The schematics are generally correct though it's possible that a replacement part isn't reflected in the latest published schematic. Some vendors are good at publishing complete information on all PCB versions and some aren't. In general the schematic comes from the PCB files so it reflects the latest PCB rev, though that's not what is always available. 

Unfortunately, parts aren't always available when you want to do a PCB run so either you wait for parts or you substitute parts that are available and hopefully fully compatible and make product. Just-in-time manufacturing is great for part vendors and distributors, in an ideal world. But as we've seen with disruptions like, say a global pandemic, the world can be pretty non-ideal.  The whole idea of being prepared for a disaster that may not come for decades is certainly good for many pub discussions. My take is that 21-century man is capable of and motivated to do things that he has no ability to control... I'd take bets on an impending mankind made mass extinction event but haven't figured out how to collect when I win....