10-13-2019 01:35 AM - edited 10-13-2019 01:37 AM
in KCU105 boad, I have run example design of GTH. I added some logics and modules to the example design.
Now my problem is when I give a reset signal through the VIO core, all my VIOs and ILAs become inactive. (All input/outputs become 0 and i can't see or drive any signal). It is more like that the clock is not arriving there.
After exploring and debugging my design I found the problem is from diagaram below.
Clock input(Clk_in1) to MMCM is rx_usrclk2 the recovered clock from GTH. Output is 1/4 of that and RST signal is connected to the AND of two signals from two different VIO. These two VIOs are in freerun clk domain.
When I assert any of the two signal mentioned, all my VIOs and ILAs become inactive (VIO/ILA from freerun clk, VIO/ILA from rxusrclk2 clk, VIO/ILA from 1/4 clk) it is like a board-dead situation!
The error after the event and running ILA is shown below:
10-13-2019 02:54 AM
10-13-2019 03:04 AM
The clock is on-board 125 MHz clock.
Actually no, I don't need to reset the MMCM. But it must be possible, isn't it?
For example if the recovered clock got lost, how could we reset the MMCM to lock to its input?
10-13-2019 03:08 AM
10-13-2019 03:14 AM
What if after completely clean reset, that clock be available for ILA? Wouldn't it run?
I don't know. Does it lock to its corrected input after some input missing period without a reset?
10-13-2019 04:39 AM
Does it lock to its corrected input after some input missing period without a reset?
According to the note below i found in PG065, No! It has to be reseted.
10-13-2019 10:52 AM
10-14-2019 12:33 AM
Is your clock liable to be lost once board is powered up ?
Yes, it is the recovered clock of the GTH.
Questions I'd ask are ,what are you trying to protect against, what do you want to happen when that situation happens, how can you design to meet that.
I want the pll reset for the time I lost my recovered clock and gain it back again.
10-14-2019 12:47 AM
Hi @behnam_2705new ,
Yes, apparently it is connected to the output of the MMCM.
Now I'll try to solve the debug_hub problem and see what will happen.
In answer to @drjohnsmith , I had a design that the VIO/ILA clocks was not exactly freerun. When I gave proper clock to them, they would work and whenever I masked the clock I would face with the error mentioned.
10-14-2019 01:57 AM
taking step back,
seems your using the recovered GTx clock as your main clock in your desing ?
Its normal to have a local clock, that runs constantly as your main lcock. The output of the GTx, comes in via a fifo, and the data is packets with the valid of the AXI bus.
The recovered clock is only then local to the GTx IP block,
If you could move over to this, then your problems of ILA / VIO and gated clocks would be solved.
10-14-2019 03:44 AM
Your suggested design is good for some application. But in my application all my data is a stream data and I want the data to be processed every clock.
10-14-2019 04:22 AM - edited 10-14-2019 07:38 AM
The above technique of crossing from an intermitant clock to a continous clock is used in many many streaming applications, such as professional video.
If you are fighting the norm, then you can expect a more difficult route,
You now have an explanation as to why your desing stops working, and an explanation as to how other profesional systems work.
I think that about closes this case does it not .
10-15-2019 12:19 AM
The problem was the dbg_hub clock that was clocked by output of the MMCM. So whenever I reset the MMCM the dbg_hub will loose its clock.
I read the posts about "connect_debug_port dbg_hub/clk" but I still can't move the dbg_hub clock to the freerun clock it is stuck to the MMCM output. (IDK maybe because most of my debug cores are in that clock region)
So I deleted that OR of resets, now I can run my application with my logic reset, But still can't reset the MMCM! So I guess I must close this issue and persue the problem in debug forum.
Thanks for your helps