Forum Discussion
Altera_Forum
Honored Contributor
10 years agoMy AXI4 Lite slave hangs CPU after read. Write transactions work correctly
Hi,
I have ported my AXI4-Lite to IPbus bridge from Zynq to Altera Cyclone V. Unfortunately, it behaves in a strange way in Cyclone V. Tests have been done with "devmem" tool in Buildroot compiled Linux. There is also Altera sys-id component connected to the same bridge using the same clock and reset signals, which works perfectly, so the clock and reset signals are correct and the lwhps2fpga bridge is enabled (at the U-Boot level). Below are the Signal Tap recordings for write transactions (32-bit write, and 64-bit write). devmem 0xff200124 32 0xdad98123 http://www.alteraforum.com/forum/attachment.php?attachmentid=12186&stc=1 devmem 0xff200000 64 0x12345678fedcba98 http://www.alteraforum.com/forum/attachment.php?attachmentid=12187&stc=1 Unfortunately, for read accesses the CPU hangs just after the first (in case of 64-bit read) or the only (in case of 32-bit read) transaction is finished: devmem 0xff200000 64 http://www.alteraforum.com/forum/attachment.php?attachmentid=12188&stc=1 devmem 0xff20001c http://www.alteraforum.com/forum/attachment.php?attachmentid=12189&stc=1 The transaction is completed correctly at the slave level, however it looks like the information about completion doesn't reach the CPU. I attach sources of the component. It contains a few IPbus slaves conencted to the bridge. One of registers drives 8 lines conncted to LEDs via "leds" conduit. The verified Xilinx version is almost the same. It only does not use the WPROT and RPROT ports and uses narrower LEDS conduit (3 LEDS). What can be the reason of such strange behaviour on the Cyclone V platform? TIA & Regards, Wojtek14 Replies
- Altera_Forum
Honored Contributor
--- Quote Start --- You may want to peruse this document: https://silica.avnet.com/wps/wcm/connect/e2612871-ffdd-470e-b355-f12e0f570395/silica_xilinx_designing_a_custom_axi_slave_rev1.pdf?mod=ajperes&cvid=liicqoz&cvid=liicqoz Page 3. --- Quote End --- That's exactly, what I have used to design my bridge. See http://opencores.org/websvn,filedetails?repname=ax4lbr&path=%2fax4lbr%2ftrunk%2frtl%2faxil2ipb.vhd ;) However this link is a "moving target"... BTW. In this document there is nothing about avoiding combinational connections between input and output signals. That's why I have run into this incompatibility. Thanks, Wojtek - Altera_Forum
Honored Contributor
--- Quote Start --- That's exactly, what I have used to design my bridge. See http://opencores.org/websvn,filedetails?repname=ax4lbr&path=%2fax4lbr%2ftrunk%2frtl%2faxil2ipb.vhd ;) However this link is a "moving target"... BTW. In this document there is nothing about avoiding combinational connections between input and output signals. That's why I have run into this incompatibility. Thanks, Wojtek --- Quote End --- Can you show the combinatorial connections? Now I already perused your code. Immediately I can't make much of it as it is rather complicated. I had expected to see a state-machine ... a state machine is worth a thousand equations Regards, Jos - Altera_Forum
Honored Contributor
--- Quote Start --- Can you show the combinatorial connections? Now I already perused your code. Immediately I can't make much of it as it is rather complicated. I had expected to see a state-machine ... a state machine is worth a thousand equations --- Quote End --- Yes, the state machine is much clearer. However this design was based on an attempt to make the bridge as fast as possible. Therefore the main part is a combinational process, which translates signals between the AXI4 Lite side and the IPbus (or WishBone in the second bridge) as fast as possible. So the combinational connections are just results of the combinational process used here. An example may be, that in the write transaction: If S_AXI_AWVALID = '1' and S_AXI_WVALID = '1' and there is no uncompleted transaction, then if S_AXI_WSTRB = "1111", finally S_AXI_AWREADY and S_AXI_WREADY are set to '1'. The above is done in a fully combinational way, creating the combinational connection between the input signals (AWVALID, WVALID, WSTRB ) and output signals (AWREADY, WREADY) at the AXI4-Lite side of the bridge. Probably to comply to the requirement of avoiding combinational connections, I'll have to rewrite it as a state machine (hopefully for translated signals it will be the Mealy one). However, almost for sure it will result in slightly slower (but safer) operation... Regards, Wojtek - Altera_Forum
Honored Contributor
--- Quote Start --- Yes, the state machine is much clearer. However this design was based on an attempt to make the bridge as fast as possible. Therefore the main part is a combinational process, which translates signals between the AXI4 Lite side and the IPbus (or WishBone in the second bridge) as fast as possible. So the combinational connections are just results of the combinational process used here. An example may be, that in the write transaction: If S_AXI_AWVALID = '1' and S_AXI_WVALID = '1' and there is no uncompleted transaction, then if S_AXI_WSTRB = "1111", finally S_AXI_AWREADY and S_AXI_WREADY are set to '1'. The above is done in a fully combinational way, creating the combinational connection between the input signals (AWVALID, WVALID, WSTRB ) and output signals (AWREADY, WREADY) at the AXI4-Lite side of the bridge. Probably to comply to the requirement of avoiding combinational connections, I'll have to rewrite it as a state machine (hopefully for translated signals it will be the Mealy one). However, almost for sure it will result in slightly slower (but safer) operation... Regards, Wojtek --- Quote End --- Now your original code as hidden state! Where a State Machine proper will clearly indicate what your intentions are, in the case of a bunch of equations one has to decode all the equations and draw a timing diagram to understand what is going on. I even write State Machines with 2 (yes even only 2) states! Now whether it is Mealy or Moore or a hybrid form doesn't really matter, that's for the academics. I divide my state machines in three parts:- a combinatorial part to decide on the next state, plus combinatorial outputs
- a registered part with a reset to register the state, and to register possible output signals that require a known reset state
- a registered part for the dataflow-type signals