标签: SRAM

SRAM:1个记忆单元至少要用1个触发器 1个触发器至少要4-5个MOS管 1个记忆单元至少要用4-5个MOS管记1位数 DRAM:1个记忆单元需要1个电容+1个MOS管

An analogue engineer and a digital engineer collaborate, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely unfamiliar. Our sales department had just accepted a new challenge on behalf of Engineering. They promised a customer that yes, of course, we can repair a telecom product that we have never seen before and for which we have no systems, no test fixtures, and no schematics. (The OEM no longer supported this product.)   Engineering was once again expected to shake our rattles, do our magic voodoo dance, and pull bunnies out of hats. About fifteen of these backplane-pluggable boards showed up in my office for initial evaluation and perusal of their inner workings. They had a proprietary SIMM (socketed memory module), which on several units turned out to be bad. Temporarily substituting the memory modules from other cards with obvious smoke damage failure modes brought them back to life when powered while lying flat on the bench. (Remember, there was no test chassis available.) They would then boot and talk to us over their RS232 ports.   These modules were populated with four SRAMs and four flash memories, each flash and SRAM shared an 8-bit-wide data bus, and each pair of SRAMs was enabled together with the same chip select. I proposed to the boss that we build a small test fixture that would take the DUT memory module, run SRAM tests, and if necessary reprogram the flash.   A digital/software colleague three cubes away was assigned to work with me on this project. He had previously designed and laid out a PCB that used a surface-mount PIC microcontroller as a universal I/O for our current and future test fixtures. It turned out that it had just enough I/O lines to handle the address and data buses on the DUT memory module, with two spares, as long as I tied the four separate DUT data busses together into two pairs on the fixture. So we decided to use it.   I ordered the necessary SIMM connector and a plated-through-hole protoboard, along with some ribbon cable and IDC header sockets to connect to the PIC board. It was somewhat annoying that the 72-pin SIMM connector was spaced at a.05-inch pitch, so the protoboard also had to be this pitch. Its tiny .025-inch-diameter holes did not accept .025-inch-square pins, so wire-wrap was impossible. (Now I know where that old adage, "Can't fit a square peg into a round hole," came from.)   I had to solder ribbon cable directly to the protoboard and string short 30AWG wires to the SIMM connector. As long as the stranded ribbon wires were not overly tinned (to keep the strands together), they actually fit into the protoboard holes.   Endeavor brings back cuss words long since forgotten Another annoyance was that the SIMM connector had plastic retaining tabs that quickly wore out from repeated insertions of memory modules. The maker had designed them for maybe a single SIMM replacement over the lifetime of the product. We wanted to plug DUTs in and out constantly.   Fortunately I had used socket pin strips in the protoboard for the SIMM connector in anticipation of eventually needing to replace it easily. I subsequently found a connector with metal retaining tabs. This particular feature does not show up in vendors’ online part descriptions. I had to look at the mechanical drawing of each of many to find "W/ Metal Latch."   The first test of the fixture went well. My colleague coded a walking-ones SRAM test that immediately identified bad SRAM chips on a couple of the DUT (Device Under Test) boards. We replaced them and now they booted, but with the disconcerting message "RAM is BAD." Due to availability we had used 12 nsec SRAMs in place of the original 20 nsec SRAMs, so speed was probably not the issue. Hmmm, maybe we needed to improve the test algorithm.   Then we got brave and copied about five different versions of firmware from the flash of the good memory modules and tried to re-write the new firmware into a module, which semi-booted at first but complained about a "missing application loader." After the firmware re-load it would no longer even talk to us over its RS232 port. Somehow a 'known good' firmware load messed it up. My colleague verified that the firmware in the good and bad modules was identical. So why did one boot and not the other? Speed?   My colleague continued writing his code and progressed to a walking-zeros test. Strange things began to happen. On several known good memory modules two SRAMs with their data busses tied together consistently failed in the same way: When 7F was written, FF got read back. It only failed on one pair of SRAMs. The other SRAM pair always worked properly.   Had I connected a wire wrong on the fixture? We put a scope on the fixture and verified that yes, when he wrote 7F that is what came back from the DUT SRAM and the fixture. Clearly his PIC microcontroller was reading a definite logic 0 as a logic 1, but only on bit 7 of that data bus. Yet the walking one's test had worked and bit 7 was correctly read as a logic 0 during that test.   Since I was not familiar with his PCB layout or the PIC chip, I asked him to send me his KiCAD board layout file. I already knew there were no power/ground planes, but I had not expected to see that some of his ground pin connections snaked in and out in roundabout paths when they should have all been joined together under the PIC chip.   Some of his Vdd connections were not even connected to the Vdd copper, but instead depended on connections within the chip. His decoupling capacitor was an inch away, adding two inches of trace inductance. I smelled analogue problems here, possibly due to the power routing. One way to find out if a suspect actually is the cause of a problem is to eliminate it. I used an approach that had been successful before, which was to add power planes and more decoupling. Here is a photo of the end result, done by one of our highly-skilled production soldering experts:   Two squares of single-sided copper-clad form the mini-power planes. Decoupling 0805 chip capacitors standing on their ends are just the right size to AC-couple the planes together. (Somehow this sounds like an oxymoron). The PIC cannot complain about poor power etch routing. All its power and ground pins are now tied together.   Unfortunately this did not help. But it did eliminate the power suspect. I still smelled an analogue problem.   This was further confirmed when we ran some tests to see if any other byte patterns caused bit 7 to falsely read a one when it was really a zero. Turned out there were many patterns that did this. If as few as three lower-order bits were ones, the PIC would read bit 7 as a one when it was really a zero. It didn't seem to matter which lower order bits, all it took was three or more set to one. With enough of them HI they seemed to bleed into bit 7. Was it analogue voltage summation?   Then it hit me. My colleague's PIC was running at 3.3V. My memory module DUT was powered at 5Vs. My colleague had previously assured me that his PIC inputs were 5 volt tolerant -- the data sheet said so. I took a closer look at the data sheet. On the first page it did say "5.5V Tolerant Inputs (digital-only pins)." So if the inputs are configured as digital, they should be 5V tolerant, right?   Some 146 pages into the data sheet was a bit (no pun intended) more detail: Any inputs that could be configured as either analogue or digital are NOT 5V tolerant. They have clamp diodes to 3.3V Vdd. All eight bits of the problem data bus and one bit of the other data bus went to such inputs. Yes, it was an analogue problem -- the 5V ones were overdriving the inputs and adding voltage-wise. I invented a couple of new cuss words.   This explained the problem with the one flash we had overwritten that would no longer boot. All the firmware images we had copied previously were garbage. I had to heat up the soldering iron again, hack into the test fixture, and carefully cut ribbon cables to add a couple of 74LVC245 bus transceivers with 5V tolerant inputs. My knowledge of PIC microcontrollers and my expletive vocabulary both improved considerably.   But it solved the problem and we could now identify bad SRAM devices and re-write the bad flash. The "RAM is BAD" message turned into "RAM is OK" after a flash re-write. Possibly the flash had logged the previous SRAM failures.   Success was achieved by a pair of engineers, one digital and one analogue, each with his own skill set, working together to solve the problem.   Glen Chenier Engineer

