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

Timing problem with Generic Tri-State Controller and asynchronous interface

Altera_Forum
Honored Contributor II
2,093 Views

Hi, 

 

I'm using a LAN9211 ethernet controller with a Cyclone III fpga. The ethernet controller is attatched to a Nios II processor through a Generic Tri-State Controller using Qsys. 

 

My problem is, that sometimes everything works great, but after changing something completely unrelated to the ethernet controller and recompiling my project, I suddenly get currupted data on that interface. So my conclution is, that there are timing problems with ethernet controller :(. 

 

I've consulted the datasheet of the LAN9211 many times, trying to find the best timing settings for the Generic Tri-State Controller, but there are some timings I just can't map to the Qsys settings: 

 

My current settings are: 

 

> System clock: 90MHz 

 

Read wait time: 32ns 

Write wait time: 32ns 

Setup time: 0ns 

Hold time: 0ns 

Max. pending read transactions: 3 

Turnaround time: 2 

Read latency: 2 

Chipselect through read latency: not checked 

 

My problems are: 

 

1. According to the LAN9211's datasheet, chipselect must be deasserted for at least 13ns between two successive read or write cycles. Writing 32bit data words from NIOS, but having a 16bit interface, I see that cs is only deasserted one clock cycle (11.1ns) inbetween writing lower and higher bytes. How can I fullfill the deassertion time requirement without having to use 16bit Read/Writes or writing my own tri-state controller? 

 

2. Setup and hold times are both specified with 0ns. But this does not ensure, that - depending on the fitter results and the board skew - these timings are not negative in respect to each other (i.e. data beeing invalid before write signal is deasserted). Do I have to take this into account by setting the setup and hold times to someting like 5ns (loosing 2 clock cycles) or can this be handled setting timing constraints with TimeQuest? => How would this constraint have to look like? 

 

 

Please let me know about your experience with specifying timings for asynchronous interfaces, any suggestions are welcome :). 

 

Best Regards 

Simon
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
1,136 Views

Any help please?

0 Kudos
Reply