Reply by essay March 3, 20052005-03-03
<kempaj@yahoo.com> wrote in message
news:1109878145.397950.47950@l41g2000cwc.googlegroups.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 > > 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
Reply by March 3, 20052005-03-03
> > 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
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
Reply by essay March 3, 20052005-03-03
<kempaj@yahoo.com> wrote in message
news:1109811051.021571.155460@l41g2000cwc.googlegroups.com...
> essay wrote: > > > > 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. > > > ... > > > > Read_Wait_States = "20ns"; > > Write_Wait_States = "20ns"; > > Setup_Time = "20ns"; > > Hold_Time = "20ns"; > ... > > 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? > > 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
Reply by March 2, 20052005-03-02
essay wrote:
> > 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. >
...
> > Read_Wait_States = "20ns"; > Write_Wait_States = "20ns"; > Setup_Time = "20ns"; > Hold_Time = "20ns";
...
> 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?
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
Reply by essay March 1, 20052005-03-01
Hello,

I have also posted this message on the niosforums site. Hopefully someone
here will have an insight to my problem.

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.