Reduced pin count dynamic random-access memory project's website


Website disclaimer

   The information contained in this website is for general information purposes only. The information is provided on an "as-is" and "as available" basis and while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
   In no event will we be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this website.
   Through this website, you are able to link to other websites which are not under our control. We have no control over the nature, content, and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
   Every effort is made to keep the website up and running smoothly. However, we take no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.

( This disclaimer was created using a Contractology template. )

http://www.seqlegal.com/sites/default/files/free-legal-document-images/website-disclaimer-image.png



Introduction

   On the innovation ground, there is news about serial dynamic random-access memory like:
The Rise of Serial Memory and the Future of DDR
Serial Memories Fill a Need
It means nothing, that I linked that two. You search for "serial dram" with Google, you will find much more. Although, all of it is a bit abstract in the question of the possible market product to create as "serial memory". Content on this webpage is a bit more specific in product-related questions of Target market, Business opportunity, Mechanic, Electronic, Software, and Future development.

   On this website, I would like to share my personal idea about a serial-interfaced dynamic memory device. The idea is built on the core conception of ergonomics. If you think about the idea with that focus, then more easy to understand it. Content on this website not meant to be professional. I offer it to innovation hobbyist and enthusiast. Anyone would use it for any purpose, it is free.

   You will be noticed, the website lacks graphic content, and acronyms. I do not have much talent for graphic content, that is one reason. For acronyms, read the "[rant]" section in this web blog please. Webpage uses long names, and I link Wikipedia content first time, I use a reference to something difficult to understand, or try to explain it myself.

   I would like to apologize for my bad English. I will fix grammatical errors and update the quality of the content on this website continuously.



Welcome

   Welcome to the reduced pin count dynamic random-access memory (or rpcdram for short). The name is created in the point of view of the 3.3-volt open-hardware market, to describe the most important advantage (more about that later).

   As far as I know, in this moment, there is no such product (or functional equal) in the market, and no such registered US utility patent. The name is created to avoid a quarrel with lawyers of many companies already invested into the name "serial dram". Also, I think, every idea deserves its own name to avoid confusion.



Target market

   Memory is a device, exists to support the central processing unit, or processor, for short. Memory is not a stand-alone thing. Without the processor, memory is useless. Therefore, the market of memory depends on processors sold. There are the different type of memories. For the dynamic type of tasks, where high memory capacity for low price counts, processors need the type of dynamic random-access memory. On this whole website, reference of memory means the type of dynamic random-access memory.

   There is a special type of processors in the market, called microcontroller unit. Someone sent me a word about, people do not know about the microcontroller, what is it are. It has to be explained.
   Microcontroller unit is like a whole desktop computer in micro size, micro performance, micro power-consumption, and micro price. While desktop computers are about performance and comfort, microcontrollers are about low power consumption, small size, and low cost of the final product. Like you drop out unnecessary peripherals, performance, dimension, power consumption and retail price from a desktop computer, and manufacture the leftover of it in a handy shape to use it for cheap products. That is the microcontroller. There are microcontrollers for wide-scale performance. You can find low-end microcontrollers in your tv remote controller and quartz clock. There is a low-end microcontroller in the mouse in your hand. You can find mid-range microcontrollers in your car electronic, or in industrial or medical equipment. High-end microcontrollers are in your mobile phone - for example.
   You pay attention to find them, you will find many of them around you.

   Actual product idea targets the open hardware market of 16-bit and low-end / mid-range 32-bit microcontrollers. There is an article with statistics

http://www.electronicdesign.com/sites/electronicdesign.com/files/uploads/2014/12/Table-1-big.jpg

about their market. Those numbers are in million US dollars revenue annual. Personally, I would estimate, that average price for those 16-bit microcontroller units are below 4 US dollars, and for those 32-bit microcontroller units are below 8 US dollars. That means target market of annual 2 billion+ microcontroller units to sell memory with them together in the market. Or maybe, a bit less.
   Something about the name "open hardware" of microcontrollers. There are microcontrollers in the industry without open public documentation. You have to sign to its manufacturer to know anything about. That means obligations and costs. Manufacturers always can decide to forbid any external device to use for their products - that is one of your obligation if you sign. I would not count on that market, so the possible market is a bit less, than listed statistics above. Not significantly less, however.

   Target microcontrollers could use extra memory device for additional functionality. There is a simple thing to understand about user experience. It always takes more expertise, more performance, and more resource as well. Their balance breaks, the cost rises or user experience falls. Memory is a resource. Microcontroller units have some low amount built-in memory, and that is enough for some function. As an expert on the field, I know about those microcontrollers, that they have enough performance to use more resources. Without more resource, their performance is used up with low effectivity. Microcontrollers could use secure digital cardsthin-film-transistor liquid-crystal display with touch support, and network communication devices for application level functionality (better user experience, for short), if they could breach the resource barrier of memory. Of course, they need memory device optimized for their electronic environment and conception.



