Jump to content

Search the Community

Showing results for tags 'mig'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • News
    • New Users Introduction
    • Announcements
  • Digilent Technical Forums
    • FPGA
    • Test and Measurement
    • Measurement Computing (MCC)
    • Add-on Boards
    • Digilent Microcontroller Boards
    • Non-Digilent Microcontrollers
    • LabVIEW
    • FRC
    • Other
  • General Discussion
    • Project Vault
    • Learn
    • Suggestions & Feedback
    • Buy, Sell, Trade
    • Sales Questions
    • Off Topic
    • Educators
    • Technical Based Off-Topic Discussions
    • Archived

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. 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!
  2. davec

    Problems with MIG_7

    Has anyone had problems trying to use MIG_7 in their block diagrams in Vivado? I had a design that was working under version 2015.3, then something went wrong. Whenever I try to select that IP block in my diagram, vivado hangs trying to open it. I tried deleting it from my design and bring in a new mig_7series block from my list of board components and it hangs as well. I brought my design over onto a different Win7 computer and did a fresh install of a newer vivado 2017.3 with the latest board files with the exact same result- when I try to bring in the mig block, vivado hangs forever. Anyone know which files in my design I can remove to eliminate the bad references to the mig_7? tnx
×
×
  • Create New...