11-25-2020 10:35 PM
I am looking at the VCU 118 Displayport RX subsystem example design and would like to port it over to other device(kintex). I noticed that these two custom IPs (vid_edid and video_frame_crc) is causing some issue when validate the bd design in IP integrator. The error is bus interface property Hz does not match. The interface property on Freq_Hz has been set to 100000000 after the migration. It was for example 300000000 in VCU118 example design. There are also some other errors reported due to Freq_Hz on other port for vid_edid and video_frame_crc. The properties Freq_Hz is a read only property and I am not able to change it.
I has been looking for any solution in the forum but did not find a solution for that. The way I ported the design was changing the FPGA part number and upgrade the IP. Wonder if any suggestion about this error or should I use another method to do the porting?
Attached images shows that the Freq_hz property after the migration
11-26-2020 06:40 PM
Hello @Way ,
An example design is generated based on the reference board. I think that it is better a design from scratch. It could be used an example design based on the KCU105 if you will use a Kintex, which is only pass-through. If it needs only RX or TX, please remove the Rx or Tx-side referring to the VCU118.
Product Application Engineer Xilinx Technical Support
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful. Please Give Kudos.
11-26-2020 09:47 PM
I tried to refer to the DP example design based on KCU105 and I changed the FPGA part number to another Kintex devices. I need to upgrade the IP as well due to part changing and the Freq_Hz property cannot be changed for the custom IP vid_edid and video_frame_crc block. Then, I faced the same issue again. The Freq_Hz property for custom IP (vid_edid and video_frame_crc) is become read only once the IP is upgraded.
I understand that the vid_edid and video_frame_crc block is just a helper core in DP example design. However, I would like to reuse the helper cores to start and do some testing. I do not have the evaluation kit and hence I cannot try out the design.
The reason I would like to do porting is because if I started from scratch, I am not able to include these two helper cores(vid_edid and video_frame_crc) into my design. Any recommendation whereby I can reuse these two helper cores in my design? Is it possible Porting method or exporting the custom IP?
I saw the recommendation to reuse the helper cores is start from example design, but I still not able to figure out any solution on how to do that when fpga part number is different
11-30-2020 12:35 AM
I has been searching and trying different ways but I couldn't find a way to reuse the vid_edid and video_frame_crc helper cores provided in Xilinx's example design.
I tried to copy the helper cores design file and create custom IP from that. However, facing some issue when try to package it to IP. I would like to do some quick test so it will be best if I can reuse the helper cores without going to code the the same modules like helper core.
I am still new Vivado. May I know if is it possible to reuse the helper core to my own design from the DP example design?
Any suggestion or help is much appreciated.
12-14-2020 06:54 AM
The helper cores are supported only in the example designs. This is the reason why they are not available in the IP catalogue.
The expectation is that the users will write their own cores for the functionality.
With that said I would expect that you would be able to move to change the device.
I assume after changing the target, you upgraded the IPs?
Did you read the warnings?
If you have the same warnings I got, then you have a clock not connected in the design (and some clocks removed). This is because the example design is using board properties which are not available when you select only a device (as there is no board).
So you might need to make sure you understand the warnings and manage the design accordingly.
To fix the clock issue, you will probably need to remove the differential clock input (connected to the clocking wizard) and create a new one not associated to the board
12-15-2020 06:19 AM
Thank you for the information and help.
The issue I encountered was like the link shared by Watari. However, the suggestion on the link cannot resolve the issue due to the FREQ_HZ property is being locked when upgrade the video edid helper core due to changing to FPGA part number. Unlike usual IP, the helper cores property is locked and it is not able to be changed. Hence, Vivado will complain the FREQ_HZ is not match.
12-23-2020 07:33 AM
One thing I do not understand is why you are not just using the same clock as in the example. The clock driving these IP are generated by a clocking wizard so you can just set the output clock to 300MHz (if starting from VCU118 exdes).
Also I just tried to change the clock generated from the clocking wizard on the design I have migrated from the VCU118 and the FREQ_HZ property is correctly updated
so my guess is that you have something not set correctly in your design
12-24-2020 11:03 PM
I tried to use the same clock as stated in the example design. However, the issue arise was the FREQ_HZ in block interface properties of the helper core is locked to 100MHz (as shown below) and the clock wizard clock is set to 300MHz. The mismatch causes error while validating the bd design.
By default, the clock properties information should be automatically pass from the master to slave (example from clock wizard to helper cores). However, once the example design is upgraded, this properties is locked in helper cores.
How I migrated the design from default part number used in example design was I am actually changing part number directly through project setting. With this, Vivado will prompt me to upgrade each of the IPs as well as the helper core. Once upgrade is completed, then the FREQ_Hz property is locked in helper cores but IP is fined.
Wonder if how you do the migration? because it seems like your FREQ_Hz property do not get locked by Vivado.
01-04-2021 01:51 AM
The way I did the migration: