Is it possible to customize the Build Configuration dump which is printed at the very beginning of each bitbake call? I'm using different flags and overrides to fine tune things like development/testing/deployment mode and I would to have these printed to the terminal to make sure I didn't miss stetting any important flags.
Is that possible? If yes, how can this be achieved?
The output of the Build Configuration is configured by the variable BUILDCFG_VARS defined in the bitbake.conf file.
You can i.e. append values to it in your local.conf. I think the output is evaluated early, so it might not use the values that would be used in a particular recipe.
Let's say I have a 5000 lines of RTL .sv file called main.sv, and inside there is a always_comb block, like so:
always_comb begin
//2000 lines of code here
end
I'm trying to cut and paste this big always_comb into another separate file called sub.sv and replace it with
`include "sub.sv"
in the same place inside main.sv file where the big always_comb once was, for better readability and concise.
The problem I'm having right now is vcs compile throws syntax error on the sub.sv file I created, it simply say it does not expect "always_comb begin" on the 1st line. I guess (although not sure) this is because vcs thinks this file as an .sv file and expects a sv module definition at the beginning.
I looked for other ways using macro online but cannot find a example for my case. What do you think is the correct or better way of doing this kind of in-place code substitution in Systemverilog?
Rename your sub.sv file to sub.svh
i.e. system verilog header
Also you don't need to compile this file since it contains no modules.
Also make sure to pass the path of this file to the tool if its in different folder
How can I create a custom batch file for my code generated from Simulink model ?
I can see, if I edit and change my template make file from Configuration Parameter Dialog box, I can get the desired make file.
But I want a custom .bat file too, that calls this make file along with other commands.
I have some environment variable to set and run couple of scripts in .bat file, before compilation begins. Based on these outputs from script the code is to be compiled and linked.
Using Matlab Version: 2012b
Create a STF_wrap_make_cmd_hook that generates your desired modelname.bat file as shown in the example code
here (mathworks login necessary).
You will probably also need to write your own make_yourtarget.m file and edit the make command field shown in your screenshot to use that one instead of make_rtw.
Other hooks into the build process are described here, perhaps the 'before_make' will also be useful.
I'm using Doxygen to generate documentation for some code. I have a large makefile with a lot of OPT+=-DSOME_OPTION that I want to Doxygen to take into account when it analyses the code, since parts of the code are conditionally compiled.
I know there is a an option PREDEFINED in the Doxygen configuration file that specifies macro names that are defined for the preprocessor, but I do not want to manually update this list every time a change happens in the makefile. In essence I want to set the PREDEFINED option to scan the makefile for compilation definitions and be automatically updated.
Is this possible with Doxygen?
Tried Googling, but couldn't find anything.
I have a few files and folders in my current MATLAB folder.
One of those folders is called 'Map' and it has a 'map1.m' file which I want to call from my code in the current MATLAB folder.
In my code, I can't call it like this:
/Map/map1;
but I can do so like this:
cd Map;
map1;
cd ..;
Somehow the above method seems incorrect. Is there a more elegant way to do it?
You can run the file without adding the folder to your path manually, using the run command, which is specifically for such cases. From the documentation:
run is a convenience function that runs scripts that are not currently on the path.
You call your function/script as
run /Map/map1
If you want to run the function/script by merely entering its name and not with the full (or relative) path, then you should add the folder to your path.
As noted by #mutzmatron, you cannot use run to call functions with input/output arguments. So, unless if it's a script/function without input/output arguments, using run will not work and you'll have to add the folder to your path.
EDIT
Just as a matter of good coding practice, and to work in cases where your function has inputs/outputs, adding/removing the folder from your path is the correct way to go. So for your case,
addpath /Map
...
map1;
...
rmpath /Map
The important thing is that your function call is sandwiched between the addpath and rmpath commands. If you have functions of the same name in both folders, then you should sandwich it tighter i.e., a line before and a line after, so as to avoid conflicts.
Just add all those directories to the Matlab path with addpath like gnovice suggests. Then you'll be able to call the functions normally, and they'll be visible to which(), help(), depfun(), and the other Matlab meta-programming commands. You can put the addpath() calls in your startup.m file to have them automatically appear each time you start Matlab.
Changing the path with addpath/map1()/rmpath each time has some drawbacks.
It's a performance hit because you're adding path manipulation to each call.
Functions in different directories won't be able to see each other.
It'll be harder to write and debug functions because the path context in which they execute will change dynamically, and won't be the same as what you see when you're in the editor and the base workspace.
You need additional error handling code to make sure the path is properly restored if the called function errors out.
This won't work with the Matlab Compiler, if you want to deploy this code at some point.
And using run() or cd() yourself is ugly, because relative paths are going to have problems.
If you really want to separate the functions in the subdirectories so they can't "see" each other, you can make those directories namespaces by putting a "+" in front of their names, and then qualify the function calls with the namespace, like Map.map1().
Just to contribute to the path-altering debate...
One way to make it a bit "safer" is to write
% start of my code: create function handles
% to the functions I need:
try
cd Map
map1_func = #map1;
catch mexception
end
cd ..
This tries to preserve the current directory, and you get a handle to the function in a different directory.
Only thing is, this method won't work if map1 relies upon other functions in the Map directory.