AXI arvalid signal issue

Status
Not open for further replies.
So if you provided an address that ended with 0x0F, then only 1 byte in WDATA can be valid.
Click to expand...

I suppose AW (address) channel is independent of WDATA ?
 

As I understand it, in AXI4 all channels are supposed to be independent because of the individual handshake mechanism.

I did not find the info in AMBA spec which says the AW and W channels should be driven at the same time, neither does it explicitely say
that first AW channel has to be driven followed by the W channels.
But I have seen many slave models where if the the master does not drive the AW and W channels at the same time proper transaction does not occur.

Whatever you do it is the job of the slave to properly latch the AW and W and give back a proper R.
 

If you provide an address that is not perfectly word aligned, you then need to set WSTRB to provide correct byte alignment.
Click to expand...

I suppose that WSTRB is only used in W* channel , not in AW* channel ?
 

I suppose AW (address) channel is independent of WDATA ?
Click to expand...

They are always independent channels. But the entire write transaction are never independent. A write transaction consists of an AWADDR transfer, a WDATA transfer (from the start of the transfer until wlast) and BRESP transfer. They do NOT have to occur at the same time. They can be separated in time by unlimited number of clock cycles. But they are treated like a FIFO, so the first AWADDR corresponds to the first WDATA and BRESP etc.

promach said:
Why for an address that ended with 0x0F, then only 1 byte in WDATA can be valid ?
Click to expand...

Because alll addresses are byte addresses. Wdata is transfered in words. Each transfer is WORD aligned, not byte aligned. So the start of the wdata transaction is the byte address corresponding to the fist WORD of the transfer, not byte. So if you specify a start address of 0x0F, then the byte address of the first byte in the 16 byte word is 0x00, and hence the first 15 bytes MUST NOT BE VALID, otherwise it doesnt match the first address specified.
 
I suppose that WSTRB is only used in W* channel , not in AW* channel ?
Click to expand...
Why are you supposing, see what is written in the AMBA spec.

Sorry to say, when a thread runs this long and you ask such a question, intuition tell me you are not reading the spec.
This is one of the very very basic things and is found in the initial pages of the spec under 'Signal Descriptions'.
 

The OP appears to have the spec, but seems to be reading it piecemeal instead of reading the whole thing through.
 

@dpaul, axi defines additional requirements for the relationship between aw/w/b in order to prevent deadlock in common cases. the main point is that the destination has the option of waiting for both aw/w valid and can ack them in any order. axi4 adds that aw and wlast must be acked before asserting bvalid. the remaining deadlock is if the destination waits on bready before asserting wready/awready.

@promach
I think in this context, the w/aw channel information (wdata/awaddr) are not independent. eg, awaddr (and awsize/awlen) determine wdata and wstrb and wlast.
 
awaddr (and awsize/awlen) determine wdata and wstrb and wlast.
Click to expand...

YES !

I am trying to put the relationship between the above variables in actual coding.

awlen is enough to determine wstrb. So, why is awsize in the equation as you suggested ?
 

AWLEN has nothing to do with WSTRB.
AWLEN = number of words in the transfer. AWSIZE is the width of each transfer word. This tells you how many WDATA words occur before WLAST.
AWADDR determines the start, and hence WSTRB is calculated from this.
 

doesn't awlen affect wstrb for the wlast transfer. I don't think I've ever wrote logic for unaligned transfers so maybe it doesn't, but it seems like it should.
 

AWLEN = number of words in the burst
AWSIZE = Size of each word in the burst
AWADDR = byte address of the start of the burst (so wstrb needs to be set correctly on the first word)

WSTB can be set to whatever you want it to on a word/word basis, but must align correctly for the first word in the burst.

To make life easiest, you can just have AWADDR always word aligned, and then set wstrb to what you need for the first word.
 
I wish to, but AWADDR cannot be set to be word-aligned for my code application.

I do not think WSTRB depends on AWSIZE, am I right ?
 

I do not have any more AXI violations since pc_status bits are all cleared as shown in the following simulation waveform.

Now, I am left with the issue where AWREADY from AXI slave is kept low for a very long time, this is due to the fact that AWREADY is computed based on WVALID from AXI master.

Any comments ?

 

Looks more like wlast has not been sent by the master, so the write data burst isnt completed.
 
My AXI burst write transactions had zero AXI protocol violations.

However, during my data loopback test, Xilinx AXI BRAM IP slave returns me unknown RDATA highlighted in red colour in the simulation waveform for AXI burst read transaction after time=235ns

Any idea why ?

 

See AWADDR at t=60ns and WLAST at t=210ns

also ARADDR at t=235ns

do you guys notice anything wrong with the AXI waveform before t=235ns ?

BRESP also returns 0 which is okay at t=220ns
 

Xilinx AXI BRAM IP slave returns me unknown RDATA highlighted in red colour in the simulation waveform for AXI burst read
Click to expand...
So you must investigate the slave IP side.

Questions to be asked for investigation:
Is there valid data for the slave address you are reading?
Are you reading from a valid address at all?
 

changing ARADDR to 1 also does not work, I suspect the data is not actually written, but we have BVALID asserted and BRESP is ok

Something is very very very wrong.
 

This is your investigation as you have the environment set with the slave instantiated.

changing ARADDR to 1 also does not work, I suspect the data is not actually written, but we have BVALID asserted and BRESP is ok
Can you not add-to-wave and investiage the slave internal signals? See if your data is getting latched after the address and write-data handshakes.
All I can say is that Xilinx AXI based cores might have bugs (they don't perform formal verification of their AXI based cores).

On another note, if there is an AXI Interconnect b/w the master and slave, then you might want to investigate the interface signals there.
 
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…