Business opportunity

   As bad news, microelectronic is one of the most costly industries. The physical design of the prototype, make it ready for serial production (purchase production mask set), launch the product into the market (fabrication-related costs, sale-related costs, market stock value), legal costs, they sum many million US dollars.
   There are different business targets, however. For example, a working prototype is enough to claim US utility patent, and that stays below 1 million US dollars (physical design, multi-project wafer run).

   As good news, microelectronic is also one of the most stable industries. Recession devastated many industries but microelectronic. It seems a real survivor. It even won on the recession. Like it will be immune to that. Also, the targeted open hardware market is a real democracy of the business world. It has got as many players as nothing else can affect it but product quality. Unless immature conception, misdesigned product, or lawyers, that is not easy to lose money in the microelectronic industry. Many million US dollars starter expenses could sound scary, but that industry is used to much more money and works well.
   A bit more about expenses. More expense on development means less price of the final product, and better quality of it (for example less power consumption). It is a trade-off for profit. That is one reason, why microelectronic industry focuses on technology development continuously, and business world buys it.
   There is an investment on behalf of the Chinese government. They will push down costs for a while in the microelectronic industry. This time is probably the best for new development if that development aims at huge scale production. The memory device is as universal as the processor. Think about them not big things, but very little. Like vigorous digital ants, as little as they fit anywhere in our everyday life, and collecting not just dollars but every cent of money for their investor. That is the product type, most likely gets into huge scale production.

   Some innovation statistics say, that a carefully designed idea with good business health can cover up at least 1% of its target market in a cost-effective way in the first 5 years with linear improvement after the minimal viable product is launched into the market. If it can not do that, then it means low-quality conception or business health problems. 1% of target market means annual 20 million parts sold (there are numbers in section "Target market"). Personally, I would estimate 5-8 US dollars retail price for a minimal vital product in the market (depends on production scale). Some statistics say about memory devices, their net profit margin is over 4%. More or less that means 4 million+ US dollars profit annually in the 5th year after product launch (development and preparation take about 1 year, or a bit more).
   Even 10 companies do the same and give such product to the market, the target market is as huge as they all can profit off of it. Rush into the market means not a much. Memory device market is not about development rush but about business health. The microelectronic industry is rather optimized for long-term business. No one should count on getting rich in one month. On the other side, it serves while lifetime. Related to that time scale, a slow beginning is just fine.



Mechanic

   Mechanic parameters can affect manufacturing cost, usability, and the popularity, what product will gain in the market.

   I linked a picture before, about a quartz clock, here it is again. That black blob is used to cover the silicon. Involved manufacturing technology is called bare-die mounting, and is a high-end manufacturing technology to save some US dollars (or cents at least) of the final product. If a product is manufactured over 50k pieces annual, then such technology can save silicon packaging cost. In huge scale production, everything gets butchered in the industry, and that does not matter anymore, what packaging a silicon had before. It matters much more in the start and in small-scale production, however.

   When a new electronic device enters the market, only early adopters welcome it. What they do, is playing with it in crafting environment like that. That board is called bread-board and is a handy tool to craft electronic circuits with devices on 2.54-millimeter connection matrix. As prototyping technology, it is quite fun - personal experience here. Whatever new electronic device enters into the open hardware market, and wants developer's attention, that is a starter advantage, if have a cheap and handy opportunity to play with. Dual-in-line package is one way to adapt to that environment. Any other packaging is used, developers of that device are better to take care to offer break-out board (some examples) of their product too. That case, it is still ok to play with, like that.

   That is a trade-off, a device should use package type like dual-in-line to favor early adopters, or use a different type of package (like small outline integrated circuit) to favor small-scale production of a final product instead (industry likes surface-mount technology, and the dual-in-line package is not its favorite). Package selection is also a question of chip size inside the integrated circuit. Every package has its cavity size, where the silicon has to fit. There are some drawings on Europractice's website about prototyping packages. Click on the package name link, and pdf shows up. For example, direct links to small outline integrated circuit 16 pins or quad flat no-leads package with 80 pins (12 x 12 millimeters), or an extra large package dual-in-line 48 pins - there are many of packages. Some package types are closed industry material, no public documentation about their details (for example, cavity size). To manufacture the same silicon resource in a smaller size, it means more development cost for higher-quality technology. It is more cheap, to choose a larger package. As long as device does not need too many pins (dual-in-line package is less effective in cavity size / package outer dimension than others, and that is even worse in high pin count case), does not use relatively high frequency (above 25 MHz), where electronic parasitics become issue, and the silicon can fit into a dual-in-line package, then probably, it is a worthy trade-off, to choose the dual-in-line package.
   On the picture, that is the dual-in-line 6 pin count package (6 pins will be just enough, more about later), and some drawings about.
