Connect with us

RAM Chips

Discussion in 'Microcontrollers, Programming and IoT' started by gulagman145, Mar 7, 2015.

Scroll to continue with content
  1. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    Hello gents,
    I'm looking to record some precise time measurements, down to the nanosecond or so. If I have a counter counting up (in ns) and I want to record the count at a given time on a ram chip, what kind of response could I expect from the chip? I know there are latencies associated with changing row and column in read operations, but the data I've found on write times is very vague.

    Any insight would be helpful!

    I don't need exactly down to the nanosecond times, but I want to keep it within the single digits of the actual 'record' time.

    Thanks!
     
  2. Gryd3

    Gryd3

    4,098
    875
    Jun 25, 2014
    Depends on your implementation.
    Will you be storing the values in the 'RAM chip' with time stamps?
    If so, latency to the chip won't matter so much as the data and timestamp will depend on the values the microcontroller currently has.
    I would think that the overall sustained write speed it more important than latency.

    Can you fill us in on more details?
     
  3. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    Thanks for the reply!
    The time stamp itself would be sufficient, I basically need the times that something occurs, but it will be happening on a nanosecond scale. I had the idea of a nanosecond pulser running a counter that i could pull values from when the appropriate signal goes high. I'm talking specifically about the most basic RAM chip, but can you describe the components you are referring to?

    Here's a basic key output I need-
    Times (in ns) at which 'x' occurs, transferred to a PC. I'm hoping to get a list of timestamps (in the case you mentioned) of all occurrences of 'x' once per milisecond ideally.
     
  4. gorgon

    gorgon

    603
    24
    Jun 6, 2011
    OK, so you want to register a timestamp from a 1GHz clock, at a 1kHz'ish rate? I would think that you will need some ultra high speed logic to count and latch the time, at least part of it, and a microcontroller to read and transmit the time stamp. As long as the latency of the latch process is known and consistent, this time can be subtracted from the registered value by the microcontroller, to get a correct time stamp. Each stamp will need a substancially number of bits to be of any use.
     
  5. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    Thanks for the reply Gorgon.
    The counter itself is going to need a huge number of bits to accommodate times at a nanosecond-level division, so yeah I expect the bits to be flipping faster than the memory can write.
    When you are referring to the 'latch' process, are you suggesting to store at least a portion of the counter bits in flip flops or the like? They would need to mimic the counter bits and 'disconnect' from the counter at the time 'x' occurs...
    Maybe I have that wrong, but it sounds plausible?
     
  6. Gryd3

    Gryd3

    4,098
    875
    Jun 25, 2014
    This depends on your setup...
    If you want a full time stamp with the current year, date, and time then you will need far more bits than if you simply wanted the current time of day.

    Additionally, have you clarified how many samples per second you want to take?
    There is resolution and frequency. I understand you want the resolution to be very accurate.
    When you determine what data you want to store, you can determine the size of each record you want to save. You then multiply this by the amount of sample you want to save each second and you get an answer to the throughput of the memory you need.
    So, what I'm trying to say is that you do not need 'fast' storage if you are only saving 100 records per second. Even if each record is accurate to the nanosecond.
    (Think about how digital cameras work. They capture the data, then write it to the SD card... you cannot do another capture until the write is complete or until enough memory frees up. They store the contents of the CCD incredibly quickly to memory, then take their time writing it to more permanent storage. To increase the frame rate, you need to A) decrease the data being stored per frame, or B) get storage with a higher sustained write speed.)
     
  7. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    Gryd-
    You're right I didn't specify the frequency of samples. I'm using a high-speed comparator to check if a voltage level is exceeded, this is basically an occurrence of 'x'.
    The minimum delay in between occurrences could potentially be on the order of a couple nanoseconds as well, which I think is the point of your question; the write time will be too-long compared to the delay between occurrences and will either clip or otherwise interfere with the accuracy of the write process. I've considered switching RAM chips for successive occurrences, but that would not prevent the bits from continuing to flip with the counter unless some kind of data buffer is used.

    I think in general I'm making too much of what I'm trying to do. Fundamentally I need a list of times (or relative times) that these occurrences happen, in ns.

    Maybe a more general question about RAM would help my understanding-
    From what i have read, a simple RAM chip stores a single bit in an address (row, column). Is that true?
    Thank you for taking an interest!
     
  8. Gryd3

    Gryd3

    4,098
    875
    Jun 25, 2014
    Well, this is certainly going to be an interesting project.
    I thought maybe recording and analysing later... but you would need a sample rate of at least 1Ghz, at which point there may still be missed 'glitches'.
    As far as the actual detection is concerned... I thought maybe a flip flop could be used, so the output would toggle between high/low each time the event occurs. This would be easier to capture, but you would need to use components that have a very fast rise/fall time, or the output of the device would simply wiggle around in the middle if multiple event occurred in succession.
    It's too bad you can't just use a digital oscilloscope and log it for a while.. How long do you need to monitor for events?

    Full disclosure, I can help brainstorm, but the speeds are way outside my experience.
     
  9. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    Full disclosure: I am a mechanical engineer by trade, electronics are just a hobby :)
    My endgame is to make this potentially part of a manufacturable device for an idea I had, and I think a scope breaks the bank. Size is also a consideration, though a scope would be perfect for looking at what I need to 'see.'
    If I'm logging 'occurrences' in 150,000 nanosecond 'cycles' could I get a RAM chip with that many rows and have the row address change with the clock? That way there would be a unique identifier in the ns-domain for each occurrence... I'm guessing that wont work because of latency in changing rows being greater than 1ns, but again that's where my knowledge of RAM chips is limited...
     
  10. Gryd3

    Gryd3

    4,098
    875
    Jun 25, 2014
    The most important part here is throughput.
    You will want to store 1Gbit / second. If each sample is delayed by 35ms, then it's pretty easy to compensate. Additionally, if all samples are delayed the same amount, the relative time between samples will be the same ;)
     
    gulagman145 likes this.
  11. hevans1944

    hevans1944 Hop - AC8NS

    4,377
    2,046
    Jun 21, 2012
    To accomplish the objectives of time-stamping events with one nanosecond resolution requires first of all a binary counter fast enough to count at a 1 GHz rate for one nanosecond resolution, and wide enough to store events for the longest period of time between the first event and the last event. For example, if there is a period of one second between the first event and the last event, then the counter must store numbers between 0 and 1,000,000,000 or about 30 bits of binary. Add more bits to the counter length for longer time periods.

    Second, when an event occurs, the present count must be transferred to RAM. The depth of the RAM depends on how many events must be recorded, while the width is equal to the number of bits in the binary counter. Since RAM storage occurs "on the fly" while the counter is incrementing, an event must cause the current count to be transferred to a RAM write-register without interrupting the incrementing count. There are static RAM devices that have input registers that can perform this function, so a separate "latch register" is not needed. After each event, which apparently can occur at nanosecond intervals, the address of the SRAM is incremented after the current count is stored. There are SRAMs available that can do this too at 1 GHz update rates.

    For more information visit this Cypress website. Their SRAMs aren't cheap, and the support circuitry will probably need ECL (emitter coupled logic) to meet setup and timing requirements. The binary counter will probably have to be implemented with ECL to reliably increment at gigahertz rates. Note this must be a synchronous binary counter, not a simple ripple counter, because the propagation delay in a 30-bit or longer ripple counter simply will not keep up. The hardware required is low voltage, so serious attention to layout, high frequency grounding practices, and controlled-impedance transmission line PCB traces is necessary to guarantee logic levels are preserved.

    I would be interested in seeing the hardware and circuitry used for an analog comparator capable of one nanosecond switch cycles.

    This does not sound like a project for the uninitiated in high-performance logic design.
     
    Gryd3 likes this.
  12. gulagman145

    gulagman145

    6
    0
    Mar 7, 2015
    hevans-
    Thanks for the detailed reply!
    The idea in your second paragraph seems to be along the lines of what I was trying to describe. Technically I don't need a 30-bit width, as long as the number of rows in the RAM are sufficient to meet the overall cycle time (I gave the 150,000 count estimate for the overall cycle time). I can simply save a non-zero value to that row and decipher the existence of a non-zero number in that row as an occurrence of the event, with the row number being the count "timestamp". This would require the current row of the RAM chip (the row being written to) to change at 1ns intervals with the 1ns pulser; this is a concern I mentioned, but you noted that there are static RAM chips with that capability!

    As far as the comparator, here's what I was considering as a potential candidate.
    https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=http://pdfserv.maximintegrated.com/en/ds/MAX9600-MAX9602.pdf&ei=s6QAVfzVDMrEggT44oCwDw&usg=AFQjCNHWree-qZMT29CbLUUmJZ8Pjz6cFA&sig2=IznXNUce7_5xWqtlwd0I8w&bvm=bv.87920726,d.eXY

    The datasheet claims propogation delays on the order of (500 min) picoseconds, but I don't know how reliable that is in reality. In addition, there seems to be sensitivity to source impedance, which may be a factor as well. I should note that while the 'promptness' of the comparator output is important, it isn't what I would call critical as long as it is consistent. For the same reason Gryd mentioned, I can subtract a standard offset from the times if large enough to cause problems.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-