Random backpressure on ready/valid

[davekeeshan]

Is it possible to introduce some randomised backpressure or disabling the ready and/or valid (depending which side of the link you are diving) mid AXI transaction?

I was using an AXI stream from a xilinx aurora IP and it would interrupt a stream every so often to do some maintenance on the link, this presented it self on the interface of at ready disappearing for a few clock cycles before being re-enabled. As I didn't know when this would happen in the real world application I had to create an interface that was disabling the ready all over the place, to try and hit some interesting edge conditions, usually within one or 2 clock cycles of the start or the end.

I would also like to see something like this for AXI burst mode, both as a master or as a slave (ready/valid respectively).

So a noisy ready/valid mode would be really handy!

[alexforencich]

Yes, all of the internal streams can be paused independently. Currently, you can either set the "pause" parameter however you like during simulation, or you can attach generators that will be advanced every clock cycle.

See (for AXI): https://github.com/alexforencich/cocotbext-axi/blob/master/tests/axi/test_axi.py#L56-L70

See (for AXI stream): https://github.com/alexforencich/cocotbext-axi/blob/master/tests/axis/test_axis.py#L54-L60

Now, in most of the tests I have done I usually test with a 1/4 duty cycle for pausing, but something random might be a better idea. I think some other cocotb components might use generators in a slightly different way, where the generator yields tuples of (on time, off time). This method may be a bit more efficient in terms of simulation time. Now that I think about it, it probably would not be difficult to support both methods - if the generator yields tuple, handle it as (on time, off time); if it yields a single value, set the pause state based on the value and wait for the next clock edge.

[tns-waymont]

Might it be possible to add support for async generators? For example:

async def generator():
    while True:
        yield random.random() < 0.5

[davekeeshan]

@alexforencich

Yes this is exactly what I was looking for. I am not up on my generators as much as I should be, I personally would like a continuous supplied random signal, not on a cycle, I'll investigate how to do that when I have time. However I was able to get a sequence I was happy with by using this function instead:

def cycle_pause(seednum=7, frequency=5):
    seed(seednum)
    length = randint(0, 0xfff)
    array = []
    for i in range(length):
        x = randint(0, frequency)
        if 0 == x:
            array.append(1)
        else:
            array.append(0)
    return itertools.cycle(array)

The length of the cycle ~0x7ff, was enough to run over the short length of most transactions.

Based on this I found 3 corner cases in my code, all clustered around the start and end of transactions (based on my past experience this is always where the problems are)

I think you should add in something into the code. My work in this area was actually spurred on by the issue I suggested you close that was querying VIP. I think it is important that these simulated interfaces into RTL don't always act like perfect AXI, they should be able to act as just barely legally satisfying the protocol as much as possible to stress the unit under test.

Now because I was messing with the cycle_pause, I think I found a corner case where clear_pause_generator() doesn't work.

So I have a setup where I enables the pause generator by default, but I have one test where I was to disable it (after being enabled). I was finding, because my sequence was random, sometimes it hangs. I think this actually comes down to clearing the pause, while it has been set to pause on the first clock cycle, so instead of your cycle_pause, imagine it used this instead:

def cycle_pause():
    return itertools.cycle([0, 1, 1, 1])

The very first cycle has been set as a pause. I think when you are clearing the pause, the state isn't cleared, so the interfaces stay in perpetual pause.

I think I will try and fix this in the code and raise a PR, but I wanted to capture it here.

[alexforencich]

Yeah, I'm definitely thinking about ways of injecting more non-idealities. For example, read data interleaving in the AXI slave is something that I'm planning on adding at some point - specify a reorder depth, and it will round-robin all of the active operations. Things like rate-limiting and latency emulation would also be good to implement, but I'm currently not sure exactly the best method for implementing that at the moment.

Also, you can set the "pause" attribute yourself with whatever routine you like. Unfortunately, cocotb doesn't currently support creating new signals within cocotb itself, so using an attribute or a generator is probably the best we're going to be able to do for the time being. Open to other ideas you might have, though.