[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [N8VEM-S100:273] Request For Comments (NIC Board)
-----BEGIN PGP SIGNED MESSAGE-----
Excellent thoughts, Douglas.
Yes, I understand the ENC28J60 is a 10mb device. I figured you're going
to probably be lucky to get 10mb average throughput even if you're
running a 100mb interface, when you consider that you're running a 4 to
10 Mhz (or so) bus master to begin with.
Other reasons I've identified for supporting the ENC28J60 is low cost,
wide availability, simple interface, it's available in thru-hole
package, small PCB real estate. and very few external components.
Yes, I agree about the window size matching the ENC28J60 dual port RAM
8K size, they aught to match. I also agree that there is a penalty for
the triple buffer transfers,from the ENC28J60 dual port RAM to the Z80
RAM and finally to to the bus master's memory and visa versa. I
considered perhaps a TMA type of transfer arrangement, but then that has
it's own set of problems such as master's interrupts being missed and
complex timing issues, and it just started getting really complicated
really quickly, which I should add, is another of the design goals here
is to design something that is relatively simple and has a high
probability of working at all without months of debugging.
So I arrived at the solution you see there, where the Z80 temporarily
buffers the data in a shared memory, and interrupts the master when it
needs attention. I think overall it puts less demand on the S100 bus
comparing with a TMA transfer mechanism, and in a multitasking
environment aught to afford a comparatively smoother overall system
Yes, I was questioning if 4 ports may be a bit of a stretch, but I guess
I have to go back to some of my own requirements. Port density is
something I have a keen eye for in my own use, achieving maximum
throughput is slightly less of a concern for me. I will have limited
S100 slots available so port density is a pretty high priority. I've
tried to optimize the bit-banging as much as I could such that multiple
channels can be clocked in at the same time. But you're right, with only
a 10MHz or so CPU, and limited RAM, it's definately starting to push the
I am envisioning the bulk of the protocol stack living on the master
CPU, in my case, I'm thinking 68K family. On a Z80 master, perhaps you
could run only one Ethernet port, and then load some of the protocol
stack onto the on-board Z80?
Great thoughts Douglas, gives me lots to think about,
On 11-06-09 02:53 AM, Douglas Goodall wrote:
> I looked over the specs for the ENC28J60 and I have some thoughts...
> The chip is interfaced via SPI, which although fast is still a serial protocol.
> The chip has on-board dual ported ram which is used for incoming and outgoing packets.
> One of the things that slows down protocol stacks is the need to copy buffers around
> (something I learned in signal processing).
> When a packet arrives, I assume it is placed in the dual ported ram of the ENC28J60,
> and can then be copied into the lower 4K at the bottom of the Z80's ram space. From
> there it would get copied yet again into the hosts systems space for further processing.
> I can see several ways to make this all work better. For one thing I think adding four
> interfaces to the card is overkill. If the board could do a really good job with just one,
> that would be something.
> You have to make a decision about how the board is to be used, and where the TCP/IP
> stack is going to live. Lets say you put this board into a Z/80 system in an S-100 bus,
> memory is short enough for the master CPU without having a full TCP stack there.
> Doing a better job with just one channel might include making the master's window into
> the ram space of the on-board CPU the same size as the dual ported ram on the
> ENC28J60. Then the master would have access to the entire buffer space. The Z80
> on the board could manage the ENC28J60 and signal the master via IRQ or perhaps
> with a DMA terminal count condition.
> Also the ENC28J60 is a 10base-T interface which I believe is limited to 10mb.
> Just some thoughts...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----