This post showed me how to see stuff in SMM. And I notice that Simics shows other normally "hidden" registers like the segment descriptor shadow values, which only get updated indirectly. So is it possible to see the "smbase" register in Simics?
To read one MSR, currently you need to use interface calls on the processor. The "%" operator reads named registers on the current processor. Calling the iface inspects any processor object, and works for-only-has-a-number MSRs.
Use online help to figure out how to use the interface. For example:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_number("IA32_TSC_DEADLINE")
1760
simics> api-help x86_msr_interface_t
Help on API keyword "x86_msr_interface_t":
DESCRIPTION
SIM_INTERFACE(x86_msr) {
void (*register_handlers)(
conf_object_t *cpu,
int64 number,
x86_msr_getter_func_t getter,
lang_void *getter_data,
x86_msr_setter_func_t setter,
lang_void *setter_data,
...
Adding a command for inspection is on the wish list.
UPDATE.
The interface also provides the ability to look up from number to name. For the case of MSR 0x9E, IA32_SMBASE, on the "client" core in Public Simics, looking up the name yields this:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_name(158)
'msr_ia32_smbase'
simics> #conf.board.mb.cpu0.core[0]0].iface.x86_msr.get_number("msr_ia32_smbase")
158
For historical reasons, the register is called msr_ia32_smbase, and not IA32_SMBASE from the manual. In general, looking things up by number is a bit more robust. Esp since many MSRs just have numbers in the Simics model as it is currently set up.
First, you may search the loaded configuration for a particular string using the apropos command (a for short). And since smbase is likely exposed via an attribute it would look like a -a smbase. And if there are anything "smbase" in the configuration you will see it.
I loaded the QSP-x86 Firststeps platform and got several hits on the form
<cpu-class>.msr_ia32_smbase
Also, in general it helps knowing the context of a certain something. Such that smbase is "part of" MSR.
Related
Roald has written an excellent guide for the Twincat Eventlogger.
https://roald87.github.io/twincat/2020/11/03/twincat-eventlogger-plc-part.html
https://roald87.github.io/twincat/2021/01/20/twincat-eventlogger-hmi-part.html
For us this is exactly what we want, there is however 1 thing I haven't figured out. How to get the sourcename of the alarm in multiple languages in the HMI. params::sourceName gives the path in the software (example: MAIN.fbConveyor1.Cylinder1) This path can be customized when initializing the alarm (as Roald has shown). This doesn't work in my case, since I would like to define a generic alarm (example: "Cilinder not retracted within maximum time") that is instantiated multiple times.
I was thinking of using the source as a way to show the operator where the alarm occurs. We use this way (path) already for saving machine settings among other things. The machines we build are installed all over the world, so multilanguage is a must.
Beckhoff does support multilanguage alarm names (when defined), but the source is not defined, but dynamically generated.
Anyone have an idea how this problem can be solved?
If I understand your question correctly, then being able to parameterize the event text with information of the source of the problem should help you out.
If you define the event text as Cylinder {0} has not retracted in time. then you can add the arguments of that text during runtime.
IF bRaiseAlarm THEN
bRaiseAlarm := FALSE;
fbAlarm.ipArguments.Clear().AddString('Alice');
fbAlarm.Raise(0);
END_IF
However, since this also stated in the articles you mentioned, I am unsure if this would solve your problem.
'Alice' in this example, can be hard to localize. The following options come to my mind.
The string can be based on an ENUM. Enums can have textlist support, so if you add your translations there, that should allow multilingual output. However... this does require a lot of setup, placing translations inside your code, and making sure the PLC application is aware of the language that the parameter should use.
Use tags to mark the source device, as tags can be language invariant. It is not the most user-friendly method, but it could work for you. It would become something like: "Cylinder 'AA.1123' did not retract in time.". 'AA.1123' as a tag would have to be stored inside your PLC code as a string. You will have to trust that your operator can relate the tag back to the actual source.
Hopefully, this helped, or else please help me understand the problem better.
Looking for ideas of how to disable a uvm_warning that occurs in the `uvm_object_utils macro.
UVM_WARNING #0: reporter [TPRGED] Type name 'xxx_packet' already registered with factory. No string-based lookup support for multiple types with the same type name.
I don't care about string-based lookup and I'd like to be able to use the same class name in multiple tests (I'm using per-test packages to make this work). So I'd really like to disable this warning. However, even the command the command line disable doesn't seem to help.
I tried:
+uvm_set_action=*,TPRGED,UVM_WARNING,UVM_NO_ACTION
This works for other warnings, but in this case the warning seems to occur even before command line arguments are processed.
These messages come because of static initializations, you will not be able to turn them off.
If you don't want register string names with the factory, use the `uvm_object_param_utils macro instead of the `uvm_object_utils The only difference that is does not register a string with the factory. See http://go.mentor.com/mcem for more information.
This is the problem:
Create a class and set the access to be private for some of the properties or methods.
Use the doc command for the created class. This will auto-generate documentation from your comments and show it in the built-in help browser.
doc classname
The problem is that documentation for the private properties and methods is not shown in the help browser. Is there any way to overcome this problem?
So I spent like 10 minutes using the debugger, jumping from one function to the next, tracing the execution path of a simple doc MyClass call.
Eventually it lead me to the following file:
fullfile(toolboxdir('matlab'),'helptools','+helpUtils','isAccessible.m')
This function is called during the process of generating documentation for a class to determine if the class elements (including methods, properties, and events) are publicly accessible and non-hidden. This information is used later on to "cull" the elements.
So if you are willing to modify MATLAB's internal functions, and you want the docs to always show all methods and properties regardless of their scope, just rewrite the function to say:
function b = isAccessible(classElement, elementKeyword)
b = true;
return
% ... some more code we'll never reach!
end
Of course, don't forget to make a backup of the file in case you changed your mind later :)
(on recent Windows, you'll need to perform this step with administrative privileges)
As a test, take the sample class defined in this page and run doc someClass. The result:
This behaviour is by design - the auto-generated documentation is intended for users of the class, who would only be able to access the public properties and methods.
There's no way that I'm aware of to change this behaviour.
You could try:
Use an alternative system of auto-generating documentation such as this from the MATLAB Central File Exchange (which I believe will document all properties, not just public).
Implement your own doc command. Your doc command should accept exactly the same inputs as the built-in doc command, detect if its inputs correspond to your class/methods/properties etc, and if so display their documentation, otherwise pass its inputs straight through to the built-in doc. Make sure your command is ahead of the built-in on the path.
Is there a way to find complete class info of an object in Lazarus. F1 doesn't work.
For example, I want to know the methods, events and properties of TSQLQuery. More specifically, I'm trying to find what constants I can use with the state property.
The docs I've found so far aren't really much help in this context.
I've also tried the menu that says 'object browser' but it simply points to the properites window.
TSQLQuery and its unit sqldb is not documented.
The state property however is from the base tdataset ancestor of sqlquery, and that IS documented.
Try typing TDatasetstate or tdataset and press F1
The best documentation is the source code. After you dropped a TSQLQuery on the form CTRL-click on the identifier "TSQLQuery" in the source editor. Lazarus will open the corresponding source file at the position where TSQLQuery is declared. Scroll down to the public methods or published properties to see everything you need. Identifiers usually are self-explanatory - the chm file often does not contain more info. And the source is always up-to-date.
You can do the same with any identifier. Depending on the Lazarus version you may land in the implementation part of the unit. In this case, just press SHIFT-CTRL Up/Down to go to the interface.
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".