vcd input file

[ghost]

it looks like that simavr does not recognize/accept a vcd input file OR the layout/structure of the vcd input file is not well documented. I try to stimulate PB2 as input. GTKWAVE shows that the vcd file seems to be correct. avr-gdb shows that soemthing is happening on the PORTB but the overall timing is not clear.

simavr command:
simavr --freq 8000000 --mcu attiny45 --gdb --input test

Attached is a TGZ file (github does not accept this format, rename to *.tgz):
attiny45_motor.gz

.vcd attiny45_motor_001.elf

Head of vcd input file:
$timescale 1us $end
$scope module logic $end
$var wire 6 % PORTB $end
$upscope $end
$enddefinitions $end
$dumpvars
bxxxxxxx %
$end
#1000
b000100 %
#1097
b000000 %
#1194
b000100 %
....

[buserror]

My bad, really. I did write teh VCD input for a purpose, then forgot to properly document it...
If you look at the files in rf_bridge, it's a bit clearer: https://github.com/buserror/rf_bridge/blob/master/files/pulseview_weather.vcd

So the syntax is not PORTB, it's the actual ioctl() call made to simavr internally, plus an index so for example for my PORTH5 is written "iogH_5" In you case since you want to set all pins, use iogB_8 ( 8 is the index in https://github.com/buserror/simavr/blob/master/simavr/sim/avr_ioport.h for IOPORT_IRQ_PIN_ALL).
I haven't tried setting multiple pins tho, I think i wrote the support for it, but you might have to tweak the reader code...

Please confirm it works for you. I have a plan to change the 'names' (that iogB_8) to use the official IRQ names at some point, as it would definitely make things clearer...
Please do confirm it works for you...

[ghost]

sorry does not seem to work. I disabled all output for PORTB in the source but see various numbers in r24 (PORTB,0x18, which should be PORTB) popping up. The r22(PINB,0x16) jumps from 0x0 to 0x1c and stays at that value.

$timescale 1000 ns $end
$scope module logic $end
$var wire 1 ! iogB_2 $end
$upscope $end
$enddefinitions $end
#0 0!
#1000 1!
#1097 0!
#1194 1!
#1291 0!
#1388 1!
#1485 0!
....

[helargus]

Hello,

for single input, I can confirm it works for me. I uploaded a complete example here:
https://github.com/helargus/simavr/tree/test-input-vcd

Multiple inputs did not work, as soon as I added
$var wire 1 c iogC_2 $end
together with corresponding signal changes then the simulator did not import the values.

The vcd output showed no changes on PINC and the output on PORTB did not change either as I would have expected.

I could need some help here to get the simulator ready to read multiple signals.

[buserror]

I'll have a look, I think VCD input is way cool for offline development

[larsks]

@buserror , I was going to open a similar issue, but then I stumbled upon this one. I am writing some code targeting an attiny85, and I am trying to feed the following file to simavr as input:

$timescale 1ms $end
$scope module logic $end
$var wire 1 p iogB_0 $end
$var wire 1 u iogB_1 $end
$var wire 1 b iogB_4 $end
$upscope $end
$enddefinitions $end
$dumpvars
xp
xu
xb
$end
#0
1p
0u
1b
#10
1u
#100
0b
#500
0p
#600
1p
#1000
1b
#1500
0u

Just to rule out dumb errors on my part, this is what I expect to happen:

• Initially set PB0 high, PB1 low, and PB4 high.
• At 10ms, set PB1 high.
• At 100ms, set PB4 low.
• At 500ms, set PB0 low (this is a button press).
• At 600ms, set PB0 high (this is a button release).
• At 1000ms, set PB4 high.
• At 1500ms, set PB1 low

The traces look fine in gtkwave, but when I feed this to simavr like this...

simavr -m attiny85  -f 1000000 pipower.elf  -t -i buttontest.vcd 

...it just exits immediately. If I add -g and attach to it with gdb, I can see that it initially starts executing but fairly quickly just drops the remote connection and exits.

Any idea what's going on here?

[larsks]

(I've worked around this by using gdb to manipulate PINB while the code is running, which works okay but is somewhat less convenient.)

[JarrettBillingsley]

Yeah, this is the exact behavior I'm getting too... not sure what the deal is. I'll try debugging simavr and see if I can find anything.

[JarrettBillingsley]

Oh. Well it's not very documented, but at sim_vcd_file.c:208, the simulator will just stop when it reaches the end of the input VCD file. If you put an event with a very large time at the end of your VCD file, it will run as you might expect. Still, this isn't obvious, and should really be an option.