AXI arvalid signal issue

Status
Not open for further replies.
No, there was no mistake - the idea was that when the last address in a bust is sent AND accepted by the slave, arvalid should return to 0.
Start_of_burst and end_of_burst do not need to have a relation to AXI signals. That are just meant to represent external stimulus to initiate/complete an axi transfer.
 
Last edited:
when the last address in a bust is sent AND accepted by the slave, arvalid should return to 0.
Click to expand...

However, in my other AXI master (address_generator.v), o_axi_araddr could be of different, unique addresses instead of increment by ONE.
I do not think I could use burst addressing for my other AXI master.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

wire transaction_is_accepted = (o_axi_arvalid) && (i_axi_arready);
 
always @(posedge clk)
begin
    if(reset) o_axi_araddr <= 0;
 
    else o_axi_araddr <= idx_n + idx_r + idx_k; // the DDR address to read data from
end
 
// used for generating address (o_axi_araddr) indexes
reg [C_AXI_ADDR_WIDTH-1:0] idx_n;
reg [C_AXI_ADDR_WIDTH-1:0] idx_r;
reg [C_AXI_ADDR_WIDTH-1:0] idx_k;
 
// no multiply in actual synthesized hardware since 'N', 'n', 'Tn' and TILE_LENGTH are constants
always @(posedge clk)
begin
    if(reset) idx_n <= n * TILE_LENGTH * TILE_LENGTH; 
 
    else if ((idx_n < (N * TILE_LENGTH * TILE_LENGTH)) && transaction_is_accepted)
                idx_n <= idx_n + Tn * TILE_LENGTH * TILE_LENGTH; 
end
 
// no multiply in actual synthesized hardware since 'r', 'MAX_J' and 'TILE_LENGTH' are constants
always @(posedge clk)
begin
    if(reset) idx_r <= r * TILE_LENGTH;
 
    else if((idx_r < ((r + MAX_J) * TILE_LENGTH)) && transaction_is_accepted) 
                idx_r <= idx_r + TILE_LENGTH;
end
 
 
always @(posedge clk)
begin
    if(reset) idx_k <= c;
 
    else if((idx_k < (c + MAX_K)) && transaction_is_accepted) 
                idx_k <= idx_k + 1;
end
 

Pending transactions means you can send multiple transactions not expecting the return reads to show up before the next transaction is completed. This can also result in out of order transactions, where a long transaction (for a flash device) is started but another transaction to read a register is completed before the data for the 1st read to the flash has even started. Most designs I've seen don't support this and will only handle single transactions.

The original code from Tricky was correct, where end_of_burst would have ARVALID as part of the gating. Therefore (ARVALID and ARREADY) = '1' is correct as that signals the end of an address transaction. The other AXI signal would be the AxLEN which tells you how long the transfer is, you have to keep track of the running count of the beats in the transfer.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12

// ignoring the always stuff
// this is slave code that does INCR burst operations.
if (ARVALID && ARREADY)  // ARADDR has an address to be read from, so grab it
  my_addr <= ARADDR;
else if (RVALID && RREADY)  // data @my_addr is being returned by the slave, so my_addr can be updated
  my_addr <= my_addr + 1;
end if;
 
// this is master code that generates addresses in a sequential pattern (non-burst)
if (ARVALID && ARREADY)  // ARADDR increments every time the address was accepted by the slave
  ARADDR <= ARADDR + 1;
end if;


Half the time I can't tell if you are showing master or slave code.
 
@ADS-ee out of order transactions are only supported in axi 3. In axi4 all transactions must be in order. Hence why in axi4 wdata has no wid signal as this is taken from awid
 
TrickyDicky said:
@ADS-ee out of order transactions are only supported in axi 3. In axi4 all transactions must be in order. Hence why in axi4 wdata has no wid signal as this is taken from awid
Click to expand...
Thanks Tricky forgot they changed that between AXI3 & AXI4, haven't had to write code for either interface for over 2 years, been stuck using APB and AHB.
 

@ads-ee : Why would AXI slave need to update my_addr ? I thought it is AXI master duty to update address ?
 

i think the "my_addr" is for designs that have arlen > 1.
Click to expand...

Wait, I do not understand how "my_addr" is needed in the context of arlen > 1
 

For slaves that support arlen >1 i.e. bursts, the slave must perform address increments, the master only sends the start address of a burst.