http://www.dema.net/pdf/artpic/9784-0.jpg https://toshiba.semicon-storage.com/shared/pkgimage/DIP6_coupler_pkgdim.gif
That is the package, I would choose for a minimal viable product of the idea.

   I would tell about a hobbyist project here. The project is a fake, but I think, it is funny. Something to show. There is a bread-boarded ATtiny10 break-out board on the picture (picture is a bit enlarged).
http://morecatlab.akiba.coocan.jp/lab/wp-content/uploads/2011/10/IMGP6002.jpg
   That little break-out board fits into the same size as a dual-in-line 6 pin package. Dual-in-line 6 pin package is not standardized, and there is no open documentation about its cavity size. I can only estimate, that cavity dimension inside more or less the same size as that ATtiny10 soldered on that break-out board. I wrote a little program (only 221 assembly instructions) to emulate electronic and software protocol of the idea (more about later). ATtiny10 is the only one microcontroller with 6 pins, what I found in the market, and the whole silly idea is all about that. Of course, it is not the same in performance and resources as a minimal viable product will be. ATtiny10 way far have no those resources, so limitations are on address width (8 bits instead of 24), memory unit length (16 bits instead of 512), communication speed (4 kHz instead of 25 MHz), memory capacity (32 bytes instead of 16 megabytes+), also ATtiny10 have static type memory, not dynamic type. For other differences, check comments in the source code. The program consists of registers and state machines, they are commented plentifully - tested only in AVR Simulator.



