Nios II timing question

LAN91C111 is

signals

appears to

...

...

it, but

each of

the

but it

Hi sja,

Thanks for noting this. You are correct and this has been filed as a bug in our tracking system to fix in a future Nios II release. I believe the reason you're seeing this fail is because when CPU accessing Ethernet, even in a tight-loop, is probably not violating the SMSC spec as the accesses are not continuous.. on the other hand DMA will attempt continuous access. I have done DMA work to/from our previous Ethernet MAC (CS8900) and with on-chip MACs, but oddly enough not this one.

That said, as you note it is an easy fix to edit the .ptf file as you indicate you have tried. The secret to this, though, is that the .ptf settings are copied into your system .ptf file when the component is added to your system in SOPC Builder. To make the fix permanent, you should close SOPC Builder, edit the class.ptf file for the lan91c111 component, open SOPC Builder, delete any existing 91c111 components from your system, and then add it back, and re-generate.

Please advise if the above doesn't correct the problem.

Jesse Kempa Altera Corp. jkempa at altera dot com

Hi Jesse,

Thanks for the quick response. I will try your suggestion to get the .ptf going.

On that topic, is there an easy way to change the timing requirements for the SRAM that is used on the eval board? I use equivalent devices on my board, but may want to use slower versions once the design is complete. i.e. I would like to keep my sysclk as high as possible, but have the option of using slower SRAM. Do I have to create an interface to user defined logic to use SRAM that is the same as the eval board, but slower? It would be nice if I could change the timing requirements in a .ptf file like we have discussed for the LAN91C111.

Thanks in advance,

sja

.ptf

for

my

complete. i.e.

option of

logic to

nice if

discussed

Hi sja,

Well the intent with the product is to have you create an interface via the Component Editor (new SOPC Builder 4.2 feature), or previously, the "Interface to User Logic". Both of these tools allow you to specify which signals you want to export to the outside world, which are shared if using a tri-state bus, setup/wait/hold timing, etc.

However if you're the adventurous sort, then as you've seen modifying the source files is another option (the component editor/interface to user logic basically creates similar files for you). In the case of the SRAM components in the Nios II dev kit, the timing figures in the class.ptf file are actually over-written by a perl script (mk_sram.pl), same folder as the class.ptf for those components, which is run at system-generation time. The reason behind this is that it allowed us to fine-tune SRAM timing depending on your system's clock speed... the script source is pretty easy to follow. If you take this route, I would save your changes in a separate component folder with separate 'class' name in the class.ptf file & separate entries in the SOPC Builder GUI (also in the class.ptf), that way your custom SRAM will show up independent of the one for the dev. kit...again though, that is what the Component Editor is for.

Jesse Kempa Altera Corp. jkempa at altera dot com

Hi Jesse,

Thanks again for the quick response. I'll have a look at the perl script, but it sounds like the Component Editor is the way to go.

You have been most helpful.

sja