Hi,

I am trying to design an 8MHz 65816 board and was working on the address decoding. However, when I looked at the 74ALS* datasheets I found that the propagation delay is in between a large interval. For example the 74ALS138 datasheet states a delay between 3ns and 22ns - which makes it extremely difficult to design a circuit. Add the 20ns worst case propagation of the 74als573 of 20ns you already are into the Phi2 high phase:

Phi2 @ 8MHz cycle time: 125ns, 62.5ns high, 62.5ns low
65816: t_ADS = time from Phi2 low to next address valid = 30ns
-> that leaves us with 32.5ns until Phi2 goes high. With a 74als573 we have 12.5ns left, so there is no room for even a 74als138!

Ok, just found that the "MAX" and "MIN" values refer to the "recommended" operating conditions - where "MAX" means a full load of 8mA for low output and -.4mA for high output (on a 74als138) - as the input draws 0.02mA on high level and -0.1mA on low level, for how many connected inputs is it save to assume a propagation delay <8ns (so I would have 4 gate delays time)? Does it mean one connected input means minimum propagation delay or is this value measured without load?

How do you handle fast designs like this? Are you using other logic families? What are your rules of thumb for this situation?

Many thanks
André

The only way you can handle this is to use custom programmable logic (e.g., FPGA, PLA, etc). Otherwise, you're running so close to tolerances that things will get flakey.

The alternative is to use multiple clock cycles per bus transaction, but widen the bus (e.g., this is the approach the 68000 took).

You mostly have to design around maximum propagation delays. Then if you're only making one unit, you can run the clock speed up until you start seeing problems, and back off a little for some safety zone for the final operating speed. The parts will usually be quite a bit faster, but they just don't guarantee it.

From my books, the max propagation delay of the worst combination of input to output of a '138 is:

LS 41ns, and that's with a 15pF load, whereas most of the others below are with a 50pF load!
HCT 40ns
HC 36ns
ALS 22ns
AC 12.5ns
ACT 12ns
VHC 10.1ns
F 8ns
AS ?

The AS section of my book with 74AS skips over the '138, but AS is much faster than ALS. You can get a feel for the speed comparison here with the '00:

LS 15, but with only 15pF load.
HCT 23
HC 16
ALS 11
F 5
AS 4.5

4011, the 4000-series quad NAND: 120ns @ 5V (use 4000-series logic only when you need higher voltages, like 12V!)

Lightening the output load will speed it up a little, but not much.

The '138 in my opinion is very overused in address decoding. It is an obvious solution, but not an efficient one. Even the '521 (or '688, same thing) 8-bit magnitude comparator is significantly faster and lets you for example forfeit a much smaller chunk of memory space for your I/O.

The '816 timing data seems to be overly conservative. Evidence of this is that WDC had at least one customer selling a product that ran an '816 at 20MHz, which according to the timing data looks impossible. But you know they couldn't have run a business on it if they got a very high percentage of 65816's that wouldn't perform consistently at that speed. I would like to get a variable delay line IC for the clock circuit and experiment to find the value that allows the fastest reliable operation.

In any case, keep the parts as close together as you can so the connections (especially with wire-wrap) will be as short as possible. Use breadboard with a ground plane.

You're referring to the SuperCPU! product for Commodore 64 and Commodore 128. The processor did run at 20MHz, was equipped with a MASSIVE heatsink if I recall (that dang thing got HOT), and coupled directly to an PGA chip of some kind. In other words, no ALS, ACT, or HCT logic anywhere between the CPU and the interface logic.

That is not good... When I look at the test load I see the resistive load and capacitance there is no way to calculate the delays for lighter loads?

Ok, I'm desperately trying to find a way...


Would have to use different clock oscillators for each frequency, but could do...


Are all the inputs TTL compatible? Have to look at that. Otherwise AC or AS would be a viable alternative.


Still looking... when I try to calculate the input resistance of an ALS I get R>2.7V/20uA=135kOhm. Don't know about the capacitance, though.
As far as I understand the output's internal resistor and the external capacitance determine the time constant of the exponential delay curve (loading/unloading the external capacitive load), while the ratio between the internal resistor and external resistive load determines the max signal voltage (for high) - which also helps with the propagation delay, as the exponential curve is scaled with it but the TTL input level is not.
So the main point is the capacitive load I guess, right?


I normally use the '688 to select the I/O address space, but where timing allows it a '138 has less board space and is basically set (for me) when I need multiple decoded outputs from the same inputs.



Yes, that's the SuperCPU for the C64.


I've been thinking about a logic probe that would take the logic IC input and then have some internal delay line to actually trigger the measurement of the logic IC output. Maybe simply a line of drivers with each of the driver outputs triggering the next measurement latch (quantize the time line though). Only problem would be the load that is put on the logic IC output. Maybe an OpAmp or other driver to decouple from the logic IC input and output would be necessary. But that was only thinking.


I am actually trying to directly design a PCB. For me that is more efficient than breadboarding at least for larger boards:

- the schematics then already is in reusable format, even with layout
- populating a PCB is definitely easier than wire-wrapping, even when fixing is required
- the associated costs keep me from building it to quickly :-) Instead I consequently do multiple reviews, which helps me keep quality high :-)