Electronic

   Electronic devices have to communicate somehow. They have their standards for that. As I checked the target market, I found, that its microcontrollers have some features in common, and I would list some points, what I think as an advantage or worthy trade-off for a memory device, to go for.

   The target market's common power supply is 3.3 volt. 5 volt already counts as obsolete, and 2.5 volt seems very distant future. If a device has to communicate to different voltage level domain, there are voltage level shifters as a workaround (electronic circuits to "translate" the same logical state between different voltage domains), so the 3.3-volt power supply is also good enough for any case. There are integrated circuits in the market (for example, dynamic memory devices) with a demand of multi-power supply. Many of those integrated circuits need the 1.8-volt power supply for core functionalities and 3.3-volt power supply for input - output communication. Of course, developers in the target market do not like such demand, it makes the electronic circuit more difficult. If that is possible to support multi-power supply inside the integrated circuit by built-in voltage regulators, that is always better in the point of view of the popularity of that integrated circuit.

   Since transistor-transistor logic, there is an experience about Schmitt trigger input, it can help a much against noisy communication lines, and accidental analog signals. It will be an effective protection to the memory device, and worthy to go for.

   The serial peripheral interface bus is a universal communication interface, mostly used in mode 3. Manufacturers of microcontrollers all have their own standards too, the serial peripheral interface is something, they have in common. It is present on every 16-bit and 32-bit microcontrollers. Most of them have more than 1, some microcontroller has even 6 of it (for example pic32mz0512efe100).
   The serial peripheral interface is also simple enough to equip up the memory device with multi-port (dual- or quad-ports) of it. It can happen in the future (more about later), even if that demands more pin counts. For first time product, that is worthy trade-off, to go for less pin count, and develop single port only. That case, the product can adapt to the restriction of 6 pin count (single power supply takes 2 lines, single serial peripheral interface port takes 4 lines), and gain advantages, already mentioned in the Mechanic section.
   Serial peripheral interface speed is supported up to 20..50 MHz on the target market's microcontrollers. In practice, it is not commonly used over 20 MHz because of electronic parasitics, and because of those microcontrollers rarely need more communication speed, even if they can have it. Developers rather prefer less power consumption to keep their stuff cold, and on "cold speed", even 20 MHz communication clock counts as fast. I would say, 25 MHZ is more than enough to support a minimal viable product.

   Memory capacity is a question of usability, continuous development logistics, power consumption. Power consumption is much more affected by the used manufacturing technology. I think so, that is not a worthy trade-off to produce memory device with too low memory capacity just because of power consumption. I can not give proof of cold logic, why target market would use at least 16 megabytes of memory for a better quality product. Cache memory usage is not a predictable point on a graph. The more is better, as long as it feels better. People getting used easily for new resources, and it is always welcome in continuous development logistic, to have some more resource, not used up before. 128 megabits of memory per device likely fine.
   As I can estimate, 128 megabit memory can fit into a dual-in-line 6 pin count package, if manufactured around 40..55 nanometer technology. (Microelectronic industry is full of non-disclosure agreements, and everything is closed material. Before someone sign, may not know anything for sure, after someone signed, may not say anything concrete publicly.)

   To sum it up, I think, 3.3-volt single power supply, single client serial peripheral interface port, up to 25 MHz supported clock speed, Schmitt-trigger inputs, 128 megabit memory capacity, dual-in-line 6 pin count package, reasonable low price, it could be a popular product in the target market.

   Serial peripheral interface mode 3 (ClockPOLarity=1 / ClockPHAse=1) is fully covered on the linked web page above. Here, I would sum up the most important parts again.
https://upload.wikimedia.org/wikipedia/commons/thumb/6/6b/SPI_timing_diagram2.svg/430px-SPI_timing_diagram2.svg.png
The device communicates in data frames. Data frame start, when bus master activates SlaveSelect line (sets to low). Bus master should do it in time when SystemClocK is in the inactive state (high), and a bit before (likely 10 nanoseconds+) SystemClocK sends the first falling edge. Data line changes on SystemClocK falling edge, data is sampled on SystemClocK rising edge. Data frame consists of bytes, the byte consists of 8 bits. The serial peripheral interface is full-duplex (there are MasterInputSlaveOutput and MasterOutputSlaveInput lines), what is supported in the protocol (more about later). That is bus master's call, to use both half of communication, or waste one. Opportunity is there for full-duplex communication by hardware. That means a bit is sent from the master (microcontroller) to the slave (memory device) and from the slave to the master as well at the same time. Bit order is standard for serial peripheral interface, always most significant bit goes first, low order bit goes last. I would keep that notation for byte order as well. The protocol uses multi-byte structures, like the 3 bytes long address or the 64 bytes long data unit (more about later). In communication, most significant byte goes first, low order byte goes last (from the master to the slave and from the slave to the master as well at the same time). Data frame has specific units and predictable length by them. Bus master should transmit the whole frame and never should transmit broken frame. The frame is allowed to be infinite long by more data units sent continuously (more about later). The communication is synchronous to the SystemClocK signal, as it is standard to the serial peripheral interface. There are no wait cycles, no extra "dummy" bytes. Data frames are allowed to read or write (or both) even the whole memory device continuously many times again and again. After SystemClocK line sent rising edge last time (lowest bit of the last one byte of the frame, where bus master wants to close that communication frame), SystemClocK keeps inactive state (high), and a bit later (likely 10 nanoseconds+) SlaveSelect goes into inactive state (high) - frame ends there. After SlaveSelect line gone inactive (high), it should keep that for a while (likely another 10 nanoseconds+), before it is allowed to go into the active state (low) again, and the next one communication frame starts there. I describe the abstraction of data frames in the Software section, what I think about its most simple form.
   Described protocol events and timings above are not obligations to the bus master (microcontroller). Serial peripheral interface bus is created to work exactly on that way and already integrated into microcontrollers. Microcontroller simple uses it. The protocol rather an obligation to the bus slave (memory device).

   Behind the serial peripheral interface, there will be registers and state machines inside the rpcdram device, to ensure about heat compensated dynamic memory refresh. The user does not have to care about. Dynamic memory refresh would happen continuously in the background, not even infinite long communication frames can disturb it.



