Symbol 'MMCME2_BASE' is not supported in target 'spartan6'.

[Nick Shaffner]

@cfelton, it would be nice to have ClockManagement for the spartan 6 series - likely the most popular hobbiest FPGA in the Xilinx line. However, it seems that the MMCME2_BASE is 7 series logic only.

Digging around in some Xilinx docs, I found clock managers corresponding to different parts:

7 Series: MMCME2_BASE, MMCME2_ADV
Virtex-5: DCM_BASE, DCM_ADV
Spartan 3: DCM_SP
Spartan 6: DCM_SP, DCM_CLKGEN

Thats a fair number of different implementations. I suspect that the the current vendor/ clock management code needs some decisions on how to cleanly factor in a larger variety of clock managers. It seems a little odd to me that this is in vendor, rather than system or build. (Maybe inside FPGA objects, similar to how the boards are arranged?) Just a thought.

[Nick Shaffner]

@cfelton What about moving away from directly modeling clock managers and clocking resources (which seem pretty diverse across devices in their capabilities and factoring). Have you considered adding the abstraction directly to clock?

clock           # example hardware clock declared in board file - 12Mhz

my_derived_clock = Clock(0, frequency=100e6, driver=clock)

I could see potentially adding phase and enable parameters as well. I imaging after being declared, such clock resources could be collected in a global registry and some magic could occur to generate the appropriate chains of clock resources using vendor and part specific hardware. (Generating errors when such hardware isn't available)

[Christopher Felton]

@NickShaffner Yes, we can and should add the spartan DCM and some of the other stuff we discussed (like removing enable since not all clock managers have it).

As far as the second goes, I think that would be a possibility but much farther in the future, we would need a generic'ish things like the vendor primitives under the hood this should work to such a solution. We should create a PEP/MEP type thing to fully outline such feature requests. We can use the issues mark them as enhancements but require the same thoroughness as a PEP.

[Nick Shaffner]

We should create a PEP/MEP type thing to fully outline such feature requests. We can use the issues mark them as enhancements but require the same thoroughness as a PEP.

Is it too early for a PEP style feature request system? Part of the reason I added the suggestion about the clock(driver=) enhancement was to do a little 'exploratory prodding' to learn more about the 'architectural style' and boundaries of the project.