powertrain-build/docs/signaling_in_powertrain_build.md
Henrik Wahlqvist 635045a3f2 Updated documentation
Change-Id: I65c140c3ab156406ba8a6ee18eba60692438e4b4
2024-09-27 10:19:31 +02:00

3.3 KiB

Summary of Signals in powertrain_build


[TOC]

Where Are the Variables Defined in the Code?

Outsignals From Models

* <model_name>.c
* VcExtVar*.c - if it is listed in the interface.

Insignals to Models

* <model_name>.c - if another model is producing it.
* VcExtVar*.c - if it is in the interface.
* VcDummy_spm.c - if neither in interface nor models.

Outsignals in the Interface List

* <model_name>.c - if a model is producing it.
* VcDummy.c - if no model is producing it.
* VcExtVar*.c - outsignals in the interface list are all defined in this file.

Insignals in the Interface List

* VcExtVar*.c - this goes for both used and unused signals for ecm projects.

Signal Flow Within a Project

Signals within a project can be divided into 4 types:

* external_outsignals - outsignals in the supplier interface list.
* external_insignals - insignals in the supplier interface list.
* internal_outsignals - outsignals from models but not in the supplier interface list.
* internal_insignals - insignals to the models but not in the supplier interface list.

As shown in the picture below, if a model takes internal_outsignals from another model, the model is regarded as consumer and another model is supplier.

powertrain_buildConsummer&Supplier

If the consumer model expects more insignals than supplier model or supplier interface could provide, then these insignals are marked as missing signals.

powertrain_buildMissingSignals

If supplier model or interface provides more signals than expecting insignals, then these signals are marked as unused signals.

powertrain_buildUnusedSignals

The picture below indicates signal flow within a project. External interface list defines external in-ports and external out-ports.

The first flow indicates the normal signal flow within a project: external_insignals defined in VcExtVar.c enters model1 and the internal_outsignals match internal_insignals of the next model; then the external_outsignals come from model3 which are defined in model3.c.

The second signal flow indicates the missing signal situation. When internal_insignals are missing, VcDummy_spm.c file is generated to define missing outport variables in the outport interface of the previous model.

The last signal flow explains two special cases: (1) unused signals; (2) external_outsignals not produced by models. Unsued signals will be ignored by models and external_outsignals that are defined in signal interface but not produced by models are defined in VcDummy.c instead of model7.c.

powertrain_buildSignalFlow

Compilation Process

Compile -> Link -> fail -> Update VcDummy and VcDummy_spm (remove multiple defs, add missing defs).
Compile -> Link -> fail -> Update VcDummy and VcDummy_spm.
Compile -> Link -> fail -> Update VcDummy and VcDummy_spm.
Compile -> succeed.

Compiling and linking SPM only works first try in gcc. Multiple definitions or missing definitions are not allowed.

The iterations are to fix the inconsistencies between SPM and EMS. If we knew what was defined in the EMS, we could generate VcDummy and VcDummy_spm on the first try every time.