GtkWave isn't getting signals from IVerilog simulation - verilog

I wrote the following test for my code:
module HalfAdder_Test;
wire sum;
wire carry;
reg a = 0;
reg b = 0;
initial begin
$dumpfile("test.vcd");
$dumpvars(0, HalfAdder_Test);
# 10 a = 0;
# 10 b = 0;
# 30 a = 1;
# 30 b = 0;
# 50 a = 0;
# 50 b = 1;
# 70 a = 1;
# 70 b = 1;
# 90 $stop;
end
HalfAdder ha (a, b, sum, carry);
endmodule
I then compile it and open it in GTKWave using the following commands:
iverilog -o HalfAdder -c files.txt
vvp HalfAdder -lxt2
gtkwave output.vcd
When I do that, I get the following output though:
The problem is that my signals aren't going high even when they do in the simulation. What could be causing my simulation to not output?
When I open my .vcd file, I get the following output:
1380 0001 4000 0000 0800 0000 9a00 0000
1400 0000 4400 0000 3800 0000 2300 1f8b
0800 0000 0000 020b 6360 f048 cc49 734c
4949 2d8a 0f49 2d2e d14b 6460 e04f 02e2
e4c4 a2a2 4a20 5d5c 9a0b 2433 12f5 1c19
1884 9c80 d819 8883 1900 93ef 3630 3800
0000 1f8b 0800 0000 0000 020b 6360 a02a
e000 6246 343e 131a 9f19 990f 003c 2732
3f80 0000 0000 0000 6a00 0000 5800 0000
0000 0000 0000 0000 0000 0000 fa1f 8b08
0000 0000 0000 0b62 6065 4005 4650 ba09
4a6f 81d2 bf00 0000 00ff ff62 6460 6462
6604 0000 00ff ff62 6062 6262 0043 2000
0000 00ff ff62 0400 0000 ffff 83ca 8943
694e 282d 08a5 e5a1 3408 b000 003e bbb2
446a 0000 0000 0000 2900 0000 3f00 0000
0000 0001 9a00 0000 0000 0001 9a1f 8b08
0000 0000 0000 0b62 6064 0003 c659 0000
0000 ffff 0233 1801 0000 00ff ff02 0206
0000 0000 ffff 6204 0000 00ff ff83 08c1
6930 1b00 c899 14b8 2900 0000

