Post by thread:Circular Buffer Help

I would really like to hear from you software `Gurus' on this... Given a 32K Byte SRAM circular buffer, a `trigger-event', and a fixed delay count after the event, I would like to know the best method of determining when the event' occurred. One method would subtract the delay count from 32K and use the result to clock the SRAM address counter to point to the event. Another method is reading the current SRAM address counter and subtracting the delay to get an absolute pointer to the event. In any case, You are working with the relative offset from the event. Both methods will provide a pointer to the event using simple math. My question is; do you really need to read the counter address in this application? From a software standpoint, is there any advantage? This has a direct impact on my PIC-based logic analyzer project and I would like to `nail this down' as I can save resources with the first method. Thanks, - Tom

> Van: Tom Handley <spam_OUTthandleyTakeThisOuTTELEPORT.COM> > Aan: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU > Onderwerp: Circular Buffer Help > Datum: zondag 26 april 1998 21:51 > > I would really like to hear from you software `Gurus' on this... Oh, Jolly ! Now I can pose as a 'Guru' ;-) > Given a 32K Byte SRAM circular buffer, a `trigger-event', and a fixed > delay count after the event, I would like to know the best method of > determining when the event' occurred. > > One method would subtract the delay count from 32K and use the result to > clock the SRAM address counter to point to the event. This method is usable, although you will be referring to the Adress-counter as in the next example. It'll take more time though, 16K clock's take some amount of time ... And what if you want to have more samples _before_ the event than _after_ (say 90% before and 10% after) ... > Another method is reading the current SRAM address counter and > subtracting the delay to get an absolute pointer to the event. This method is quite fast, because you only have to do a simple 16-bit subtraction/addition. And that for any event-delay. > In any case, You are working with the relative offset from the event. > Both methods will provide a pointer to the event using simple math. My > question is; do you really need to read the counter address in this > application? From a software standpoint, is there any advantage? No, you don't have to. But it will be quickest. _and_ you will have an absulute reference. (Two counters, one in hardware & one in software _could_ get out-of-sync ...) > This has a direct impact on my PIC-based logic analyzer project and I > would like to `nail this down' as I can save resources with the first method. > Thanks, > > - Tom Greetz, Rudy Wieser

Rudy, thanks for the feedback. I agree that the ability to read the absolute address is a plus. Note, the current design does this. That particular CPLD contains the address counter and control circuitry to read the counter as well as the SRAMs. By eliminating the need to read the absolute address, I could move the counter to a single 74x393 and free up a lot of CPLD resources for other functions, possibly reducing the design from 3 CPLDs to 2. [concerning the first method without an absolute address] >This method is usable, although you will be referring to the Adress-counter >as in the next example. It'll take more time though, 16K clock's take some >amount of time ... And what if you want to have more samples _before_ the >event than _after_ (say 90% before and 10% after) ... >................... (Two counters, one in hardware & one in software >_could_ get out-of-sync ...) The delays are fixed at 1, 16, 64, 256, 1024, 4096, 16384, and 32768 Bytes. The host still has to read 32K Bytes. My thought was to subtract the fixed delay from 32K and clock the result into the host buffer. At that point you would have a pointer to the trigger in the host buffer. Then you would clock in the remaining Bytes. With the absolute address, the host would first read the address, then reset the counter and read 32K. Once the captured data is in the host, it seems to me that the host software would have to do similar math to look at events before and after the trigger. I'm not too concerned about the hardware counter and the host pointer getting out of sync if the hardware design is `clean'. Still, I'm leaning towards providing the absolute address. - Tom At 11:42 AM 4/27/98 +0200, Rudy Wieser wrote: {Quote hidden}>> Van: Tom Handley <thandleyKILLspamTELEPORT.COM> >> Aan: .....PICLISTKILLspam.....MITVMA.MIT.EDU >> Onderwerp: Circular Buffer Help >> Datum: zondag 26 april 1998 21:51 >> >> I would really like to hear from you software `Gurus' on this... > >Oh, Jolly ! Now I can pose as a 'Guru' ;-) > >> Given a 32K Byte SRAM circular buffer, a `trigger-event', and a fixed >> delay count after the event, I would like to know the best method of >> determining when the event' occurred. >> >> One method would subtract the delay count from 32K and use the result >to >> clock the SRAM address counter to point to the event. > >This method is usable, although you will be referring to the Adress-counter >as in the next example. It'll take more time though, 16K clock's take some >amount of time ... And what if you want to have more samples _before_ the >event than _after_ (say 90% before and 10% after) ... > >> Another method is reading the current SRAM address counter and >> subtracting the delay to get an absolute pointer to the event. > >This method is quite fast, because you only have to do a simple 16-bit >subtraction/addition. And that for any event-delay. > >> In any case, You are working with the relative offset from the event. >> Both methods will provide a pointer to the event using simple math. My >> question is; do you really need to read the counter address in this >> application? From a software standpoint, is there any advantage? > >No, you don't have to. But it will be quickest. _and_ you will have an >absulute reference. (Two counters, one in hardware & one in software >_could_ get out-of-sync ...) > >> This has a direct impact on my PIC-based logic analyzer project and I >> would like to `nail this down' as I can save resources with the first >method. >> Thanks, >> >> - Tom > >Greetz, > Rudy Wieser > >

