Patch to export VCD files

Hello,

against version 1.0.1 I created a patch which allows to export the logic analyzer data in VCD formal.If the logic analyzer view is epanded there is a new button at the bottom allowing export. I hope it can be incorporated into the official releases.

Thanks.

- Thomas

Thanks.
I will have a look.

The code looks great, I will add it.

This is a feature I had in mind, but I'm not familiar with VCD format, so this contribution is of great help.

My pleasure to be able to help.

I added this feature at trunk Rev 1437.

I had problems watching the vcd file in GtkWave because it exports a lot of data.
So as a first step now it exports only the data in the screen.
Next step probably will be a dialog to set start and end times to export.

Also the time is the simulation time so in GtkWave you may get a looong space without data.
I changed this so the start of the data dumped is time 0.

If you find some inconveniences with these changes let me know.

Hello,

I think the line:
out <<"$timescale "<< 1 <<"ps $end"<< endl<< endl;

is not good as a fixed resolution of 1ps creates huge data in pulseview. I think it is snappy only if you make this time info as high as possible as in my original patch.

Otherwise I agree. Thanx.

- Thomas

is not good as a fixed resolution of 1ps creates huge data in pulseview.

That's true that Pulseview generate insane amounts of data at 1 ps, but this is the fault of this program.
Or we should say that Pulseview is not an VCD viewer.

For example for this 426 byte vcd file Pulseview generates something like 10 GB of data:

Code:

$timescale 1ps $end

$var wire 1 * D0 $end
$var wire 1 " D1 $end

$enddefinitions $end

#1 1" 1*
#500000001 0*
#1000000001 0" 1*
#1500000001 0*
#2000000001 1" 1*
#2500000001 0*
#3000000001 0" 1*
#3500000001 0*
#4000000001 1" 1*
#4500000001 0*
#5000000001 0" 1*
#5500000001 0*
#6000000001 1" 1*
#6500000001 0*
#7000000001 0" 1*
#7500000001 0*
#8000000001 1" 1*
#8500000001 0*
#9000000001 0" 1*
#9500000001 0*
#10000000000 0" 0*

In any case using Simulator stepSize is not the solution.
Note that SimulIDE 1.x.x simulation engine is not clock driven but event driven and all events have a time resolution of 1 ps.

To solve this we need some other solution.

Looks like the solution in Pulseview is import VCD and set a downsampling of at least 1000 (ps to ns).

In the future when an export dialog is added, the time scale could be added to it.
This dialog should have:
- Time frame: start and end times to export (default = screen).
- Time scale: in picoseconds (maybe default = 1000).
- Format: VCD, Wav, Raw, Comma, etc.
- Any other??

One nice thing about Pulseview is the protocol decoders, this was discussed some time ago: https://simulide.forumotion.com/t484-more-intuitive-way-for-usart-monitor

I wonder how difficult would be to interface with Pulseview from simulide...

I did some modifications to  interface relatively easy with Pulseview just using VCD files:
- Set timescale to 1000 ps.
- keep file path, not folder path.

A very simple test using PWM decoder, but something similar could be done with communication protocols, for example using "Pause on Condition" set to stop condition in I2C:

Hello,

I added the calculation of the biggest common denominator over all timestamps to determine the sample distance for export to VCD and use this in the header section. This should minimize the data generated by pulseview.

Additionally there is a bug when the zoom window stretches to negative times which I partially fixed. I was not able to fix it completely as the line for timestamp 0 now can contain multiple identical entries. This does not seem to bother pulseview but is not nice. My knowledge about the internal is not good enough to find a suitable solution.

- Thomas

I added the calculation of the biggest common denominator over all timestamps to determine the sample distance for export to VCD and use this in the header section. This should minimize the data generated by pulseview.

Cool, that seems a good solution.
Maybe we should also set a minimum timestamp.

Additionally there is a bug when the zoom window stretches to negative times which I partially fixed. I was not able to fix it completely as the line for timestamp 0 now can contain multiple identical entries. This does not seem to bother pulseview but is not nice. My knowledge about the internal is not good enough to find a suitable solution.

That's right, I didn't do any checks.
I will have a look.

I solved the issues with negative times.

And I had some problems with GCD:
I was getting always 1 ps timescale for a 1kHz square wave which does not make a lot of sense.
Then I realized that the first rising edge was just 1 ps away from the time start (edge of the screen) and that's why timescale was always 1.

Still thinking how to solve this...

Hello,

maybe calculate not based on the timestamps but on timestamps divided by 2 or 4 and then use 2 or 4 ps as minimum resolution and when adding the timestamps to the file divide by the same number. So we sacrifice a bit of resolution.

- Thomas

maybe calculate not based on the timestamps but on timestamps divided by 2 or 4 and then use 2 or 4 ps as minimum resolution and when adding the timestamps to the file divide by the same number. So we sacrifice a bit of resolution.

Yes that helps.

I added a property to set the minimum timestamp, so the final timestamp after GCD is a multiple of this value.
By default it is set to 1 ns (1000 ps) which in most cases is more than enough.

Another property to export data every time the simulation pauses.
This makes much easier to interface with VCD viewers: just pause the simulation (manually or by condition) and reload file in the viewer (just press "Run" in Pulseview).

Also solved some issues:
- I think all problems with zero or negative time are solved.
- Add initial values : $dumpvars section.
- Add final values: just repeat the last values with timestamp timeEnd.

Here an screenshot using Pulseview to decode I2C (click to see the full image):

Hello,

I could not compile 1444 as the changes from 1440 are, as I see it, not complete. After solving this I could try it out and the "auto-export-on-pause" is really nice. I only would propose to name the exports not Dn but Ch0.. so it is the same as in your internal logic analyzer (line 306 in logicanalizer.cpp). But the original idea to use Dn is from me...., ;-)

So thanks for implementing so quickly. It helps a lot.

- Thomas

I could not compile 1444 as the changes from 1440 are, as I see it, not complete.

Sorry, hopefully fixed at Rev 1445.

After solving this I could try it out and the "auto-export-on-pause" is really nice.

Nice to know it is working.

I only would propose to name the exports not Dn but Ch0.. so it is the same as in your internal logic analyzer (line 306 in logicanalizer.cpp). But the original idea to use Dn is from me...., ;-)

Yes, it makes sense.

So thanks for implementing so quickly. It helps a lot.

Thanks to you.
Your code "opened the gate" to interface with PulseView and it's protocol decoders, and this is a huge improvement to debug many things.