IFFT HDL optimizer block to HDL coder conversion

Hi; I have this message when tray to convert IFFT TO HDL "Error: Evaluation of elaborate function on class hdldspblks.HDLIFFT failed with the error message: hdlcommon:hdlcommon:RateMismatch: rate mismatch on input signals 3 in network"

How can I solved ?

Answer 1

[Tim McBrayer]

Are the input and output signals attached to the IFFT block all running at the same rate? You can check the model's rates with the model menu Display>Sample Time>Colors.

Have you run hdlsetup on your model? hdlsetup will configure a set of parameters on the model in a way that is most appropriate for HDL code generation.

[Tim]

What if the rates (i.e colors) match and hdlsetup has been run and one still gets this error?

How to resolve?

[Tim]

FWIW, it seems we stumbled on to the real problem.

The instance name that was reported was ..../FFT/RADIX22FFT_SDF1_1/SimpleDualPortRAM_generic which lead us to believe the problem was deep in the FFT.

However, the real problem was in a SimpleDualPortRAM_generic much further down the data path.

And, yes, the issue was different rates going in to that RAM which was easily fixed with a Rate Transisition block.

Ultimately the problem we initially has was HDL Coder pointed to the wrong instance.

Answer 2

[Kiran Kintali]

Can you provide us a sample example and the version of MATLAB you are using?

[Tim]

we're using 2018a

I can't send the design. We tried a smaller design subset and it did not exhibit the problem.

Basically what the design block in question is:

dual port RAM1 -> FFT -> complex multiplier -> (I)FFT -> dual port RAM2

• FFTs are HDL optimized FFT
• the complex multiplier is multipling data from FFT and a third dual port RAM
• data comes into the RAM1 at 6 MHz (from a filter but could just be at 12 MHz) and is pulled out by the FFT at 48 MHz
• data goes into RAM2 at 48 MHz and is pulled out at 12 MHz
• the idea is that the FFT -> FFT operations run faster than the incoming data in order to keep up

The error message pointed to the FFT but the rate problem was ultimately on RAM2.

The way we stumbled on the real problem was by puttting the FFT in a subsystem. This changed the error message, pointing to RAM2.

We had "automatically deal with rate changes" checked in the setup which worked for months using the other FFT (minimal resource FFT - now obsolete).

The reason for the FFT change from minimal resource FFT to HDL optimized FFT is that we want to pipeline the FFT operations (i.e. start a 2nd FFT before the results of the 1st FFT finish) - minimal resource FFT doesn't seem to support this

Answer 3

[Kiran Kintali]

Based on the description of the issue this may already resolved in latest version of MathWorks. Please reach out to [e-mail] for help.