Implement sc_trace for std::string

[Hadrian2002]

Hi,

I try to implement sc_trace for an std::string. In the end, I would like to view this string with e.g. gtkwave in the data format ASCII. From digging through the standard SystemC implementation, I found the vcd_T_trace class would already serve my needs, or at least I could use it as template since std::string do not have a to_string() member. But from here I'm a bit confused, which else function I need to implement to have a standard conform sc_trace Implementation. Of course I need the sc_trace(sc_trace_file *tf, std::string &obj, std::string &name), but I think I cannot call traceT from a free sc_trace, so I also need to inherit my own vcd_trace_file type. Am I right and exist there better ways to save strings in a VCD ?

The number of different strings is constant after elaboration, so the string literal trace would be enough, but the current implementation does not save the string literal to the VCD, so it's useless here.

Thanks it advance!

 

[sumit_tuwien]

Hello,

I think vcd will not let you save a string (?).

I am not sure if it will work, but can use string to integer conversion and save them in vcd file. And in your viewer (if there is a way, Cadence simvision has a way) you can convert these signal to ASCI. 

You can write to_string() which will do this job on your own.

Regards,

Sumit

 

[Eyck]

Actually Sumit is right, you need to convert the string to a bit vector (sc_bv) of length string.lenght()*8. And here the problem starts: the sc_bv needs to have a constant lenght from the very beginning on and it cannot change during the simulation as the length is store in VCD at the very beginning of the file. In the viewing tool you can then select an interpretation of the bit vector to see a string.

Best regards

Eyck

[sumit_tuwien]

Hello Eyck,

If I can imagine an use case for this, it will be storing state of state machines or some enumerated values. 

If this is true, then storing numerical integral values will be sufficient and in the viewer, they can be mapped to respective ASCII values.

If what I can imagine is correct use case, then this solution is better.

Regards,

Sumit

[Hadrian2002]

As I said, after elaboration (or before_end_of_elaboration) the actual number of different strings and the number of bytes of the longest string is determinable, so I could try to wrap it around sc_bv. Since I know my target will be gtkwave I could use the string extension for vcd of gtkwave. I firstly will patch the current implementation for vcd_trace_enum, but my original questions were about the class hierarchy of the reference implementation. 

[Roman Popov]

Unfortunately current implementation was not designed to be extensible by user. So you will have to hack SystemC kernel itself. Tracing part is relatively small so it's should not be very hard. Just follow the implementation for existing types.

In general however it should be better to redesign tracing API so it will be extensible for user-supplied types. In addition to accepting fixed set of datatypes, it should also accept abstract interfaces that can be implemented by end user. For example:

// currently does not exist
struct BitVecConvertible {
	virtual sc_dt::sc_bv_base to_bv() = 0;
}

sc_trace(sc_trace_file* tf,  BitVecConvertible &obj, onst std::string& name);

In that case user can trace any type as a bit vector, by implementing an interface or providing a proxy-class. 

 

[rainer]

gtkwave actually supports strings in VCD files as an extension (see, eg., https://sourceforge.net/p/gtkwave/support-requests/2/ and the sample VCD file thats attached). With hacking the kernel to support tracing strings, as Roman mentioned, this works well in SystemC (I wrote such a patch some time ago, but unfortunately don't have it available anymore).

Still, this means that your model will only work with the patched kernel and the VCD will only display correctly in gtkwave.

test.vcd

[Hadrian2002]

For everybody interested in my actual solution: I used the "translation filter file" feature of gtkwave. Therefore I created a class traceString, which is created with a standard string, and assigns an ID to every new created instance. I also create while construction a translation with all IDs and the corresponding strings is created and after the simulation you open the VCD in gtkwave and apply the filter file. The you can simply trace the integer ID.

[David Black]

Perhaps you would be willing to share your work as an Apache 2.0 licensed github project with the minimal code needed and a screen snapshot of the results.

[Timur Kelin]

The basic idea:

• calculate hash for the string
• call sc_trace for the hash value
• update a translation file which maps hash values and the string contents.

 

Exemplar github project which utilizes this approach:

https://github.com/timurkelin/simschd

In this project the translation file is written before the simulation starts

 

raw 64-bit hash values:

 

simvision mmap translation applied:

 

simvision mmap is generated automatically and translates string hash (%x=) into string value (-label {}). 

mmap new -reuse -name schd -radix %x -contents {
{%x=0000000000000000 -label { } -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape z   -textcolor #F8F8FF -linecolor green}
{%x=613d30040ed92e78 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
{%x=d1a020f2dd73715f -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
{%x=69071983ebd1b6d4 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
{%x=3a5413510c68f021 -label {run_80.exec_80()} -bgcolor #808000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
{%x=55691ef70e86d835 -label {run_60.exec_60()} -bgcolor #8b0000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
{%x=6f9e19f9823cb15c -label {run_40.exec_40()} -bgcolor #4b0082 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green}
}

 

generated gtkwave translation file for the similar appearance 

0000000000000000 ?grey0? 
613d30040ed92e78 ?grey0?delay_chain.dly10
d1a020f2dd73715f ?grey0?delay_chain.dly10
69071983ebd1b6d4 ?grey0?delay_chain.dly10
3a5413510c68f021 ?OliveDrab?run_80.exec_80()
55691ef70e86d835 ?DarkRed?run_60.exec_60()
6f9e19f9823cb15c ?navy blue?run_40.exec_40()