cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jimg@crypto4a.com
Adventurer
Adventurer
1,169 Views
Registered: ‎05-11-2018

AXI VIP issues

Jump to solution

Hello,

 

I'm trying to port a ZYNQ 7000 design to ZYNQ Ultrascale, which includes migrating from the old AXI BFM verification methodology to the new VIP-based approach. Looking at the example design it seems like this should be relatively painless for simple operations like AXI reads/writes by just referencing the VIP APIs to invoke write_data( ) and read_data( ) tasks. Unfortunately, when I do this I'm seeing a single 4-byte (32-bit) write operation being turned into a 4 x 32-bit write operation where the last 3 writes have their wrstrb signals set to 0. My testbench's write_data( ) invocation looks like the following:

 

      i2_top.i0_ps_complex.ps_complex_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0000000, 4, 32'hDEADBEEF, resp);

 

Anyone have any ideas why the above call would generate 4 write operations (the address increments between each one so it appears it's being converted into a burst operation for some reason)? I've tried it with different numbers of bytes and I get the same behaviour, just different wrstrb values on the first of the four write operations (e.g., 1-byte generates a wrstrb = 4'h1).

 

When I do a read_data( ) operation I get a similar behaviour (i.e., a 32-bit read gets converted into a sequence of four 32-bit reads with an incrementing address value), so at least it's consistent!

 

Any suggestions would be greatly appreciated. Thanks!

 

Take care.

 

Jim

0 Kudos
1 Solution

Accepted Solutions
jimg@crypto4a.com
Adventurer
Adventurer
1,371 Views
Registered: ‎05-11-2018

Mistake was all mine as I had forgotten to reconfigure the MPSoC's M_AXI_HPM0_FPD bus interface to be 32-bits from its default 128-bit value (I'm ultimately going through a 32-bit AXI4LITE interface so the wider bus is of no use to me).  I reconfigured the block design and now it works as expected. My apologies for cluttering up the forums with a non-issue.

 

Take care.

 

Jim

View solution in original post

1 Reply
jimg@crypto4a.com
Adventurer
Adventurer
1,372 Views
Registered: ‎05-11-2018

Mistake was all mine as I had forgotten to reconfigure the MPSoC's M_AXI_HPM0_FPD bus interface to be 32-bits from its default 128-bit value (I'm ultimately going through a 32-bit AXI4LITE interface so the wider bus is of no use to me).  I reconfigured the block design and now it works as expected. My apologies for cluttering up the forums with a non-issue.

 

Take care.

 

Jim

View solution in original post