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:
>> Van: Tom Handley <thandley@TELEPORT.COM>
>> Aan: PICLIST@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
>
>