Dynamic (run-time configurable) AXI Data Width Converter?

[helmutforren]

I'm using Vivado 2018.1

The doc in PG059 is not too explicit about the AXI Data Width Converter.  Just now, I tried adding this IP to a project and running customize IP.

• Is it true that you can only build a bitstream with AXI Data Width Converter, where such converter is FIXED in incoming and outgoing data width? 
• Is it true that you can NOT cause the output width to be configurable via TKEEP?  (Specifically, this would require TKEEP to be an *input* to the master output.  But TKEEP is an *output* from the master output.)

I need to have 16 bytes fixed width coming in, but a variable 1 to 10 bytes coming out.  I need to configure this in real time.  Once running, the 16 bytes coming in will get funneled through the select number of bytes coming out.  As I see things, I think I must write a little custom code to do this.  Based on prior experience, I think this will be almost trivial.  (Note that I don't know yet if the input is going to have TKEEP or not.  If it does, it will not be a randomly changing value of TKEEP.  Instead, it will only have TKEEP bits zero whenever tlast comes along and there's not enough data to fill up the whole incoming 16 bytes coming in.  This should be very straightforward to handle in System Verilog that I use.)

(I realize the TKEEP question gets confusing.  Consider my case where I need 3 bytes coming out.  Further downstream, there might be a TKEEP=10'b0000000111.  However, I don't think there's a way to tell the AXI Data Width Converter to forceable send out this value on the master TKEEP output.  This would require some auxiliary control input that I don't see on the IP.  This is NOT about translating the slave input's TKEEP to the master output's TKEEP.  In my case, for the most part, the slave input's TKEEP would be all 1's, except for when TLAST occurs.  During this time of slave inputs' TKEEP being all 1's, I would still need the master output's TKEEP to be 10'b0000000111, and exactly that.  Yes, I could hard code the output to 3 bytes width.  But then a few minutes later I may need to real-time-configure it to 1.  Or 10.  Or...

[demarco · Accepted solution]

Hi @helmutforren,

I think you are looking at the wrong product guide. It sounds like you are working with AXI4-Stream interfaces. You should refer to PG035. PG059 is for AXI Memory Mapped interfaces.

https://www.xilinx.com/support/documentation/ip_documentation/axis_interconnect/v1_1/pg035_axis_interconnect.pdf

The IP description is that the data width converter allows the expansion of the AXI4-Stream TDATA width by aggregating multiple transfers into one transfer or allows reduction of the AXI4-Stream TDATA width by splitting a transfer into multiple transfers of smaller TDATA width. It is assumed that the data widths of the master and the slave are fixed, so there's no concept of run time reconfiguration. 

I'm not clear how your AXI4-Stream slave changes itself to only have a 1-10 byte interface. Do you have a 10 byte master interface that you then use TKEEP to indicate which bytes are valid?

There is a longer discussion to TKEEP handling in UG1037. Please take a look at this and see if this helps explain what happens. Xilinx IP typically only allows sparse TKEEP to indicate trailing bytes on a packet.

https://www.xilinx.com/support/documentation/ip_documentation/axi_ref_guide/latest/ug1037-vivado-axi-reference-guide.pdf#page=90

Regards,

Deanna

[helmutforren]

Thanks, @demarco .  My destination does have a 10 byte interface, of which a configurable number must be LS-justified within there.  It could use TKEEP to confirm, but since it can't force its TKEEP input, it's not going to use TKEEP.  Instead, it needs to tell the width converter what width it desires today.  I'll just have to hard code it myself, which should be pretty straight forward.  (Actually, it *will* use TKEEP for exactly the trailing bytes on a packet.  But within a large packet, it won't need TKEEP.  I want to talk in circles now about TKEEP, but I won't.  If my destination tells my custom width converter how wide it wants to receive, then it ought to get what it asks for.  It's too complicated to subsequently make my destination work properly whenever the TKEEP doesn't match.  I could throw an error, however.  Anyway, I'll just have to code it myself.)

Thanks also for the PG/UG references.