Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

Another Lan91C111 LWIP problem!

I tried running the Nios Stratix DevKit on a 10BaseT link (rather than 100BaseT), and was surprised when everything fell apart.

Ethereal shows that certain longish packets would switch half-way through to containing data from what should have been the subsequent packet - because the low-level packet output isn't correctly waiting for the previous packet to be sent before sending the next one.

On a fast link, this seems not to be a problem, but the 10MBit speed shows up the bug.

The fix which seems to work is to insert the following line at the top of the low_level_output routine in altera_avalon_lan91c111.c, immediately before polling the TX_empty bit. This is needed because the TX_empty bit is latched 

IOWR_ALTERA_AVALON_LAN91C111_ACK(dev->base_addr, ALTERA_AVALON_LAN91C111_INT_TX_EMPTY_INT_MSK );

Check page 62 of the LAN91c11 datasheet to read WHY this is needed. The PDF is protected, so I can't paste the sentence in here!

- Roddy

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Great catch! Maybe my comms will finally work right.

    The datasheet is contradictory on this point. Is the TX_EMPTY bit latched high only once when the empty condition first occurs, or continously as long as the empty condition exists? The paragraph manages to say both things. Your fix suggests it is the latter case. If so, the ack following the polling seems to be useless.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    --- Quote Start ---

    originally posted by tns1@Nov 25 2004, 01:17 AM

    the datasheet is contradictory on this point. is the tx_empty bit latched high only once when the empty condition first occurs, or continously as long as the empty condition exists? the paragraph manages to say both things. your fix suggests it is the latter case. if so, the ack following the polling seems to be useless.

    --- Quote End ---

    The datasheet is clear that for a "Real-time" reading of the fifo empty state you must 'clear' the bit FIRST. I hadn't actually spotted the code clearing it after polling it, which does appear to be redundant now. The whole concept of this bit being latched is somewhat bizarre, even in an interrupt-driven system.

    I was also surprised to see that network transmission is effectively polled - One task continually sending packets will hog all available CPU time.

    - Roddy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Roddy,

    It looks like you're correct this is indeed a bug fix. I'll put it into the driver for a future release.

    As for the output driver being polled, yes it is. However I doubt that this is a problem, as a quick calculation of the cycles used in the main Tx loop and all the other overheads shows that the CPU cannot keep up with line rate so you're unlikely to get the situation where you enter low_level_output and the previous transmission has not completed.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    You're right, the polling is only going to be significant if you have either a slow LAN (10BaseT and/or heavily loaded with other traffic), or a fast processor. The fact that this bug hasn't shown up until now means that most designs don't reach the performance where they need to poll! I guess it's just something to bear in mind for the future.

    - Roddy