verilog implementation of a viterbi decoder

hello everybody.
I'm trying to implement a viterbi decoder.
I actually know the algorithm but I need to know the implementation techniques.
could anybody introduce me an appropriate article or book.
I want to know the concepts of traceback,register exchange and PNPH (Permuation Network based Path History) or other probably new methods and their trade offs in implementing a viterbi decoder.
I really need it and I haven't find anyone to help me unfortunately.

Do you know Verilog Already? Why not present what you have tried already and say what the problem is?
Verilog is NOT like software programming, you need to understand the hardware before you can write the code.

The normal viterbi decoder is basically an array of add-compare-select units and then a traceback unit.

For the entire design, a key question is if the design runs at full-rate, slightly less than full rate, half-rate, or lower. This affects how much logic sharing you can have, as well as allows solutions to some other problems.

The add-compare-select units should be small. This is because they will be in a potentially large array. Any inefficiency can be multiplied 128x or more. Further, the array routes to a single unit which means larger units also lead to more congestion issues. A main decision for this stage that is not present in the explaination of the algorithm is how to keep the accumulators stable. This comes up when you look at sizing the accumulator with the knowledge that an arbitrary number of non-zero inputs can go to each. There are a variety of methods that can be employed here.

The traceback is practical. Register exchange isn't really that practical. From looking at PNPH, it also looks suspicious. Perhaps they are fine for some design specs or on asics, but they do grow in size quickly.

That said, you may have a short register exchange stage feeding the traceback unit. This is based on the required read bandwidth of the traceback ram. Instead of storing best single-step to the ram, you can store best two-step path. This allows you to read two steps per cycle while writing only one on average. Thus you can read out a number of steps equal to the pre-read amount followed by the number of data points equal to that amount. This can be finished in the time it takes to write another pre-read amount. (I forget the term here. It is some scaling of constraint length normally.) However, if the design runs at half rate this extra stage is not needed.