Honored ContributorI've read everything I can find on the forum about this topic, and so far the answer seems to be no. One guy got it to work on a custom board, and Nate Knight got it to work on a DSP board, but I can't find anything about using one of these daughtercards under Nios II on a Stratix II dev kit.
If you have a Quartus design that works, I would love to see it. Thanks!
Honored ContributorI was able to get a 16bit interface to the Lan91C111 working under the quartus4.1 environment. Although I was using a custom cyclone board and a custom daughtercard, they were not very different from the kit boards.
There is documentation on the altera daughtercard, which I can send you if you like. If this is what you are using, then you can just build a project with the Lan91C111 (daughtercard option selected). At the time, I found I also needed to invert the reset line and select native address alignment in the class.ptf. These changes may not be needed under 5.0. Then set aside a week or so to rewrite the lan91C111 drivers, since they are written for the 32bit interface only. You will need to be very familiar with the datasheet for that chip, and you will end up modifiying altera_avalon_lan91c111.c, .h, regs.h . It helps to have a kit board with the on-board Lan91C111 (32bit interface), so you can watch the working driver code in a debugger to understand how it should behave. It is far easier to just get a board that already has a working driver.Honored Contributor
there is documentation on the altera daughtercard, which i can send you if you like.
if this is what you are using, then you can just build a project with the lan91c111 (daughtercard option selected). at the time, i found i also needed to invert the reset line and select native address alignment in the class.ptf. these changes may not be needed under 5.0.
then set aside a week or so to rewrite the lan91c111 drivers, since they are written for the 32bit interface only. you will need to be very familiar with the datasheet for that chip, and you will end up modifiying altera_avalon_lan91c111.c, .h, regs.h . it helps to have a kit board with the on-board lan91c111 (32bit interface), so you can watch the working driver code in a debugger to understand how it should behave.
it is far easier to just get a board that already has a working driver.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10782)
--- quote end ---
--- Quote End --- I have the altera daughtercard documentation, thanks though. How did the change to native addressing help? I found an explanation of the difference but I'm still confused about what situations you'd use each in. Also how did you hook up your address and byte enable lines? Right now I have my daughtercard component hooked up to a separate tri-state bridge. It gives me address lines 3..0 and byte enable 1..0.
Honored ContributorI have the altera daughtercard documentation, thanks though.
How did the change to native addressing help? I found an explanation of the difference but I'm still confused about what situations you'd use each in. Also how did you hook up your address and byte enable lines? Right now I have my daughtercard component hooked up to a separate tri-state bridge. It gives me address lines 3..0 and byte enable 1..0. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=10794)</div> --- Quote End --- Connect pins# BE0,# BE1 to the same named module port pins. Connect pins A1,A2,A3 to module pins A2,A3,A4. Tie pins A8,A9 high, all remaining address pins low. IRQ and Reset connected to obvious pins.# IOR,# IOW to# RD,#WR.# ADS, AEN low, LCLK,# BE2,#BE3 high. With the address lines connected as described, your registers should be on 32bit boundaries: BASE+0,BASE+4,BASE+8,etc. As a test try to read the BSR: write 0x0003 to BASE+0xE, then you should read something like 0x339n from BASE+0xA. You may have to use 0x1C,0x14 instead of 0xE,0xA depending on if you have used any of the built-in macros to do the job. Once this works, you will know what kind of changes will be needed to the driver - mainly shift and mask. The reason for using native addressing is to prevent the nios from doing two reads when you really want just one (data FIFO access) . Use a scope to see if you need to worry - it may not happen under 5.0.Honored Contributorconnect pins a1,a2,a3 to module pins a2,a3,a4.
tie pins a8,a9 high, all remaining address pins low.
irq and reset connected to obvious pins.# ior,# iow to# rd,#wr.# ads, aen low, lclk,# be2,#be3 high.
with the address lines connected as described, your registers should be on 32bit boundaries: base+0,base+4,base+8,etc.
as a test try to read the bsr:
write 0x0003 to base+0xe, then you should read something like 0x339n from base+0xa. you may have to use 0x1c,0x14 instead of 0xe,0xa depending on if you have used any of the built-in macros to do the job. once this works, you will know what kind of changes will be needed to the driver - mainly shift and mask.
the reason for using native addressing is to prevent the nios from doing two reads when you really want just one (data fifo access) . use a scope to see if you need to worry - it may not happen under 5.0. --- Quote End --- Sweet, I got it working. Nate Knight's 16-bit-friendly driver helped out too, although I had to fix the offsets for the IORD_8DIRECT calls and use regular IORD/WR for the rest. The IORD/WR calls work off Base+0, Base+2, Base+4 etc too which was nice. For the IORD_8DIRECT I had to use Base + (x * 4) for the low byte and Base + (x * 4 + 1) for the high byte. Next step is to stack two of these puppies and get three interfaces running simultaneously on the board. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif Thanks!
