On 1/11/02 at 4:17 AM Dexter wrote: >On Thu, 10 Jan 2002, ZN wrote:
>> No need for the mezzanine card, the required chips are found on the GF, >> in fact, even that part of the PCB has been designed! Normally I would >> not be againgst such a board, but as you know, the GF is intended to be a >> semi-SBC. >So all that needs doing is to get that section as a schematic and do >the board. :o) More or less... well, more. The GF does not have IDE, so a few additional bits will be needed. Also, I think I am using the IDE decode of the chip for something else, I haven't had a look at that part of the schematic in a while :-) but I think that 'else' is the processor and interrupt controller which will not be needed on the IO card version so there should not be any problem. The schematic WILL have to be modified, and several decisions will have to be made: 1) Will this thing ever be plugged into the real ISA (IMHO, hopefully not! The PC87307 is made for motherboard apps, although they do have an ISA card implementation, usefull to look into for this project). This question can be reformulated as: do we, and in what extent, have the ability to change the existing code to simplify the design or add new features? What needs to be ABSOLUTELY compatible with the existing card? One problem: PC87307 is a PnP device (fortunately, vastly simplified because it's intended for a motherboard). I am not sure but it may be possible to circumvent outright software PnP (although I have described the process in detail in the GF docs) by using a serial EEPROM. I have not looked in depth into this because the GF requires new initialisation code to be written anyway, so PnP can be part of that (and this also saves the need for an EEPROM). 2) How far does the design move from the GF implementation to an ISA (even if only Q40/60 ISA) implementation. This impacts interrupt line routing and base address selection (which in turn impacts the PnP initialization values), 8/16 bit bus width selection for ethernet (probably this will be 16 bit), local interrupt routing between UltraIO, Sound, Ethernet and whatever else gets on the board. All of this also impacts Q40/60 linux drivers if it deviates too much from regular ISA cards, but then, knowing the Q40/60 implementation of ISA and designing speciffically for it (see 1 above) might make things easyer both for Q40 and GF, even though some existing Q40/60 Linux drivers may need slight modifications (It seems to me the later should not be a problem, but I'm not involved with any aspect of Q40/60 Linux so I simply can't be sure). 3) What additional stuff we want on this board - IDE, drivers for MIDI, CF card... 4) Existing design decisions and peculiarities of implementation. Example: the sound chip wants to be Windows Sound System compatible, along with a 'native' AD1816 mode. On GF the WSS is ignored because the native mode is both simpler and more flexible, and unlike WSS has access to ALL the chips considerable features (since we have to pay for them once we buy the chip, we might as well use them!). 5) Feedback to original GF design - decisions made in the design of the IO board might override some of the ones made for the design of GF IO (a 'let's meet in the middle' effort) if it simplifies matters with making the drivers more uniform across platforms. I don't have a lot of leeway, but I can certainly try to do what I can! >>> I have Eagle 4 Professional, which is half the tools for the job. > ...It does pretty good with 4-layers. But then, it is a $1200 program. Care to take up the challenge of making it a two-layer board? It would certainly make it MUCH cheaper... However, 4 layers make it MUCH easyer to route, and may also make the whole thing smaller, which would certainly be of interest to some people :-) The GF board is certainly going to be the most peculiar one I have ever designed. With the surface mount chips I am using, the largest portion of their pins are either power, ground or not connected. I have calculated that the regular setup where power and ground layers are in the middle would therefore require more vias than the not so often seen version with ground and power on the outside. The vias and other thru-holes take a huge amount of space - one via is larger than a CPLD pin, for instance, even for the smalles still financially viable via size. Also, with small pitch surface mount chips, the spaces between pins are too small to pass a line between them, so effectively the relatively large area taken by the chips is 'in the way' of the tracks. This is why the overwhelming number of tracks is routed in the middle two layers. Allmost all surface mount passives are on the bottom layer, which is also the power layer, pads for the components are 'islands' in the power plane. The top layer is ground, and it's also used as a cooling surface, since it's a large exposed copper plane. Saves costs on power supply heatsinks too :-) >Could you see it in your heart to get that specific part of the schematic >and send it to me? I wouldn't disclose it, and could move things forward a >little. Absoultely, but I need to go through it and back-annotate some of it first (I didn't update the schematic in a long time and there were some minor but important changes that looked like a good idea while I was doing the routing). There is also one other problem: The schematic is in OLD Orcad 1.0 and it's drawn to be readable, and not necesairly to produce a netlist. The reason I did it this way is that the copy of Protel I was using at the time had rather bad bugs that resulted in corruption with components with a large pin count. It became so annoying I stopped using the schematic editor altogether. Obviously, I was onto something there as even Protel stopped using it - the new one is quite different, and the reason why I have not yet converted the schematic to it, I have to redo the library definitions of the components speciffic to the design - which is basically all the chips! I really see no problem even in making that (or any other) part of the schematic public - the real important stuff is in the CPLD. But honestly, I am really not at all concerned that someone would steal the design - the question being, why? Still, the CPLD code stays closed, just in case all of this turns to be somehow lucrative (and yes, I can just see certain people doing a ROTFL having just read this - pity email doesn't convay my own cynical laugh here). It doesn't mean I won't share it with anyone willing to help with it, though! >I'll check on the Q60 web site for the specs on their implementation of >the ISA slot. Yes, that would certainly be prudent. Nasta
