This section refers to generated VHDL® entities or Verilog® modules generically as “entities.”
A mapping file is a text report file generated by
makehdl. Mapping files are generated as an aid in tracing
generated HDL entities back to the corresponding systems in the model.
A mapping file shows the relationship between systems in the model and the VHDL entities or Verilog modules that were generated from them. A mapping file entry has the form
path --> HDL_name
pathis the full path to a system in the model and
HDL_nameis the name of the VHDL entity or Verilog module that was generated from that system. The mapping file contains one entry per line.
In simple cases, the mapping file may contain only one entry. For example, the
symmetric_fir subsystem of the
model generates the following mapping file:
sfir_fixed/symmetric_fir --> symmetric_fir
Mapping files are more useful when HDL code is generated from complex models where multiple subsystems generate many entities, and in cases where conflicts between identically named subsystems are resolved by HDL Coder™.
If a subsystem name is unique within the model, HDL Coder simply uses the subsystem name as the generated entity name. Where
identically named subsystems are encountered, the coder attempts to resolve the conflict
by appending a postfix string (by default,
'_entity') to the
conflicting subsystem. If subsequently generated entity names conflict in turn with this
name, incremental numerals (
As an example, consider the model shown in the following figure. The top-level model
contains subsystems named
A nested to three levels.
When code is generated for the top-level subsystem
makehdl works its way up from the deepest level of the model
hierarchy, generating unique entity names for each subsystem.
makehdl('mapping_file_triple_nested_subsys/A') ### Working on mapping_file_triple_nested_subsys/A/A/A as A_entity1.vhd ### Working on mapping_file_triple_nested_subsys/A/A as A_entity2.vhd ### Working on mapping_file_triple_nested_subsys/A as A.vhd ### HDL Code Generation Complete.
The following example lists the contents of the resultant mapping file.
mapping_file_triple_nested_subsys/A/A/A --> A_entity1 mapping_file_triple_nested_subsys/A/A --> A_entity2 mapping_file_triple_nested_subsys/A --> A
Given this information, you can trace a generated entity back to its corresponding
subsystem by using the
open_system command, for example:
Each generated entity file also contains the path for its corresponding subsystem in the header comments at the top of the file, as in the following code excerpt.
-- Module: A_entity2 -- Simulink Path: mapping_file_triple_nested_subsys/A -- Hierarchy Level: 0