Problem with Altera timing model for LAN91C111?

[Altera_Forum]

Hello, 

 I am developing on a system that is very similar to the Nios II evaluation kit. I am trying to transfer data to and from the LAN91C111 Ethernet MAC but have noticed some problems. The MAC is connected to the Nios II in exactly the same way as on the demo board.  It appears as though the Altera model for the interface to the LAN91C111 is incorrect. The data sheet for this device shows the timing when the LAN91C111 is used in asynchronous mode, and although the nRD & nWR signals meet the timing shown in the data sheet, the minimum cycle time appears to be violated.  In the SMSC LAN91C111 FAQ and Application Note 9.6, it clearly states that the minimum cycle time should be either 80ns or 100nS depending on whether the interface is operating as half or full duplex. When I try to use the DMA to read from the LAN91C111, it see a cycle time of 40nS (when clocking the Nios II with 50MHz). The timing for the LAN91C111 is not directly accessible from the SOPC builder, but looking at the class.ptf file for the LAN91C111, it shows the following:  Read_Wait_States = "20ns"; Write_Wait_States = "20ns"; Setup_Time = "20ns"; Hold_Time = "20ns";  in the SYSTEM_BUILDER_INFO section.  If I am interpreting this correctly, this will result in the 40nS cycle time for Read and Write operations which is in conflict with the SMSC FAQ and the App Note. I have measured this using an oscilloscope.  Now, this wouldn't be a huge problem for me, if I was able to change it, but it doesn't seem to be vary if I change the class.ptf file so that each of the above times are, say, 40nS. This is really the second part of my question. Should it be possible to change the timing as defined in the class.ptf file? I have tried changing it outside of the SOPC builder but it compiles the same regardless. Perhaps there is a trick here?  If anyone has had any luck with using DMA transfer to and from the LAN91C111, it would appreciate any tips you might have.  Many thanks,  sja.

[Altera_Forum]

I came across the issue a while back when I was adding a DMA in to the flow. The problem I saw was that the Lan ship asked for wait states and the driver did not used the ardy signal. 

 I opened a ticket back in march and it is supposed to be addressed in either 5.0 or the first bug fix. There solution was to slow down the access and still not use the ardy signal.

[Altera_Forum]

The fix for this went out with either 5.0 or 5.0SP1 -- get 5.0SP1 and you're sure to have it. To apply this to an existing system you'll need to open SOPC Builder, remove the ethernet component, and then add it back in before generating. The example designs that ship with 5.0SP1 should have this modification built in and not need any alteration. 

 We analyzed the timing presented in the SMSC literature as well as the actual behavior of the ARDY output and decided that the most efficient solution (as well as best performing) was simply to ignore ARDY and treat every transfer to/from the lan chip as if ARDY asserted for its maximum time, as specified in the SMSC datasheet.  Why was this done, you may ask? Simple: In hardware testing we found that ARDY was negated by the ethernet chip on every transfer to/from it -- therefore, modifying wait-state values to pretend that ARDY was negated for the maximum amount of time results in meeting chip timing withuot any additional avalon logic or complexity to worry about getting just right.