Enhacement: Sync only on TLAST option for axis2mm

[zipcpu]

Enhacement: Sync only on TLAST option for axis2mm

[ZipCPU]

I'm ... not sure I follow. You currently have a design that works "not on the first capture or the first capture after an abort and clearing on an error." What logic would you have me write that would fix this? Would you have me throw away the first packet?

I do have some solutions which are designed to address the data loss problem you are having by using an ABORT signal to reset all partial packet data downstream to the last packet boundary. Since that would be off topic here, we can discuss these other approaches off forum if you would like.

[baileyji]

Hmm, looking at the verilog I'm wondering if simply making the core reset r_tlast_syncd either 1 or 0 depending on a user parameter would solve this. Then I could control if the core assumes it is synced after a soft reset. I suspect the relevant code that would use the parameter would be around line 1112:
initial r_tlast_syncd = 1; or maybe r_tlast_syncd <= 1; a few lines later

[baileyji]

Did that clarification make any sense? I'm actually now pulling my hair out unable to get my axis stream synced up properly and am not sure why. I need to take a step back and be more systematic, at present I'm still hesitant to point at the RTL and say there is a bug, but I'm certain that I've placed the core in situations that it should have lost sync and I've never seen the !synced bit go high, which does have my slightly concerned there may be something going on internally as well.

[baileyji]

Here is a specific example:

• A 32 byte wide stream with tlast asserted ever 256 beats that is valid every beat
• Stream is passed to axis2mm via a switch that allows me to disable the stream.
• axis2mm configured with OPT_TLAST_SYNC
• Stream is configured such non-zero bytes fall in a specific pattern e.g. the first two byes after a tlast are nonzero, rest are zero
• Configure core to capture (incremental, continuous=False) n_bytes where n_bytes = n32256
• Capture completes w/o err

The first non-zero bytes appear with a random offset from the starting memory address but < 32*256. What I'm inferring from this is that the core gets r_busy set with the stream at a random phase, assumes it is synced, and captures the requested bytes. The relative spacing is correct within a capture.

I've not been able to fix this by playing with gating the stream (thereby dropping TVALID), the abort key, or anything else raising this issue. I'm not sure why I thought I'd sorted it out then and now the workaround I though I had isn't. It is possible that I didn't actually have a working workaround.

[ZipCPU]

How are you setting the reset? Is it a system wide reset, like it is supposed to be, or are you pulling S_AXI_ARESETN low at other times?

[baileyji]

This particular portion of the design doesn't have a reset, so its tied off. I'm slowly breaking down the behavior I'm seeing and so far that is shifting some of my focus away from this core. I've identified an issue with a stream switch prior to a width converter creating a half beat misalignment and until I get that sorted I can't be certain what, if anything, I'm seeing with this core.

[ZipCPU]

Something you might try: Replace TDATA with a counter that gets reset following TLAST. That should help to make it clearer what is (and isn't) working.

[baileyji]

That's nearly exactly what I'm doing, though it resets some multiple of TLAST. Between my source and the axis2mm core I've got a custom stream filter that will drop an arbitrary (but even number), user specified selection of of beats in each packet, a stream switch, and width doubler going from 32-64 byte streams. Part of my problem was that (silly of me) forgot that switching the xilinx axis switch might cause a switch from an odd aligned stream to an even aligned stream at the width converter throwing everything off.
I'm trying to roll my own in HLS and am very close, but am running into a c vs rtl sim mismatch.

[baileyji]

Looks like this was an upstream issue with an axis data width converter on my end.

[ZipCPU]

I'm excited to hear from you that it is now working!