An analogue engineer teams up with a digital engineer, they use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely unfamiliar. Our sales department had just accepted a new challenge on behalf of Engineering. They promised a customer that yes, of course, we can repair a telecom product that we have never seen before and for which we have no systems, no test fixtures, and no schematics. (The OEM no longer supported this product.)   Engineering was once again expected to shake our rattles, do our magic voodoo dance, and pull bunnies out of hats. About fifteen of these backplane-pluggable boards showed up in my office for initial evaluation and perusal of their inner workings. They had a proprietary SIMM (socketed memory module), which on several units turned out to be bad. Temporarily substituting the memory modules from other cards with obvious smoke damage failure modes brought them back to life when powered while lying flat on the bench. (Remember, there was no test chassis available.) They would then boot and talk to us over their RS232 ports.   These modules were populated with four SRAMs and four flash memories, each flash and SRAM shared an 8-bit-wide data bus, and each pair of SRAMs was enabled together with the same chip select. I proposed to the boss that we build a small test fixture that would take the DUT memory module, run SRAM tests, and if necessary reprogram the flash.   A digital/software colleague three cubes away was assigned to work with me on this project. He had previously designed and laid out a PCB that used a surface-mount PIC microcontroller as a universal I/O for our current and future test fixtures. It turned out that it had just enough I/O lines to handle the address and data buses on the DUT memory module, with two spares, as long as I tied the four separate DUT data busses together into two pairs on the fixture. So we decided to use it.   I ordered the necessary SIMM connector and a plated-through-hole protoboard, along with some ribbon cable and IDC header sockets to connect to the PIC board. It was somewhat annoying that the 72-pin SIMM connector was spaced at a.05-inch pitch, so the protoboard also had to be this pitch. Its tiny .025-inch-diameter holes did not accept .025-inch-square pins, so wire-wrap was impossible. (Now I know where that old adage, "Can't fit a square peg into a round hole," came from.)   I had to solder ribbon cable directly to the protoboard and string short 30AWG wires to the SIMM connector. As long as the stranded ribbon wires were not overly tinned (to keep the strands together), they actually fit into the protoboard holes.   Endeavor brings back cuss words long since forgotten Another annoyance was that the SIMM connector had plastic retaining tabs that quickly wore out from repeated insertions of memory modules. The maker had designed them for maybe a single SIMM replacement over the lifetime of the product. We wanted to plug DUTs in and out constantly.   Fortunately I had used socket pin strips in the protoboard for the SIMM connector in anticipation of eventually needing to replace it easily. I subsequently found a connector with metal retaining tabs. This particular feature does not show up in vendors’ online part descriptions. I had to look at the mechanical drawing of each of many to find "W/ Metal Latch."   The first test of the fixture went well. My colleague coded a walking-ones SRAM test that immediately identified bad SRAM chips on a couple of the DUT (Device Under Test) boards. We replaced them and now they booted, but with the disconcerting message "RAM is BAD." Due to availability we had used 12 nsec SRAMs in place of the original 20 nsec SRAMs, so speed was probably not the issue. Hmmm, maybe we needed to improve the test algorithm.   Then we got brave and copied about five different versions of firmware from the flash of the good memory modules and tried to re-write the new firmware into a module, which semi-booted at first but complained about a "missing application loader." After the firmware re-load it would no longer even talk to us over its RS232 port. Somehow a 'known good' firmware load messed it up. My colleague verified that the firmware in the good and bad modules was identical. So why did one boot and not the other? Speed?   My colleague continued writing his code and progressed to a walking-zeros test. Strange things began to happen. On several known good memory modules two SRAMs with their data busses tied together consistently failed in the same way: When 7F was written, FF got read back. It only failed on one pair of SRAMs. The other SRAM pair always worked properly.   Had I connected a wire wrong on the fixture? We put a scope on the fixture and verified that yes, when he wrote 7F that is what came back from the DUT SRAM and the fixture. Clearly his PIC microcontroller was reading a definite logic 0 as a logic 1, but only on bit 7 of that data bus. Yet the walking one's test had worked and bit 7 was correctly read as a logic 0 during that test.   Since I was not familiar with his PCB layout or the PIC chip, I asked him to send me his KiCAD board layout file. I already knew there were no power/ground planes, but I had not expected to see that some of his ground pin connections snaked in and out in roundabout paths when they should have all been joined together under the PIC chip.   Some of his Vdd connections were not even connected to the Vdd copper, but instead depended on connections within the chip. His decoupling capacitor was an inch away, adding two inches of trace inductance. I smelled analogue problems here, possibly due to the power routing. One way to find out if a suspect actually is the cause of a problem is to eliminate it. I used an approach that had been successful before, which was to add power planes and more decoupling. Here is a photo of the end result, done by one of our highly-skilled production soldering experts:   Two squares of single-sided copper-clad form the mini-power planes. Decoupling 0805 chip capacitors standing on their ends are just the right size to AC-couple the planes together. (Somehow this sounds like an oxymoron). The PIC cannot complain about poor power etch routing. All its power and ground pins are now tied together.   Unfortunately this did not help. But it did eliminate the power suspect. I still smelled an analogue problem.   This was further confirmed when we ran some tests to see if any other byte patterns caused bit 7 to falsely read a one when it was really a zero. Turned out there were many patterns that did this. If as few as three lower-order bits were ones, the PIC would read bit 7 as a one when it was really a zero. It didn't seem to matter which lower order bits, all it took was three or more set to one. With enough of them HI they seemed to bleed into bit 7. Was it analogue voltage summation?   Then it hit me. My colleague's PIC was running at 3.3V. My memory module DUT was powered at 5Vs. My colleague had previously assured me that his PIC inputs were 5 volt tolerant -- the data sheet said so. I took a closer look at the data sheet. On the first page it did say "5.5V Tolerant Inputs (digital-only pins)." So if the inputs are configured as digital, they should be 5V tolerant, right?   Some 146 pages into the data sheet was a bit (no pun intended) more detail: Any inputs that could be configured as either analogue or digital are NOT 5V tolerant. They have clamp diodes to 3.3V Vdd. All eight bits of the problem data bus and one bit of the other data bus went to such inputs. Yes, it was an analogue problem -- the 5V ones were overdriving the inputs and adding voltage-wise. I invented a couple of new cuss words.   This explained the problem with the one flash we had overwritten that would no longer boot. All the firmware images we had copied previously were garbage. I had to heat up the soldering iron again, hack into the test fixture, and carefully cut ribbon cables to add a couple of 74LVC245 bus transceivers with 5V tolerant inputs. My knowledge of PIC microcontrollers and my expletive vocabulary both improved considerably.   But it solved the problem and we could now identify bad SRAM devices and re-write the bad flash. The "RAM is BAD" message turned into "RAM is OK" after a flash re-write. Possibly the flash had logged the previous SRAM failures.   Success was achieved by a pair of engineers, one digital and one analogue, each with his own skill set, working together to solve the problem.   Glen Chenier Engineer