If you make the master do single transfers you lose a lot of the benefit of using AXI4 (non-Lite), which gives you burst capability improving the overall transfer rate and reducing the overhead. If all you need is single transfers and the master will update all the addresses then you might as well only use AXI4-Lite as it is simpler to implement.
 

@ads-ee , @vGoodtimes : My AXI code seems to have satisfied **broken link removed** after heeding advice from you guys, but why it still fail in AXI Protocol Checker IP ?

Bit 59 : AXI_ERRS_RID
Bit 78 : AXI_AUXM_RCAM_OVERFLOW

Note: I have two AXI masters, one of them could have made use of burst capability, the other could not though.
 

you seem to have ignored the advice and re-asked the same question. at least I see the same errors as before.

you seem to have ignored advice to make each module work independently. I think you are looking for quickfixes and ignoring anything that isn't a 1-line fix.

the ip checker fails for the same reason it failed before. but I don't think the checker can catch all of the axi errors you have.
 

I think I also found another error with my skid buffer implementation. It should not just buffer RDATA, but also RVALID.

make each module work independently <-- as in including the skid buffer inside AXI slave module ?

Note: AXI Protocol Checker IP cannot verify AXI transaction using master or slave alone.
 

you should try to make a tb that aggressively tests each axi module. not something nice. look at each module and try to break it -- while being axi complient. this means stuff like toggling ready at random. always holding valid at 1. etc... but not things that break the axi spec like toggling valid from 1 to 0 when ready is/was 0.
 

but not things that break the axi spec like toggling valid from 1 to 0 when ready is/was 0.
Click to expand...

The above issue had been solved using the following code segment for AXI slave : 

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

always @(posedge clk)
begin
    if(reset) o_axi_rvalid <= 0;
 
    // AXI specification: A3.3.1 Dependencies between channel handshake signal
    // the VALID signal of the AXI interface sending information must not be dependent on 
    // the READY signal of the AXI interface receiving that information
    // this is to prevent deadlock 
    // since AXI slave could wait for i_axi_arvalid to be true before setting o_axi_arready true.
    // Note: For same interface, VALID cannot depend upon READY, but READY can depends upon VALID
    // Note: Once VALID is asserted, it MUST be kept asserted until READY is asserted.
    //       VALID signal needs to be set (initially) independent of READY signal, 
    //       and then only ever adjusted if !(VALID && !READY)
    // Note: the slave must not wait for the master to assert RREADY before asserting RVALID
    // Note: (!(o_axi_rvalid && !i_axi_rready)) == (!rvalid || rready) 
    //       == (!rvalid || (rvalid && rready)). 
    //       it means "no transaction in progress or transaction accepted"
    // Note: the slave must wait for both ARVALID and ARREADY to be asserted before 
    //       it asserts RVALID to indicate that valid data is available
    else if(!(o_axi_rvalid && !i_axi_rready))
            o_axi_rvalid <= i_axi_arvalid && o_axi_arready; 
end


And just for information, AXI Protocol Checker IP raised the errors for both AXI interfaces even when RREADY and ARREADY signals are asserted high (free-flow AXI bus without any barriers)
In other words, the AXI code is not AXI-compliant in the simplest test scenario.

 
Last edited:

// Note: the slave must wait for both ARVALID and ARREADY to be asserted before
// it asserts RVALID to indicate that valid data is available
else if(!(o_axi_rvalid && !i_axi_rready))
Click to expand...
Your implementation of an AXI slave may behave this way but this is not part of the AXI specification. You should avoid ambiguities in your comments that mix specification and specific implementation details. Something as simple as AXI-2.3.2.1: <some spec info> and the rest of the comment is better than Note: <some spec info>.

Both ARVALID and ARREADY asserted only indicate that ARADDR has been accepted by the slave and the master no longer needs to hold ARADDR constant and can start another address channel cycle furthermore there is nothing in the spec that requires the slave to assert RVALID once that has occurred (the comment is really about how this slave is always single cycle access, i.e. 1st cycle address, 2nd cycle is read data).
 

MAXRBURSTS is 64 , but AXI Protocol Checker IP gave errors in the first 5 clock cycles ....
 

what did the sim waveforms look like for the first five cycles?

- - - Updated - - -

ads-ee said:
...there is nothing in the spec that requires the slave to assert RVALID once that has occurred...
Click to expand...

I agree with your comment but this part might be confusing. I think axi does require the slave to eventually assert rvalid after the arvalid&&arready occurence. maybe not 1 cycle later, maybe not 2, but eventually.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…