03-13-2019 03:34 PM
I'm using a modified version of the Zynq Example project in Vivado 2018.3 where I've:
I've been trying to successfully run the in-built test bench which writes to some block memory using the Zynq VIP.
I've encountered two issues and would like to know if they're bugs or genuine issues (note, all connected IP is Xilinx origin):
Clearly the bram controller IP etc is good so something else is wrong. At the moment I can only successfully run if I disable Static Remap and leave a master disconnected on the AXI interconnect.
Something doesn't seem right but I'm running out of ideas! Project attached.
03-20-2019 09:41 AM - edited 03-20-2019 01:07 PM
I was able to see this issue on my end by opening the Zynq 7000 example design and removing the GPIO block and related ports. I then altered the testbench to not use the LED pins. I get the same spec. violation which points to the ARM spec. (https://developer.arm.com/docs/ihi0022/d) where it states that a BVALID signal must first have both WVALID and WREADY asserted. In the simulation I can see BVALID asserted on the same clock cycle as WVALID and WREADY which indicates it did not follow the AXI specification.
Since this seems to be viewable in Simulation the change in board preset is probably not necessary as it is potentially obscuring the real problem. Same with the Static Remap option.
Leaving the AXI Interconnect open is not a good solution as that can cause some unwanted behavior and is not fixing the underlying issue.
I am also able to continue running the simulation after the fatal error occurs for another 10us, and I receive the statement "AXI VIP Test PASSED" with the correct data read back from BRAM. Can you check whether this is true for you as well? I am going to see what is causing BVALID to assert. I notice that the processor seems to be pulled out of reset before the BRAM controller which may be causing some issues.
Edit: I was able to solve this issue and it looks like the testbench you are using has some issues with resetting properly within the time allotted. The big change I added was to wait for 200 clock cycles before sending a command to the BRAM controller. The BRAM controller needs time after being reset to get sorted out before it can receive a command.
Of note, this error can be seen by looking at the AWVALID/AWREADY handshake and see that the timing is not correct with a reset occurring only a cycle before this handshake occurs. Then the WVALID/WREADY handshake and BVALID/BREADY handshake occur, but on the same (incorrect) cycle so causing the fatal AXI spec. violation.
My changes to the testbench can be seen below:
//--------------------------------------------------------------------------- // Testbench //--------------------------------------------------------------------------- // //*************************************************************************** // DISCLAIMER OF LIABILITY // // This file contains proprietary and confidential information of // Xilinx, Inc. ("Xilinx"), that is distributed under a license // from Xilinx, and may be used, copied and/or disclosed only // pursuant to the terms of a valid license agreement with Xilinx. // // XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION // ("MATERIALS") "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER // EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING WITHOUT // LIMITATION, ANY WARRANTY WITH RESPECT TO NONINFRINGEMENT, // MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. Xilinx // does not warrant that functions included in the Materials will // meet the requirements of Licensee, or that the operation of the // Materials will be uninterrupted or error-free, or that defects // in the Materials will be corrected. Furthermore, Xilinx does // not warrant or make any representations regarding use, or the // results of the use, of the Materials in terms of correctness, // accuracy, reliability or otherwise. // // Xilinx products are not designed or intended to be fail-safe, // or for use in any application requiring fail-safe performance, // such as life-support or safety devices or systems, Class III // medical devices, nuclear facilities, applications related to // the deployment of airbags, or any other applications that could // lead to death, personal injury or severe property or // environmental damage (individually and collectively, "critical // applications"). Customer assumes the sole risk and liability // of any use of Xilinx products in critical applications, // subject only to applicable laws and regulations governing // limitations on product liability. // // Copyright 2009 Xilinx, Inc. // All rights reserved. // // This disclaimer and copyright notice must be retained as part // of this file at all times. //*************************************************************************** // `timescale 1ns / 1ps module tb; reg tb_ACLK; reg tb_ARESETn; wire temp_clk; wire temp_rstn; reg [31:0] read_data; wire [3:0] leds; reg resp; initial begin tb_ACLK = 1'b0; end //------------------------------------------------------------------------ // Simple Clock Generator //------------------------------------------------------------------------ always #10 tb_ACLK = !tb_ACLK; initial begin $display ("running the tb"); tb_ARESETn = 1'b0; repeat(20)@(posedge tb_ACLK); tb_ARESETn = 1'b1; @(posedge tb_ACLK); repeat(20) @(posedge tb_ACLK); //repeat(5) @(posedge tb_ACLK); //Reset the PL tb.zynq_sys.base_zynq_i.processing_system7_0.inst.fpga_soft_reset(32'h1); repeat(5) @(posedge tb_ACLK); tb.zynq_sys.base_zynq_i.processing_system7_0.inst.fpga_soft_reset(32'h0); //tb.zynq_sys.base_zynq_i.processing_system7_0.inst.set_verbosity(400); //This drives the LEDs on the GPIO output //tb.zynq_sys.base_zynq_i.processing_system7_0.inst.write_data(32'h41200000,4, 32'hFFFFFFFF, resp); //$display ("LEDs are toggled, observe the waveform"); //tb_ARESETn = 1'b0; repeat(200)@(posedge tb_ACLK); //tb_ARESETn = 1'b1; //@(posedge tb_ACLK); //repeat(5) @(posedge tb_ACLK); //Write into the BRAM through GP0 and read back $display("has a violation occurred yet?"); tb.zynq_sys.base_zynq_i.processing_system7_0.inst.write_data(32'h40000000,4, 32'hDEADBEEF, resp); $display("how about now?"); tb.zynq_sys.base_zynq_i.processing_system7_0.inst.read_data(32'h40000000,4,read_data,resp); $display ("%t, running the testbench, data read from BRAM was 32'h%x",$time, read_data); if(read_data == 32'hDEADBEEF) begin $display ("AXI VIP Test PASSED"); end else begin $display ("AXI VIP Test FAILED"); end $display ("Simulation completed"); $stop; end assign temp_clk = tb_ACLK; assign temp_rstn = tb_ARESETn; base_zynq_wrapper zynq_sys (.DDR_addr(), .DDR_ba(), .DDR_cas_n(), .DDR_ck_n(), .DDR_ck_p(), .DDR_cke(), .DDR_cs_n(), .DDR_dm(), .DDR_dq(), .DDR_dqs_n(), .DDR_dqs_p(), .DDR_odt(), .DDR_ras_n(), .DDR_reset_n(), .DDR_we_n(), .FIXED_IO_ddr_vrn(), .FIXED_IO_ddr_vrp(), .FIXED_IO_mio(), .FIXED_IO_ps_clk(temp_clk), .FIXED_IO_ps_porb(temp_rstn ), .FIXED_IO_ps_srstb(temp_rstn));//, //.leds_4bits_tri_o(leds)); endmodule
03-20-2019 03:23 PM - edited 03-20-2019 03:30 PM
@calebd , really good spot on the reset issue; I just thought as it was an example one it'd be all correct -- I should have looked harder!
So incorporating your test bench changes I can correct the AXI interconnect (so no longer need the nugatory port). However when I re-enable static remap it looks like we've still got a problem there. I re-run the simulation with both remap enabled and disabled and the only difference I can see before the failure is the AXI write ID (as this is what the remap is doing).
Of note though is that on the simulation where it passes, the write ID is 0xd71 and after the write call I see:
wr_id called with wr_size 69b
4910ID1 in strb task is d71
On the failed simulation with remap enabled, the write ID is 0x16 howerver after the write call I see:
wr_id called with wr_size 69b
4910ID1 in strb task is d56
Clearly it's just truncated the upper bits when remapped as it goes down to 6-bits but I wonder if the VIP doesn't like the mismatch in ID? The simulator currently bombs out when it hits the error as it can't find the SV sources files (and the open directory button doesn't work while the simulation is running..!) so I can't get past the error point. Would be good to know if you can at least recreate though.
Edit: To confirm, whilst the error the simulation gives is the same as before, the BVALID signal does appear to be operating correctly as per the AXI spec now.
03-20-2019 04:09 PM
Would you be willing to start a new forum thread about the static remap issue so that more people are likely to see the issue who would have expertise in that area, as well as more people who might be running into that problem?
Also if you found my answer above to be the answer to your problem, could you "Mark as Solution" so that others who run into this issue would be able to see the solution quickly and easily?