axisafety module fails tests with ZYNQ + AXI BRAM controller

[zipcpu]

axisafety module fails tests with ZYNQ + AXI BRAM controller

[ZipCPU]

Thank you for reporting this.

The bug is in line 637, where the downstream write data is assigned to M_AXI_WDATA (the downstream write data), rather than S_AXI_WDATA. Expect an update shortly.

Dan

[ZipCPU]

Fixed in 77ab90a.

Dan

[ZipCPU]

I should also point out that it looks like you have promoted several localparam's to full blown parameters. These were designed as localparam's to guarantee proper functionality. While I understand that Vivado may require to you turn them into parameters, if you actually override their values--or set them to values inconsistent with their original (sometimes equation) values, you may break the core. For example, IW is shorthand for C_S_AXI_ID_WIDTH. If the two are ever out of synch, the core will not work. DW and AW have similar definitions. Likewise if you change LSB, EXOKAY, or SLAVE_ERROR, the design may not be protocol compliant.

Dan

[madorskya]

Thanks for the fix, it's now working, at least with BRAM controller.

Regarding localparam vs parameter: I left the equations as they were for localparams, so the link between parameters is still there. But if you have a better suggestion, please let me know. Vivado definitely does not like localparams

Another question, if you don't mind:
Do I understand correctly that M_AXI_ARESETN output from axisafety should be connected to S_AXI_ARESETN input of the unreliable core?

thanks.
Alex.

[ZipCPU]

If you use the OPT_SELF_RESET capability then M_AXI_ARESETN needs to be connected to the downstream/unreliable slave, yes. If not, M_AXI_ARESETN is just a simple passthrough and you can choose to connect it or not at your leisure.

The self reset capability is one of the big benefits of this particular design: on any fault, it can reset the slave and try to start over. This could be valuable if you want to discover what conditions cause the violation and the first trace you get doesn't tell you enough and so you want to try again. I'm unaware of any other firewalls with this capability.

Incidentally, don't forget to trigger a trace on one of the fault outputs. That'll help you understand what's going on when/if your design does fail.

Dan

[madorskya]

thanks Dan,
I'm actually using axisafety with Xilinx Chip2chip IP. That IP is pretty much guaranteed to lock up the system if the other side of the link is missing, for example in case of the other FPGA being unconfigured. It entirely evades me why Xilinx does not care about this glaring omission. So axisafety is invaluable in this scenario. I do use it with OPT_SELF_RESET=1 and have connected M_AXI_ARESETN output to Chip2chip reset input.
thanks for your help.
Alex.

[ZipCPU]

Awesome! That's what it axisafety was made for. I'd love to hear how it works for you once you get far enough to be able to tell.

Dan