A few months ago, I was invited to give the keynote presentation at the forthcoming FPGA Forum, which is to be held in Trondheim, Norway, on Tuesday 14th and Wednesday 15th February 2012. Well, believe it or not, things just got even more exciting! Quite apart from anything else, this is going to be a great opportunity to meet friends that I've previously known only via the Internet, including Sven-Ake Andersson, the creator of the Designing an FPGA from Scratch blog andÿErik Astrand, founder of Vanserum Vision, which specliazes in robotic vision inspection systems. Also, I just heard from the organisers that the conference program is really starting to fill up. They slipped me an advanced copy showing that there are going to be all sorts of interesting talks, many of which "tweak" my personal "hot buttons" such as: * Using FPGAs to perform algorithmic trading on the New York Stock Exchange * OpenCL and hardware accelerator development for FPGAs * Next-generation devices that combine dual-core ARM processors with programmable FPGA fabric * New tools and techniques for building run-time reconfigurable systems * Quantifying the effects of radiation environments on SRAM-based FPGAs * ...and many more... Remember that this is just a teasing tempting taste of things to come – I'll let you know as soon as the final schedule has been tied down. Actually, I believe that there are still a few slots open and that there is still time for you to submit additional papers and/or book exhibit space. Of particular interest to me was when I saw the description of my own keynote presentation, which reads as follows: Everything that can be invented has been invented... or so thought Charles H. Duell, who was the Commissioner at the U.S. Office of Patents in 1899. Fortunately for us, no one listened to Mr. Duell, otherwise we wouldn't have gone on to create things like vacuum tubes, transistors, and silicon chips; and spaceships, smartphones, and tablet computers. The strange thing is that people continue to have a tendency to think "This is as good as it gets." When the first FPGAs arrived in the scene in the early 1980s, for example, many engineers said that these components would only ever be useful in the context of implementing slow, simple logic functions. However, today we have devices running at hundreds of megahertz containing the equivalent of 20 million ASIC gates. Does this mean that we have finally reached the point where we can say "This is as good as it gets" ? In his presentation, Max will consider many aspects of technology, from 2000-year-old steam engines to 200-year-old mechanical control systems to the latest-and-greatest in today's FPGA technologies and some thoughts on what we might expect in the years to come... I must admit that this sounds quite exciting – I for one cannot wait to hear what I have to say about all of this (grin). And, in addition to all of the other goodies, I'm also looking forward to hearing the final talk by Geir Førre, who is the president and CEO of a company called Energy Micro . I hear that Geir had a big success creating low-power wireless chips and is now into his second start-up developing low-power microcontrollers. But wait, there's more, because this is where things start to get even more exciting... but first let me set the scene... In a prveious column, I waffled on (as is my wont) about a number of things, including the fact that one of my all-time heroes is the Norwegian explorer and writer Thor Heyerdahl. In 1947, Thor and five companions sailed a balsa raft from South America to the Polynesian islands. This epic voyage took them 101 days and they covered over 4,300 miles before smashing into a reef at Raroia in the Tuamotu Islands on August 7, 1947. Their trusty raft is now located in the Kon-Tiki Museum in Oslo, Norway. The museum is also home to permanent exhibitions about Thor's other expeditions and exploits, including Ra, Tigris, Fatu-Hiva, Kon-Tiki, and Easter Island.   The original Kon-Tiki raft in the museum When I was first invited to speak at the FPGA Forum I thought "Wow! Now I will finally be able to visit the Kon-Tiki museum!" Sad to relate, however, Trondheim and Oslo are hundreds of miles apart, and it was becoming harder and harder to justify the time and expense of a side-trip to Oslo to visit the museum, until... A few days ago as I pen these words, I received an email from Jim Torresen, who is a Professor in the Department of Informatics at the University of Oslo. A couple of years ago, Jim was involved in establishing a new FPGA/VHDL course at the University. And guess whose book forms "An important part of the syllabus" (Jim's words, not mine). Yes! You are correct! It is The Design Warrior's Guide to FPGAs by yours truly! Click Here to see the course web page (of course you have to be able to read/speak Norwegian to understand it, but just knowing that they use my book as part of the course certainly made my dear old mom very proud). Anyway, the point of all this is that Jim has invited me to make a stop-over in Oslo after the FPGA Forum to give a talk to the department (students and faculty) on "A topic of my choosing." I think Jim must have a second degree in psychology, because saying I can talk on a topic of my choosing is like offering candy to a young child (grin).   I'm hoping my talk will draw a packed house like this...   I certainly hope that this isn't my view from the podium   So now that I'm going to visit Oslo on official business, who could possibly blame me from taking a brief excursion to visit a cultural establishment like the Kon-Tiki Museum? All joking apart, I fully realise how incredibly lucky I am to be presented with opportunities like this. And to think that when I was at high school, at a parent-teachers evening, the teachers told my parents that I was a complete idiot who would never make anything of himself (seriously). It just goes to show that I'm not as stupid as I look (I know, I know, you are about to say something like "Well, who could be?" aren't you? )  