Software

   Microcontroller and memory device supposed to communicate on serial peripheral interface bus by bytes. Bytes build communication frame, organized into logical functionality by microcontroller's firmware. Therefore, communication frame organization is part of software abstraction, part of a program, and I think, better to describe it in that style. I wrote about communication's bit order, byte order, and electronic-related parts in the Electronic section above.

   A simple software protocol has advantages in silicon used, device testability, documentability, and business profit, in the end.
   There is an electronic device family, named application-specific integrated circuit. Think about them, like even more simple microcontrollers (or at least, they are more simple in most cases) in the name of even more cost effectivity. Some of them are developed in an environment of a field-programmable gate array. Field-programmable gate array is an integrated circuit. It offers precise hardware resources to customize with hardware description language. Once the hardware description is done (called "configuration" by its experts), the industry can manufacture it by used up resources and their configuration into the form of an application-specific integrated circuit - they call it conversion. I mentioned that expertise field as a measurement of simplicity. The most simple software protocol of an electronic device is more or less the protocol, what demands the lowest amount of resources to apply, and results in lower cost of the silicon used. That simplicity is not always the same what people think about.
   Once the optimization of using the lowest amount of resource is done, that is also into consideration, that manufacturer has to test the electronic device somehow, before release it into the market. Testing difficulty and time are also costly, and that expense is part of the retail price as well as the silicon used. It takes an another optimization of lowest final cost.
   Documentability also affects the profit. If documentation is easier to understand, results in more popularity, more demand for the product, and more profit in the end. It is better to plan only such software protocol, easy to understand in a very simple documentation, or at least, something "simple" enough in the point of view of all other parameters too.

   The whole memory device will be segmented into memory pages. Memory page consists of 64 bytes (most likely). Only whole memory pages will be read or written. Bus master has to transmit or receive a whole memory page. It means less effectivity if a microcontroller would access only 1 specific byte in the memory, but that unlikely happens in the targeted performance class. If a 32-bit microcontroller would use many megabytes, that likely means kilobytes to transmit or receive at a time, and even 64 bytes of memory pages are very little.

   Communication frame consists of a header, followed by any amount of memory pages continuously. The header consists of a read address (read address first!), followed by a write address. There would not be other elements in the communication, no explicit command codes in the data transfer, no extra bytes, no implicit wait states. (Some testing-related command codes are implicitly implemented in control registers, more about later.)
   Read or write address means page address in the memory. They have the same structure and length, they are 24 bits long (serial peripheral interface is used to communicate by bytes, better to round up the address width), consists of a control bit in the most significant bit position, and 23 address bits. Valid data address starts from 0, has to contain "0" bit in the most significant bit position, and "0" bits in not used high order bit positions as well for later compatibility reasons. The 23-bit long address can reach out for 8388608 memory pages, 64 bytes long each, it means the total of 512 megabytes of memory is addressable. If memory device has less capacity, high order address bits are ignored. There is a "void address" supported. It consists of "1" bit in the most significant bit position and "0" bits in all other bit positions (some explanation later at control registers).
   Planned data transfer operations: read only, write only, and exchange (read and write at the same time). If bus master (the microcontroller) would only read memory content, then opens a new communication frame, sends valid read address, then sends void address as the write address, then sends dummy data, and while that, reads the content of the addressed memory page. If bus master would only write memory content, then opens a new communication frame, sends void address as the read address, then sends valid write address, then sends valid data bytes, and ignores bytes read in. If bus master would exchange memory content, then opens a new communication frame, sends valid read address, then sends valid write address, then sends valid data bytes, and while that, reads the content of the addressed memory page.
   Exchange transfer is an opportunity to double the speed compared to write only plus read-only transfer. To use a large capacity external memory device, likely demands to sacrifice some of microcontroller's own built-in memory to implement a cache policy there, for example, write-back cache. While maintaining access to external memory pages, microcontroller will change cached memory pages (in its own memory) time to time: write out a changed memory page, and read in a different one, based on their program's actual need. That is the situation, when bus master either executes a write-only transfer plus a read-only transfer, or instead of them, executes an exchange transfer to utilize both halves of the serial peripheral interface bus, what is supported by the hardware. As I can estimate, in a carefully organized application, most of the memory transfer will use exchange transfer.
   Communication frame is allowed to be even infinite long. The original read and write address gets automatically incremented after each one memory page transferred, and the next one memory page comes into operation. When read or write operation reached the end of the valid memory area (counts for both addresses of an exchange transfer as well), its pointer gets positioned back to the start of the memory automatically.
   That is totally on the bus master, which content to read or write in exchange transfer. It is guaranteed by the conception, that in case, bus master sends the same read address and write address, then old content will be read from the memory first and overwritten with the new content after. If write address is higher by 1 compared to read address, exchange transfer still gives back the old memory page content, before overwrites it.
   While bus master sends the header of a new communication frame (read and write addresses), should ignore bytes received in. Those bytes likely will be 0x00 to save some energy on not driving the output line to high level.

   There will be control registers in the device, to support design for testing. It is something, the manufacturer will need to test the memory device fresh from fabrication. In most cases, such control registers are undocumented.
   For example, desktop computer environment uses dynamic ram devices with automatized built-in self-test on power-up. The drawback of the automatic self-test is the extra power consumption of it. That environment does not really care much about power consumption, as there is more than enough energy. Comfort makes more sense. To save the energy comes into the focus if the electronic circuit is powered by limited energy source (accumulator).
   After device tested by the manufacturer and found perfect, a dynamic memory device unlikely getting damaged for many years, unless fatal electronic failure (something like this). Even in that case, it demands no further testing to know the condition of that device. I think, it would be unfair in a mobile electronic environment (in most cases, microcontrollers are used for that), to test the memory device automatically on power up without question, and use all that extra energy (memory device testing is a huge bump on their power consumption for that time). It makes much more sense instead, to support (and document) the test process, and let the user do it if needs that test (likely, it will never happen). That is, what control registers below are all about. Unless device test, or a very rare need of functionality of these registers (for example the position response on multi-port device, more about later), the user will not need them. The manufacturer still needs them, so they are there.

   I planned 3 control registers to support device test: void address, control flag, control data. If bus master uses "1" bit in the most significant position in the address, then addressing a control register instead of memory data. The above mentioned "void address" is nothing else, but the control register on the address 0x00. Flag register is accessible on the address 0x01, and the data register is accessible on the address 0x02.
   When reading or writing operation targets a control register, then address gets not incremented automatically after the data unit transfer, but stays the same. For example, reading or writing the void address register will always read or write the void address register, whatever amount of data units are transferred.
   The void address register is simple a register, what is not implemented. Therefore, reading it gives back nothing ("0" bits), writing it has no effect. Control flag register contains flag bits to turn on / off a special functionality or get the result of it. The data register is a normal latch register, possible to read or write, as wide as a normal data unit (64 bytes, likely), and contains a parameter to support the functionality of control flag register. Bits of control flag register:
   -bit 0: refresh pass (read / autoclear / set by write "1")
