I am trying to prepare a SystemC application with a QT5 GUI. I have the experience that if I make the call sc_start() in the constructor of a QMainWindow, then all objects receive the Clock signals and work as expected, but QMainWindow does not appear until sc_stop() called.
My guess is that the frequent SystemC events fill thread's event queue. Am I right? Is there any simple way to deal with SystemC events when using Qt5's graphic stuff?
You will need to run a SystemC in a separate thread. For example you can use C++11 std::thread. Use sc_elab_and_sim to launch simulation. To communicate with SystemC model asynchronously use async_request_update.
Both sc_elab_and_sim and async_request_update are documented in IEEE-1666 SystemC Standard.
Related
I've got a SystemC testbench (for a VHDL DUT but that's irrelevant right now). I'd like to be able to cause the test to terminate, with a specific exit code, from within an SC_CTHREAD. I am pretty new to SystemC (I'm mostly a verilog/sv guy).
I've tried simply including "exit(error_code)" but while that terminates the simulation, the final exit code comes from my sc_main's return statement. I guess this makes sense since the "exit" probably terminates the separate thread with that exit code, but not the sc_main thread.
I've tried calling sc_stop before that exit, and usually get an error about calling a pure virtual method (I believe that's end_of_simulation, which I have not defined....but that should be optional, right?).
The only way I see to affect the exit code of the process is to change the return statement of sc_main, but that doesn't quite work when all my action is happening in an SC_THREAD created by a constructor of an object somewhere (if it's not obvious I truly don't understand how SystemC works very well, probably because there's a lot of hidden action with secret classes that we can't see, as opposed to verilog where simulation ordering is all there is, assuming you understand blocking/non-blocking).
Is there a way for the SC_THREAD to pass some failure information up to sc_main?
Note: I am running with a commercial simulation tool, and not pure C++. It's possible that there's an implementation bug there. I'm trying to get our pure C++ compile running but it seems to have broken a while ago (I'm not responsible for the SystemC model).
The answer, of course, is to have sc_main get its return value by reaching directly into the module that it instantiates to get at a member variable:
return(test_module.exit_code);
I need to remember that we're still running C++ and basic C++ rules apply, so this is possible. In my hardware-design mind, I was spinning off modules and threads that had no connection to the classes that they actually are.
I read that when you run module, the code becomes part of the kernel. But I figured that there can be context switch between processes while module's function is still executing. How could it be? I read that there are no context switches while in kernel.
Certainly there are context switches in the Linux kernel. It's called kernel pre-emption. I'm not sure where you read that there are no context-switches in the kernel or why you'd think it's impossible.
A kernel thread (presumably where your module code will be executing on) is scheduled just like any other user thread.
But the question seems incorrect.
But I figured that there can be context switch between processes while module's function is still executing.
What?
Say we have a module which implements a filesystem. If you open a file on such a filesystem through open syscall, the code goes open -> some lookups -> the code in the module. All of this is happening in the context of the same thread. There is no concept of module context. It may be the code in the module created some kernel threads on its own, but this has zero relation to it being a module.
process could run in one of these context at any given point of time :
user mode
kernel mode
Interrupt mode
Context switch happens in all cases. In Interrupt mode, it is programmer responsibility to disable context switch on the CPU while executing top half section of the interrupt. I dont know where you read that context switching do not happen in kernel mode.
I am trying to make a DKM (Downloadable Kernel Module),"my_dkm.o", that I can load into a custom VxWorks kernel in run-time. I was able to make a simple one (it prints "hello world") but I want my DKM to invoke system calls that already exist within the kernel that is running.
From the shell, I can do -> syscallShow <my_group_#>,1 to give a list of the system calls I want to run. I can also invoke these system calls from the shell, but I don't know how to refer to them when developing my DKM.
Also, the Wind River Workbench help documentation only discusses invoking system calls from RTPs, which doesn't help because I am executing within kernel-space.
Thanks
In Short: You Don't
System call are exclusively to be used by RTPs to make a call to a function that resides in the kernel. The system call itself does a bit of housekeeping and then invokes the underlying kernel routine.
In the context of a DKM, since you are already in the kernel space, you simply need to invoke the same underlying kernel function as the system call.
are there any objects when running wxWidget's common dialogs on a separate thread? I'm developing a browser plugin and so I need to put lengthy operations outside the main browser thread.
I did a small test and it seems to work but a warning appears:
....\src\msw\dirdlg.cpp(333): 'CoCreateInstance(CLSID_FileOpenDialog)' failed with error 0x800401f0 (coInitialize has not been called.).
Does that mean I have to call wxApp::Initialize(...) or some other functions?
Thanks,
Christian
You just need to call CoInitialize() in each thread where you are using COM. So before creating common dialog objects just call CoInitialize() (one per thread) and in the end of thread call CoUninitialize().
For main thread wxWidgets does this internally. For other threads you'll need to call these functions manually. It is generally not related to GUI but related to COM objects which wxWidgets uses internally.
Yes, there are 'objections'
Important notes for multithreaded applications
When writing a multi-threaded application, it is strongly recommended
that no secondary threads call GUI functions.
http://docs.wxwidgets.org/trunk/overview_thread.html
I am porting a regular C++ app to metro in C++ using WRL. I have an existing thread pool and that some point I need to update the UI from one of these threads.
Touching directly the UI objects gives the expected RPC_E_WRONG_THREAD so I need somehow to execute in the right thread. Looking in MSDN I discovered that the metro dispatcher (CoreDispatcher) has a RunAsync method.
Larry Osterman sort-of answers the question of how to use it here:
Run code on UI thread in WinRT
But what is not clear is if I can do that from a non-winrt thread, that is from a thread which has not called RoInitialize.
I guess to be more precise I fear that the dispatcher might belong to an STA and I would need to somehow marshal the interface so it would be safe to call from my other thread.
Note that the main() function of my app following the msdn samples calls RoInitialize(RO_INIT_MULTITHREADED).
You should be ok calling CoreDispatcher::RunAsync from a non UI thread. But there are a couple of caveats:
1) You need to be in a metro style app (this should go without saying). The reason is that the application object creates an MTA that lives for the life of the application. There's this nifty feature of COM called the implicit MTA - if the MTA exists in your process any threads are considered to be a part of that MTA even if they've not called CoInitialize.
That means that when you access CoreDispatcher::RunAsync, even if you need to proxy objects, the MTA is active so the marshaling should succeed.
Note that there is a period of time during app startup where it's possible that the application object hasn't yet been created - you should refrain from doing anything until your application's code has been executed.
2) You need to capture the CoreDispatcher object on the UI thread you want to use. This is made easier by the fact that the Xaml infrastructure already captures the dispatcher in DependencyObject. So if you already have a Xaml UI element, you can just call .Dispatcher.RunAsync().
PS: The UI thread is on an ASTA (application STA, a new kind of apartment added in Win8) but the dispatcher is thread agile. Note that while the dispatcher is agile, the CoreWindow should not be considered agile.