Open NickShaffner opened 7 years ago
@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)
@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.
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.
@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.