Is there any way to specify a clock frequency for ...
# openlane
k
Is there any way to specify a clock frequency for a second clock domain? I was not able to find any information about this. In my config.tcl i have something like the following
Copy code
set ::env(CLOCK_PERIOD) "10"
set ::env(CLOCK_PORT) "wb_clk_i"
but I would like to specify a second, faster, clock. Update: It seems that I can just specify my second clock domain and frequency, run the tools, and have a look at the clock report, then change back and make a run normally. Does the result I get here (in this case over 400 MHz, awesome!) also apply when I make a run with the main clock configuration? Or does the clock configuration affect the place and route?
h
I asked the openlane team during the Q&A section recently about Clock domain crossing and they confirmed that the tool does not support it. I think that one way you can do CDC is to partition your design according to the clock domains. Then you can harden each clock domain separately with some synchronization structure. After that, you can assemble these macros in the top-level design. The synthesis and PNR depends on the clock configuration, therefore, doing like the one that you described in the question would be dangerous. For big designs, you need to ensure the clock tree for each clock is correctly implemented. And signals that travel among clock domains will be correctly synchronized so that they will not cause metastability. You can read more about this problem and solution here: http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf
k
Thanks for the reply! The paper in question is a very good resource indeed. In my design, the CDC goes from a slow to a fast clock domain (5x faster). The output bits are stored in registers and are then fed into a 2-register chain in the fast domain (no comb-logic in between). But maybe I should add an extra register in the fast domain just to be safe?
h
When you sending signals from a slow clock domain to a fast clock domain, 2-reg chain might be good enough already because the signal from the slow clock domain will expand to multiple cycles in the fast clock domain. Another idea is to use a 5x clock divider from the original clock and then analyze them as synchronous clocks (because they have relation and they all start at the same source). This is just my idea. I've never done it in openlane.
k
Thanks for the suggestions. I think I'll keep it the way I have it. One thing to keep in mind with doing it the way you are suggesting, is that the clock divider might introduce some delay/phase shift, but it will at least be constant. In my case I will be using the two PLL outputs which have a fixed relationship as well, so I think this should work in a similar fashion.