• FULLY non-destructive read-back!

    Eric Hertz • 03/15/2020 at 18:53 • 0 comments

    As a reminder:

    We have two independently-controllable banks of RAM, each of 4 chips [Left column and right]. These banks are wired together in such a way that all 8 chips can be accessed by a single r/w connection to the data bus through a sort of march ("Left right left") of the data.

    Today's waking thought is much like the other day's "duh moment" [in a previous log]. WE HAVE TONS OF RAM. For some reason, last time I made that observation, I didn't get the full implication!

    Last time I realized that to read-back the left column, I don't have to destroy the data at the same addresses in the right column, so therefore could read-back any address from the left to any address on the right. Like, for instance, a dedicated address for the shear purpose of a temporary shift-space. YEAH!

    But, for some reason I hadn't made that same observation the other way. Thus, it was expected that read-back from the left column would inherently shift the data stored there from chip to chip, and eventually out of the column entirely.

    That's fine for most intended cases; #sdramThingZero - 133MS/s 32-bit Logic Analyzer uses the left column for the realtime sampling of data, and in most cases will be connected to a computer with plenty of its own RAM to store the samples internally once transferred.

    BUT: the original data, in the left column, *doesn't* have to be destroyed, nor even shifted, because, again, WE HAVE TONS OF RAM. So, another dedicated temporary location can be used in the left column, TOO! [DUH!]

    And now, #sdramThingZero - 133MS/s 32-bit Logic Analyzer can use this method to connect 64 data bits to an 8 bit bus and is no longer limited to computers with lots of RAM; can be used with a PC/XT, a Kaypro, a Gameboy, or an AVR-based arduino, as I'd intended from the start. WEEE!

    [And another thought on using this same method to *serialize* the 8-bit bus down to a single bit?!]

    [And maybe the DQ latch could be replaced with a buffer with /OE, buffer output tied to the first 'chip' in the right column, since sdramThingZero has no reason to *write* to the sample-memory... hmmm... OTOH, there's little reason to *read* the right-column, either... main reason is just to make certain it wrote correctly... so there may be room for even further optimization]

    Hey HaD!!!

    Please do something about the editting of logs' sometimes deleting images! All I did was add that last bit in brackets, and hitting backspace[?] somehow deleted the image numerous paragraphs above?! This is nowhere near the first time.

  • Shift-left for ALU?

    Eric Hertz • 03/01/2020 at 21:04 • 0 comments

    With two working registers, this makes for, say, the shift-left portion of a 4-bit homebrew ALU/CPU...

    With two separately-controlled DRAM banks, or one and a register, could easily serialize any nibble stored anywhere...

    I *think* this could be used for e.g. SPI, where several hosts communicate in a ring topology...


  • Overview

    Eric Hertz • 03/01/2020 at 18:05 • 0 comments

    Times like these, it might be wise to start a new project-page, for a "subproject"... 'cause it's been so long I've actually worked on the #sdramThingZero - 133MS/s 32-bit Logic Analyzer  main project, that I'mma have to read through tons of logs to remember where I left off, and to sort through TODO ideas like these...

    But this idea is pretty durn interesting to me at the moment, so it'll prb occupy several log-entries.

    ----

    The basic idea:

    On a PC-100 SDRAM DIMM, there are two separately-controllable "banks" of 32-bit wide memories. It is technically possible [to some extent] to have these two banks running separate read/write operations simultaneously. Thus, it's possible to have one bank, 32bits, reading [outputting data] at the same time the other 32-bit bank is writing [inputting data].

    That's a *huge* part of sdramThing. But I'm not going into that, here.

    A key factor of #sdramThingZero - 133MS/s 32-bit Logic Analyzer is that I intend to interface all 64bits [and more] to an 8bit bus... and... that 8-bit bus I'd like to be quite simple e.g. not having 8 separate "Byte-Select" signals. Ideally, something similar to a LPT port, or like a character-LCD... 8 data I/O's, Read/Write, strobe, and maybe one or two register-selects... something like that. [For some reason I kinda want this to work with USB-LPT dongles, though it's mostly aimed at single board computers with their own GPIOs].

    OK, that's the jist.

    Now, The obvious solution is to just wire 'em all together in 8-bit groups, then use the SDRAM's Data-Mask [DQMB] pins to select which byte to access. Those DQMB pins could be wired to an 8-bit D-latch register like a 74HC574.

    BUT: another key factor of this project is that the memory banks are ALSO used *separately* from the data-bus... So, all those data I/O bytes can't be wired directly together... 

    So, now the next obvious solution is to isolate them from each other and the bus when doing other things, then connect them to the bus when necessary. 64bits is 8 bytes. An e.g. 74HC245 could handle each byte's bus connection, so 8 chips for arbitrating 8 bytes onto the bus. Now, each of those chips has an Output-Enable pin and a Direction pin, so now we need 16 additional control signals on our bus. So, now we need Two 74HC574 8-bit D-Latch registers to set up a read/write on the bus. We'll need two register-select wires to carry the three states [w Direction register, w byte-select register, r/w data byte]. And we'll need glue logic to decypher those two binary signals into three control signals. 

    We're at 11 chips, now. Just to connect the memory to the bus. [Nevermind all the non-bus-related circuitry!]

    So, I'mma step back and think of other options. And I've come up with *numerous*.

    -----

    Here's the recent thought:

    In my case I don't often need to randomly access any byte from the bus; most of the time I'll be reading/writing huge blocks in sequence...

    Also, the memory is *huge* [for my needs], we can sacrifice half of 128MB and still be doing great.

    So an option is to use a shifting method; connect the two 32-bit banks together such that e.g. bank1-byte1 is written to bank2-byte1 [and bank1-byte2->bank2-byte2, and so forth], then in the next operation bank2-byte1 [which now contains the data from bank1-byte1] is written to bank1-byte2, and so-forth. 

    Thus, the data shifts through the bytes, and only one r/w byte needs to be connected to the bus.

    Of course, this destroys the data in one bank... but we have PLENTY of RAM, and [I think] can limit the "destruction" to a single page [bytes!], which could simply be a designated "temporary" page...

    "But Wait! You can't just wire the bytes like that directly, otherwise there'll be contention, you still need some buffers with output-enables, etc."

    True, but, note that now there's only *two* output-enables instead of 8, and no direction signals. Also, we may be able to use the SDRAM's output-enables, etc....

    Read more »