I have finished a qpsk/16QAM carrier recovery on fpga based on Costas loop and is relatively tracking well across a good range of frequency shifting tests from a tx generator inside same fpga(thus avoiding clock recovery issues for now). But occasionally it would lock with some minor tilt of constellation plane. So I am trying to model what I am doing for fpga in MATLAB to understand it better. I went through a variety of matlab models all based on emulating fpga design and in fixed number format.

I ended up in a mess of conclusions. My latest greatest MATLAB model has the following features:

1) alpha factor for loop filter(leaky integrator)

2) proportional factor added to final error

3) nco models for tx and rx based on fpga phase accumulators.Tx nco is used as test to drift the phase 

4) The error feedback is applied to rx nco phase.

Now I have no issues with all above ingredients except that I don't see any convergence !!!

When testing with "static tx frequency" there is no problem and constellations are recovered spot on as expected. As I slightly start moving tx frequency(phase) the error does not converge but diverges or stays on some mean value.

The input I am using is I/Q symbols upsampled by factor of 2,3,4,5.etc.  Both NCOs(Tx and Rx) are complex.

My current conclusion is that I cannot use MATLAB modelling even though it is numerically equivalent to my FPGA implementation. May be it is to do with waiting hours for convergence as opposed to seconds of hardware.

My question is does anybody know whether it is feasible to model such loops in MATLAB?  I have come across various mathematical accounts of Costas loop but nothing practically useful for me.

I am aware modelling could go wrong but I have exhausted all tests that seem to indicate equivalence between model and fpga.

Any comment appreciated.

Kaz 

To answer the question posed in your title: yes.  Because you could always use a bit-accurate simulation of your Verilog or VHDL code.

The really slow and pedantic, but sure way of doing this would be to run some known data through each block in your HDL design in your simulator, then verify that those blocks give results that are bit-accurate in MATLAB.  If you haven't done that yet, you're not done!

Yes, it is possible to model the behavior in C, Matlab, or just about any software language.  Many professional design processes over the years have developed systems by modelling the algorithms and system in C and/or Matlab and then testing the fpga or silicon (basically HDL) implementation against the software models.

The language is not a limitation.   You have a bug somewhere or the model doesn't fully match the implementation.

Your problem is probably the costas loop.. you really want to have a timing recovery loop to identify the correct timing samples... using a polyphase matched filter and then a phase locked loop that runs the phase recovery at the right sampling time... the costas loop does not supply the product phase detector signal at the time the eye opening is maximized... it runs the product at every sample... very bad ting to do... i gave a lecture yesterday on the fault of the costas loop and designed a receiver to replace one that used a costas loop.... it way out performed the one it replaced.  look at attached files...  hot off the press.

fred

modem_2008a.m

SYNCHRONIZATION_Qualcomm_2018_4.pdf

 SYNCHRONIZATION_Qualcomm_2018_3.pdf   

Thanks all for the encouragement. Yes it works now!!

The bug was in the phase accumulator wrap up (positive and negative directions).

My work proved one point about modelling and tuning feedback loops. It is terribly difficult and pitfalls are everywhere and it works within limited window of tuning. In my case I concluded the following:

1) The accumulators(tx for test drift and rx for lock) must wrap up around correctly. I am using positive and negative increments.

MATLAB index must be taken care of (that 1 vs 0 issue)

2) The instantaneous frequency (current tuning word) may go wild and violate sampling rule. 

3) scaling is critical for final error, so is fixed point representation in the model at every stage.

4) Rx nco must start at phase zero, Tx can start at any phase. This turned out to be the cause of my fpga issue and was related to restarting at different NCO phase.

5) The error must be sampled only at symbol time, errors at non symbol time should be ignored. As pointed out by Fred. We already had done that in FPGA.

6) Random symbols generation may lead to false conclusions especially when loop is faulty as results could vary because of that rather than other variables. 

7) Delay stages of fpga (registers, loop filter) seemed less critical than I expected.

Cheers

Kaz

Dr. Harris,

These are truly excellent slides! Is there a way to get the first two slide decks in this series (assuming these exist, the ones you post above are #3 and #4).

Thanks!