Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)

MAX10 UFM timing

Michael_Ford
Beginner
555 Views

I am simulating an interface with Max10 UFM and having readdata output delayed by one clock cycle more than what is shown in Intel MAX 10 UFM Implementation Guides. Is the timing provided incorrect? 

Labels (1)
0 Kudos
6 Replies
sstrell
Honored Contributor III
550 Views

It's an Avalon interface.  You should be monitoring the waitrequest signal as well.  If waitrequest is low, data transfer is delayed.

0 Kudos
Michael_Ford
Beginner
483 Views

I had thought the  avmm_data_waitrequest was only applicable to the data register not the control register.  Waitrequest is not shown in timing diagrams for reading of control register in the UFM User Guide.  Diagram shows output on next clock after avmm_csr_read goes high. However I do see waitrequest get asserted in the simulation when the control register data becomes valid so maybe that is the issue. In which case the documentation seems misleading. Thanks.

0 Kudos
Michael_Ford
Beginner
471 Views

Another odd behavior. After an erase operation completes I see the status data change without even doing a read.

Thought maybe I could keep avmm_csr_read high to continuously monitor status for 01=BUSY_ERASE to clear but why does it change when read is low?

0 Kudos
sstrell
Honored Contributor III
450 Views

I inverted it.  It should be that if waitrequest is high, data transfer is delayed.  The command (address and read or write control signal) must be held until waitrequest goes low.  One cycle after that, the data transfer occurs.

See the Avalon spec: https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html

As for your simulation there, perhaps it's a burst transfer?  It's not clear without knowing all the signals involved.

0 Kudos
Michael_Ford
Beginner
429 Views

Based on the text in 4.2.4. UFM Sector Erase Operation of the UFM User Guide and what the simulation shows I now believe the Avalon interface at least for the MAX10  work like this:  avmm_csr_read merely selects the address of register (Status or control) to be output. That register is then immediately output after the address has been clocked in.  (Kind of what diagram indicates)  Because I had initiated a sector Erase prior to read the status goes to Busy apparently after some delay then back idle when complete at up to 350mSec.  The status is continuosly available on avmm_csr_readdata and do not need to keep reading (Strobing  avmm_csr_read or taking it high). Does not seem avmm_data_waitrequest and avmm_data_readdatavalid are involved in IO on the status or control register other than indicating when busy and cannot use the data side interface.  Will need to update my test VHDL and see if this model of operation pans out.

0 Kudos
Fakhrul
Employee
296 Views

Hi Michael_Ford,


We sincerely apologize for the inconvenience caused by the delay in addressing your Forum queries. Due to an unexpected back-end issue in our system, your Forum cases, along with others, did not get through as intended. As a result, we have a backlog of cases that we are currently working through one by one.


Please be assured that we are doing everything we can to resolve this issue as quickly as possible. However, this process will take some time, and we kindly ask for your patience and understanding during this period. The cases will be attended by AE shortly.

We appreciate your patience and understanding, and we are committed to providing you with the best support possible.


Thank you for your understanding.


0 Kudos
Reply