|
Message
From: "Jim Dempsey" <tapedisk@a...>
Date: Thu, 13 Nov 2003 11:32:04 -0600
Subject: Re: [oc] An FPGA Implementation Question
If the worst case is every clock cycle and/or if you have long streams of
every clock cycle ticks and absenses of ticks then you have a problem in
that the method implied by the 64-bit counter would indicate an extremely
large logging buffer. I would suggest you change the design from using an
explicit 64-bit time-stamp to a derrivable 64-bit time-stamp. One method to
do this is to log the delta-time and state changes.
xnnn nnn nnn nnn 16-bit code, x=signal value, nnn nnn nnn nnn =
number of ticks x was held.
The memory capacity of the log then only needs to be large enough to contain
the state changes. The worst case scenario then becomes a state change at
every other tick.
You would want to select a count field width suitable for the expected data.
The higher the frequency of events the smaller the requirements for the
number of bits in the delta field.
xnnn nnn An 8-bit encoding
Note, you can also use a count width stretching technique reminiscent of the
width specifier for displacements as used on the TMS3200 microprocessor:
0nnn nnnn 7-bit displacement
10nn nnnn nnnn nnnn 14-bit displacement
11nn nnnn nnnn nnnn nnnn 30-bit displacement
You could use a variation on this theme optimized around the behavior of the
expected data. For example, if you have areas of high activities at
relatively short intervals followed by relatively long areas of no
activities you might select for 2, 5 and 21 bit count field widths.
0xnn State=x, nn=number of ticks less 1 (2 bit count field, 00=1,
01=2, 10=3, 11=4)
10xn nnnn State=x, n nnnn = number of ticks-1
11xn nnnn nnnn nnnn nnnn nnnn State=x, ... (i.e. if it isn't close
then it is very far)
Using this model you could place the state value x in front
x0nn
x10n nnnn
x11n nnnn nnnn nnnn nnnn nnnn
if you expect a preponderence of one tick wide events then reduce the
narrowest bit field width to zero bits, the second order field width to 5
bits and the third order field width to 21 bits
x0 = one tick of x
x10n nnnn = n nnnn-1 ticks of x
x11n nnnn nnnn nnnn nnnn nnnn = ...
Then you could vary that variation such that if the state change (x) doesn't
change between log entries then this implies a continuation of the current
state.
00 = one tick of 0 (following encoding begins with 1)
10 = one tick of 1 (following encoding begins with 0)
000 = two ticks of 0 (")
101 = two ticks of 1 (")
0000 = three ticks of 0 (")
1011 = three ticks of 1 (")
010n nnnn = n nnnn-1 ticks of 0 (")
110n nnnn = n nnnn-1 ticks of 1 (")
011n nnnn nnnn nnnn nnnn nnnn = large n ticks of 0's (")
111n nnnn nnnn nnnn nnnn nnnn = large n ticks of 1's (")
Scenarios
Alternating values at every other tick
Input: ...0101010101010101...
Output: ...00 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 ...
Eight input events in sixteen time intervals requires 32 bits of log (versis
8 x 64 bits of log) or a 16:1 reduction in log capacity requirements.
A lessor strain
Input: ...0100000000011001...
Output ...00 10 01001000 101 000 10...
Three input events in sixteen time intervals requires 20 bits of log verses
3 x 64 bits of log ~9:1 reduction in log capacity.
This does complicate the logic for the data formating but it reduces log
capacity and the data rate at which you need to make entries into an
external log.
There are many such techniques that can be used.
Please keep in mind that this is a public forum searchable by google. If
this work if for a thesis then it would behoove you to make reference to
these discussions instead of claiming this as your original work.
Jim Dempsey
----- Original Message -----
From: "Erez Birenzwig" <erez_birenzwig@y...>
To: <cores@o...>
Sent: Wednesday, November 12, 2003 3:04 PM
Subject: Re: [oc] An FPGA Implementation Question
> Yes. But it's arbitary clock cycle, so the worse case could be every clock
> cycle.
>
> Erez.
>
>
> --- Jim Dempsey <tapedisk@a...> wrote:
> >
> > ----- Original Message -----
> > From: "Erez Birenzwig" <erez_birenzwig@y...>
> > To: <cores@o...>
> > Sent: Tuesday, November 11, 2003 9:01 PM
> > Subject: Re: [oc] An FPGA Implementation Question
> >
> >
> > > It also means that I have to be able to read the value out on every
clock
> > > cycle.
> >
> > Don't you mean on _any_ clock cycle? If you were to read the counter on
> > _every_ clock cycle then that would seem to imply that you were doing
> > something at each clock tick (besides incrimenting the 64-bit counter).
From
> > our prior discussions it seemed to indicate that you wanted to construct
a
> > large counter, presumably to contain an accurate time-stamp
(time-clock).
> > Then after this time-clock is initialized and running you go about your
> > application's business. At some point in time an event occures and at
that
> > time you need to determine the "now" value of the counter. Is this
> > assumption correct?
> >
> > Jim Dempsey
>
>
|
 |
Browse
