My Mainboard Design

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 12, 2011 7:04 pm

--unrelated: BDD check PM please--

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 12, 2011 9:55 pm

I'm sorry to have interrupted the flow of your thread Karatorian, but...

BigDumbDinosaur wrote:

...On the other hand, R/W should be qualified by Ø2 so a write only occurs while Ø2 is high...

This is a solid foundation I use on all my circuits now... Most memory devices today use a WE signal (a clue), whether active low or active high.

In the past, I've also used O2 with an address select signal. And while it does work for slower speeds, when you start to push CPU phase 2 speed limits, you will run into problems.

GARTHWILSON · Post by **GARTHWILSON** » Tue Apr 12, 2011 10:16 pm

Quote:

On the other hand, R/W should be qualified by Ø2 so a write only occurs while Ø2 is high

That's true of memory if it is enabled before Φ2 goes high, to get more access time; but again, some I/O ICs like the 6522 require that R/W\ be valid and stable before Φ2 goes high.

BigDumbDinosaur · Post by **BigDumbDinosaur** » Wed Apr 13, 2011 4:23 am

GARTHWILSON wrote:

Quote:

On the other hand, R/W should be qualified by Ø2 so a write only occurs while Ø2 is high

That's true of memory if it is enabled before Φ2 goes high, to get more access time; but again, some I/O ICs like the 6522 require that R/W\ be valid and stable before Φ2 goes high.

That can easily be accommodated by tying R/W directly to the 6522 and gating it with Ø2 for all other devices.

Karatorian · Post by **Karatorian** » Wed Apr 13, 2011 6:41 pm

GARTHWILSON wrote:

The SRAM's OE\, CS\, and WE\ inputs are just that, meaning active low, not active high. ... You'll need to change some logic.

Thanks for pointing that out. The SRAM's /E pin (/CE) should be tied to ground, not Vcc, and likewise with the FRAM's /G (/OE) pin. I somehow got them mixed up when I was rearranging things. I think the rest of the SRAM's logic is correct.

The OR gates are supposed to function as negative logic AND gates. If the clock is low and A15 is low, /OE is low. Likewise, if the clock is low and /RW is low, /W is low. Unless I've made a mistake somewhere, it should work.

