generalizing viterbi code in SPRA776A

The decoder is not dependent on the polynomial used for encoding.  It's just looking for the most likely path through the trellis. 

I'm sorry, but I do believe that there must be information in the decoder related to the polynomials.  For a convolution of Rate = 1/2 and K = 5, there are 64 different combinations of legal polynomials.  For K=5, each polynomial is a 5-bit value.  But the first and last bit must always be 1.  So there are really only 3 bits that may vary, thus 8 different possibilities per polynomial, and 64 different combinations of the two polynomials.  I wrote a test program that performed all 64 possible combinations of the polynomials in the encoding. It executed the unpacker and decoder on the results of each of the 64 encodings.  The only combination that worked successfully was the one set of polynomials used by the TI encoder.

Let me know if you want to see my code.

Let me apologize for not researching this carefully enough.  It's been a long time since I've looked at this.

But you are correct, that the polynomials do impact the trellis structure, and thus the decoder.  The examples in the appnote were written for a specific standard in which the associated trellis structure applies.  This can be seen by the path states in the diagram.  Using a different encoder polynomial will give different path states, and thus different local distances.  As a result, the basic Viterbi butterfly may need to be calculated differently.

I don't have any example to show you, but I would suggest you analyze the trellis diagram resulting from the desired encoder to determine the actual calculations needed by the decoder.  The basic butterfly structure still applies, but the order of calculations may change. 

Hi,

I am studying the same code now. Would you send me your modified code to me?

Thanks in advance

Robert,

I'm glad that someone else is looking into it.  I did my best to make the code generic for any polynomial.  From the posts, I assumed that it should be.  But I was never able to get it to work with my polynomial.  I spent about 30 hours on it, and couldn't afford to spend any more time on it.  I eventually went with a generic version in C off the web.  It's taking about 20 MIPS to run, which is outrageously large.  But I've got 200 MIPS to play with and very little other CPU-intensive code in my application.  So I'll live with that.  If you ever get anywhere with it, please let me know.

Craig

Hi,

I am glad to know your progress. I am not familiar with C55x. At first, I set to chip "Generic C55xx Device" in CCS v5.1, there are some building warnings. I just get through this by setting to TMS320C5515 (Is it right?). The building has passed through, but the result "dec_out" is not the same with "frame", no matter reverse or not.

Do your modification of T3, and/or other corrections, are necessary? If yes, could you send me the code with modification? I do not ask for the new polynomial code.

The endiann is default as "big endianness". Is this right? This is quite different from C6000.

I submit the project settings here. Please check it for me.

Thanks.

After 10 months, I have no idea what state I left my code in.  I'm not sure that it wouldn't be more confusing for someone than helpful at this point.  First I tried to make it more generic.  At that point, it still worked for the original TI test case.  Then I tried to tailor it to my polynomial.  That never worked.  I don't remember what I last was trying with it. 

As far as the T3 register goes, it ought to be saved and restored.  Otherwise it is not compliant to be considered callable by C.  But that doesn't mean that it won't work in most cases.  It's just no guarantee.  What I find is that in small test cases, that kind of deviance from the standard works.  But when you embed it in a real application, it doesn't.

A c55x is big-endian, as you say.  The even word of a pair of words accessed as a double is the most significant word.

I cannot read your screenshot.  But I'm not the right person to look at it anyway.

Hi,

I am new to C55x. I don't know why T3 needs store and recover. From the C asm interface description on page 6-13, spru281.pdf, it has:

T0, T1  Parent  16-bit data
T2, T3  Child    16-bit data

It does not mean that the asm file can use T3 freely?

If T3 needs protect, what instruction to push T3 to stack?

Thanks.

Hi,

I don't think the original program is right. I create a simple case, only one bit set while the rest are 0s (It is in the attached test.h file). The output signal (dec_out) should return to 0s. From the picture we can see that it is not return to 0 (On the contrary, there are many 1's thereafter). There may be some problem still exist, at least in this rare, simple case. Thanks.

8468.TEST.H

I try input info bit stream: 00000000000000110000000000.. The dec_out does not pass. It has the similar problem as the 000000000000100000000000.....case.

The more strange result from all 0s input. The dec_out cannot be recognized by debugger. I shall look into it if I have time.

Hi,

I have browsed through the C55x instruction manual for the description of AC3<<#-8, AC1. I do not find anything on this topic. Of course, it should have, but I cannot find it. Could you tell me something meaning on this line. It is also better you point me to the exact section on a manual. Thanks in advance.

;*AR4(T0) = lo(AC2), ;Store New_metric(7)&(15)
;*(AR4+T0) = hi(AC2)
;||AC1 = AC1 | (AC3 <<< #-8) ;Combine hard decisions
dec_loop: MOV AC2, *mnew_ptr(m_index), *(mnew_ptr+m_index)
|| OR AC3<<#-8, AC1

Robert W said:

AC3<<#-8

That's signed right shift by 8.

Hi Robert,

I tried to run the spra776a example but I obtained your same results (dec_out is the same as in your figure with frame array sets as in your test.h file). Did you find any solution? I think the problem is in the memory map but I don't know how fix it.

Thanks