HDL Coder creates too many files in my full model, but works as expected on a subystem

7 次查看(过去 30 天)
I'm running into a strange problem that almost seems like a stack overflow where the stack holds all Verilog files that have been built before looking at the current subsystem (so the program misses that there is a version to use and creates another one). But my model isn't so huge to think this is very likely (my model writes out 80 Verilog files in around an hour).
Inside my model is a subsystem which holds 16 masked subsystems with a single parameter (the address bitwidth of a RAM block inside the mask). I did not attempt to get a single file with parameterized HDL since I've read that only certain parameters (such as gain in a multiplier) are valid and my case doesn't apply. But in my 16 instances, I have only 4 unique values of this parameter so I expect to get 4 files. And here's the thing - I do get 4 files when I write out code just for the subsystem holding the 16 masks (using right click > HDL Code > Generate HDL for Subsystem). But when I write out code for the entire model (using HDL Workflow Advisor), I get 16 files (and when I diff two of them, I get line differences only in an the module index, e.g., one says "module ping_pong1" and the other "module ping_pong2" (and this is the only difference not part of a comment).
Is there anything besides a bug that can explain this? If it is a bug, is there a work around (maybe I should try not using the Workflow Advisor)? If it's not a bug, I'd love to know what I could be doing wrong.
Thanks, Dara
  3 个评论
Dara Parsavand
Dara Parsavand 2017-3-21
编辑:Dara Parsavand 2017-3-21
I do get one file (SinglePortRAM_generic.v) for the RAM itself (actually I'm getting two - one for unsigned which is the case for the 16 RAM wrappers mentioned and one for signed which is used in another place for the model). But it is the wrapper module containing 2 RAMs and ping/pong logic that is duplicated 16 times.
I tried last night writing out code for my entire model by right clicking top level hierarchy instead of using the Advisor and surprisingly, it makes the 4 files instead of 16. How is that possible - wouldn't the advisor call the same routine? So now I'm down to a single duplicated file (a non-masked subsystem in another spot on the model with two identical instances and two files). I might try copying these blocks to a smaller file and see when it starts not creating two files.
Dara Parsavand
Dara Parsavand 2017-4-4
I now have a test model I can provide to illustrate the behavior. Simulink 2016b and the Readme.txt file discusses the procedure I used to get two different sets of files.
Dara

请先登录,再进行评论。

回答(1 个)

Kiran Kintali
Kiran Kintali 2021-5-22
Sharing requirements for generating reusable code from atomic and virtual subsystems in Simulink models from R2021a documentation.
Generate Reusable Code for Subsystems
HDL Coder™ can detect atomic subsystems that are identical, or identical except for their mask parameter values, at any level of the model hierarchy, and generate a single reusable HDL module or entity. The reusable HDL code is generated as a single file and instantiated multiple times.
Requirements for Generating Reusable Code for Atomic Subsystems
To generate reusable HDL code for atomic subsystems:
  • The DefaultParameterBehavior Simulink® Configuration Parameter must be Inlined. You can set this parameter at the command line by using the set_param or hdlsetup function. To specify this setting in the Configuration Parameters dialog box, you must have Simulink Coder™.
  • Logging functionality must not be used, such as signal logging or using blocks such as To Workspace or To File.
  • The atomic subsystems must be identical, or identical except for their mask parameter values.
  • MaskParameterAsGeneric must be on. For more information, see Generate parameterized HDL code from masked subsystem.
  • Mask parameters must be nontunable. The code generator does not share atomic subsystems with mask parameters that are tunable.
  • Mask parameter data types cannot be double or single.
  • The tunable parameter must be used in only Constant or Gain blocks.
  • Port data types must match.If you change the value of the tunable mask parameter, the output port data type can change. If one of the atomic subsystems has a different port data type, the code generated for that subsystem also differs.
Requirements for Generating Reusable Code for Virtual Subsystems
Set SubsystemReuse option to 'Atomic and Virtual' (new in 21a)
To generate reusable HDL code for virtual subsystems:
  • The DefaultParameterBehavior Simulink Configuration Parameter must be Inlined. You can set this parameter at the command line by using the set_param or hdlsetup function. To specify this setting in the Configuration Parameters dialog box, you must have Simulink Coder.
  • Logging functionality must not be used, such as signal logging or using blocks such as To Workspace or To File.
  • The virtual subsystems must be identical, or identical except for their mask parameter values.
  • SubsystemReuse must be set to 'Atomic and Virtual'.
  • Setting SubsystemReuse to 'Atomic and Virtual' reduces artificial algebraic errors and improves the recognition of identical subsystems, irrespective of their topology within the rest of the design. Identification of similar subsystems can help resource sharing.
  • To set these values to your required setting, in the MATLAB Command Window, enter:hdlset_param('myHDLModel', 'SubsystemReuse', 'Atomic and Virtual')
  • Alternatively, you can set this option from the top-level HDL Code Generation pane in the Configuration Parameters dialog box. Under Global Settings > Coding style, you can change the Code reuse setting to the required option.
  • The previous commands set the SubsystemReuse option for your project. To set this option for only the current code generation session, enter:makehdl(<DUT system>, 'SubsystemReuse', 'Atomic and Virtual')
  • MaskParameterAsGeneric must be on. For more information, see Generate parameterized HDL code from masked subsystem.
  • Mask parameters must be nontunable. The code generator does not share atomic subsystems with mask parameters that are tunable.
  • Mask parameter data types cannot be double or single.
  • The tunable parameter must be used in only Constant or Gain blocks.
  • Port data types must match.If you change the value of the tunable mask parameter, the output port data type can change. If one of the atomic subsystems has a different port data type, the code generated for that subsystem also differs.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by