If you really need a large quantity of RAM look at Garth's 4MB DIMM, which is built with 10ns SRAMs and is fast enough to stay with a 65C816 running at 20 MHz. The next version of my POC series will have one of these modules, along with an Atmel 1508as CPLD to handle the glue logic.
Should be good. At 10 ns I'd have some reservations about an intermediate connector and relatively long tracking, though.
Careful board layout is the key. Bus drivers might be necessary, but that's something that ties back to board layout. 8Bit used the 4MB DIMM in his SBC-3 and reported good results.
Parts are on both sides, and the bypass capacitors are embedded in the PCB near the connector and directly under the die of each IC. Being able to stand modules up close together keeps the total length of any given net shorter than it would be if you put them all on the mother board. The layout is really just about the best it could be for the ICs' pinout and size. I'm confident that the modules will perform at least as good as you could get the same ICs to work on your mother board, if not better. I have quite a bit of experience designing mixed-signal PCBs with audio/digital/SMPSs/RF, very successful at avoiding crosstalk and keeping good behavior of all parts of the circuits. In the last one, I had a 2.4GHz antenna transmitting about 1/4" away from an embedded processor and switching power supply, and 1/2" away from analog parts. It worked very well, exceeding the boss's dreams.
Parts are on both sides, and the bypass capacitors are embedded in the PCB near the connector and directly under the die of each IC. Being able to stand modules up close together keeps the total length of any given net shorter than it would be if you put them all on the mother board. The layout is really just about the best it could be for the ICs' pinout and size. I'm confident that the modules will perform at least as good as you could get the same ICs to work on your mother board, if not better. I have quite a bit of experience designing mixed-signal PCBs with audio/digital/SMPSs/RF, very successful at avoiding crosstalk and keeping good behavior of all parts of the circuits. In the last one, I had a 2.4GHz antenna transmitting about 1/4" away from an embedded processor and switching power supply, and 1/2" away from analog parts. It worked very well, exceeding the boss's dreams.
We may know in the not-too-distant future if your DIMM can run at with a 65C816 at full speed. I've decided to switch gears and get cracking on building POC V2. To paraphrase a Depression Era slogan as folks migrated to California, "Twenty megahertz or bust!"
We may know in the not-too-distant future if your DIMM can run at with a 65C816 at full speed. I've decided to switch gears and get cracking on building POC V2. To paraphrase a Depression Era slogan as folks migrated to California, "Twenty megahertz or bust!"
See my avatar picture for a design of mine that runs the 65C816 at 14.7 MHz on 55 ns SRAM. It sure is borderline. After all, at 14.7 MHz, a half-cycle is only 34 ns, so anything based on phi2 is not enough time. Thankfully, SRAMs start their address decoding spontaneously, outside the strobe, so it actually has most of the full cycle.
We may know in the not-too-distant future if your DIMM can run at with a 65C816 at full speed. I've decided to switch gears and get cracking on building POC V2. To paraphrase a Depression Era slogan as folks migrated to California, "Twenty megahertz or bust!"
See my avatar picture for a design of mine that runs the 65C816 at 14.7 MHz on 55 ns SRAM. It sure is borderline. After all, at 14.7 MHz, a half-cycle is only 34 ns, so anything based on phi2 is not enough time. Thankfully, SRAMs start their address decoding spontaneously, outside the strobe, so it actually has most of the full cycle.
The question isn't whether the SRAM can do it. It's whether the bus loading caused by the DIMM will sabotage the quest for full throttle.
See my avatar picture for a design of mine that runs the 65C816 at 14.7 MHz on 55 ns SRAM. It sure is borderline. After all, at 14.7 MHz, a half-cycle is only 34 ns, so anything based on phi2 is not enough time. Thankfully, SRAMs start their address decoding spontaneously, outside the strobe, so it actually has most of the full cycle.
According to the '816 data sheet timing specifications, there's only 30ns guaranteed for tACC on a 14MHz '816. tADS can be as high as 30ns and tBAS can be as high as 33ns, eating up nearly the entire phase-1 time. The read data setup time tDSR (the amount of time data has to be ready before the fall of phase 2) is specified to be 10ns max. Glue logic further eats into the time budget. Fortunately, actual parts are usually much faster than the specifications say, and you're probably also not running things at the upper temperature extreme where they're the slowest. Otherwise, 55ns SRAM would not stand a chance of running on an '816 at 14.7MHz, according to the specs.
For any system though, it's always interesting to slowly raise the clock speed until you start having problems, the back it down at least 20% so you know how fast it really can go and how much headroom you have.
On the topic (or should I say off-topic ) of '816 timing, I agree the WDC timing spec is conservative. Also not terribly easy to comprehend!
Allow me to re-post (from this thread) my own edited version of Figure 4-1 from the '816 Data Sheet (Sept 2010 version). To put all the various delays in perspective I squeezed and stretched things so that the diagram is now approximately to scale along the horizontal axis. 5V operation is assumed.
-- Jeff
[Edit: fix image so it will enlarge]
Attachments
Last edited by Dr Jefyll on Thu Dec 12, 2013 1:04 am, edited 1 time in total.
According to the '816 data sheet timing specifications, there's only 30ns guaranteed for tACC on a 14MHz '816. tADS can be as high as 30ns and tBAS can be as high as 33ns, eating up nearly the entire phase-1 time.
I saw this a few days ago while I was doing a timing analysis on the decoding scheme that I'm planning on trying, and was shocked. With tPWL at 35ns and tADS at 30ns you have 5ns to set the chip selects on your 6522 before phi2 heads north for the summer. If you also want to involve the bank address, tBAS at 33ns means you have 2ns left to set those chip selects. Or, at least, to trigger a wait-state or something. I guess the other angle is to delay the phi2 signal going to the VIA, I haven't looked into how that works out for read/write timing.
On the topic (or should I say off-topic ) of '816 timing, I agree the WDC timing spec is conservative. Also not terribly easy to comprehend!
Allow me to re-post (from this thread) my own edited version of Figure 4-1 from the '816 Data Sheet (Sept 2010 version). To put all the various delays in perspective I squeezed and stretched things so that the diagram is now approximately to scale along the horizontal axis. 5V operation is assumed.
-- Jeff
[Edit: fix image so it will enlarge]
BTW, I now have an 18 × 24 version of that on my office wall.
According to the '816 data sheet timing specifications, there's only 30ns guaranteed for tACC on a 14MHz '816. tADS can be as high as 30ns and tBAS can be as high as 33ns, eating up nearly the entire phase-1 time.
I saw this a few days ago while I was doing a timing analysis on the decoding scheme that I'm planning on trying, and was shocked. With tPWL at 35ns and tADS at 30ns you have 5ns to set the chip selects on your 6522 before phi2 heads north for the summer. If you also want to involve the bank address, tBAS at 33ns means you have 2ns left to set those chip selects. Or, at least, to trigger a wait-state or something. I guess the other angle is to delay the phi2 signal going to the VIA, I haven't looked into how that works out for read/write timing.
The CMD SuperCPU accelerator cartridge for the C64, which has a 65C816 running at 20 MHZ, was by all accounts stable at that speed. Therefore, something was rotten in the woodpile, timing-wise. I've long been suspect of the quoted tBAS number in particular, as the resulting 2ns until the rise of Ø2 would be unworkable, even with the fastest PLDs currently available. CMD designed their cartridge nearly 20 years ago, so you'd think it would have been more difficult then than now to achieve satisfactory operation. Yet they did, and supported 16MB of RAM to boot.
Wow! That's tight timing. I was left wondering if the '816 does anything special when the bank address changes ?
Am I right in thinking that the bank address is basically stable much of the time, given that it's high order address bits ?
For instance, if the '816 held the bank address for a cycle on a bank switch would that help (so that the external latch had time to change) ?
The bank address goes out on the data bus during phase 1, so the data bus carries two different bytes in each clock cycle, even though the program bank does not change very often. The program bank and the data bank don't have to be the same though, so the bank number on the bus could be bouncing around like crazy; and then there are the long addressing modes which can address things in any bank regardless of the current program bank or current data bank, and there's also direct-page, stack, and interrupt access which are always in bank 0, regardless of the previously mentioned accesses. It would sure have made things easier if they had just started with a 48-pin DIP and 52-pin PLCC, and not multiplexed the high 8 address bits!
According to the '816 data sheet timing specifications, there's only 30ns guaranteed for tACC on a 14MHz '816. tADS can be as high as 30ns and tBAS can be as high as 33ns, eating up nearly the entire phase-1 time. The read data setup time tDSR (the amount of time data has to be ready before the fall of phase 2) is specified to be 10ns max. Glue logic further eats into the time budget. Fortunately, actual parts are usually much faster than the specifications say, and you're probably also not running things at the upper temperature extreme where they're the slowest. Otherwise, 55ns SRAM would not stand a chance of running on an '816 at 14.7MHz, according to the specs.
You should not put too much faith in timing information in datasheets. If timing is tight, you should measure.
In my case, by logic analysis I found that, even though address valid should come close to phi2, it actually comes shortly after phi1. Bank address (via the databus) same thing. However, for the 816, the inevitable latching of the bank address consumes some of the timing budget, and makes it tight depending on the SRAM's address decoding strategy.
Last edited by Windfall on Thu Dec 12, 2013 10:15 am, edited 2 times in total.
We may know in the not-too-distant future if your DIMM can run at with a 65C816 at full speed. I've decided to switch gears and get cracking on building POC V2. To paraphrase a Depression Era slogan as folks migrated to California, "Twenty megahertz or bust!"
See my avatar picture for a design of mine that runs the 65C816 at 14.7 MHz on 55 ns SRAM. It sure is borderline. After all, at 14.7 MHz, a half-cycle is only 34 ns, so anything based on phi2 is not enough time. Thankfully, SRAMs start their address decoding spontaneously, outside the strobe, so it actually has most of the full cycle.
The question isn't whether the SRAM can do it. It's whether the bus loading caused by the DIMM will sabotage the quest for full throttle.
True. But it should be interesting to know that 55 nS SRAM is borderline at 14.7 MHz. Extrapolate from that.
I once tried 20ns SRAM at 22 MHz (different clock divider ...) and it did run. But it was not stable. Whether that was CPU, SRAM or something else is anyone's guess.
You should not put too much faith in timing information in datasheets. If timing is tight, you should measure.
It is always safe to go with the datasheet, but there is often far more performance that can be squeezed out beyond what the datasheet guarantees. Without measuring, it is impossible to know how much. It won't be worse than the data sheet says though.
Quote:
In my case, by logic analysis I found that, even though address valid should come close to phi2, it actually comes shortly after phi1. Bank address (via the databus) same thing. However, for the 816, the inevitable latching of the bank address consumes some of the timing budget, and makes it tight depending on the SRAM's address decoding strategy.
How much actual delay (in ns) did you find, compared to the datasheet? It would be nice to find out that the margin between the datasheet and the reality is huge.
On the '816, the bank address byte is specified (the reality might be different) to come out at about the same time the 16 bits of the address bus do; but the latch will take a few ns of propagation delay. It is a transparent latch though, meaning that the bank byte can still come through long before the rising edge of phase 2. It doesn't wait for the edge.
Quote:
True. But it should be interesting to know that 55 nS SRAM is borderline at 14.7 MHz. Extrapolate from that.
55ns just means that it's guaranteed not to be any slower than 55ns. It will probably be faster, even at the high temperature extreme and the low end of the voltage range (4.75V?). Bring it down to room temperature and up to 5V, and it's definitely faster than 55ns.
) of '816 timing, I agree the WDC timing spec is conservative. Also not terribly easy to comprehend!
