Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎05-13-2015

I/O Buffers removed during implementation but present at synthesis - XAPP524

I am interfacing to an A/D using xapp524 as an example. The A/D sends differential *DCO, *OUT1, *OUT2 and *Frame signals to the design (like the xapp524). After synthesis things are fine in that I see for example AD1_DCO_P, AD1_DCO_N, AD1_OUT1_P, AD1_OUT1_N, etc. I see that the pins are connected correctly and also appear correct in the schematic view.

However, after implementation, all the signals from the A/D disapper and the module which holds the A/D interface logic (same as xapp524) shows up with zero slice utilization. In the post-implementation schematic these pins i.e. the A/D interface pins are all sitting on the side and not going into the rest of the circuit.

I thought that if inputs are stuck or outputs dont drive anything, synthesis will take it out first before it goes to implementation.

The design like xapp524 uses locations for the BUFIO and BUFR and these are correct I think as there were errors when they were not correct. These locations are next to the AD_DCO clocks coming in.

So why does implementation remove the wires from the A/D pins going into the design? I hunted in the report/log files but nothing stood out.

Other comments - a) the xapp524 works fine ofcourse. b) desgin flow is as follows --

design_wrapper.v --> (a block diagram) --> micro + memory + custom_rtl.

custom_rtl --> module_a, module_b, module_c and atod_top.v instantiated.

atod_top.v has the xapp524 AdcTop.vhd in it.




0 Kudos
3 Replies
Registered: ‎01-23-2009

Have you simulated your design?

When Vivado removes a module it is because it thinks it is useless - nothing the module can do will make any difference to the observable system. This is generally due to some kind of a gross error.

  • The module is held in reset at all times
  • The output of the module doesn't drive anything
  • The receiver of the module is held in reset at all times
  • The outputs are gated with a controlling signal

Basically anything that prevents this module from having an effect on any primary output of the FPGA.

This kinds of gross coding errors are most easily found with simulation - it is often pretty easy to see when large portions of your design aren't doing what they are supposed to do. Debugging this problem using only synthesis logs is very difficult to do...


Registered: ‎05-13-2015



I thought that Vivado removes modules in synthesis for the reasons you describe above. However, in my case I see the output of synthesis is fine i.e. post-synth schemactics and post-synth utilization look correct. It is implementation that takes it out i.e. post-implementation schematic shows the A/D pins disconnected and sitting on the side and post-implementation utilization shows A/D using zero slices.

I did simulate the original xapp524 using the testbench that came with it. At that time I did not see any data coming out of the memory. However, did not want to debug the xapp524. In my case I am using it on an Artix and yes, if I build my A/D_module_top.v it will synthesize and implement and produce a bit file. But when I put it in a my_top.v file which has other code and then put the my_top.v in a block diagram with a micro and mig, it disappears.

So the question remains - can Vivado tell me why things got lost in implementation and if so where should I look. The other question is "is xapp524 known to work?

Appreciate any help on this.

0 Kudos
Registered: ‎11-08-2018

don't mean to derail the original post.

I am seeing similar issue. Please see the attached picture from synthesis and implementation. Vivado removes the high speed I/O ip all together, even though in my RTL code the output from the IP is being fed to BRAM FIFO structure.

I just opened a case. Let me know if you need my testcase project archive to duplicate the behavior.

0 Kudos