Dynamically repogramming an MMCM block

[hamster]

Prompted by another thread here ( https://forum.digilentinc.com/topic/4180-mmcm-dynamic-clocking/ ), I've been experimenting the the Dynamic Reconfiguration Port on the Artix-7 MMCM 

You can find the code and constraints for the Basys3 here: http://hamsterworks.co.nz/mediawiki/index.php/MMCM_reset 

It might be of interest to somebody (e.g. to change a VGA clock frequency dynamically). 

 

 

[zygot]

@hamster

Your code is an interesting introduction to using the DRP to dynamically change an MMCM2 block. The DRP port is a marvellous way to access internal configuration registers for a lot of Series7 modules.

I'd like to add a few observations:

- I urge anyone interested in using your code to read through the XAPP888 document and example code carefully. The example follows a more rigorous method for updating MMCM DRP registers as there are bits that need to have previous values retained.

- Some readers might not realize the importance of the lock output signal or that the output lock will not be valid until the MMCM achieves a lock condition. Using a button to change the MMCM is not necessarily the same as using a high speed internal signal to do the same.

- It should be noted that an LED indicator has limitations. If you clock a 32-bit counter and connect one of the high bits to an LED you have an indicator with limitations. If the counter process is correct and the LED is not blinking then your indicator pretty reliably indicates a missing clock. If you choose the correct counter bit to drive the LED then you have some idea, more or less, about the clock frequency... with emphasis on the more or less part. If an LED indicator blinks as expected this does not mean that the design is correct or functioning properly. In general LED indicators should be used with caution as they don't indicate transient conditions very well.  I just wouldn't assume that all readers understand this.

- Trying to control multiple things through the DRP might be problematic

As a general template for using the DRP to control the MMCM your code is nice as long as you understand the details.

As always I enjoy reading about your ideas and experiments.

 

[hamster]

6 hours ago, zygot said:

@hamster

Your code is an interesting introduction to using the DRP to dynamically change an MMCM2 block. The DRP port is a marvellous way to access internal configuration registers for a lot of Series7 modules.

I'd like to add a few observations:

- I urge anyone interested in using your code to read through the XAPP888 document and example code carefully. The example follows a more rigorous method for updating MMCM DRP registers as there are bits that need to have previous values retained.

- Some readers might not realize the importance of the lock output signal or that the output lock will not be valid until the MMCM achieves a lock condition. Using a button to change the MMCM is not necessarily the same as using a high speed internal signal to do the same.

- It should be noted that an LED indicator has limitations. If you clock a 32-bit counter and connect one of the high bits to an LED you have an indicator with limitations. If the counter process is correct and the LED is not blinking then your indicator pretty reliably indicates a missing clock. If you choose the correct counter bit to drive the LED then you have some idea, more or less, about the clock frequency... with emphasis on the more or less part. If an LED indicator blinks as expected this does not mean that the design is correct or functioning properly. In general LED indicators should be used with caution as they don't indicate transient conditions very well.  I just wouldn't assume that all readers understand this.

- Trying to control multiple things through the DRP might be problematic

As a general template for using the DRP to control the MMCM your code is nice as long as you understand the details.

As always I enjoy reading about your ideas and experiments.

 

Yep - completely agree.

If you were to use this (I'm thinking of using it for generating a changing VGA pixel clock) you should probably use the inverted 'LOCKED' signal as a reset for the critical bits of your design, or have your design organised so any 'badness' will get flushed out quickly (which shouldn't be a problem for a VGA controller - assuming I don't reset the clock midway through a memory transaction).