(I changed the RAM's pin names to /E, and /G, following the JEDEC standard, which prefers those names over /CE and /OE. However it seems that no one actually uses them, so perhaps I should change them back.)

GARTHWILSON wrote:

Although the 65816's Φ2 pin is an input, on the 6502 it's an output. Input must come through Φ0 on the 6502. It looks like you don't have any clock input.

The W65C02S's datasheet labels the clock pins PHI2, PHI2O, and PHI1O, with the PHI*O pins being the outputs. I'll double check, but I'm fairly sure that I've got the right pin. Perhaps I should change the label to PHI0...

BigDumbDinosaur wrote:

GARTHWILSON wrote:

The FRAM's enable circuit has an awful lot of gate delays. See if you can reduce it.

Yes it does. If you absolutely must have all that logic in the circuit, you should use 74ABT or 74F glue to keep the prop delays out of the stratosphere.

The FRAM's enable circuit is kinda complicated because of the write protection. The logic is somewhat obscured by the all NOR gate implementation. I'll post the original circuit I derived that from and perhaps we can come up with a way to cut it down.

GARTHWILSON wrote:

just a note: Some I/O ICs like the 6522 require that the RS and CS lines be valid and stable before Φ2 rises; meaning you can't select them with a circuit that goes through your '138 which is enabled by Φ2.

BigDumbDinosaur wrote:

I've often said it, with some here disagreeing, but will reiterate. Device selection should not be qualified by Ø2. Doing so needlessly limits the maximum speed at which the circuit can run.

The reason I decided to make the '138 clock qualified is that the FRAM latches the address lines when /CE goes low. If, while the address lines are in transition, /CE got enabled, but the rest of the address wasn't stable yet, the wrong address could get latched, which I want to avoid. Perhaps with the gate delays, that's not likely to be a problem, but it seems like a kludge to depend on that.

I originally had the '183 only enabled by the A15 line, but I changed it because it simplified the FRAM's select logic. I also like the idea that when one of the IO selectors (Yx on the '183, Px on the bus) goes low, the address lines are valid.

I guess it's a conflict between synchronous and asynchronous devices. Synchronous devices like the 6522 expect their select lines to be valid when clocked. On the other hand, asynchronous devices aren't clocked and (at least some) expect their address lines to be valid when they are selected.

It seems the consensus here is strongly against qualifying device selection with PHI2. In light of that, I suppose I ought to redesign the device selection. Making the '138 not qualified by PHI2 is easy enough. The problem is that the FRAM selection currently depends on the existing behavior.

GARTHWILSON wrote:

As to whether the RST\ line will be pulled down by the LED: That depends on the resistor value you choose for it. Even with no resistor at all, the LED will not pull the line down low enough to be a valid 0, but the MAX6804 may hardly be able to pull it up hard enough to get a valid 1 to let the processor run. (I have not looked up the current-- I'll let you do that.)

Well, I think I'll need a resistor as IIRC, most LEDs want somewhat less than five volts. I'll have to go look at the 6804's datasheet again and see what I can come up with. I suppose the LED's not really necessary, but it seems that it might be nice to have some sort of indication of whether the power is good or not.

GARTHWILSON wrote:

For low operating speeds, the rise and fall times for most things are not very critical since they are level-sensitive.

The reason I'm worried about the rise times is that if the input to a CMOS circuit spends too long between 0.8 and 2v, it leads to excessive current draw, which causes overheating and can damage the chip. The TI document I linked to earlier explains the details.

GARTHWILSON wrote:

Having the oscillator's duty cycle at 50% is not necessary if you're well below the maximum operating speed anyway.

Due to the speed of the FRAM, I'll be limited to a little over 7MHz at the most.

GARTHWILSON wrote:

For the connectors to another board, it would be good to have more grounds sprinkled in, or at least move the ground pins you do have to a quarter of the way in from the ends (ie, half way to the middle of the connector) so that the return path for any given signal is not so far from the signal pin.

BigDumbDinosaur wrote:

Perhaps you can take a cue from "narrow" SCSI. In that layout, every other line is a ground. Hence each signal is separated from the next by a ground, making for a stable, high performance bus that will easily run at 20 MHz.

I have quite a few lines that are currently unused, so I can add additional grounds without too much difficulty. I would like to keep some pins for available for future expansion, I'll see what I can come up with. I think the PC/104 bus only has around four grounds and it seems to work fine, but I'll look into it again.

BigDumbDinosaur wrote:

Lastly, and I'm sure Garth and others will agree with me on this, try not to let too much creeping featurism get into your first effort.

I'm trying not to go overboard. The two things I've added that might be more than is strictly required are the FRAM write protection and some support for in-circuit programming (the CLKE and /REST lines).

The write protection, which seemed like such a simple idea at first, is quickly becoming complicated and I might just scrap it. However, it does seem like it'd be a nice thing to have when developing my software.

The in-circuit programming stuff is a bit complex. I realized I needed some way to program the FRAM in the first place, so I started to design a programmer. While I was designing the bus, I realized that I could (with a few modifications) just as easily hook the programmer up to the bus as a socket (I'm planning on doing both now). However, to do that, it'd need to override the clock. Luckily the can oscillators I'm planning on using have an enable line, so it's not that complicated to do so. The /REST line was just gravy, but easy to do with the right reset controller.

Perhaps I am going overboard. What do you think?

BigEd · Post by **BigEd** » Wed Apr 13, 2011 7:07 pm

Karatorian wrote:

It seems the consensus here is strongly against qualifying device selection with PHI2.

I don't want to be controversial, but I'm not sure this is true. Garth has a specific point about 6522, and BDD has a general rule which he acknowledges isn't used by everyone.

My feeling is that I've seen conversations but I haven't seen a tutorial explaining the various types of devices and the tradeoffs being dealt with by each approach - but I know that it takes a lot of effort to put such a thing together, and I have no right to expect anyone to do it.

Karatorian · Post by **Karatorian** » Wed Apr 13, 2011 7:20 pm

BigEd wrote:

I don't want to be controversial, but I'm not sure this is true. Garth has a specific point about 6522, and BDD has a general rule which he acknowledges isn't used by everyone.

So, out of curiosity, do you qualify device selection based on PHI2?

Quote:

My feeling is that I've seen conversations but I haven't seen a tutorial explaining the various types of devices and the tradeoffs being dealt with by each approach - but I know that it takes a lot of effort to put such a thing together, and I have no right to expect anyone to do it.

I'm still not entirely sure which way is the best. However, if I qualify device selection based on PHI2, then I cannot use any device where that won't work. On the other hand, if I don't, I have the option of adding PHI2 qualification for any device that requires it. However, that adds more propagation delays. Perhaps once I get my basic IO board worked out, I'll have a better idea of the tradeoffs.

Ok, as promised, here's the FRAM's select logic:

6502.org wrote:

Image no longer available: http://static.karatorian.org/hardware/fram-decode.png

The top version has standard logic symbols and the bottom version has the equivalent inverted symbols, which, as all these lines are all active low, may make things easier to follow.

The jumpers are to enable or disable write protection for the two separate pages. The original version without separate write protection for the two banks has the same number of gate delays, but is arranged a little bit differently.

I'll try to think about how I can improve this myself, but I'd appreciate any suggestions you may have. Keep in mind that if I don't qualify device IO with PHI2, then I'll have to add it to the FRAM specifically.

GARTHWILSON · Post by **GARTHWILSON** » Wed Apr 13, 2011 8:28 pm

Quote:

The OR gates are supposed to function as negative logic AND gates. If the clock is low and A15 is low, /OE is low. Likewise, if the clock is low and /RW is low, /W is low. Unless I've made a mistake somewhere, it should work.

OE\ or W\ need to be low when Φ2 is high, not low.

Quote:

(I changed the RAM's pin names to /E, and /G, following the JEDEC standard, which prefers those names over /CE and /OE. However it seems that no one actually uses them, so perhaps I should change them back.)

I've always seen them in the data books as CE and OE, not E and G, so I go with that. When I was in school (not long after Columbus visited this hemisphere), it was always said, "chip-enable-not" (with the "not" at the end), and since there's no practical way to put the overbar on in text, I put the slash at the end, backwards like OrCAD does, or at least did when I was using it constantly in the late 1980's and early 1990's-- not that OrCAD knows how to do things right, since they still don't know how to draw the schematic symbol for a resistor after all these years, or that it really matters, as long as we are communicating.

Quote:

The W65C02S's datasheet labels the clock pins PHI2, PHI2O, and PHI1O, with the PHI*O pins being the outputs. I'll double check, but I'm fairly sure that I've got the right pin. Perhaps I should change the label to PHI0...

Yes, I forgot some call Φ0 "Φ2 in". On the DIP, it's pin 37.

On the Φ2 qualification, try to do it later in the glue logic, so there aren't so many gate delays between Φ2 and the device you're enabling. Also, instead of bring Φ2 into everything, bring it in only for things that need it. I don't know if the 6522 is particularly synchronous like you're saying, because the time it needs for the RS and CS lines to be valid before Φ2 rises suggests it needs time to do something with them before Φ2 rises, not just a set-up time for latching. Models of the inside of the 6522 are not common like they are for the 6502 though.

Quote:

As to whether the RST\ line will be pulled down by the LED: That depends on the resistor value you choose for it. Even with no resistor at all, the LED will not pull the line down low enough to be a valid 0, but the MAX6804 may hardly be able to pull it up hard enough to get a valid 1 to let the processor run. (I have not looked up the current-- I'll let you do that.)

Well, I think I'll need a resistor as IIRC, most LEDs want somewhat less than five volts. I'll have to go look at the 6804's datasheet again and see what I can come up with. I suppose the LED's not really necessary, but it seems that it might be nice to have some sort of indication of whether the power is good or not.

My apologies-- I was not recommending that you go without a resistor. IIRC, red LEDs take somewhere around 1.7V and green maybe 2.3V. Blue was something like 3.3, but don't quote me on that. They are indeed diodes though, so you do need some way to control the current, and having the IC's output current limit is not a good way to do that, especially since on a red LED that would mean the LED would hold that line down a little too low to be considered a valid logic "1". 3 to 5mA would be plenty visible, and if the IC could pull it up to 4V at 5mA, then (4-1.7)V/5mA=460 ohms, and 470 is a standard value so that would work fine-- if the RST IC can pull up that much current ok.

Quote:

The reason I'm worried about the rise times is that if the input to a CMOS circuit spends too long between 0.8 and 2v, it leads to excessive current draw, which causes overheating and can damage the chip. The TI document I linked to earlier explains the details.

I'ved used LM339 comparators for voltage translation like on my PIC programmer where I can check the programming at anywhere from 2V to 6V yet it's interfaced to the 5V CMOS 65c22 on the workbench computer. This comparator is pretty slow in slew rate but it's easy to work with for a wide range of voltages. If you do all the tricks right, it's still limited to dozens of ns best-case, such that the fastest I've been able to toggle the output with a somewhat squarish wave was not much over 4MHz; but I don't notice any increase in current from it. Granted, it's not on a data or address bus, and I don't have 24 or more of them, but I have used it in many applications like that described above, with no current or heating problems on the CMOS inputs it goes to. IOW, I wouldn't worry about it. The slew rate is incorporated into the propagation delays printed for various 74xx logic families in my National Semiconductor (now Fairchild) data books, so if the prop delay is acceptable, the slew rate will be too.

Quote:

Lastly, and I'm sure Garth and others will agree with me on this, try not to let too much creeping featurism get into your first effort.

I'm trying not to go overboard.

I definitely agree with BDD here. Your ideas will keep evolving, even improving, even after you've started building, meaning you will tend to always be dissatisfied with last week's ideas that you're busy building today. They also tend to become so complex that you'll never live long enough to finish it and get anything at all going. Been there, done that. What I've found works better, for more reasons than the newcomer would dream of, is to do a basic design that can be expanded later, but to plan on many of the features you add later to be interfaced through the I/O ICs like the 6522 instead of directly on the bus.

Also, plan to take advantage of the synchronous-serial ICs. There are thousands of them on the market, in SPI, I²C, Microwire, other 2- and 3-wire interfaces, even dumb shift registers like the 74xx165 and '595. Besides not loading the processor's buses, these have a big advantage in ease of construction because there are so few lines to connect, and without so many pins, they take a lot less board space too. Daryl (8BIT here on the forum) sells a 65SPI IC which works like a standard 65-family I/O IC with an SPI port for good speed. The 74xx164 and '595 can be connected directly to the 6522's synchronous-serial port. But even without those, you can bit-bang these interfaces very easily-- far faster and more easily than trying to bit-bang an RS-232 port. You can even get a floating-point coprocessor with a serial interface for Pete's sake. Look into our 65SIB also, a very flexible, multi-purpose, multi-protocol, serial interface bus.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Apr 13, 2011 8:51 pm

GARTHWILSON wrote:

... for various 74xx logic families in my National Semiconductor (now Fairchild) data books...

Now TI owns National Semiconductor as of a few days ago. Just FYI...

GARTHWILSON · Post by **GARTHWILSON** » Wed Apr 13, 2011 8:59 pm

Quote:

Now TI owns National Semiconductor as of a few days ago. Just FYI...

Yeah, I got the email last week. The logic stuff was spun off to Fairchild quite a few years ago though, and I don't think Fairchild is part of TI. I was disappointed to see that TI got National, because when I was needing parts the most, back in the late 1980's and early 1990's, TI was much harder to get data books or samples from. National was just much easier to do business with, so they got our business.

fachat · Post by **fachat** » Wed Apr 13, 2011 9:43 pm

Edit: cleaned up the quotes as mentioned below /Edit

Karatorian wrote:

I guess it's a conflict between synchronous and asynchronous devices. Synchronous devices like the 6522 expect their select lines to be valid when clocked. On the other hand, asynchronous devices aren't clocked and (at least some) expect their address lines to be valid when they are selected.

It seems the consensus here is strongly against qualifying device selection with PHI2. In light of that, I suppose I ought to redesign the device selection. Making the '138 not qualified by PHI2 is easy enough. The problem is that the FRAM selection currently depends on the existing behavior.

I'd say it depends. On a device that has its own Phi2 input, I'd not qualify the select lines for the reasons mentioned (although the only one I know is the 6522). Edit: For most RAM chips I would recommend you do qualify the select signal with phi2. /Edit

But my general advice is: always look into the datasheets of the chips you are using. You might have a seemingly asynchronous RAM, where you maybe don't want to qualify the select signal with Phi2, the internal operations may require stable address lines (e.g. row/col selection). Also you have to note that r/-w has the same timing constraints as the address lines. If by any chance r/-w is not stable enough before you assert the select signal, you may even generate a stray write.

So again my advice: look into the datasheets.

André

fachat · Post by **fachat** » Wed Apr 13, 2011 9:51 pm

fachat wrote:

If by any chance r/-w is not stable enough before you assert the select signal, you may even generate a stray write.

Please also note that if you don't qualify the select line, this may not only happen at the start of a cycle, it may even happen because the _previous_ cycle was a write and the select line was asserted too quickly.

Something similar happened to me when I did a DRAM board. Phi1 was used for video refresh reads, Phi2 for CPU access. Only that R/-W was asserted too quickly at start of Phi2, while the actual read access wasn't completely finished due to the complex /RAS and /CAS generation delay - but the early R/-W sometimes converted the video read into a write access!

So again my advice: consult the datasheets

André

GARTHWILSON · Post by **GARTHWILSON** » Wed Apr 13, 2011 9:55 pm

fachat wrote:

Karatorian wrote:

GARTHWILSON wrote:

I guess it's a conflict between synchronous and asynchronous devices. Synchronous devices like the 6522 expect their select lines to be valid when clocked. On the other hand, asynchronous devices aren't clocked and (at least some) expect their address lines to be valid when they are selected.

It seems the consensus here is strongly against qualifying device selection with PHI2. In light of that, I suppose I ought to redesign the device selection. Making the '138 not qualified by PHI2 is easy enough. The problem is that the FRAM selection currently depends on the existing behavior.

To clarify the quotes: Karatorian is the one who said that.

BigDumbDinosaur · Post by **BigDumbDinosaur** » Thu Apr 14, 2011 1:06 am

The only thing that I qualify with Ø2 in my POC unit is RWB (MPU output). If RWB is high it is used without qualification. If RWB is low, Ø2 must be high before the affected hardware "sees" that a write is in progress. This arrangement reliably functions at 15 MHz on my POC unit.

The theory behind this is that when the MPU is reading data, it doesn't actually sample D0-D7 until very late during Ø2 high (look at tDHR on the timing diagram). Therefore, any glitches on D0-D7 caused by a device responding to a chip select and address bus pattern occur well before the MPU goes looking for data.

Also, the MPU requires that D0-D7 stay valid for a short time after Ø2 goes low again. If you deselect your device when Ø2 goes low you may cause the MPU to get corrupted data, because you haven't met the data hold time.

On the other hand, write has to qualified by Ø2 because the address bus (and hence chip selects) does not become valid until midway through Ø2 low. D0-D7 become valid even later, and in the case of the 65C816, D0-D7 is really BA0-BA7 while Ø2 is low. Therefore, the affected device should be selected as soon as the address bus goes valid but not written until Ø2 goes high.

Note that 65xx family peripheral silicon like the 65C21, 65C22 and 65C51 are exceptions to the above "qualify writes with Ø2 high" rule. As they are synchronous to Ø2, they will not sample the data bus until Ø2 goes high, and will hold the data until shortly after Ø2 goes low again (again, see the timing diagrams).

As I earlier said, qualifying chip selects with Ø2 needlessly limits the maximum usable bus speed. I've never run into anything that can be connected to the 65xx bus (excepting the above peripheral devices) with a requirement that chip selects must be slaved to the clock.

fachat · Post by **fachat** » Thu Apr 14, 2011 7:18 am

BigDumbDinosaur wrote:

The only thing that I qualify with Ø2 in my POC unit is RWB (MPU output). If RWB is high it is used without qualification. If RWB is low, Ø2 must be high before the affected hardware "sees" that a write is in progress. This arrangement reliably functions at 15 MHz on my POC unit.

I did that and it bit me with a Flash-ROM chip (for programming write accesses), where I didn't qualify /SEL, but did qualify R/-W. Looking into the datasheet revealed that the chip obviously gated R/-W when /SEL became active (low).

I am also not sure if 65xx chips would handle that well either, I never tried, but I also did not check with the datasheets.

André