I learned from my 6502 CPU board, currently in revision 2.0H on the web - but I also have a now heavily patched 2.0B PCB at home - so I learned to more strictly check the schematics. The coprocessor board then worked right on the first try, and even the auxiliary CPU board worked (almost) on the first try now.

And the 65816 board is currently in the review process where I found these problems.

André

For the Kestrel-2, although schematics for the K2 will be drawn up in GSchem (of gEDA package), I'm going to explore doing my primary development directly with a homebrew PCB design tool based on Chuck Moore's grid-based design concept from OKAD. The reason is primarily self-education: after using gschem to design the circuit for the Kestrel 1 *then* trying to draw up PCB from those schematics, I found I had made a number of design errors which greatly complicates the layout. I want to see if it's easier to do the reverse: to design the PCB layout *first*, then update the schematics based on the PCB layout, for human consumption.

Note that this is the hardware analog of bottom-up programming.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Garth,



ok, got it :-)


Thanks for the info. I have another (german) page where I normally look into, but it was late. Will look at your links though!


Yes, I was just trying to simplify to get a good result....


Yes, I know that trick - only the memory I have has a single select input only :-)


I am trying to keep to 2 layers, to keep the costs low, and so far I have succeeded.

I am just trying to optimize my bang-for-the-buck - and buck here means available time. schematics quality assurance I can do out-of-town during evenings at the hotel, while hardware debugging takes time off my precious weekends...


Normally I start out by hand, but then quickly go to Cadsoft's Eagle of which I bought the non-profit version. It is somewhat difficult to use, although I probably have to discover more shortcuts.

But getting back to the original point: Looking at the logic equations for the address decoding and the timing requirements, I think I have to go for a GAL now, for the first time ever for me :-(
Normally I want to keep things a) simple and b) understandable so people can easily understand and reproduce it (another reason for max 2 layer). And therefore so far no GALs.

Now I have to build a GAL burner - anyone has experience with GALblast?
http://www.geocities.com/mwinterhoff/galblast.htm

Thanks
André

I think it's best to perhaps have two schematics: the initial design-time schematic, just to see how everything is going to be laid out, and the finished schematic that is camera-ready for publication. In between, I think the final PCB layout is the determining factor for the design.



According to the gschem author, and some of its most adherent users on the gEDA mailing list, gschem lacks many of the bugs that many other EDA tools have. You can see an example of the schematics it produces on my website, for the Kestrel 1p3 (see http://www.falvotech.com/content/kestrel/1p3/ ).

Note that I'm not deciding to reverse the design process because I find gschem to be buggy (there are known issues with gschem, like its inability to handle buses currently; but they're slowly being worked on). I'm doing it because I don't want to waste time designing something, wirewrapping or breadboarding it, then trying to deal with a layout that wasn't designed with physics in mind. A layout, being physical and tangible in nature, must be managed with a correspondingly adept CAD tool. Schematics lack *any* notation for physical layout -- it describes a logical view of the circuit. The PCB layout describes the physical view. Since physics always dominates the logical design, it makes sense to start out with a physical layout system.

Also, since gEDA tools use text files for EVERYTHING, it's possible to construct my PCB tool such that it emits some (very, very poorly laid out) gschem schematic symbols. Although it'll be a total mess to clean up, it at least has the benefit that it won't forget something, thus ensuring that what's really on the board always matches what's available in the schematic.

Companies have had a lot of trouble when managers don't want to "waste" engineers' time doing something like board layout, so the job was assigned to lower-paid mouse-pushers who had no concept of crosstalk, stray inductance and capacitance, transmission lines, IR drops across copper which was supposedly zero ohms, etc., and they were not allowed to bother the design engineers by asking questions.


Hey I like that! At least gerber and excellon files have been text since the beginning, but it would be nice if the storage format for schematic and board lay-out were standardized between brands and even human-readable (at least sort of) for debugging. It reminds me of when I've had to find bugs in a compiler we bought. I had to actually pick through the .hex file to find out that certain lines were getting skipped, even though those parts of the code were untouched from the last time that they compiled correctly. I never did figure out the pattern, but at least I was able to do some manual patches. It wouldn't have been possible if the file output weren't readable text.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for the links! A really good read to understand the effects - and why you have to design with the maximum delays.

André