June 16, 2005

June 06, 2005

Long writes to memories

I have been fixing a bug that involves writing to memories which take a long time to accept the charge. This used to be very common when FLASH memories were first introduced. Now, we see it in specialized ASICS.
PigeonPoint_Lighthouse.jpg Writing a value to an area of buffer memory which behaves differently than the rest of DRAM or SRAM involves tricking or faking out the processor. CPUs tend to set a timer before it does a write to memory. If the the timer goes out and the CPU doesn’t receive a DTACK from the memories, a processor exception happens. In our case, DTACK would not happen for 100s of milliseconds.
In order to prevent the exception, the CPU must turn off the DTACK timer just before it proceeds to do the WRITEs. In the same manner, it would have to remember to re-enable the timer after such accesses are done.

From a software perspective, each of the long WRITEs would seem like jumping into a black hole. Microsoft has solved this problem in Win32 with a mechanism called Asynchrous IO. In it, the software just hooks worker function and a callback function and goes on its merry way. As the worker finishes, the callback is called and software knows the process has completed. In firmware, we don't have any of those particular luxuries. "Printf" is about the best luxury that we can afford. How do we wait for IO completion? What you (or I) tend to find in a lot of firmware is fixed "for xxx to yyy" loops. Nothing fancy. The processor doesn't do anything but spin until the time it thinks the memory WRITEs are done.

We see a lot of silly code in firmware. However, if it gets the job done... what more can you want?