As some of you know, I'm creating a hardware MDCT core. At the moment
I'm working out the best way to create a lookup table for the trig
values, as set up in mdct_init:
/* trig lookups... */
for(i=0;i<n/4;i++){
T[i*2]=FLOAT_CONV(cos((M_PI/n)*(4*i)));
T[i*2+1]=FLOAT_CONV(-sin((M_PI/n)*(4*i)));
T[n2+i*2]=FLOAT_CONV(cos((M_PI/(2*n))*(2*i+1)));
T[n2+i*2+1]=FLOAT_CONV(sin((M_PI/(2*n))*(2*i+1)));
}
for(i=0;i<n/8;i++){
T[n+i*2]=FLOAT_CONV(cos((M_PI/n)*(4*i+2))*.5);
T[n+i*2+1]=FLOAT_CONV(-sin((M_PI/n)*(4*i+2))*.5);
}
I'd like to work out how big this table is to put it in hardware, could
someone confirm the following assumptions:
Assumption 1: n = 256 or n = 2048 only (the two window sizes). There is
something in the Vorbis spec about any power of two being allowed as a
block size?
Assumption 2: Values are assigned not from T[0] to T[n-1] but from T[0]
to T[n + (n/4) - 1], e.g. if n = 256, then values assigned from T[0] to
T[319], and if n = 2048, then values assigned from T[0] to T[2559]
Assumption 3: Each value is 4 bytes by default (if floats - I know I'll
have to integerize it soon!) so storage space required is 320*4 bytes 1280 bytes
for n=256, or 2560*4 bytes = 10240 bytes for n=2048.
Assumption 3: M_PI is just PI, i.e. 3.1415....
Consider n=256, then n2=n>>1=128, n/4=64, n/8=32
first loop:
(i=0)
T[0]
T[1]
T[128]
T[129]
i=63 (last value)
T[126]
T[127]
T[254]
T[255]
econd loop:
i=0
T[256]
T[257]
i=31 (final value)
T[318]
T[319]
<p><p>
--
Govind S Kharbanda Institute for System Level Integration
MSc Course Rep. Alba Campus, Livingston, EH54 7EG
http://www.sli-institute.ac.uk/~gk/ Tel: 01506 469340
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
On Friday, August 16, 2002, at 06:36 AM, Govind Kharbanda wrote:> As some of you know, I'm creating a hardware MDCT core. At the moment > I'm working out the best way to create a lookup table for the trig > values, as set up in mdct_init:I thought it was standard practice to build trig functions via CORDIC or something like that. At any rate, I would sort of assume that a lookup table would be the last approach in a hardware design. It seems like you would take less footprint with a circuit that could do a series approximation of trig functions than putting in a lookup table. (I've never designed hardware, only read about it, so maybe I'm just misinformed -- I'm certainly interested in hearing more about the hardware implementation of Ogg, though) -tim --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Govind Kharbanda wrote:> I'd like to work out how big this table is to put it in hardware, could > someone confirm the following assumptions: >OK, assuming all my assumptions in the last email were correct trig and bitrev should be OK to implement. Could someone confirm how long the "in" and "out" arrays are (indexed by iX and oX). I don't quite understand the 'rotate' business in the code, but if I'm just porting it I guess I shouldn't need to. Best regards, Govind -- Govind S Kharbanda Institute for System Level Integration Hardware Perceptual Audio Decoding Alba Campus, Livingston, EH54 7EG http://www.sli-institute.ac.uk/~gk/ Tel: 01506 469339 --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.