Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17267 Discussions

Timing problem with Generic Tri-State Controller and asynchronous interface

Altera_Forum
Honored Contributor II
2,103 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,146 Views

Any help please?

0 Kudos
Reply