I am trying to add an accelerator to the rocket chip framework through the MMIO peripheral. I went through the GCD example and was able to build the basic GCD code. I then replaced the GCD with an accelerator which has it's own Config, Parameters and Field information. Now when I try to pass this information to the rocket chip there is a name clash with the freechips.rocketchip.config.{Parameters, Field, Config}. I tried specifying the whole path i.e; accelerator.util.conig.Parameters to distinguish it from freechips.rocketchip.config.Parameters but it still gave me the same error. When I remove my accelerator configs and parameters and pass simple hand made parameters the build is successful, however, when I add my config I get %Error-TIMESCALEMOD and this error is in the generated file which I am not modifying. I tried a work around by altering my verilator options but that goes down a rabbit hole of errors. I have narrowed down the problem to the fact that this is being caused because I am using two different configs both of which have their own Config.scala file shown here Is there a way to fix this problem? I have attached the error with this question.
The problem was with a blackbox, not sure why it was giving me that error, but yes we can mix two different configs having different util.config files. We just have to specify them explicitly.
Related
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I would like to add a post-build hook to my code generation process. However, when I try to associate a function with the simulink model's PostCodeGenCommand, I get the following error.
set_param(bdroot, 'PostCodeGenCommand', 'packNGo(buildInfo);')
A configuration set reference does not allow writing to parameters in the source configuration set
I don't really understand the error message, and it doesn't bring up any useful hits on my favourite search engine. Can anyone help me decipher it?
Unfortunately, I could not reproduce this problem on a simple simulink model, even if I included a reference model. (I thought that might be what the word "reference" was, um, referencing in the error message. And I've noticed previously that referenced models are handled differently to other models in the simulink code generator.)
I'm using R2015a, but have access to the newer versions if that would help.
Note that this question was originally posted on the Matlab forum, but didn't get any answers.
It turns out that the model was using a "configuration reference" rather than storing its configuration internally. The Model Explorer provides the following description
Configuration Reference
A model may reference a 'Configuration set' that is defined in the
source location rather than stored in the model....
This is useful for us because we use several models which all share the same configuration set. It's saved in a central place and all updates apply immediately to all models.
The side effect is that bdroot no longer has a PostCodeGenCommand associated with it. Instead, the command I was looking for was
configurationSettings.set_param('PostCodeGenCommand', 'packNGo(buildInfo);')
where configurationSettings is a variable in your workspace, and the variable's name should match the "Referenced configuration set name" in the Model Explorer.
I recently obtained a license to use Embedded Coder with an existing Simulink model that we have developed. In attempting to generate C code for the first time from the model, I am working through several errors. At first, we had no code generation templates (.cgt) files defined in the model parameters. After some hunting, I found the default template that comes with MATLAB (matlabroot/toolbox/rtw/targets/ecoder/ert_code_template.cgt).
The latest is that I get errors on nearly every token in this default code generation template.
Since I'm just trying to get something to build, at first I commented out the offending lines (things like RTWFileVersion, etc), but now I am noticing that it's giving me errors for things that are mandatory (ie. Types). Types is one of several required items that must be in the .cgt file, so what's wrong that causes MATLAB to not recognize these tokens? I'm guessing something may be messed up with my installation, such as a path.
Other details:
Simulink R2013A x32
Target is a Freescale device
Thanks to Matthias W for getting me to check other configuration options. Turns out I had selected a .tlc file that was probably incompatible with Embedded Coder.
In Code Generation for "System target file" I have selected the ert.tlc file and now I am able to build the parts of my model I'm interested in.
I'm getting the following run time output:
"Class _NSZombie_GraphicPath is implemented in both ?? and ??. One of the two will be used. Which one is undefined."
Have no clue how to fix this. There are a couple of other questions that cover this, but it seems in those unit testing was involved. Has anyone ever come across this problem before and if so how was it fixed?
It implies that two images and/or static libraries export the class GraphicPath. For example, one may be your app, and the other a unit test. A library you link to could also export that class. In any event, you should review your projects' compilations phases including all dependencies, and ensure that GraphicPath.m is compiled exactly once, then remove all others. Also note that it is possible to compile the file twice for the same target. I expect that you would also see a log warning when running with zombies disabled. You can also use nm to dump an image's symbol names.
os i figured out how to use the -mthumb and -mno-thumb compiler flag and more or less understand what it's doing.
But what is the -mthumb-interlinking flag doing? when is it needed, and is it set for the whole project if i set 'compile for thumb' in my project settings?
thanks for the info!
Open a terminal and type man gcc
Do you mean -mthumb-interwork ?
-mthumb-interwork
Generate code which supports calling between the ARM and Thumb
instruction sets. Without this option the two instruction sets
cannot be reliably used inside one program. The default is
-mno-thumb-interwork, since slightly larger code is generated when
-mthumb-interwork is specified.
If this is related to a build configuration, you should be able to set it separately for each configuration "such as Release or Debug".
Why do you want to change these settings? I know using thumb instructions save some memory but will it save enough to matter in this case?
my application uses both, thumb and vfp code but i never specifically
set -thumb-interwork flag.. how is that possible?
According to man page, without that flag the two instructions sets
cannot be reliably used inside one program.
It says "reliably"; so without that option, it seems they still can be mixed within a single program but it might be "unreliably". I think normally mixing both instructions sets works, the compiler is smart enough to figure out when it has to switch from one set to another one. However, there might be border cases the compiler just doesn't understand correctly and it might fail to see that it should switch instruction sets here, causing the application to fail (most likely it will crash). This option generates special code, so that no matter what your code does, the switching always happens correctly and reliably; the downside is that this extra code is needed for every global visible function and thus increases the binary side (I have no idea if it also might slow down function calls a little bit, I personally would expect that).
Please also note the following two settings:
-mcallee-super-interworking
Gives all externally visible functions in the file being
compiled an ARM instruction set header
which switches to Thumb mode before executing the rest of
the function. This allows these
functions to be called from non-interworking code.
-mcaller-super-interworking
Allows calls via function pointers (including virtual
functions) to execute correctly regardless
of whether the target code has been compiled for
interworking or not. There is a small overhead
in the cost of executing a function pointer if this option
is enabled.
Though I think you only need those, when building libraries to be used with other projects; but I don't know for sure. The GCC thumb handling is definitely "underdocumented".