I am currently trying to implement an interface between multiple ports of a custom memory bus and the MIG IP of my Arty A7-35T board.Basically in my current example design, the first port reads a memory range 128-bit by 128-bit (it is for a custom VDMA). In the same time, the second port writes values in the same memory range (it is to emulate a CPU activity). The first port has the priority: if it is not busy, it sends its read request and else, its the second port which tries to write. I try to debug my design with an ILA.
(See picture normal_read) In the first cycles after the reset, the system looks to work as expected. The app_rd_valid is asserted some cycles after the request (r_rpend indicates how many read requests are pending, r_mig_not is simply used to try to visualize the clock, r_mig_cycle indicates the number of cycles since the last reset).
But later during the execution, the whole system seems to be locked (or slowed down). Particularly, the MIG becomes really slow during read requests. We can see (on pictures rpend_increase and long_read) that app_rd_valid is now asserted only after many cycles (512+ cycles if we consider the r_mig_cycle[15:8]) while the app_rdy is high. This hypothesis is validated by the value of r_mig_rpend which stays at 7 most of the time ... Finally, it seems that the MIG does not respond at all to my read requests since the trigger on app_rd_valid is never activated again.
I thought that the MIG asserts a read request in only some cycles (~22 cycles). Is that correct ? Do you have any ideas of what conditions I have possibly missed which leads to this strange working ? Or a possible strategy to debug my design ?
Question
escou64
I am currently trying to implement an interface between multiple ports of a custom memory bus and the MIG IP of my Arty A7-35T board.Basically in my current example design, the first port reads a memory range 128-bit by 128-bit (it is for a custom VDMA). In the same time, the second port writes values in the same memory range (it is to emulate a CPU activity). The first port has the priority: if it is not busy, it sends its read request and else, its the second port which tries to write. I try to debug my design with an ILA.
(See picture normal_read) In the first cycles after the reset, the system looks to work as expected. The app_rd_valid is asserted some cycles after the request (r_rpend indicates how many read requests are pending, r_mig_not is simply used to try to visualize the clock, r_mig_cycle indicates the number of cycles since the last reset).
But later during the execution, the whole system seems to be locked (or slowed down). Particularly, the MIG becomes really slow during read requests. We can see (on pictures rpend_increase and long_read) that app_rd_valid is now asserted only after many cycles (512+ cycles if we consider the r_mig_cycle[15:8]) while the app_rdy is high. This hypothesis is validated by the value of r_mig_rpend which stays at 7 most of the time ... Finally, it seems that the MIG does not respond at all to my read requests since the trigger on app_rd_valid is never activated again.
I thought that the MIG asserts a read request in only some cycles (~22 cycles). Is that correct ? Do you have any ideas of what conditions I have possibly missed which leads to this strange working ? Or a possible strategy to debug my design ?
Thanks for your help!
Link to comment
Share on other sites
5 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now