08-01-2014 03:18 PM
In Vivado 2014.2 the AXI4 stream broadcaster seems to have a tdata width on the output that is twice what it should be. Is this correct or is it a bug?
08-03-2014 11:32 AM
03-02-2015 06:05 PM
Same problem. All of the output ports are twice the width that they should be. I've tried leaving the settings on 'auto' and then hooking up the ports but they don't change. This is version 1.1 of the IP and I'm using Vivado 2014.2
04-14-2015 06:23 PM
I'm getting something similar. Perhaps I've missed something but I can't see how this block is even supposed to work at all?
It's not just the outputs (m_axis drivers) that are doubled, it's the input too for m_axis_tready. However the doubling on this tready signal (only) is accounted for inside the block - looking at the synthesis, the two m_axis tready signals are AND'ed together and used to drive the s_axis tready. In other words the broadcaster block only signals upstream that's it's ready when all of it's children are ready, this part makes perfect sense.
But the tlast, tuser etc. are different. Each of these signals comes in from s_axis as a single signal input. The outputs to m_axis however are vectors, the doubling mentioned, and I suspect is actually one bit per output m_axis port. But: each s_axis signal is just wired straight to the first bit (only) of the m_axis output, meaning that it connects to the first child m_axis block only! See the blue highlighted signals in the screenshot attached. The other bits in the vector are just optimised away and tied low, so nothing works.
Can someone from Xilinx please step in and confirm how exactly this block is supposed to be used, perhaps an example or testbench? The docs for this (in the AXI stream suite) or the similar AXI Video Broadcaster don't have any detail of what is supposed to happen with all these signals.
08-04-2015 07:19 AM
08-10-2015 11:01 AM
04-10-2017 03:14 AM
Year and no answer... So Axi-Broadcaster is just "AND" for tready signal and thats all?
No, it's not just that. The TVALIDs for each master also need to be adjusted. So its:
1) S_READY = M_READY_1 & M_READY_2
2) M_VALID_1 = S_VALID & M_READY_2
3) M_VALID_2 = S_VALID & M_READY_1
This deals with the case where one master is valid and the other isn't. Without #2 and #3 included, the valid master will see an asserted valid and an asserted ready, so it'll think it's a valid databeat. But it isn't, because the other master isn't ready. So it's necessary to drive the valid low when the opposite master isn't ready to deal with this case.
10-12-2018 08:19 AM
I have ran into slightly different issues regarding data width from the broadcaster. The simplest solution for me was to set the data width manually instead of relying on the 'auto' data width which uses parameter propagation to update the widths.
And my specific issue will also occur in 2018.3.