It's just that when I played with the KISS32 PRNG it would take forever to start looking "random" when seeded with zero or a low entropy seed. Much better to have at least an equal number of zero and one bits.
So I had to try the 1, 0 seed with xoroshiro128+. It gets into something looking "random" much quicker. Like so:
Casting to 16 bits and printing from the beginning gives the exact same sequence as you!
I lied; It does not! I got the same 32 bit result as Heater though... Something funky is going on!
Your result was throwing away the LSB. After I shifted my result by 1 bit, I got your same values from the 12345th iteration, as well as the bigger one.
I'm not getting the same output from verilog as the C version. I modified my C test harness to output the high 31 bits:
It starts out well, and many values along the way can be correct. With the odd error thrown in:
On AIX (Power 7) it fails with gcc as well, in 32-bit mode. Although differently than with xlc (IBM compiler). gcc 4.8.3
All's well with xlc when compiled with -q64.
'//' comes from C++, so I call it C++ comments, even if it's been adopted by C99 or whatever. Never liked the look of those comments either. I liked the Ada comments though:
I'm running Dieharder as we speak. On my i7-6700K @ 4GHz it will run for 30 minutes or so, using the raw input mode through the pipe mechanism in Linux!
The data rate is 9.51e+06 random character / sec.
I'm running Dieharder as we speak. On my i7-6700K @ 4GHz it will run for 30 minutes or so, using the raw input mode through the pipe mechanism in Linux!
The data rate is 9.51e+06 random character / sec.
I think it would be best to take the good 63 bits out of the xoroshiro128+ and come up with sixteen randomly-chosen static 32-bit patterns which each use 32 of those 63 bits. Most of those 63 bits should only be used 8 times across all 16 patterns, while a few will need to be used 9 times, since we only have 63 bits, not 64, from the xoroshiro128+. Each cog will get one of these 16 patterns for its own RND value.
Here is what the result needs to look like, except those "--" need to become "00".."62" values:
Those 32'hxxxxxxxx values are fractional parts of the square roots of the first 16 prime numbers. They are there to further distinguish patterns from each other. I know, they have no cryptographic benefit.
... come up with sixteen randomly-chosen static 32-bit patterns which each use 32 of those 63 bits.
Since the bits are random, do you need random pickoff ?
eg you could allocate 4 groups of 32 to 4 COGS and get different results, then you could repeat that byte shifted 4 x, and everyone has a different snapshot of the 128 bits.
If you really do want random taps, run this RNG to generate some
... come up with sixteen randomly-chosen static 32-bit patterns which each use 32 of those 63 bits.
Since the bits are random, do you need random pickoff ?
eg you could allocate 4 groups of 32 to 4 COGS and get different results, then you could repeat that byte shifted 4 x, and everyone has a different snapshot of the 128 bits.
If you really do want random taps, run this RNG to generate some
Random pickoff matters, relatively, between sets of 32 bits.
It's kind of a two-dimensional problem. Some divide-and-conquer is needed.
I assume the new FPGA images with this new random number generator will have the same instruction set and encoding as the current v16. Is that correct?
I assume the new FPGA images with this new random number generator will have the same instruction set and encoding as the current v16. Is that correct?
Yes. This is a very subtle change that almost nobody would recognize, in practice.
Comments
Yes!!! I'm able to output the 16 LSBs and they match your sequence. Here's what I saw:
0001
4001
0121
4122
C401
40E2
C544
5EE6
0CA2
C1B1
FE2C
ED27
656A
7508
D26F
44F2
80C3
4734
4DCE
1CB8
364B
3248
E5DB
A465
40D1
A65F
CE36
0C5E
2CBD
188D
66F4
8A00
2225
04EE
3834
9344
602A
7277
C0EA
CAD8
In the PRNG class constructor
PRNG get method
Casting to 16 bits and printing from the beginning gives the exact same sequence as you!
I lied; It does not! I got the same 32 bit result as Heater though... Something funky is going on!
Your result was throwing away the LSB. After I shifted my result by 1 bit, I got your same values from the 12345th iteration, as well as the bigger one.
In the normal Verilog, I don't use the LSB, but for single-stepping, I made it output result[31:0].
Okay, we have it working then!
Right. There should be no surprises, though, if that xoroshiro128+ page was accurate in its claims.
It starts out well, and many values along the way can be correct. With the odd error thrown in:
C output:
0000000000000000
0040000800002000
000420100c000090
c0402b1808222091
04e812058c04e200
00ec10093ac4a071
34d82eb81903e2a2
efac90afec692f73
cd3293b975ac8651
25d3fd9d32afe0d8
d2232430c64dff16
ec48abda86ce7693
218df697abbbb2b5
1e994ae9f17d3a84
d34d862e033fe937
05f696ca131fa279
3d5db0e43348c061
263a9c552d81a39a
25dab82a39faa6e7
f55244eb04720e5c
Verilog output:
xxxxxxxxxxxxxxxx
0000000000000000
0040000800002000
000420100c000090
40402b1808222091 Err
04e812058c04e200
00ec10093ac4a071
34d82eb81903e2a2
6fac90afec692f73 Err
4d3293b975ac8651 Err
25d3fd9d32afe0d8
52232430c64dff16 Err
6c48abda86ce7693 Err
218df697abbbb2b5
1e994ae9f17d3a84
534d862e033fe937 Err
05f696ca131fa279
3d5db0e43348c061
263a9c552d81a39a
25dab82a39faa6e7
755244eb04720e5c Err
Something seems to be going wrong with the top bits.
Could be my test harness of course...
I made a verilog test harness:
I use the plain verilog version as I don't have the regscan macro available.
I run it under Icarus Verilog:
Chip, what have you done? I'm writing verilog!
On AIX (Power 7) it fails with gcc as well, in 32-bit mode. Although differently than with xlc (IBM compiler). gcc 4.8.3
All's well with xlc when compiled with -q64.
'//' comes from C++, so I call it C++ comments, even if it's been adopted by C99 or whatever. Never liked the look of those comments either. I liked the Ada comments though:
Yes, Heater needs to change this line:
wire [63:0] value;
And I'm reading C code.
The data rate is 9.51e+06 random character / sec.
/Johannes
That's the Chr(0..255) byte rate?
Super! I'm going to sleep now, but I'll be checking this thread for the results when I get up. If I could work all day and night, I would.
My wire definition was fine. Changing it as suggested causes Icarus Verilog to give a warning:
$ iverilog -o xoroshiro128plus.vpp xoroshiro128plus_tb.v xoroshiro128plus.v
xoroshiro128plus_tb.v:17: warning: Port 3 (out) of rnd expects 63 bits, got 64.
xoroshiro128plus_tb.v:17: : Padding 1 high bits of the expression.
My C code test harness went wrong because I had a cast to intmax_t rather than uintmax_t so there was a signed shift right going on!
C and Verilog results match up fine now.
The C test harness: Results:
I think we have a winner.
It will take 5 hours to complete!
The first few tests looks like this
Without bit reordering I guess every test would fail!
We've got a much better random number generator now.
I think it would be best to take the good 63 bits out of the xoroshiro128+ and come up with sixteen randomly-chosen static 32-bit patterns which each use 32 of those 63 bits. Most of those 63 bits should only be used 8 times across all 16 patterns, while a few will need to be used 9 times, since we only have 63 bits, not 64, from the xoroshiro128+. Each cog will get one of these 16 patterns for its own RND value.
Here is what the result needs to look like, except those "--" need to become "00".."62" values:
Those 32'hxxxxxxxx values are fractional parts of the square roots of the first 16 prime numbers. They are there to further distinguish patterns from each other. I know, they have no cryptographic benefit.
Since the bits are random, do you need random pickoff ?
eg you could allocate 4 groups of 32 to 4 COGS and get different results, then you could repeat that byte shifted 4 x, and everyone has a different snapshot of the 128 bits.
If you really do want random taps, run this RNG to generate some
Random pickoff matters, relatively, between sets of 32 bits.
It's kind of a two-dimensional problem. Some divide-and-conquer is needed.
Yes. This is a very subtle change that almost nobody would recognize, in practice.