MATLAB: Problems with HDL coder, sharing, CRP, delays and oversampling. Is the combination not possible

Question

Hello Mathworks-Community,

I’m trying to generate VHDL code with Matlab 2016a. Using sharing, Clock-Rate-Pipelining and delays in atomic subsystems. However, these options seem to exclude each other somehow.

I have attached the model I’m trying to generate.

Problem: I have modeled a closed-loop control system for avionic systems. Output/Path-Delays are therefore unacceptable. The included atomic subsystems (reduced to the troublemaking delay block) shall be shared and pipelined. Pipelining obviously introduces latencies/path-delays. To find a solution to this problem, I read the Clock-Rate-Pipelining article in the documentation: http://www.mathworks.com/examples/simulink-hdl-coder/mw/hdlcoder_product-hdlcoder_clock_rate_pipelining-clock-rate-pipelining CRP pipelines the clock-path, not the data-path. This is what I want. However, the HDL coder seems to completely fail to share subsystems and pipeline them in the clock-path, when the subsystem contains delay blocks. I’ve tried different combination of flags (Distributed Pipelining, Balance Delays, Oversampling factor, etc.), but no configuration seemed to generate the desired model. When I remove the delay from the subsystems, HDL coder generates the desired model and code.

Is this a bug, is the configuration incorrect, or simply not supported by the HDL coder?

Greetings from Germany Hagen Hasberg

PS: readme.txt contains some additional information about the problem.

Answer 1

Hi Hagen,

Before getting to the problem, I noticed that the attached model uses some incompatible model parameters and solver settings for HDL code generation. This causes compilation and/or simulation failures in the generated model and validation model due to discrepancies in sample time. You can see these warnings in the HDL Check Report once code generation is successful. To resolve this problem, before generating HDL code, run hdlsetup on the model to set the appropriate model parameters and solver settings.

Now getting back to the problem, the issue has to do with how resource sharing works in both cases. In case 1, the DUT has a Delay block preceding the Add block inside each of the four Atomic Subsystems. In case 2, it's the same DUT but each Atomic Subsystem contains only the Add block. When you apply resource sharing on a Subsystem that has Delay blocks, the optimization tries to insert pipelines with a delay length equal to N, where N is the SharingFactor that you specify.

In case 1, where you have a Unit Delay inside the Atomic Subsystem, resource sharing tries to introduce an Integer delay of length 4, i.e Z^-4, in the generated model (since the SharingFactor is 4), which becomes part of a feedback loop. HDL Coder is unable to insert the delay on the feedback path since they cannot be path balanced resulting in a delay balancing failure. You can see a similar error message in the Delay Balancing section of the Code Generation report. However, in case 2, when you have only the Add blocks in your design, resource sharing does not have to insert pipelines and hence delay balancing works successfully. For the issue in case 1, as a workaround, you can flatten the hierarchy of all four atomic subsystems by setting FlattenHierarchy to ‘inherit’ or ‘on’ for all four subsystems. Setting this option removes the subsystem hierarchy and considers the Delay and Add blocks to be at the same level in the hierarchy. With this optimization, you cannot share the Atomic Subsystems but you can share the Add blocks by enabling the ShareAdders setting on the model. Enabling these settings shares resources and also improves opportunities for clock-rate pipelining which you can see in the generated model. You could also apply these same optimizations for the DUT in case 2 and make clock-rate pipelining work more effectively.