#1
256 bytes of RAM
Archive: 12 posts
As far as I know, this is the single highest capacity digital memory chip anyone has made in LBP so far. Specs 2048-bit read/write memory organised as 256 8-bit words Access read/write 0.06 seconds (2 frames) 2 notches of thermo Pinout diagram https://i.imgur.com/CXWLXc7.jpg Layout diagram There's just enough room on a max size microchip to fit everything neatly. https://i.imgur.com/L6w9HNI.jpg https://i.imgur.com/TpXKR1q.jpg How to use it The memory is addressed by applying a binary number to the 8 Address inputs. After addressing, information may be either written to or read from memory. To write, the Write Enable input must be equal to 1. Information applied to the 8 Data inputs will then be written to the addressed location. To read, the Read Enable input must be equal to 1. Information will be read from the addressed location to the 8 Read outputs. Example https://i.imgur.com/oDN4NCx.jpg In this example 3 is being written to address 1. https://i.imgur.com/BOJuVuJ.jpg Reading from address 1. The contents of this address are 3, as seen on the Read outputs. EDIT: It might help if I remembered to publish the thing: http://lbp.me/v/qrwmv4c If you make something cool using this chip I'd be interested to know. I made it shareable so you're free to do whatever you want with it. | 2014-05-27 12:56:00 Author: Ayneh ![]() Posts: 2454 |
WOW, I'm impressed! Functional and beautiful. Incredible work, well done. I can't think of any use I would have for it right now, but it's nice to know that it's there if I need it. Thanks for sharing! | 2014-05-27 19:26:00 Author: fluxlasers ![]() Posts: 182 |
Wow Ayneh. You really get everything you can from LBP's engine! This is quite awesome. Thanks for sharing ![]() | 2014-05-27 20:59:00 Author: yugnar ![]() Posts: 1478 |
http://graphicashen.com/wp-content/uploads/2013/08/mind-blown.jpg Wow... just... wow! | 2014-05-28 03:11:00 Author: Pulparindo15 ![]() Posts: 334 |
Wow.... That is Impressive! It looks just like a real microchip. Crown for Ayhen! | 2014-05-30 09:23:00 Author: CodemanPSX ![]() Posts: 147 |
No we only needed a programmable interface to go with it... But I think that would be something for a LPB3! (processor chip anyone?) | 2014-06-01 00:50:00 Author: gdn001 ![]() Posts: 5891 |
Mighty ambitious and very interesting undertaking. I have a question about the format in which you actually store the data itself. Given that 1 analogue signal is capable of holding 26 bits worth of information, you could hold all 2048 bits of information by saving only 79 unique signals, is this what you did, or did you save the unique state of all 2048 individual bits? If you did save each bit individually it may yet be possible to further increase the simplicity / thermo efficiency of your design by instead saving just 79 signals. | 2014-06-02 14:45:00 Author: Seku ![]() Posts: 65 |
No we only needed a programmable interface to go with it... That's why I made it. It's been done before (http://lbp.me/v/0s5dj3) in LBP if you didn't already know, Given that 1 analogue signal is capable of holding 26 bits worth of information, you could hold all 2048 bits of information by saving only 79 unique signals, is this what you did, or did you save the unique state of all 2048 individual bits? If you did save each bit individually it may yet be possible to further increase the simplicity / thermo efficiency of your design by instead saving just 79 signals. Each bit is individually stored in a counter. I have zero experience with analog systems, so that'd have to come down to someone else to implement. | 2014-06-03 12:59:00 Author: Ayneh ![]() Posts: 2454 |
Although you may have zero previous experience, if you ever want to learn more about analogue signals and how they can be useful in memory systems such as this, give the rest of this post a read. I also have quite a few blog entries that discuss logic, particularly dealing with analogue signals. Blog - http://www.lbpcentral.com/forums/blog.php?23190 ----------------------------------------------------------------------------------------------------------------------------------------- http://www.lbpcentral.com/forums/entry.php?10459-Signal-Memory-Sampling http://www.lbpcentral.com/forums/entry.php?10735-Memorizer-Efficiency-Binary-Data-Compression https://lbpcentral.lbp-hub.com/index.php?t=83858-Thinking-Outside-the-Box-in-Bit-Compression The 3 articles above detail how to convert up to 26 bits into 1 analogue signal and then save that signal. If you wish to utilize this method effectively there are some design issues which should be considered. For example, in its current state your system considers ever 8 bits as 1 position in memory. If you consider an analogue signal as 26 bits, this means that 1 analogue signal will hold 3 positions in memory with 2 bits remaining, for simplicity we can ignore these two remaining bits and begin storing the next 8 bits of data in an entirely new signal. This means that you only need to convert 24 bits into an analogue signal which will reduce the complexity required for converting binary -> analogue just a tad, however we are being wasteful in terms of optimizing the systems overall memory capacity by discarding these 2 bits. A problem that would arise from this as your system currently stands is addressing each location in memory. To illustrate the issue, lets say you decide to store 8 analogue signals (each containing 3, 8-bit locations, a total of 192 bits), to address any particular location you could use 3 bits to address which of the 8 analogue signal the the data is contained within, then you would require 2 bits to identify which of the 3 locations you actually want to refer to within the analogue signal itself. This is a problem because 2 bits can represent 4 states, which means that we are wasteful in the sense that 1 of these states will never be utilized. These kinds of problems can be overcome by making some design choices before creating your system. However, before we do that there is one important question you should ask yourself: "Do I want the data stored at a particular location to be able to hold the address of another location in memory". If you answered yes (which I am going to assume you did for the rest of this post) it implies that if your system is 8-bit addressable, each position in memory must hold AT LEAST 8-bits (possibly more). If you answered no this limitation doesn't apply. So to begin with lets say you want your system to be 8 bit addressable. We can choose to store 2, 13-bit pieces of data in each signal (we chose 2 here because it is a binary number unlike 3 which was previously wasteful when addressing memory locations and we chose 13 because 13x2 fits perfectly into 26; the bit capacity for each signal). This means when we want to address a particular location in memory, 1 bit of that memory address will dictate which of the 2, 13-bit locations we are referring to within the analogue signal in question. Given that we chose to have an 8 bit addressable system, this means we have 7 bits remaining to address the analogue signal itself. 2^7 = 128 analogue signals (maximum). This gives the system a total capacity of 128 x 26 = 3328 bits. You could still choose to store just 8 bits at each memory location if you would like, however, the total capacity of your system would decrease back to 128 x 16 = 2048 which is not optimal for the number of signals you are storing. This decrease in overall capacity is because with each analogue signal we would only be using 16 of the available 26 bits, effectively discarding 10 bits from each signal. 3328 - ( 10 x 128 ) = 2048. Note - I mentioned in my previous post that 2048 bits can be stored within 79 analogue signals. This is true, however, implementing this in a system where each memory location holds 8 bits would mean that some memory locations extend across multiple analogue signals. This would effectively increase the system's complexity because it requires more logic to figure out how to correctly read/write data to each location. Because this additional complexity is not actually necessary for this kind of memory system to function (as demonstrated throughout the rest of this post) it can be said that such a system is poorly designed. | 2014-06-04 03:33:00 Author: Seku ![]() Posts: 65 |
The 3 articles above detail how to convert up to 26 bits into 1 analogue signal and then save that signal. The inverse, converting from an analog signal to binary, is conspicuously absent. Perhaps you can show me a circuit that converts binary to analog to binary. It's not implicit from the links to me. If you wish to utilize this method effectively there are some design issues which should be considered. For example, in its current state your system considers ever 8 bits as 1 position in memory. If you consider an analogue signal as 26 bits, this means that 1 analogue signal will hold 3 positions in memory with 2 bits remaining, for simplicity we can ignore these two remaining bits and begin storing the next 8 bits of data in an entirely new signal. This means that you only need to convert 24 bits into an analogue signal which will reduce the complexity required for converting binary -> analogue just a tad, however we are being wasteful in terms of optimizing the systems overall memory capacity by discarding these 2 bits. The 13-bit width memory you go on to describe is, in the context of an 8-bit system, less efficient given it can only store 2 bytes per feedback loop, as opposed to the 3 bytes you mention here. The potential thermo savings are tempting. You have 10 components per byte and 1 frame of latency from enabling the microchip to beat. Assuming this, the analog chip would be superior on all fronts. How I imagine it being implemented from what you describe is for every 3 addresses you have 1 feedback loop. How to write to a specific byte is unknown to me but I assume you divide or multiply by some power of 2 to shift the bits x places. I would forget individually addressing the analog signal itself for reading and just dump the entire thing in binary to a 24-bit buffer, at which point it would be trivial to decode since the address line is still high. | 2014-06-04 15:06:00 Author: Ayneh ![]() Posts: 2454 |
I have a logic kit on my earth which has a 24 or 25 bit binary -> analogue AND analogue -> binary converter in it, although I can update the logic kit to instead have the 26 bit version if you'd like. http://lbp.me/v/jy7b2e Also, I'm not entirely sure what you mean by: "I would forget individually addressing the analog signal itself for reading and just dump the entire thing in binary to a 24-bit buffer, at which point it would be trivial to decode since the address line is still high." The way I imagine the reading would occur is that some of the address bits are responsible for selecting which analogue signal is passed through the analogue -> binary converter to convert it to 24 or 26 bits (depending on how you choose to design your system), then the other address bits are responsible for selecting which byte is passed as your final output. ----------------------------------------------------------------------------------------------------------------------------------------- You are correct in saying that the 13 bit method does have less bytes per feedback loop (2, rather than 3) but the implication that it is then less efficient isn't quite true. To store 3 bytes in each feedback loop means you're only storing 24 bits in each feedback loop, however, the other method stores 26 bits per feedback loop (which is the maximum possible). It also doesn't have the inefficiency with addressing locations in memory. The primary problem with having 3 bytes within each feedback loop comes when you wish to read/write to a particular location in memory. Perhaps the simplest way to think about how to do this is to break it up in to a 2 step process. Consider the method with 3 bytes in each feedback loop and suppose we have 64 feedback loops. 1) The first step to read/write to any particular location would be to reference which feedback loop we want to read/write within, given that 2^6 = 64, we can uniquely reference each feedback loop using just 6 bits. 2) The second step deals with determining which of the 3 locations within the feedback loop in question we want to read/write to. In order to distinguish which position we wish to read/write to we need to use 2 bits, herein lies the problem. With 2 bits we are capable of representing 4 possible states, not just 3, this means that 1 state will always remain unused and this is very wasteful when complying with the below statement: If your system is 8-bit addressable, each position in memory must hold AT LEAST 8-bits (possibly more). In a mathematical sense: (No. of bits for address) Must be less than OR equal to (No. of bits for data) The system described uses 8 bits for data and already requires ( 6 + 2 ) = 8 bits to address each location in memory with just 64 feedback loops (to add more feedback loops means to require more bits to address any particular location in memory which we cannot do without violating the above statement). This limits your total memory capacity to: 3 byte system (8 bit address) ( 64 x 3 ) = 192 bytes OR ( 64 x 24 ) = 1536 bits. [1] This gives us incentive to stick with binary numbers when considering how many bytes we want to store in each feedback loop (1, 2, 4, 8, etc.) as this will optimize how many bytes we can reference for a given number of bits in our address [1]. The bit capacity of a feedback loop is 26 which is not divisible by 4 or 8, this implies that to try to fit 4 or 8 bytes within a feedback loop will result in some of the 26 bits not being used. [2] In this sense, storing 1 or 2 bytes in each feedback loop is more optimal (because 26 is divisible by these numbers) as it allows us to store a greater total number of bits for the same number of feedback loops [2]. To demonstrate this consider now the 2 byte system (with 13 bits in each byte and 2 bytes in each feedback loop), again with 64 feedback loops. Again we use 6 bits to address the feedback loop, but now we only require 1 bit to determine which of the 2 bytes we are referring to within the feedback loop and this time each of the two states that can be represented by this 1 bit are utilized. This means we are only using 7 bits, rather than 8 to address each location in memory AND we have a total memory capacity of: 2 byte system (7 bit address) ( 64 x 2 ) = 128 bytes OR ( 64 x 26 ) = 1,664 bits Directly comparing the two systems it does seem as though the 3 byte system is capable of storing more bytes, however, [2] the 2 byte system stores more bits for the same number of feedback loops (in this case 64) [2]. Recall that the 3 byte is also using 8 bits for its memory address while the 2 byte system is using just 7 bits. To use an 8 bit address with the 2 byte system allows us to store up to 2^7 = 128 feedback loops, rather than 64, which would put the total memory capacity up to: 2 byte system (8 bit address) ( 128 x 2 ) = 256 bytes OR ( 128 x 26 ) = 3,328 bits [1] This demonstrates how storing a binary no. of bytes within each feedback loop, for a given number of address bits ( in this case 8 ) we can store more bytes [1]. Furthermore, you could still comply with the earlier statement when pushing the address up to 13 bits which could allow up to 2^12 = 4,096 feedback loops, which would really be overkill and almost certainly consume way too much thermo but it does give the system more flexibility to accommodate for a high demand of memory if needed (though I doubt anyone in LBP would ever need this much). In theory it could have a total memory capacity of: 2 byte system (13 bit address) ( 4,096 x 2 ) = 8,192 bytes OR ( 4,096 x 26 ) = 106,496 bits I hope this clarifies the advantages not only for this particular system but also for carefully considering how to design any system. Remember that both of these systems would be perfectly identical in the way that their logic operates, one is no more difficult to understand than the other, however, carefully considering your design options can allow you to get a lot more value for a system of the same complexity. | 2014-06-05 01:13:00 Author: Seku ![]() Posts: 65 |
I'm not entirely sure what you mean by: "I would forget individually addressing the analog signal itself for reading and just dump the entire thing in binary to a 24-bit buffer, at which point it would be trivial to decode since the address line is still high." The way I imagine the reading would occur is that some of the address bits are responsible for selecting which analogue signal is passed through the analogue -> binary converter to convert it to 24 or 26 bits (depending on how you choose to design your system), then the other address bits are responsible for selecting which byte is passed as your final output. Take incrementing the address of the 3 byte feedback loop we were chatting about for example. No matter how you slice it there's gonna be problems, 'cause outside of the least significant bit there's nothing to sink your teeth into. There's no reason to sub-address each individual byte with 2 bits when you can just tie every third address directly to the third byte of the decoded output of the entire feedback loop, you get me? In this sense, storing 1 or 2 bytes in each feedback loop is more optimal (because 26 is divisible by these numbers) as it allows us to store a greater total number of bits for the same number of feedback loops. Directly comparing the two systems it does seem as though the 3 byte system is capable of storing more bytes, however, the 2 byte system stores more bits for the same number of feedback loops The highest order 5 bits of a 13-bit number will simply never be utilised in an 8-bit word system. In theory since it makes full use of an analog signal in LBP it's superior, but it's simply not practical for what I want to use it for. http://lbp.me/v/jy7b2e Thanks, this is pretty cool. It looks like there's a frame of delay somewhere during the conversion. Do you know offhand what section of the circuit causes this? | 2014-06-05 15:04:00 Author: Ayneh ![]() Posts: 2454 |
LBPCentral Archive Statistics
Posts: 1077139
Threads: 69970
Members: 9661
Archive-Date: 2019-01-19
Datenschutz
Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.