Jump to content
Hadrian2002

Implement sc_trace for std::string

Recommended Posts

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!

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×