cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tjrqlsdl11
Contributor
Contributor
1,110 Views
Registered: ‎10-15-2018

MIG do not assert axi_awready.

Jump to solution

Hello

I'm trying access PL memory with MIG.

The MIG is successfully calibrated, but it do not assert axi_awready.

I don't have any idea what is wrong.

Could you please give me any suggestion?

Thanks

 

 

 

mig.gif
0 Kudos
1 Solution

Accepted Solutions
tjrqlsdl11
Contributor
Contributor
691 Views
Registered: ‎10-15-2018

@calebd @dgisselq 

Thanks for reply.

I transferred a transaction after MIG calibration done. The reason I instantiated clock converter is that the operating clock of ECC I/F and AXI-MIG I/F are differ. 

After clearing the IP cache, it works without modification of design and testbench. I don't know what was wrong correctly though.

Thanks.

View solution in original post

0 Kudos
11 Replies
dpaul24
Scholar
Scholar
1,099 Views
Registered: ‎08-07-2014

@tjrqlsdl11,

Why is your awvalid looking like a short pulse?

the awvalid must be KEPT asserted until the address phase is over. Fix this first and then you might see the awready being asserted by the slave.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

0 Kudos
tjrqlsdl11
Contributor
Contributor
1,030 Views
Registered: ‎10-15-2018

@dpaul24 

Thanks pointing that

however, in another boards' design(I have two ZynqMP board), axi_awready asserted as soon as MIG is calibrated. 

I'm wondering if ddr4 memory model make this issue. (MIGs' configuration are different)

 

I will make axi_awvalid asserted and keep update.

mig2.GIF

0 Kudos
dgisselq
Scholar
Scholar
1,019 Views
Registered: ‎05-21-2015

@tjrqlsdl11,

I've now seen this "problem" a couple of times over on the forum.  In every case it was "solved" when the poster adjusted their design so that it complied with the AXI standard.

An AXI slave, such as the MIG, does not need to raise AWREADY until after AWVALID is asserted.  The specification recommends that the slave idle with AWREADY high, but this is not required.  Further, in my own experiences, if something gets out of sync (like the slave is waiting for more WVALID's), AWREADY will never return high even for those slaves that idle with AWREADY high.

Fix your AXI master.  Make it protocol compliant.  Then your MIG interactions will work.

Dan

0 Kudos
tjrqlsdl11
Contributor
Contributor
994 Views
Registered: ‎10-15-2018

Hi @dgisselq,

Although I have modified axi_awvalid goes high, it did not solved. 

Do you happen to know what makes axi_awready goes low?

 

mig3.GIF

 

Here is my block design included MIG IP

FPGA fabric clock is 125Mhz and DDR4 reference clock is 200Mhz.

I have added clock_converter (1:2 ratio, S:M) and protocol converter for AXI_CTRL (ECC I/F)

I cannot understand axi_awready goes low while MIG is calibrated.

Could you please help me ? 

Thanks

BD.GIF

 

 

 

0 Kudos
dgisselq
Scholar
Scholar
970 Views
Registered: ‎05-21-2015

@tjrqlsdl11,

I just wanted to point out from the DDR3 specification, a DDR3 SDRAM requires roughly 700us (actually a bit more) to go through it's reset sequence before you can issue it a command.  I wouldn't be surprised if the MIG controller held AxREADY low for that period of time.

Dan

0 Kudos
calebd
Moderator
Moderator
873 Views
Registered: ‎01-09-2019

@tjrqlsdl11 

Did this help resolve your issue in the end?  I believe what @dgisselq is saying should help you with the starting AxREADY, but can you mark solved whichever answer helped you solve this issue.

Thanks,

Caleb


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
tjrqlsdl11
Contributor
Contributor
854 Views
Registered: ‎10-15-2018

No, it is not solved I'm working on it

My MIG configuration is DDR4, not DDR3

0 Kudos
calebd
Moderator
Moderator
764 Views
Registered: ‎01-09-2019

@tjrqlsdl11 

Looking at this again, I think what @dgisselq was pointing out about reset is also true for the DDR4 MIG.  You will need to wait for init_calib_complete before you start transactions to the MIG.

I am also wondering why you have instantiated the clock converter and protocol converter separately as opposed to just using the Interconnect IP which will do those functions as it sees necessary.  Have you tried with an interconnect to handle the AXI signals being sent to the MIG?

The reason the MIG is deasserting awready is because it isn't ready to handle a transaction.  Usually that condition is either not being calibrated or being initiated a transaction before calib. is complete.

 

Thanks,

Caleb


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
dgisselq
Scholar
Scholar
762 Views
Registered: ‎05-21-2015

@tjrqlsdl11,

Looking over this again, it looks like I missed something before: You are setting AWVALID but not WVALID.  A slave is allowed to hold AWREADY low until both AWVALID and WVALID have been asserted, so ... this trace still isn't illustrating protocol compliance.

Dan

0 Kudos
calebd
Moderator
Moderator
758 Views
Registered: ‎01-09-2019

@dgisselq 

I agree that what you said is true.  Although, I would have expected the MIG to respond with AWREADY and making the Write Address handshake before receiving the WVALID for a Write Valid/Write Ready handshake.  From that info., I believe something isn't being asserted correctly that the MIG isn't responding appropriately.

Thanks,

Caleb


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
tjrqlsdl11
Contributor
Contributor
692 Views
Registered: ‎10-15-2018

@calebd @dgisselq 

Thanks for reply.

I transferred a transaction after MIG calibration done. The reason I instantiated clock converter is that the operating clock of ECC I/F and AXI-MIG I/F are differ. 

After clearing the IP cache, it works without modification of design and testbench. I don't know what was wrong correctly though.

Thanks.

View solution in original post

0 Kudos