From: Bil Herd (bherd_at_ids-business.com)
Date: 2007-05-28 17:43:00
Hi Andre,
There are three aspects to making DRAMs work; absolutely getting all of the timings correct, the environmental aspects of noises, glitches and terminations, the architectural issues such as access mode and DRAM organization, refresh, etc.
For DRAM timings you absolutely need a stable source of control signals; you need to be able to generate /RAS, /CAD, /WE and the direction controls. You need to be able to multiplex the addresses to coincide with those major controls, and then you need to cleanly get the signals propagated into and out of the arrays.
Lastly, the logical function of DRAM's may not be the same. The old CBM where the simplest use of drams, we didn't use nibble or page mode accesses, we didn't rely on self refresh devices. With that said I don't know what the underlying architecture is of the SIMMS you mentioned.
I don't know what you are doing for DRAM timing signals, are you tapping the VIC chip's signals?
Brief tutorial on olde DRAM use, based on 25 year old memory:
/RAS and /CAS need to go high per the precharge specs
Address set up prior to /RAS per Row Address Setup Spec (I have seen this spec blown a lot)
/RAS goes low and addresses are held for Row Address Hold (RAH) time.
Only after RAH can you flip the control signal for the address buss mux, we used to create a signal between /RAS and /CAS called MUX for this purpose.
Addresses, Data and /WE set up before /CAS. You can delay some of this for a late write but you need to know what your doing so best is you declare a write cycle prior to /CAS falling.
For reads, data comes out one access time after TCAS (Time CAS Access), there is also a half dozen other specs that determine when data is valid, such as the shortest time from RAS, etc.
For a write cycle you have to hold write data per the specs, which are related to CAS not PHI. As CAS is generally held later than PHI for writes you may end up latching the data.
Every now and then you need to generate refresh addresses for the dynamic part of DRAM.
CAREFULL layout and series termination of signals is a must. The one jumper on the C128 production was due to a single reflecting node on one address line when the Z80 was the active CPU. The jumper is in parallel to a trace on the board that is otherwise perfectly fine except there is a glitch that "stands" on the line at a certain point in time under certain circumstances. My boss didn't believe me and ran 10,000 units over the weekend to prove that this really did fix the "CPM Loading problem", it was more sensitive on one brand of multiplexers than the other. Also had a problem early on when multiplexing from all ones to all zeros's except for one bit, the last bit would get drug to zero also.
As you can see DRAMS are dynamic creatures. Makes static RAMS look like a pretty simple alternative.
I used to say that engineers should have to get certified to do certain parts of a design and that there should definitely be a DRAM badge/stamp before tackling DRAMS for production release.... tricky critters on the outside, very stable once you get your hands around it. Think of an array of capacitors with leakage and you have a DRAM array. BTW, I have never been to school for any of this (electronics or college, etc), it is careful study of the specs and then some lumps along the way. We didn't have simulators back then, we started with timing analysis on graph paper and then later used visicalc type programs, there are about 16 specs you need to account for if memory serves.
Regards,
Bil Herd
-----Original Message-----
From: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se] On Behalf Of "André Fachat"
Sent: Monday, May 28, 2007 10:14 AM
To: cbm-hackers@ling.gu.se
Subject: Re: RE: How to design non-trivial cartridges for c-64?
Hi Bil,
many thanks for the engineering lesson :-)
While I am able to make a coprocessor, or a second processor
that takes over the bus on some condition work almost on the first
try, I tend to miserably fail with dRAM due to timing problems.
So maybe I am one of those you mentioned, who get everything
right but... - but then again, I do it for a hobby :-)
Currently I am working on a RAMdisk, re-cycling old 30-pin SIMM
memory modules, and I am desperate because I cannot make it work.
Probably because the dRAM has much stricter timing requirements.
Compared to this, 65xx and 74LSxxx parts seem to be much more
forgiving.
Also the SIMM modules draw a lot of power, and I had to add an
extra power supply connector to the board to keep the voltage monitor
(7705) from asserting RESET on a low voltage condition.
Maybe this power hungryness also puts strains on signal lines...
I will try the Phi0-approch you mentioned, though.
Thanks again
André
P.S.: my system is here: http://www.6502.org/users/andre/csa/index.html
(the ramdisk is not yet there, though)
-------- Original-Nachricht --------
Datum: Mon, 28 May 2007 09:33:03 -0400
Von: "Bil Herd" <bherd@ids-business.com>
An: cbm-hackers@ling.gu.se
Betreff: RE: How to design non-trivial cartridges for c-64?
> Hi Andre
>
> Bear in mind that I was from the production world where I had to pay
> strict attention to specs or get thousands of failures, not to mention the range
> of temperatures, voltages and related part specs that we had to account
> for. (as it was parts didn't always pay attention to specs and we would get
> thousands of failures). You can often get designs to work just fine in low
> quantities at room temperature under a stable voltage... I.E. some things I
> couldn't do will work just fine for experimenters.
>
> Using a buffer to hold data valid longer was not a useful approach back
> then as there generally were no valid minimum times on a chip, I.E. your best
> off to assume that the output goes invalid almost immediately after the
> input goes invalid. I think in terms of data valid propagation and invalid
> propagation, hoping a buffer reliably holds the exact same input after
> currents start dumping and nodes start discharging is a bad bet when multiplied
> times 100,000. Signetics buffers used to Hi-Z with a vengeance as an
> example.
>
> A variation on this is where someone will but a buffer between the clock
> and data lines of a latch hoping to create hold time, problem is that
> variations in layout, pin capacitance, etc can result in -1 ns hold time worse
> case. (not only no delay but negative delay)
>
> You also slow things time by the TProp of the buffer so at best you pick
> up a hold of something like 3ns but slow things down by an additional 20ns.
>
> This was a recurring stickyness to 6502 designs, I used PHI0 (clock source
> instead of clock output) a lot and thought about using long traces on
> data lines (joke) among other things... more than one engineer got everything
> else right except for this part.
>
> Bil Herd
>
>
>
>
> -----Original Message-----
> From: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
> On Behalf Of "André Fachat"
> Sent: Monday, May 28, 2007 8:27 AM
> To: cbm-hackers@ling.gu.se
> Subject: Re: How to design non-trivial cartridges for c-64?
>
>
> > Bil Herd wrote:
> > > The area you have to watch is that the data is valid for only a short
> > > period after Phi goes low, known as the hold time. Holdtimes are as
> > > short as 10-20 ns (shorter if using Phi2) which means that if you have
> > > too much logic in line to create the strobe, the data goes away before
> > > the strobe (took you longer than 10ns to decide to do something).
> Rule
> > > of thumb is the strobe has time for only one level of TTL type logic
> on
> > > anything trying to capture data.
> > >
> > So, for something a bit more time intensive, are there any suggestions?
> > Delay after Phi2 going Hi to start the work?
>
> You can delay the data by feeding it through a buffer (e.g. 74ls245)
> first.
>
> André
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Message was sent through the cbm-hackers mailing list
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.