Xilinx CIC+FIR compilers implementation problem

Question

Hi,
we have been facing a problem for the last 2 weeks and I can't find a rational explanation. I think we could use inputs from Xilinx developpers / Vivado users. Here is the deal:
I designed a down-sampling block made of the CIC compiler compensated with the FIR compiler.
I was able to simulate this block calling both the CIC/FIR block Out Of Context, and this worked exactly as expected.
The logic is very simple, I am simply mapping these blocks which are customized for our application, I am eventually casting data in between the two. I also have a little logic framing the data at the output.
Simulation time is over, now this is the first time I am packaging an IP based on other IPs.
I packaged the block calling the two .XCI files, you can see a screenshot of the IP hierarchy.
I think the design flow / packaging process works because in the Synthesized/Implemented design, I can see logics related to those filters I did not write.
The test consists in putting a signal into this block (sinusoid or constant value) and see what comes out.
The external clock runs ideally at 300MHz to simulate an A/D converter.
The 'working design' is an example showing that without the new CIC block, everything works as expected.
The green squares are the Chipscope probes and the main logic signals.
dds_tvalid, dds_tdata are latched in the external clock domain and that I can clearly see in Chipscope as you can see in the (working design) Chipscope output. PL/PS is my general purpose Linux interface and I can sample the DDS as expected in this configuration.
Now the new cic_design is put to the test and this design does not produce anything.
I am expecting a 12 times slower data_1_tvalid latching data out of the CIC block (R=12 is the decimation factor), and that I cannot see. dds_1_tlast is a framer of those dds_1_tvalid's (say 1024 frame, so this is 12*1024 times slower), that I cannot see either.
As I played with Chipscope triggers for hours (flashed this bistream many times), I once triggered on data_1_tvalid but that only happened once, when I reflashed it, nothing happened anymore.
So now I am very confused. The combined CIC/FIR IPs seem to be implemented. I can't explain why nothing comes out of this block. The logic after this new block should be slower and so less critical.
This problem got me stuck in my progress on the current project, I could really use some inputs guys!
I am expecting this block to work, the simulations matched our expectations perfectly (both MATLAB and VHDL heavily put this block to the test).

Answer 1

bwiec wrote:
Can you post a bigger shot of your block diagram? It's really blurry when I zoom in on it.
Yeah I know I can't seem to attach a .pdf file like the ones Vivado would generate. I took screenshots myself and updated my first post. Thank you for your answer.
Also, it's not clear if you're removing the FIR block from your custom IP while testing the CIC. Is this the case? Or are you testing both in cascade inside the custom IP?
You're right I didn't make that clear, I have now removed the FIR instance until I can get the CIC working (cf top_file.vhd).
Another thing I like to do with these types of issues is to pull up the implemented schematic and start checking if connectivity makes sense (i.e. no clocks/resets unexpectedly tied to gnd, output tvalid not tied to gnd, etc).
I have gone through the implementation/synthesis log files in detail.
No warnings on implementation. I get a lot of 'pin has no driver' when synthesizing, but my understanding is that those undriven pins are non-used features of the CIC compiler (significant signals like tvalid or tdata are not mentionned has not being driven).
So far I noticed one thing I was not expecting, dds_tvalid is tied to VCC. But that does not disturb anything since dds_tvalid is '1' on every rising edge of this clock domain. I will go through the implemented design in detail and keep you updated.