Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

AXI arvalid signal issue

Status
Not open for further replies.
Does AXI protocol require data packet re-transmission in the case of error arising from receiver/destination side ?
 

What do you mean by error? AXI itself is only a pipe, it doesnt care about what is carried over it. Retransmission might be a master requirement, but has nothing to do with AXI.
 
I have updated the code to use Xilinx own AXI slave in order to minimize the location of bug finding.

just uncomment `define XILINX 1 in load_data_from_bram.v

VlvnoLT.png
 

is this a question or a request for help/comment?

I didn't read the entire thing. I did notice "o_axi_wvalid && o_axi_awvalid" appears in an expression and both are outputs. this is not specifically an error, but likely is one. normally, this would be a small fsm -- NOT_WAITING, WAITING_FOR_BOTH, WAITING_FOR_AW, WAITING_FOR_W. the intent is to not make any assumptions about either ready signal. I'm guessing if it works in your design it is because there is an assumption that ready will be true for both channels.
 
"o_axi_wvalid && o_axi_awvalid" appears in an expression and both are outputs. this is not specifically an error, but likely is one.
Click to expand...

I do not quite understand your explanation on the intent is to not make any assumptions about either ready signal with the following code snippet ?

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

reg [$clog2(MAX_BURST_LENGTH)-1:0] num_of_write_transactions;
 
always @(posedge clk) 
begin   
    if(reset) num_of_write_transactions <= 0;
 
    else if(o_axi_wvalid && o_axi_awvalid)
            num_of_write_transactions <= (o_axi_wlast) ? 1 : num_of_write_transactions + 1;
end


- - - Updated - - -

Or are you suggesting that there are bugs in the following logic for WVALID and AWVALID ?

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
41

reg [$clog2(MAX_BURST_LENGTH)-1:0] num_of_write_data_sent;
 
always @(posedge clk) 
begin
    if(reset) 
    begin 
        o_axi_wvalid <= 0;
        num_of_write_data_sent <= 0;
    end
 
    else if(!(o_axi_wvalid && !i_axi_wready))
    begin
        o_axi_wvalid <= (o_axi_wlast && write_response_is_ok) ? 
                        0 : (num_of_write_data_sent < o_axi_awlen);
 
        if(write_response_is_ok) num_of_write_data_sent <= num_of_write_data_sent + 1;
    end
end
 
wire ddr_write_address_range_is_valid = (o_axi_awaddr < (1 << C_AXI_ADDR_WIDTH));
 
always @(posedge clk) 
begin   
    if(reset) o_axi_awvalid <= 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_awvalid to be true before setting o_axi_awready 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 master must not wait for the slave to assert AWREADY before asserting AWVALID
    // Note: (!(o_axi_awvalid && !i_axi_awready)) == (!awvalid || awready) 
    //       == (!awvalid || (awvalid && awready)). 
    //       it means "no transaction in progress or transaction accepted"
    else if(!(o_axi_awvalid && !i_axi_awready))
            o_axi_awvalid <= /*i_axi_awready &&*/ (ddr_write_address_range_is_valid);
end


I am still debugging the following waveform

RbHOQHB.png
 
Last edited:

Code: 
// convenient common subexpressions
assign w_accept = (w_valid && w_ready);
assign aw_accept = (aw_valid && aw_ready);

// next-value logic also useful for use in the ready logic
// can be written in other ways to make it more clear.
// w_accept && !aw_block is the same as w_accept && !aww_accept effectively.
//                     (retain               set          )    reset
assign next_w_block <= (w_block || (w_accept && !aw_block)) && !aw_accept;
assign next_aw_block <= (aw_block || (aw_accept && !w_block)) && !w_accept;

always @(posedge clk) begin
  // boilerplate assigns for the 2-process style logic.
  w_block <= next_w_block;
  aw_block <= next_aw_block;
  
  // these have to be registered by axi spec.  
  // realistically, probably becomes something really simple or really complex.
  // can be moved to another always block that uses next_w_block/next_aw_block.
  w_ready <= !next_w_block && logic_for_w_ready;
  aw_ready <= !next_aw_block && logic_for_aw_ready;

  // reset
  if (rst) begin
    w_block <= 1'b0;
    aw_block <= 1'b0;
    w_ready <= 1'b0;
    aw_ready <= 1'b0;
  end
end

// true when both aw and w accepted.  "aww" sounds cute.  for the read channel,
// "arr" sounds like a pirate.  although it does mean there is w, aw, and aww
// prefixes, so typos could be an issue.
assign aww_accept = (w_accept && aw_accept) // both on same cycle
  || (w_accept && aw_block)  // w on this cycle, aw on some previous cycle
  || (w_block && aw_accept); // aw on this cycle, w on some previous cycle

// these can happen when the logic for the ready signals is not based on the block signals.
assert(!(w_block && w_accept)); // w accepted after blocking
assert(!(aw_block && aw_accept)); // aw accepted after blocking
assert(!(aw_block && w_block)); // invalid state.

This example is untested, but should be correct. in your code, what would happen if !wready && !awready? if wready and awready both remain low? the concern is that this triggers wvalid and awvalid to remain high. but the logic increments anyways.
 
@vGoodtimes You were writing code snippet for AXI slave in which I am using Xilinx own AXi slave IP, which means I have no control over AXI slave
 

ok, fair. this does change the commentary about the 2 process vs 1 process style. In anycase, you have "o_axi_wvalid && o_axi_awvalid" as a condition. but what happens if i_axi_wready and i_axi_awready are both low?
 

Are you saying that I need to synchronize or make both AW* and W* channels in sync ?
 

axi is a protocol that allows one to consider the correctness of a module based only on that module. When a module is used in only one design it can be tempting to bend the rules.

let's say you assert wvalid and awvalid. there are four cases for wready,awready. how does your design handle them?
 
Ok, I understand your concern about AWREADY and WREADY signals.

However, I am facing some X unknown for AXI protocol checker IP (pc_status)

dZLXON7.png
 

For this AXI master coding, how do I guarantee AW* payloads are sent first, followed by W* payloads without violating AXI protocol (a master must not wait for AWREADY to be asserted before driving WVALID) ?

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

always @(posedge clk) 
begin
    if(reset) 
    begin 
        o_axi_wvalid <= 0;
    end
 
    else if(!(o_axi_wvalid && !i_axi_wready))
    begin
        // Note that both o_axi_awsize , o_axi_awlen are of hardware constants, so no multiply hardware
        // since this is for testing, WDATA just uses some values up to the total size of the write address space
        // see [url]https://i.imgur.com/LBO9pQz.png[/url] in which AW* payloads are sent first, followed by W* payloads
        // Note: a master must not wait for AWREADY to be asserted before driving WVALID
        o_axi_wvalid <= (o_axi_wlast) ? 0 : 
                        (o_axi_wdata < (o_axi_awsize*o_axi_awlen)) && o_axi_awvalid; 
    end
end


LBO9pQz.png
 

Why do you need to guarantee that? thats the Slaves problem by assertion of awready and wready. The Master is allowed to send WDATA before AWADDR.
 
In the pc_status error bit location , is it bit #32 because in the following simulation waveform, BVALID is never asserted high during the time when pc_status error bit #32 is asserted ?

xoVlqJUe.png
 


The byte lanes are fixed at specific addresses so the lower order bits of the address must be consistent with the byte lane being accessed.
 
AWADDR is a byte address, which you have set to 3. Therefore wstrb should be 0x1FFF or 0xFFF8 depending on the byte ordering on your bus
 
Why if AWADDR is set to 3 , then WSTRB should be 0x1FFF or 0xFFF8 ???
 

I do not quite understand the following **broken link removed**

lrF6N9g.png
 

AWADDR = 0x03 is not word aligned. With a 128 bit WDATA interface the word address alignment increments in steps of 16. So AWADDR of 0x00, 0x10, 0x20 etc would be word aligned. If you provide an address that is not perfectly word aligned, you then need to set WSTRB to provide correct byte alignment. So if you provided an address that ended with 0x0F, then only 1 byte in WDATA can be valid.

- - - Updated - - -

The image you show is such that AWSIZE = 2 (transfers are 4 bytes per beat), but WDATA = 8 bytes. So when doing transfers only 4 bytes can be transfered per beat.
Usually, you would set AWSIZE to match WDATA width. In your case, AWSIZE should ideally be 4.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top