currently in the new niolib plugin the assumption is that all clocks which are given separate domains (and therefore separate IO Rings) will be external and therefore require a global H Clock Tree to cover the entire ASIC https://bugs.libre-soc.org/show_bug.cgi?id=155#c24 if we have an external 24mhz Reference Clock, we do not actually want this to result in a full global H-Clock Tree covering the entire ASIC. the only place we want it to go is: to the PLL block. however it is the *output* from the PLL that we want to have a global H-Clock Tree. but, given that this could run as high as 300 mhz we do *NOT* want it to go out as an external pin. bottom line is that we need to be able to specify, as a coriolis2/settings.py configuration parameter, exactly which clocks are to have an H-Tree created for them. not for the assumption to be that if it is a clock, and it is on the IORing, it *must* have an H-Tree.
Jean-Paul: index f1fc2f61..9877199d 100644 --- a/cumulus/src/plugins/alpha/chip/corona.py +++ b/cumulus/src/plugins/alpha/chip/corona.py + @property + def coronaCks ( self ): + if self.corona.conf.useClockTree: return self.corona.conf.coronaCks + return [] + this would be parameteriseable in coriolis2/settings.py (or chipConf dictionary) to allow explicit naming of clocks that were to be an H-Tree. in the ls180 case these would be: * JTAG_TCK * PLL_OUT_CLK they would *NOT* be: * JTAG_TCK * PLL_OUT_CLK * SYS_CLK but, note: the IORing clocks would be: * JTAG_TCK * SYS_CLK the H-Tree clocks *are not the same as* the IOring clocks. this i believe is what we need. is this easily achievable by simply modifying corona.Side class coronaCks function to return a user-defined list? if so then i could try that.