Mike, I understand the port density issue. Here is what I was thinking... How about a card, as you suggested, with the on-board Z80 and the ram window, and interrupts... I visualize the board with four locations where SPI daughterboards could be installed. Four miniboards with ENC28J60 and appropriate RJ connectors, as a maximum configuration. Or perhaps one ethernet miniboard, leaving space for up to three other kinds of SPI miniboards you can also create. I would love to be able to buy such a device, with the ability to host four SPI devices. The on-board Z80 could query the SPI devices, and provide the IDs back to the master that could then load the appropriate driver code into the local Z80 through the ram window. Once the appropriate driver code is loaded into the non-volatile ram, it will stay there for subsequent use for up to ten years. 0000-07FF 2716 2Kx8 EPROM with Z80 startup code This code would identify SPI devices on board and post their IDs in the dual ported ram. Also it can provide transfer services to load local SPI drivers into the non-volatile ram (8K/SPI device) 2000-5FFF Static ram (16k) (OPTIONAL) Used as local storage for on-board drivers 6000-7FFF Dual Ported RAM for Master access (8K) Conveniently sized to access one ethernet miniboard's internal dual-ported ram.
Attachment:
7015_DS_89949.pdf
Description: Adobe PDF document
8000-FFFF Non-volatile RAM (Dallas...) (32K=8K/SPI device)
Attachment:
ds1244.pdf
Description: Adobe PDF document
Douglas On Jun 9, 2011, at 2:21 AM, mike wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 > operation. > > 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 > envelope. > > 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, > > - --Mike > > On 11-06-09 02:53 AM, Douglas Goodall wrote: >> Mike, >> >> 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... >> >> Douglas >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJN8JCbAAoJEEzVYN3s3Af7Xw0H/0xr2+3dc6FLzhNAtGnTPO6U > HUjlspcF8KRcIANuI/1ZGmTcsrKY59Ct00uwM8dQnmxYKCftj+wLcZaKtQwXvwR9 > aBpbQKWDWww4wRrJ/NnzhtlyaJ5XBh6HkUywU8wnIIIom/ljXfDP5RvkpfW2teC5 > 1NMMjJHXlSqoI2dClR7OaKrbeQOFl0nUFzfjA+WFJzJt8u9/3q0hSimD4sIRoo0/ > PjRK+K3zNyFxJX1+D8HzrWNiH2FtUh1dtnYA8LaA9fu5RaOyVNG/isgHhSWHj1QP > BH1pxdyikxZMFLA1QMhYqkk7nP107fSpTOyy9GNJBkzF1POxmuR5S9VIWD6C3zA= > =Gryj > -----END PGP SIGNATURE-----