02-14-2020 09:42 AM
I'm struggling with some funny clocking architecture I need to implement, I've attached a sketch to try to explain the problem. We are using the GTH in transmit mode. There are two main modes of operation, one (mode A in my picture) which runs at 297MHz, and another Mode B which runs at 200MHz in the GTH, but the actual logic needs to run at 10/9x faster than this, i.e. 222.222MHz. We've got an MMCM to generate the 222MHz clock, and a gearbox to cross back to the 200MHz domain when in mode B. I don't care about the output of the mode B logic when I'm in mode A, and vice versa. I'm having trouble telling vivado that the clock at point "A", on the input of the x 10/9 MMCM is at 200MHz - it always overwrites anything I tell it and goes with the worst case 297MHz. In reality I don't care what the MMCM or mode B logic does in that case. Unless I can convince vivado that the clock at point A is at 200MHz, I'll need to optimize all the mode B logic to go faster, when in reality it will never be run that fast. Do you have any suggestions?
02-14-2020 11:56 PM
Try use -combinational option of create_generated_clock at point A and see if that works.
02-17-2020 07:24 AM
OK - but I can't see how on it's own "-combinatorial" would help. I need to somehow tell Vivado that the clock is 200MHz rather than 297MHz.
I am trying something today, where I pass the clock through some logic on the FPGA fabric then pass it through a BUFG to get it back into the clocking network. I'm hoping that because Vivado doesn't know what I've done to the clock in th efabric, I might be able to trick it into thinking it's MAX rate is lower than what it is in reality. I've attached a picture to explain what I'm trying.
02-17-2020 09:19 AM
FYI: I get
CRITICAL WARNING: [Common 17-170] Unknown option '-combinatorial', please type 'create_generated_clock -help' for usage info. [/home/bristolbuild/.jenkins/workspace/nefario_hdmi_2_1/chaz/syn_dl_sdi_8k/timing.xdc:27]
I'm running with Vivado 2018.2
02-19-2020 01:04 AM
OK I think I have a solution that will work:
1) Put the 200/297MHz clock into the MMCM directly.
2) Choose MMCM settings such that if there were a 297MHz ref clock it outputs a frequency just above my desired 222.2MHz. In reality I got it to go about 242MHz. This means Vivado will synthesize all my Mode B logic at 242MHz. Near enough.
3) Make a state machine to use DRP when the block comes out of reset to overwrite the MMCM settings. The new settings are such that with a 200MHz ref clock, the MMCM will generate 222.2MHz exactly.
With this scheme I can see the tool is synthesizing the logic at 242MHz, but I've yet to debug the rest of the system and make it actually work! I'm confident this is a solution that will work.
Seems a bit weird that I can't just overwrite auto-generated constraints, and it's a shame to have to throw LUTs at the problem. Does anyone from Xilinx has any better suggestions? When I have more time I could come back and try to fix it in constraints?