I have a fairly complex Simulink model with multiple referenced models that I am trying to interface with external C++ code. I am using 2014a and generating code using Simulink Coder. Below are two important requirements I would like to satisfy while doing this:
Have the ability to create multiple instances of the model in my
external C++ code.
Have the ability to overwrite data that is input to the model and
have it reflected to the external application.
Given these requirements, at the top level what is the best method to interface to external IO, datastores or IO ports?
From my understanding using datastores (or Simulink.Signal objects) and by specifying the appropriate storage class I may be able to satisfy 2 above, but in doing so I would have to specify signal names and this would not allow me to satisfy 1.
If I use IO port blocks at top level, I may be able to satisfy 1 but not 2.
Update: #2 constraint has been removed due to design change. Hence the io port approach works for me.
Related
The only use with uvm_config_db is when we have more than one testbench in our system?
I`ll be glad to have some explanation about this macro.
The uvm_config_db class (it's not a macro) has many uses besides multiple testbenches. The most common is sharing data from the top-level testbench module, like the location of interface instances, with the drivers and monitor classes that need to access the virtual interfaces.
It also gets used for communicating data between components and sequences, not just for passing values, but notifiers when data has been set.
You could certainly write a testbench without using the uvm_config_db, or the entire UVM for that matter. But that misses the whole point about writing testbenches for maintainability within the same testbench and reusability with other testbenches.
I'm trying to build a model with many same blocks, which need to have different inports data types. Is it possible to make it with referenced models (no subsystems/library blocks) ?
I've already did it with subsystems, but copying objects with changing some parameters manually looks depressing. I put repeatable code in a separate model, created arguments with which I want to change the data types of the output ports.
I got a behavior I didn't expect - the arguments only affected the values of the blocks of constants, but the port types remained the same as in the default values of the arguments.
UPD. All these models are used in HDL code generation.
I have a huge Simulink model and I am testing some options to improve its performance. The model is implemented using a library for reusable components and subsystem for the hierarchy and organization.
I was wondering if converting some subsystems to model reference will improve performance, besides other advantages. The problem is that every single library component is a masked subsystem itself, and so far I couldn't figure out how to convert a masked subsystem to a model reference. A error message appears when trying to convert:
Invalid usage of convertToModelReference. The subsystem to be
converted must be an atomic, or triggered subsystem block. Cannot
convert a virtual subsystem to a model
Reading simulink documentation did not help.
My questions is:
Is it possible to convert a masked subsystem to a model reference?
If yes, do I need to make some adjustments in every masked subsystem/library block through the whole hierarchy? (Or only in the reespective top tier block that I am trying to convert?)
What is this error message about?
In addition to what Phil said, you can only convert an atomic subsystem into a referenced model. An atomic subsystem means that the subsystem executes as a whole rather than the hierarchy of the model being flattened during compilation, as with virtual subsystems. For more details, see the documentation. You can have library components within referenced models, but there are a number of limitations, see Simulink Model Referencing Requirements and Model Referencing Limitations.
Despite the constraints, model referencing is generally advised as the way to approach large-scale modelling and it should give you performance improvements, as the referenced models run in accelerated mode (unless otherwise configured), and are rebuilt only when structural changes are made to the model. See Componentization Guidelines in the documentation for more details.
In my experience that's a catch all error message, which basically means that something is wrong (but not necessary the obvious virtual subsystem problem that it seems to indicate), but the converter doesn't have enough "smarts" to give a very specific fix to the problem.
Sometimes the problem is that parameters needed by the reference block aren't being passed through the mask to it correctly.
But you most likely need to look at various of the limitations of model referencing and work through the potential issues.
Depending on how many conversions you have to do you might find manually converting the subsystems (by copying them into new models and configuring the new models manually) is less frustrating that trying to figure out why the automatic conversion is not working.
I started writing graphic dsl in eclipse by using Epsilon. However the problem is there is that epsilon doesn't have support for writing specific behavior for dsls. For the reference, i'm writing a dsl for data flow diagrams, where i'd need to implement system for decomposition, meaning i'd have to fetch all of external entities, interfaces and connections that are related to the process i'm decomposing it by and transfer them to lower level of decomposition. Does anyone know if there's a way to deal with this problem within epsilon framework, or is there any other framework that would allow me to make dsl out of metamodel with addition of defining a behavior for the dsl.
What are (If there are) the differences between a Simulink library and a model reference. There's advantadges in using either of them in different situations?
The main purpose of libraries and model reference are the same: facilitate the reuse of simulink models. When you work with libraries, simulink "imports" the content of the referenced models in to the main model. Sometimes, this leads to the developer dealing with gigantic models (more than 50k blocks), which can be time consuming. When you are designing a library, the lib file cannot be run. You have to "instantiate" it in the main model. On the other side, model reference deals with separated models. They are put together when you press the simulate button, but during the design time, you deal with completely separated models. With model reference, you can also select acceleration methods (it basically compiles the model) and this can't be done with libraries.
Adding some more to danielmsd's answer:
Configuration Management: Model references can be put easily into
version control and developers can work independently from each other. A library is one file, so the blocks
cannot be versioned individually and developers cannot work in parallel.
You can protect model references.
Code Generation: Incremental build is only possible with model referencing.
BUT:
Model referencing has quite a few limitations, so check them out carefully before picking this option. See Model Referencing Limitations.
From a system design perspective model references should be used for components of your system. That is the different parts your system is made from. Libraries should be used as utilities. That is reuable blocks that are used through out your design.
For example a robot control system includes components: navigation, control, path_plannen etc. These are components and should be implemented with model references. In that case they are developed as independent models and can be tested independently.
Inside the components you could need utility blocks such as low_pass_fileter, error_state_handler and check_input_range, they are libraries.
Advantages of mdl ref:
- Code generation: Model references allow partial builds when using the coder product. Assuming you have a really large model with 100k blocks and it takes 20 minutes to build, splitting it up in model references will reduce the build time since only the changed model will need to rebuild.
Model update: only changed model references are updated "CTRL+D" therefore this helps when having really large models.
Simulation: In simulations mdl refs are generated as dlls which makes your simulations much faster (the effect is much bigger than the difference between normal and accellerator mode)
Disadvantages pains:
- In general Mdl referencing is somehow a pain to use due to limitations
There is no possibility to pass a Simulink.parameter.object which has a tree structure. (When using type:BusObject only the value property has a structure, the other properties don't)
When a subsystem has a bus signal as input, a mdl ref needs a bus object to specify the input interface, and the library block doesen't. (Even if its quite ugly to use unspecified bus inputs in a lib block). (Note that busobject are always global in the base workspace... risk of naming collisions)