06-25-2015 04:57 AM
I have a task to edit design wich is assemled from several Ip cores. I have to edit one of them. It includes several source files and I have to replace one group of files with the other packaged IP core wich is also created from several IP cores(Microblaze, memory, etc..). I don't know if is it even possible to do something like this, but I already successful changed the contents of IP core, successful synthesised and packaged but when I try this IP core fit to top design the Vivado cannot see the "sub-IP cores" (icroblaze, debug module etc...)and add them to sources tree. All repositories are set and I also tried add all "sub-ip cores" wich are in IP core, to the project but still it cannot be associate. It's kind a tricky so I try to explain in other way:
Top design has several IP cores. Part of one of them must be replacet with a design wich is also IP core wich is created from other ip cores. I ask again is this even possible? If yes how can I sort it out? Thanks for any feebacks
06-25-2015 07:37 AM
07-14-2015 04:09 PM - edited 07-14-2015 05:04 PM
When packaging an IP that contains sub-IPs, you have the option to include .xci files or source files for sub IPs. Do you know which it is for you?
Are you using the same version of the tools in which it was originally designed?
If you are in a different version of the tools and you've included .xci files for sub-IP, then any sub-IPs that have been rev'd won't show up.
Another possibility if including .xci's is that the sub-IPs are generated for one device and the project where you instantiate the IP is targeting a different device.
I have been trying to do the same thing (for the first time) since the last couple of days without any results.
I clearly demonstrated the problem is this new IP being packaged - everything works as expected without it.
This IP is made of a CIC filter (Xilinx) and an FIR filter (Xilinx) put together, with some cast in between and I also have a counter at the output to generate a TLAST. It is clocked by an external clock at 300MHz (which works as expected).
The entire block has been simulated many times with XSIM, simulating and the results work as expected.
Here is my design flow:
CIC: entity work.cic_compiler_0 port map ( s_axis_data_tvalid => data_1_tvalid_i, s_axis_data_tready => data_1_tready_i, s_axis_data_tdata => data_1_tdata_i, m_axis_data_tvalid => cic_tvalid_s, m_axis_data_tdata=> cic_tdata_s, aclk => clk ); --- a few casts in between --- FIR: entity work.fir_compiler_0 port map ( aclk => clk, s_axis_data_tvalid => cic_tvalid_s, s_axis_data_tready => fir_tready_s, s_axis_data_tdata => cic_fix18_17_24b_s, m_axis_data_tvalid => fir_tvalid_s, m_axis_data_tdata => fir_tdata_48b_s );
This compiles but do not produce anything.
I know I have seen somewhere someone mentionning the 'blackbox' thing but I was not able to even get it implemented.
Could anyone provide the right steps to package something like that?
packaging the IP with the .xci technique, as prefered in QA60975 ends up in a critical warning at synthesis time - cic_compiler_0 is not recognized.
packaging the IP with the .xci and declaring them as blackboxes:
component fir_compiler_0 is port ( s_axis_data_tvalid: in std_logic; s_axis_data_tready: out std_logic; s_axis_data_tdata: in std_logic_vector(23 downto 0); m_axis_data_tvalid: out std_logic; m_axis_data_tdata: out std_logic_vector(47 downto 0); aclk: in std_logic ); end component; attribute black_box: string; attribute black_box of cic_compiler_0: component is "yes"; attribute black_box of fir_compiler_0: component is "yes";
ends up in a critical warning at implementation: could not resolve non primitive blackbox.
My best result so far is 'package source files' instead of 'package .xci', although the QA mentionned above says it may not copy all the IP source files. This may explain why I am not receiving valuable logic out of this block which is finally generated in this case.