TI E2E Community
Digital Signal Processors (DSP)
C5000 Ultra Low Power DSP
C5000 Ultra Low Power DSP Forum
generalizing viterbi code in SPRA776A
I am needing to code a hard-decision Viterbi decoder on the c55x with K=5 and Rate=1/2. This is exactly what the SPRA776A does. However, my generator polynomials are different than are used in SPRA776A. I see that the code in SPRA776A is hard-coded to 189 bits. That's not a problem. I have fixed that in TI's code. It is also not legally C-callable as written (e.g. it modifies T3 without restoring it). I have fixed that too. The project does run successfully with the results reversed, exactly as described. But there are no comments about the usage of the polynomial in the decoder, only in the encoder. I can't see any direct relationship between the polynomial and the assembler source for the decoder. It must be very subtle.
What I really want is the C reference code for the decoder so that I can modify the assembler code to fit my generator polynomials. An earlier post has said that reference is available somewhere on the internet. However, I have spent days looking for it without finding it. I would be happy to publish the final working and optimized assembler code, once I get the C reference.
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.
I am studying the same code now. Would you send me your modified code to me?
Thanks in advance
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.
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.
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.
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 dataT2, 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?
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.
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.
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 decisionsdec_loop: MOV AC2, *mnew_ptr(m_index), *(mnew_ptr+m_index) || OR AC3<<#-8, AC1
That's signed right shift by 8.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.