Jump to content

escou64

Members
  • Posts

    2
  • Joined

  • Last visited

escou64's Achievements

Newbie

Newbie (1/4)

0

Reputation

  1. Thanks for you answer: I'll take a closer look on this post to make sure I haven't missed anything. Just to to be sure that I am clear on my issue: I'm not trying to redesign a more complex MIG. I am just using the one available on Vivado which has one use interface port. It's in my own system where I have a module which receives requests coming from two ports and tries to redirect them to the one MIG port. It acts like a "multiplexer" with priorities. That's why I am surprised when I see the MIG not responding after many cycles while it seems to work fine in the beginning of the execution ... I am not sure to understand how I can debug the design without the ILA here: simulate my own design with MIG seems completely impossible and I do not have any other way to observe signals during execution ... However, I did not try to use the debug feature of the MIG. If I understand correctly, it adds some signals to the MIG interface (dbg_*) which allow to view internal states of the MIG. Am I right ?
  2. 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!
×
×
  • Create New...