> Van: Tom Handley <EraseMEthandleyspam_OUTTakeThisOuTTELEPORT.COM> > Aan: PICLISTspam_OUTMITVMA.MIT.EDU > Onderwerp: Re: Circular Buffer Help > Datum: maandag 27 april 1998 16:04 Hello Tom, > Rudy, thanks for the feedback. I agree that the ability to read the > absolute address is a plus. Note, the current design does this. That > particular CPLD contains the address counter and control circuitry to read > the counter as well as the SRAMs. By eliminating the need to read the > absolute address, I could move the counter to a single 74x393 and free up a > lot of CPLD resources for other functions, possibly reducing the design from > 3 CPLDs to 2. [Cut] Oh ... I was thinking you wanted to build a stand-alone device, but I understand now that you are designing a sort of PC-probe. O.k. Why not give the PC the data as-is ? At the next adres would be the first valid sample. Clock 32K times and your buffer is send to the host in the most usefull way there is. The first valid sample at offset 0 in the Host-buffer. Just send the event-delay value as special data to your host. The Trigger-Event would be at that offset in the Host-buffer. In this way you would not need an absolute adres into your sample-buffer. This would even mean that resetting the hardware adress-counter is not needed anymore ... Greetz, Rudy Wieser

> This method is quite fast, because you only have to do a simple 16-bit > subtraction/addition. And that for any event-delay. > > > In any case, You are working with the relative offset from the event. > > Both methods will provide a pointer to the event using simple math. My > > question is; do you really need to read the counter address in this > > application? From a software standpoint, is there any advantage? > Correct me if I'm wrong but whenever I have used a circular buffer, I get to the top of my memory map and rollover back the the start of my memory map. My current location is my latest sample, and the next highest byte is my oldest data. If your 'trigger event' occured BEFORE you rolled over, it would no longer be SIMPLE math. What would be wrong with haveing the 'trigger event' run a simple interupt that simply stores a counter location to RAM? P.S. My programming knowledge far exceeds my PIC knowledge (which doesn't say much).

Mark Devin Newland <@spam@apeKILLspameskimo.com> wrote: > Correct me if I'm wrong.... Ok. > .... but whenever I have used a circular buffer, I get to the top > of my memory map and rollover back the the start of my memory map. > My current location is my latest sample, and the next highest byte > is my oldest data. If your 'trigger event' occured BEFORE you > rolled over, it would no longer be SIMPLE math. Sure it would, Mark... Look at these two examples: Buffer extends from 0000 to FFFF. Trigger event occurred 5 cycles ago. Example #1: Current location = 9. Subtract 5 to find the trigger location: Trigger event occurred at 9 - 5 = 4. Example #2: Current location = 2. Subtract 5 to find the trigger location: Trigger event occurred at 2 - 5 = -3 = FFFD. See? It works even if your subtraction wraps around the buffer. -Andy === Andrew Warren - KILLspamfastfwdKILLspamix.netcom.com === Fast Forward Engineering - Vista, California === http://www.geocities.com/SiliconValley/2499 (personal) === http://www.netcom.com/~fastfwd (business)