In one of the more interesting articles in the Communications of the ACM in recent years, Halderman and a cast of thousands write in the May, 2009, issue that they have found a way to get encryption keys from any PC using, of all things, Freeze-Mist.   In the very well-written piece "Lest We Remember: Cold-Boot Attacks on Encryption Keys," they demonstrate that keys must exist, at least for a time, in system DRAM. Though we know DRAM forgets once the refresh cycles stop " or when power goes away " they remember much longer than one expects.   At room temperature they found that a 1999-era Dell PC's DRAM gives a 41% bit error rate after 60 seconds without power, rising to only 50% after 5 minutes. But at -50C there were no errors after a minute, and only a 0.000095% bit error rate after 300 seconds! I was astounded by those numbers which go against everything I believed about DRAM.   Things get worse ( or better, for those trying to keep stuff encrypted ) with more modern DRAM. But not enough better to thwart determined attackers. A 2006 IBM Thinkpad had a bit error rate of 0.025% after 40 seconds, and only 0.18% after twice that time.   The implications are stunning. First, everything PC folks believe about security is wrong. The authors were able to freeze memory, remove power, pull the chips, and then reconstruct keys. They went much further, and created software that very effectively searches DRAM for all sorts of keys (DES, AES, and RSA), extracts them, fixes bit errors in the keys, and then decode files stored on the systems' hard disks. I had to check to make sure this wasn't an April 1 article.   Second, do you ever depend on DRAM forgetting? For creating, say, a seed for a random number generator, to hide data, to see if power failed, or for other reasons? If so, your assumptions may be wrong.   ( Note: We've long known that memory at power-on isn't particularly random, so it's poor practice to use it as a random number seed. But a lot of code looks to see if stored values are corrupt to detect a power-cycle, and that scheme doesn't seem valid anymore. )   The authors cite a study that suggests SRAM has similar retention issues.   I highly recommend reading the piece. Alas, it's available only to ACM members. It's one of the few articles I've read in a long time that just flabbergasted me.