12-05-2019 07:57 AM - edited 12-06-2019 06:31 AM
I packaged a block design as a custom IP using 'Create and Package new IP' , IP name: ltedata_v1.0
As can be seen, there are two external clock ports, s00_axi_aclk and s_axi_aclk. These are by default 100MHz. The two slave interface ports S00_AXI_AddrDec and S_AXI_BRAM are associated with the above clocks respectively. I understand that the frequency set in the 'external port propeties' for clock ports are automatically propogated to the IPs.
My top level design:
The custom IP 'ltedata_v1_0' can be seen instantiated in the top design above. My top design is clocked @245.76MHz. Ideally, I would want the top design to propagate the 245.76MHz clock to the custom IP 'ltedata_v1_0' but it didn't. It threw the following error during validation,
I changed the s00_axi_aclk and s_axi_aclk frequency values inside the custom IP manually in the GUI from 100MHz to 245.76MHz,
then repackaged the IP and ugraded the IP in the top level design. Now I am getting only the critical warnings as below,
I have two queries,
1. I am giving the same clock source (clk_out1 from the clocking wizard) to axi smc and the custom IP. I don't know why vivado is throwing this critical warning. Can I just ignore this?
2. Is there a way to automatically propagate the clk frequencies from top level to the custom ip. In future, if the clock of the top design is changed, it would be better for the custom ip to automatically adapt to the new clk freq instead of manually editing it.
I looked around a lot for the query 2 and failed to find a proper explanation or solution to this problem.
Any help, suggestions or corrections are appreciated!
12-05-2019 08:19 AM
I can say that creating IPs and re-using them can be problematic. I don't have the solution to your problem but an easy work-around (which you might have already thought of).
Can you proceed with your BD if instead of creating the IP, connecting the addr_decoder, blk_mem_gen and axi_bram_ctrl?
If yes, then you know for sure that creating the IP is causing the problem.
12-05-2019 09:04 AM
Thank you for your reply.
I agree, the workaround would be to not create the custom IP at all and directly connect these IPs in the top design. I already have a design like this and it is working fine.
For simplicity, we wanted to package these three IPs, AddrDecoder, BRAM and AXI BRAM Controller into one single IP as 'data'...so in future this will be replaced by RF DAC and ADCs. If this is going to be a lot of work, then probably we would go with the workaround which is more direct.
It would still be interesting and useful to know how this problem can be solved.