There is a memory refresh state machine in the background, does its job automatically. When it passes the end of the memory and starts to refresh the memory content on the start again, clears this bit. A test rutin can use this bit to be sure about, previously set "data overwrite" or "data verify" function fully affected the whole memory content already. To use this bit properly, a self-test process sets one of those functions first, then sets this bit. When finding this bit cleared, sets it again, and wait again until this bit gets cleared. After that, selected special function is surely affected the whole memory content, and time to turn it off. It is a cheap and easy way to support the synchronization. Writing "0" to this bit has no effect. Once set, only the memory refresh state machine can clear it. This function is supposed to consume very low extra energy.
   -bit 1: data overwrite (read / write / default 0)
When this bit set to "1", then memory refresh state machine will use the content in the data control register to overwrite every one memory page with that, rather than refresh memory pages. This function is supposed to bump relatively a huge on the power consumption of the memory device.
   -bit 2: data verify (read / write / default 0)
When this bit set to "1", then memory refresh state machine will check the content in each one memory page against content in the control data register. The operation is a logical exclusive or. When any positive bit reports, that there is a difference between bits on any of those 512 positions (64 bytes = 512 bits), then sets the data mismatch flag to "1". The data verify bit has no effect when either, the data mismatch flag is already set to "1", or data overwrite function is turned on. There are best bit patterns for memory test to use them all after each other in 4 cycles: 0x00, 0xff, 0xaa, 0x55 bytes. This function is supposed to bump relatively a huge on the power consumption of the memory device.
   -bit 3: data mismatch (read / autoset / clear by write "1")