Rudy, I really should have posted this in my PIC-based Logic Analyzer topic so it would have been easier to see where I was comming from. The host sends the delay count to the analyzer as part of the sample request so it already knows the delay. Once `armed' the analyzer records data in the circular buffer until a trigger event. Then a delay counter is started. At the end of that count, the address counter clock is disabled and the capture mode is complete. The host can monitor this. I like your suggestion of clocking in 32K and then subracting the delay. Last night I did another update to that particular CPLD and I was able to eliminate 1 74x-family `glue' chip while retaining the capability to read the absolute address. At this point, eliminating the address read-back will not save anything so I'll keep it. - Tom At 09:26 AM 4/28/98 +0200, you wrote: {Quote hidden}>> Van: Tom Handley <RemoveMEthandleyTakeThisOuTTELEPORT.COM> >> Aan: spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU >> Onderwerp: Re: Circular Buffer Help >> Datum: maandag 27 april 1998 16:04 > >Hello Tom, > >> Rudy, thanks for the feedback. I agree that the ability to read the >> absolute address is a plus. Note, the current design does this. That >> particular CPLD contains the address counter and control circuitry to >read >> the counter as well as the SRAMs. By eliminating the need to read the >> absolute address, I could move the counter to a single 74x393 and free up >a >> lot of CPLD resources for other functions, possibly reducing the design >from >> 3 CPLDs to 2. > >[Cut] > >Oh ... I was thinking you wanted to build a stand-alone device, but I >understand now that you are designing a sort of PC-probe. > >O.k. Why not give the PC the data as-is ? At the next adres would be >the first valid sample. Clock 32K times and your buffer is send to the >host >in the most usefull way there is. The first valid sample at offset 0 in >the >Host-buffer. Just send the event-delay value as special data to your host. >The Trigger-Event would be at that offset in the Host-buffer. > >In this way you would not need an absolute adres into your sample-buffer. >This would even mean that resetting the hardware adress-counter is not >needed anymore ... > >Greetz, > Rudy Wieser > >

> Van: Tom Handley <TakeThisOuTthandleyEraseMEspam_OUTTELEPORT.COM> > Aan: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Onderwerp: Re: Circular Buffer Help > Datum: woensdag 29 april 1998 0:10 Hello Tom, > Rudy, I really should have posted this in my PIC-based Logic Analyzer > topic so it would have been easier to see where I was comming from. Ah, I have to confess : I do not read every article that is posted ... )-: It would take to much time ... :-( > The host sends the delay count to the analyzer as part of the sample > request so it already knows the delay. Once `armed' the analyzer records > data in the circular buffer until a trigger event. Then a delay counter > is started. At the end of that count, the address counter clock is > disabled and the capture mode is complete. The host can monitor this. That is as much as I thought. Good to know we are talking about the same method of operation ! > I like your suggestion of clocking in 32K and then subracting the delay. > Last night I did another update to that particular CPLD and I was able to > eliminate 1 74x-family `glue' chip while retaining the capability to read > the absolute address. At this point, eliminating the address read-back > will not save anything so I'll keep it. > > - Tom Ehh .. Tom, something keeps nagging me : Why do you need to be able to read the absolute adres of the Sample-buffer ? As you've seen, you don't really need it (anymore). Greetz, Rudy Wieser

Rudy, while I was designing the chip-set I was always concerned about unforeseen software issues. One of those was the ability to know the absolute (physical) trigger address. I've looked at several other designs and some included it. I really did'nt think it was necessary but I added it in case others might see a benefit. When a `gotcha' cropped up and it looked like I was going to have to eliminate it or add a `glue' chip, I sought opinions from the group. Some folks preferred the capability. I was able to squeeze in some extra logic to cover the `gotcha' so I decided to retain it. If I removed it, I would free-up 4 I/Os and 1 dedicated input. That may allow me to fit the external decade clock prescaler in that chip. This would eliminate 2 74x390s but, internally, that chip's resources are mostly `exhausted'... From a software standpoint, it makes no difference if I keep it. It uses 4 states of a 12-state machine. The first 8 control reading data from the SRAMs. If you ignore it, your host (PIC or PC) has one less control line to deal with (3 state-select inputs vs. 4). - Tom At 02:27 PM 4/29/98 +0200, Rudy Wieser wrote: [snip] {Quote hidden}>Tom Handley wrote: >> I like your suggestion of clocking in 32K and then subracting the delay. >> Last night I did another update to that particular CPLD and I was able to >> eliminate 1 74x-family `glue' chip while retaining the capability to read >> the absolute address. At this point, eliminating the address read-back >> will not save anything so I'll keep it. >> >> - Tom > >Ehh .. Tom, something keeps nagging me : Why do you need to be able >to read the absolute adres of the Sample-buffer ? As you've seen, you >don't >really need it (anymore).