module tb_top
(
top_clk,
top_rst
);
input top_clk;
input top_rst;
reg thirty;
reg twenty;
reg [31:0]SHOW_CLK;
always #( posedge top_clk or negedge top_rst)
begin
if (top_rst==1'b0)
begin
SHOW_CLK <= 32'h0;
twenty <= 1'h0;
thirty <= 1'h0;
end
else
begin
SHOW_CLK <= (SHOW_CLK+32'h1);
twenty <= 1'h0;
thirty <= 1'h0;
if ((SHOW_CLK==32'h14))
begin
twenty <= 1'h1;
end
if ((SHOW_CLK==32'h1e))
begin
thirty <= 1'h1;
end
end
end
endmodule
this is what a vcd file looks like, they vary by tool as to what the shortcut name is (D is SHOW_CLK in this case)
$scope module tb_top0 $end
$var wire 32 D SHOW_CLK $end
$var wire 1 B thirty $end
$var wire 1 E top_rst $end
$var wire 1 C twenty $end
$enddefinitions $end
#0
b00000000000000000000000000000000 D
0B
0E
0C
#20
b00000000000000000000000000000001 D
1E
#22
b00000000000000000000000000000010 D
#24
b00000000000000000000000000000011 D
#26
b00000000000000000000000000000100 D
#28
b00000000000000000000000000000101 D
#30
b00000000000000000000000000000110 D
#32
b00000000000000000000000000000111 D
#34
b00000000000000000000000000001000 D
#36
b00000000000000000000000000001001 D
#38
b00000000000000000000000000001010 D
#40
b00000000000000000000000000001011 D
#42
b00000000000000000000000000001100 D
#44
b00000000000000000000000000001101 D
#46
b00000000000000000000000000001110 D
#48
b00000000000000000000000000001111 D
#50
b00000000000000000000000000010000 D
#52
b00000000000000000000000000010001 D
#54
b00000000000000000000000000010010 D
#56
b00000000000000000000000000010011 D
#58
b00000000000000000000000000010100 D
#60
b00000000000000000000000000010101 D
1C
#62
b00000000000000000000000000010110 D
0C
#64
b00000000000000000000000000010111 D
#66
b00000000000000000000000000011000 D
#68
b00000000000000000000000000011001 D
#70
b00000000000000000000000000011010 D
#72
b00000000000000000000000000011011 D
#74
b00000000000000000000000000011100 D
#76
b00000000000000000000000000011101 D
#78
b00000000000000000000000000011110 D
#80
b00000000000000000000000000011111 D
1B
#82
b00000000000000000000000000100000 D
0B
#84
b00000000000000000000000000100001 D
#86
b00000000000000000000000000100010 D
#88
b00000000000000000000000000100011 D
#90
b00000000000000000000000000100100 D
#92
b00000000000000000000000000100101 D
#94
b00000000000000000000000000100110 D
#96
b00000000000000000000000000100111 D
#98
b00000000000000000000000000101000 D
If you get to the end of definitions and maybe a #0 but no clocked data that could mean that your design didnt actually change state for any of the selected signals (which could be because of your design or because you didnt run the sim long enough).
VCD is an ascii file format so independent of your recent success you should try to figure out how to fiew text files (same text editor you use
to edit your verilog for example).

The problem was with the time scale in viewing the simulation.

Related

elf aarch64 golfed with sys_write

To better understand the ELF format and the ARM aarch64, I'm trying to create my elf binary without compilers, just echoing bytes with bash.
Will can see my effort here: http://www.github.com/glaudiston/elf
I have succeeded in achieving a fully working elf with sys_write and sys_exit syscalls for x64.
But for aarch64, it's not working as I expect it to:
# cat make-elf.sh
#!/bin/bash
#
# depends on:
# - elf_fn.sh (github.com/glaudiston/elf)
# - base64 (gnu-coreutils)
#
. elf_fn.sh
instructions="";
instructions="${instructions}\nwrite $(echo -en "hello world\n" | base64 -w0)";
instructions="${instructions}\nexit 3";
write_elf elf "${instructions}";
It generates:
$ xxd elf
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............
00000010: 0200 b700 0100 0000 7800 0100 0000 0000 ........x.......
00000020: 4000 0000 0000 0000 0000 0000 0000 0000 #...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000 ....#.8.........
00000040: 0100 0000 0500 0000 0000 0000 0000 0000 ................
00000050: 0000 0100 0000 0000 0000 0000 0000 0000 ................
00000060: 7800 0000 0000 0000 7800 0000 0000 0000 x.......x.......
00000070: 0000 0000 0000 0000 2000 80d2 010c 0058 ........ ......X
00000080: 8201 80d2 0808 80d2 0100 00d4 6000 80d2 ............`...
00000090: a80b 80d2 0100 00d4 6865 6c6c 6f20 776f ........hello wo
000000a0: 726c 640a
$ ./make-elf.sh 0 && ./elf; echo $?
3
$ cat elf | base64 -w0; echo
f0VMRgIBAQAAAAAAAAAAAAIAtwABAAAAeAABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAOAABAAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAeAAAAAAAAAB4AAAAAAAAAAAAAAAAAAAAIACA0gEMAFiCAYDSCAiA0gEAANRgAIDSqAuA0gEAANRoZWxsbyB3b3JsZAo=
It returns the expected exit code, with no illegal exceptions, but the sys_write call is not printing anything.
Hiding all ELF overhead, we have this:
00000078: 2000 80d2 010c 0058 ......X
00000080: 8201 80d2 0808 80d2 0100 00d4 6000 80d2 ............`...
00000090: a80b 80d2 0100 00d4 6865 6c6c 6f20 776f ........hello wo
000000a0: 726c 640a rld.
The exit call is working as expected, so I can hide it too:
00000078: 2000 80d2 010c 0058 ......X
00000080: 8201 80d2 0808 80d2 0100 00d4 ............
00000090: 6865 6c6c 6f20 776f hello wo
000000a0: 726c 640a rld.
So we have the data hello world.\n starting at position 98. I am very confused about how to do the sys_write call here. In x64 I can set to the next data address that in this case should be 65688(composed of PH_VADDR_V(65536) + ELF_HEADER_SIZE(64) + ELF_BODY_SIZE(32) (without DATA_SECTION)")
To the output fd I do set in r0 the value 1 with 2000 80d2
To the data address I am using 010c that is little endian representation of 0c01 this bits: 00001100000 00001 The last 5 bits are the r1 register, used to data address.
Given I only have 11 bits
Here I've used the LDR (0058) but I've tried MOV (here 80d2) too. With no success
I've tried any value from 0 to 2048 where it starts to reports Illegal instruction and exit code 132.
I think maybe aarch64 does not allow the same trick I've used in x64 to print data without a labeled data section. I'll work on creating it, but this is just a guess and I really want to understand why this is not printing nothing.
So, your string is at absolute address 0x10098 and you need to get this address into the x1 register.
First of all, LDR is not what you want. It is, as the name suggests, a load (read) from memory. You don't want your instruction to access memory at all, it just wants to put the value 0x10098 into the register.
MOV is closer, which writes an immediate value into the register, but the problem is that the immediate is limited to 16 bits, and you need 17. Because instructions are 32 bits, there are only so many bits available for an immediate. My guess is that you overflowed this and ended up changing opcode bits instead, so you encoded a totally different instruction. (Don't guess at encodings! Look them up. This would have shown you the 16-bit limit.)
For getting arbitrary immediate values into a register, the intended approach is a sequence of MOV/MOVK instructions to write 16 bits at a time. Here you would just need two of them:
0: d2801301 mov x1, #0x98 // #152
4: f2a00021 movk x1, #0x1, lsl #16
Though since we are using a extra word, the address of the string will also shift, so you'd have to adjust accordingly.
However, for addresses in particular, AArch64 provides pc-relative address generation instructions, ADR/ADRP. These let you add an immediate value to the current value of the program counter (i.e. the address of the currently executing instruction) and write the result to a register. As a bonus, they allot more bits for the immediate (though you will no longer need them).
Here we can use ADR. Its opcode is 0 at bit 31, and 10000 at bits 24-28. The destination register is bits 0-4, we want 00001. The immediate gets its low two bits at bits 29-30, and the higher bits at 5-23. The ADR instruction will be at absolute address 0x1007c and we want 0x10098, so the displacement is 0x1c = 0b11100. Thus the encoding we want is
0 00 10000 0000000000000000111 00001 = 0x100000e1
Some general tips:
Try writing code with an assembler first, so that you can learn the instruction set and be able to focus on experimenting with what the instructions do, instead of also getting bogged down in how they are encoded. If you want to come back and do the encoding by hand later, fine, but with an assembler you'll also have a way to check your work.
Use a debugger to single-step your program. That would have showed you that your LDR was giving you a totally bogus value and might have been a hint that it didn't do what you think it did.
Use strace to see what system calls your program makes. That would show you (I think, I didn't test) that write does get invoked but with the wrong address.

jumping indices of values in buffer

I am currently testing some things with an accelerometer and its iio buffer and there is something that confuses me.
The sensor does have four different scan elements: x, y, z and a timestamp.
The indices of those values are:
x = 0, y = 1, z = 2 and time = 3. So far so good.
If I enable all available scan elements the order of the entries is set according to the description.
everything enabled:
0000010 f758 011c 3f64 c0b0 be90 0bfe 499f 0004
0000020 f724 0134 3f58 c0b0 3f2f 10ab 499f 0004
But once I have gaps, for example if I disable the scan element for y, the z value jumps onto index 1 and my buffer looks like this:
x, z and time:
0000010 f720 3f70 0000 0000 722a 5c13 4946 0004
0000020 f728 3f74 0000 0000 0958 60c0 4946 0004
z and time:
0000010 3f6c 0000 0000 0000 ca0b 6ef1 48be 0004
0000020 3f44 0000 0000 0000 edf7 739e 48be 0004
only x and z:
0000010 f720 3f48 f748 3f54 f744 3f5c f75c 3f68
0000020 f750 3f78 f738 3f80 f718 3f64 f700 3f50
I could not find further information on this but I am a bit confused and surprised that the scan elements do not respect their given index once the timestamp is activated and there is an index gap. Is this the normal behavior or is this some stuff that the current sensor driver mixes up?

How to get audio peaks with FFmpeg?

I am working on a music app and need to generate audio spectrum for my files. Like this one:
So I tried using audiowaveform like this:
audiowaveform -i music.mp3 --pixels-per-second 1 -o out.dat
which gives me the following results[correct results]: [the first 10 words are meta data]
0000000 0001 0000 0000 0000 bb80 0000 bb80 0000
0000020 00f9 0000 df3e 1fa2 e22c 1ef3 e0bb 1e5a
0000040 e099 1e88 dfcf 1c33 e29f 1d4c e055 1f80
0000060 df63 1e3a e1b4 1f31 e271 1d81 e0e5 1b1c
0000100 e06d 1be4 dee2 1cb0 e118 1da1 e026 1dea
0000120 e055 1dac df9b 1dbf e0c3 2063 ded4 21b2
0000140 dec9 1f8d de5b 20c8 e02d 216a dd7e 21af
0000160 dea1 20ac de6c 2170 de80 1e12 de6f 1fb9
0000200 dde3 2106 e0d9 21be de88 218c de81 1f9f
0000220 decb 20ff deb2 1edc df32 20c4 dde7 ...
But when I do this kind of job with FFmpeg:
ffmpeg -y -i music.mp3 -acodec pcm_s16le -f s16le -ac 1 -ar 1 -v quiet out.pcm
that gives the following results, which is not same at all:
0000000 0001 fffe fffe fffe 0000 ffff fffd 0000
0000020 ffff ffff fffe 0001 0001 fffd 0001 fffe
0000040 0002 fffe fffc 0002 ffff fffc fffe 000b
0000060 0007 fffb 0004 0001 ffff fffd ffff 0002
0000100 0008 0006 fffe ffff 0001 0000 0003 000a
0000120 fffd ffff 0004 ffff 0001 ffff fffd ffff
0000140 fffe ffff 0001 fffd fffe 0000 fffb 0002
0000160 0002 0000 fffe 0000 fffb fffe fffe 0000
0000200 ffff 0000 ffff fffc 0002 0003 0005 0003
0000220 0002 fffb fffb fffa fffa 0004 0009 ...
You may wonder that why am i doing -ar 1 or --pixels-per-second 1? This is because I want to draw a line for each second, so I need to get peak for each second. . I don't know what am I missing there but I expect to get the same results from FFmpeg.
This is not a solution with FFMPEG, but still results with a wave form array.
My solution was to use the audiowaveform linux package which has a simple cli to extract the waveform data with the desired sample rate.
You can install it on ubuntu like:
sudo add-apt-repository ppa:chris-needham/ppa
sudo apt-get update
sudo apt-get install audiowaveform
Or on macOS with homebrew like:
brew tap bbc/audiowaveform
brew install audiowaveform
First I used the provided command in the question to draw the waveform but it was inaccurate and dirty. Because it takes one sample from each second which is not what I was looking for. So I decided to take 100 samples from each second and get the average with some JS code. So the command to extract the wave form will be:
audiowaveform -i /root/audio.mp3 --pixels-per-second 100 --output-format json -
This will output the audio wave form data along with some metadata on the stdout (That hyphen at the end does the trick). So in my case I used NodeJs to get this output and reduce the waveform array to the average of waveform blocks. Note that I removed the negative numbers from the waveform to work on the upper half of the waveform.
import {exec} from "child_process";
export default function getAudioWaveform(filename, blockSize = 100) {
return new Promise((resolve, reject) => {
const command = `audiowaveform -i ${filename} --pixels-per-second ${blockSize} --output-format json -`;
exec(command, (error, stdout, stderr) => {
if (error) reject(error, stderr);
try {
const data = JSON.parse(stdout).data.filter((_, i) => i % 2 === 1)
const waveform = [];
for (let i = 0; i < data.length; i++)
waveform[i] = Math.round(data.slice(i * 100, (i + 1) * 100).reduce((s, n) => s + n, 0) / 100);
resolve(waveform);
} catch (ex) {
reject(ex);
}
});
})
}

Python stops binary reading of file after getting byte 0xa or 0xd

I want to read some binary file. It is a big file so i use maximalOffset variable to stop reading after getting to it. But reading is always ends at one offset - 8199. The last byte i get is 0xa. In xxd it is the part of byte 0a0d.
I am using Ubuntu 18 and Python 3.
I found some info about 0x1A in Windows (it's EOF symbol or something) but the solution was to use binary reading and 0xA is not 0x1A...
maximalOffsetString = "2070"
maximalOffset=int(maximalOffsetString,16)
offset=-16 # first 16 bytes must be on 0x0 offset
line = [ ]
pagefile = open("./pagefile", "rb")
for bytes in pagefile:
for byte in bytes:
if maximalOffset==offset: break
if len(line) == 16:
print(hex(offset))
print(str(offset)+" : "+str(maximalOffset))
print(line)
del line[:]
line.append(hex(byte))
offset=offset+1
break
pagefile.close()
# here i see what was the last symbols in array:
print(hex(offset))
print(str(offset)+" : "+str(maximalOffset))
print(line)
Output:
0x2007
8199 : 8304
['0xf0', '0xa9', '0xc', '0x7', '0x71', '0xc0', '0xa']
as you can see, my maximalOffset is 8304 but the reading stops at 8199. In xxd this line is:
00002010: f0a9 0c07 71c0 0a0d 0000 006c 0105 5c00
All file before this is only zeros. After 0x2000 there are random bytes.
00001fb0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00002000: 0104 0000 6f01 005c 0094 008c e026 6469 ....o..\.....&di
00002010: f0a9 0c07 71c0 0a0d 0000 006c 0105 5c00 ....q......l..\.
00002020: 9500 8c20 b800 8040 0001 10ab 0c07 4230 ... ...#......B0
00002030: 0dba 0069 010a 5c00 9600 8ce8 b800 38a7 ...i..\.......8.
00002040: 0c07 fbd0 7b01 6601 0f5c 0097 0008 0020 ....{.f..\.....
00002050: 208c f8b8 0090 940d 0724 0000 7a01 6301 ........$..z.c.
00002060: 0c5c 0098 008c 0027 6469 9892 0d07 f2b9 .\.....'di......
00002070: 0009 0080 4100 4100 6001 115c 0099 008c ....A.A.`..\....
00002080: 08b8 0020 0d0e 072b 7c01 7d01 165c 009a ... ...+|.}..\..
00002090: 008c 10b8 0028 a20c 0727 bc00 8100 4200 .....(...'....B.
000020a0: 7a01 1b5c 009b 008c 18b9 009f 0d07 29bc z..\..........).
000020b0: 0077 0118 5c00 9c00 8c98 b803 6091 0d07 .w..\.......`...
000020c0: 06b0 3b05 4000 0103 7401 1d5c 009d 7801 ..;.#...t..\..x.
000020d0: b800 208f 0d07 10f0 097a 0471 0122 5c00 .. ......z.q."\.
I think you are breaking the outer for loop before reading is finished, remove break at the bottom of the outer for loop.
...
for bytes in pagefile:
for byte in bytes:
...
line.append(hex(byte))
offset=offset+1
break # <- Remove this
pagefile.close()
...

what left and right shift operator and how they works

//((Hello everybody!
i am C# beginner can any one tell me the function of left and right shift operator and their working way w.r.t the following program. I read it somewhere but confuse.
thanks ))
using System;
class clc
{
public static void Main() // the Main method
{
int x = 7, y = 2, z, r;
z = x << y ; //left shift operator
r = x >> y; // right shift operator
Console.WriteLine("\n z={3}\tr={4} ",z,r);
}
}
To understand the shift operations you must understand binary numbers.
Let's take your example for left shift:
z = 7 << 2;
32 bit integer 7 is 0000 0000 0000 0000 0000 0000 0000 0111 in binary. You must move the bits to the left beginning from the right. The bits that are shifted out of either end are discarded.
Shifting it by 1 will result 0000 0000 0000 0000 0000 0000 0000 1110
Shifting it by 1 one more time will result 0000 0000 0000 0000 0000 0000 0001 1100 which is 28 in integer representation.
Read this good wikipedia article Binary number

Resources