This bit gets set to "1" automatically by data verify function. The user may read it back or can clear this bit by writing "1" into this bit position. Only data verify function can set this bit to "1". Writing "0" to this bit has no effect.
   -bit 4..7: port address (read only / write 0 for later compatibility reasons / default hardware set)
On multi-port devices, there will be set an address of 0x00 .. 0x0f here, based on which port is used in the communication actually. It can help to bus masters to identify their position in the electronic circuit if they need it.
   -bit 8..511: reserved (read only / write 0 for later compatibility reasons / default 0)



Future development

   Likely, after product launch, the market will want some range of products. A memory device is easy to scale. Give more capacity to the market or lower price or some extra feature, and the market will be happy. Capacity is the first point, and the interface is the second.

   Some microcontroller has many serial peripheral interfaces, others have only one. Still, all of them may want multi-port of rpcdram devices for different reasons.
   One reason is the access speed. It is simple. A quad-port device can offer 4x faster data transfer. I would predict this reason for less chance. In the target market, there is an experience about, developers like simple structure of an electronic circuit, even if the application becomes a bit slower. The "simple structure" means simple printed circuit board. That is not a problem if some more modules are stacked on the printed circuit board as long as they do not need too many wires between them. To keep up that simplicity is a trade-off of maintenance, stability, continuous development logistics, product price, and many other things. There are always different opinions, however.
   Another reason is the communication ability. For last years, target market much more likely uses the microcontroller as single-core in the electronic circuit. I would point out, that such condition is based on the fact, communication also takes memory buffers, to keep the firmware development simple, and target microcontrollers have not enough built-in memory. For example, no point to develop a module to be your flash card file system, when you do not even have chance to use reasonable amount of cache memory to speed up application level operations (give reasonable quality of user experience, in short), neither it makes any sense, if there is no mature technology to communicate between modules. That does not mean, a multi-core design is impossible to develop, it is only about such development style unlikely conquers the expert field. That can change with the multi-port rpcdram device. A quad-port memory device can offer connection ability of +3 module to the main module, and support the communication between modules with relatively infinite long memory buffers, for example, fifo buffers. If such development happens, rpcdram device may take away the microcontroller from the central position of the electronic circuit, and there is truth in it, that memory also deserves its own position in the information technology.

   I would say about the range of products, that single port 128 megabit memory device will be great first, let developers get used to it, and when developers ask for more memory capacity, a quad-port 512 megabit memory device is also worth a try.
   To maintain such product in the market, there are only well-known everyday tasks. Build a close connection to developers, use community managers. Support as many microcontroller families as possible with open-source program libraries for free. Developers will tell, how many ports they like to use, and when they want more memory capacity per device.

   I mentioned application-specific integrated circuits in the Software section. Also, microcontroller is made by a lot of finite-state machines. Finite-state machines can build up many things. The final result rather different in their quantity than in their quality. Processor, microcontroller, communication controller are all the same in that point of view. I think, the conception described in the Software section is simple enough, to be able to adapt to an environment, where a very simple (and cheap) communication controller has to use the rpcdram device. To keep the conception in such simple state offers an opportunity. There is a technology in the market, three-dimensional integrated circuit. For example, the microcontroller in the Raspberry Pi has built-in dynamic memory by that technology. (Raspberry Pi has a high-end microcontroller. I did not find any middle- or low-grade microcontroller with such peripheral integration in the market to link it.) If rpcdram proves itself in the "normal" market and gets built into microcontrollers, that is an opportunity to enter a new market what sells billion parts annual.



Special thanks to:

Glenn DeMichele, VP Engineering, Sigenics inc.
Mark Jones, Director of Sales, asicNorth
Jim Handy, Objective Analysis Memory Market Research, The Memory Guy

   I would like to apologize for those annoying e-mails. In the start, every little bit advice is a great help.



Feedback

   Whatever is on your mind about the rpcdram device idea, you can send e-mail to info@rpcdram.com
   To keep the communication simple, I would like to ask everyone to use only English in feedback e-mail.

(Last update: 2017 june)


http://i.quoteaddicts.com/media/q2/1412681.png