I need to trace enum signals type in SystemC AMS.
This is my code:
sca_util::sca_trace_file* atf = sca_util::sca_create_vcd_trace_file( "trace.vcd" );
sca_util::sca_trace( atf, system.cmd_sig_tdf_fw, "controller_cmd" );
where "system.cmd_sig_tdf_fw" is a:
sca_tdf::sca_signal< command_type > cmd_sig_tdf_fw;
And the enum is:
enum command_type { IDLE, OPEN, CLOSE };
I'm able to trace all tdf double type signal, but command type signal is never traced
Enum VCD tracing is not supported and is deprecated.
You can find relevant discussion here.
Also I have tried to add enum variables to VCD traces and have observed only constant values being recorded in the VCD trace file.
Related
Is it possible to run the simulation for a certain amount of ticks, and then read the value of selected statistics from the Python config script?
Edit: a patch has been submitted at: https://gem5-review.googlesource.com/c/public/gem5/+/33176
As of 3ca404da175a66e0b958165ad75eb5f54cb5e772 it does not seem possible, but it is likely easy to implement.
We already have a loop that goes over all stats in the Python under src/python/m5/stats/__init__.py, so there are python stat objects fully exposed and iterated, but the actual stat value appears not exposed to them, only the stat name:
def _dump_to_visitor(visitor, root=None):
# Legacy stats
if root is None:
for stat in stats_list:
stat.visit(visitor)
# New stats
def dump_group(group):
for stat in group.getStats():
stat.visit(visitor)
The visit method then leads the value to be written out to the stat file, but the Python does not do it.
However, visit is already a pybind11 Python C++ extension defined at src/python/pybind11/stats.cc:
py::class_<Stats::Info, std::unique_ptr<Stats::Info, py::nodelete>>(
m, "Info")
.def("visit", &Stats::Info::visit)
;
so you would likely need to expose the value there.
One annoyance is that each stat type that derives from Stats::Info has a different data representation, e.g. scalars return a double:
class ScalarInfo : public Info
{
public:
virtual Counter value() const = 0;
but vectors an std::vector:
class VectorInfo : public Info
{
public:
virtual const VCounter &value() const = 0;
and so there is no base value() method due to the different return types, you'd juts need to expose one per base class.
TODO I couldn't see the value() method on the Python still, likely because they were still objects of the base class, needs more investigating.
You can use variation of the gem5-stat-summarizer. gem5-stat-summarizer is used to extract selected gem5 statistics to a csv file when you have multiple stats.txt files
I've inherited a piece of custom test equipment with a control library built in a COM object, and I'm trying to connect it to our Tcl test script library. I can connect to the DLL using TCOM, and do some simple control operations with single int parameters. However, certain features are controlled by passing in a C/C++ struct that contains the control blocks, and attempting to use them in TCOM is giving me an error 0x80020005 {Type mismatch.}. The struct is defined in the .idl file, so it's available to TCOM to use.
The simplest example is a particular call as follows:
C++ .idl file:
struct SourceScaleRange
{
float MinVoltage;
float MaxVoltage;
};
interface IAnalogIn : IDispatch{
...
[id(4), helpstring("method GetAdcScaleRange")] HRESULT GetAdcScaleRange(
[out] struct SourceScaleRange *scaleRange);
...
}
Tcl wrapper:
::tcom::import [file join $::libDir "PulseMeas.tlb"] ::char
set ::characterizer(AnalogIn) [::char::AnalogIn]
set scaleRange ""
set response [$::characterizer(AnalogIn) GetAdcScaleRange scaleRange]
Resulting error:
0x80020005 {Type mismatch.}
while executing
"$::characterizer(AnalogIn) GetAdcScaleRange scaleRange"
(procedure "charGetAdcScaleRange" line 4)
When I dump TCOM's methods, it knows of the name of the struct, at least, but it seems to have dropped the struct keyword. Some introspection code
set ifhandle [::tcom::info interface $::characterizer(AnalogIn)]
puts "methods: [$ifhandle methods]"
returns
methods: ... {4 VOID GetAdcScaleRange {{out {SourceScaleRange *} scaleRange}}} ...
I don't know if this is meaningful or not.
At this point, I'd be happy to get any ideas on where to look next. Is this a known TCOM limitation (undocumented, but known)? Is there a way to pre-process the parameter into an appropriate format using tcom? Do I need to force it into a correctly sized block of memory via binary format by manual construction? Do I need to take the DLL back to the original developer and have him pull out all the struct parameters? (Not likely to happen, in this reality.) Any input is good input.
I have an existing project, originally implemented as a Vxworks 5.5 style kernel module.
This project creates many tasks that act as a "host" to run external code. We do something like this:
void loadAndRun(char* file, char* function)
{
//load the module
int fd = open (file, O_RDONLY,0644);
loadModule(fdx, LOAD_ALL_SYMBOLS);
SYM_TYPE type;
FUNCPTR func;
symFindByName(sysSymTbl, &function , (char**) &func, &type);
while (true)
{
func();
}
}
This all works a dream, however, the functions that get called are non-reentrant, with global data all over the place etc. We have a new requirement to be able to run multiple instances of these external modules, and my obvious first thought is to use vxworks RTP to provide memory isolation.
However, no matter what I try, I cannot persuade my new RTP project to compile and link.
error: 'sysSymTbl' undeclared (first use in this function)
If I add the correct include:
#include <sysSymTbl.h>
I get:
error: sysSymTbl.h: No such file or directory
and if i just define it extern:
extern SYMTAB_ID sysSymTbl;
i get:
error: undefined reference to `sysSymTbl'
I havent even begun to start trying to stitch in the actual module load code, at the moment I just want to get the symbol lookup working.
So, is the system symbol table accessible from VxWorks RTP applications? Can moduleLoad be used?
EDIT
It appears that what I am trying to do is covered by the Application Programmers Guide in the section on Plugins (section 4.9 for V6.8) (thanks #nos), which is to use dlopen() etc. Like this:
void * hdl= dlopen("pathname",RTLD_NOW);
FUNCPTR func = dlsym(hdl,"FunctionName");
func();
However, i still end up in linker-hell, even when i specify -Xbind-lazy -non-static to the compiler.
undefined reference to `_rtld_dlopen'
undefined reference to `_rtld_dlsym'
The problem here was that the documentation says to specify -Xbind-lazy and -non-static as compiler options. However, these should actually be added to the linker options.
libc.so.1 for the appropriate build target is then required on the target to satisfy the run-time link requirements.
i've assumed that dumping a .bc file from a module was a trivial operation, but now,
first time i have to actually do it from code, for the life of me i
can't find one missing step in the process:
static void WriteModule ( const Module * M, BitstreamWriter & Stream )
http://llvm.org/docs/doxygen/html/BitcodeWriter_8cpp.html#a828cec7a8fed9d232556420efef7ae89
to write that module, first i need a BistreamWriter
BitstreamWriter::BitstreamWriter (SmallVectorImpl< char > &O)
http://llvm.org/docs/doxygen/html/classllvm_1_1BitstreamWriter.html
and for a BitstreamWriter i need a SmallVectorImpl. But, what next?
Should i write the content of the SmallVectorImpl byte by byte on a
file handler myself? is there a llvm api for this? do i need something
else?
The WriteModule function is static within lib/Bitcode/Writer/BitcodeWriter.cpp, which means it's not there for outside consumption (you can't even access it).
The same file has another function, however, called WriteBitcodeToFile, with this interface:
/// WriteBitcodeToFile - Write the specified module to the specified output
/// stream.
void llvm::WriteBitcodeToFile(const Module *M, raw_ostream &Out);
I can't imagine a more convenient interface. The header file declaring it is ./include/llvm/Bitcode/ReaderWriter.h, by the way.
I use following code :
std::error_code EC;
llvm::raw_fd_ostream OS("module", EC, llvm::sys::fs::F_None);
WriteBitcodeToFile(pBiFModule, OS);
OS.flush();
and then disassemble using llvm-dis.
The next two declarations are equivalent:
protected type prot_Type is
....
pragma Priority(System.Priority'Last);
end;
protected type prot_Type is
....
end;
One way of attaching interrupt handler is:
protected type prot_Type is
procedure Handler;
pragma Attach_Handler(Handler, ...);
end;
--//Attach is made at the creation of the next object:
Object : prot_Type;
it's a legal attachment (It works).
How is it possible that the handler has ceiling priority of System.Priority Last ? (As far as I know the legal priority is in range Priority'Last+1 .. Any_Priority'Last).
Another thing:
if I add the pragma Priority(System.Priority'Last); to the protected declaration, a program_error exception is raised at the elaboration (when attaching the handler).
Someone can please spread the fog?
I finally manage to understand thanks to:
http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/node33.htm
The fact that an hadler that defined in a protected with ceiling priority System.Priority'Last managed to be attached to Interrupt seems to me like bug in the compiler.
Only hendlers that defined in a protected with ceiling priority in Interrupt_Prioriy'Range can be attached to interrupt.
Another important thing - for non static protected (i.e declared with "protected type ... ") the attachment is made by the creation of the object of that type. The object must be allocated dynamicly.
Yony.
This question is about attaching interrupts (or signals) to a protected object to function as interrupt handlers. It is wonderful that Ada provides you a mostly language-standard way to do this, but there are limits to what is in the standard, and I think your question hits one. You really need to read your compiler's documenation for this one.
For example, if what you are attaching to is an honest-to-god system interrupt, then it is quite possible that your handler will get called directly from the system interrupt, which is of course completely outside of (and thus above) both your OS's process priority and Ada's task priority systems.
Generally in such a case, like with any ISR, you'd want to do the absolute minimum required to make note of and deal with the interrupt, interact with the system as little as possible (no I/O or tasking interactions), and return control back to the system so it can start behaving normally again. In your case, you might want to increment a variable or set a flag internal to your tagged type, take down any volatile info about the interrupt you may need later, then return.