Quote Originally Posted by hamster_nz View Post
Once tested in C, it gets re-written into a hardware description language (HDL):

Code:
        if rising_edge(clk) then
            random <= s0 XOR s1 XOR s2;
            s0 <= (s0(19 downto 1) & s0(31 downto 19)) XOR (zero(31 downto 13) & s0(18 downto  6));
            s1 <= (s1(27 downto 3) & s1(31 downto 25)) XOR (zero(31 downto  7) & s1(29 downto 23));           
            s2 <= (s2(14 downto 4) & s2(31 downto 11)) XOR (zero(31 downto 21) & s2(28 downto  8));   
        end if;
So using the preprocessor isn't an improvement, nor is using pointers.

Code:
   TMP(s2,0xFFFFFFF0,17, 3,11);
By itself this line is pretty ambiguous, and can't be mapped to hardware.


The rest of my design flow is that the HDL is verified in simulation against the C implementation, then converted to hardware and sort-of-implemented in silicon of an FPGA..

In case you are interested, attached is the resulting logical h/w schematic and a snippet of the FPGA die where the PRNG is placed.

The purple bits is logic resources that makes up the random number generator, the green lines are active wires in this design, and the gray lines are possible connections.
When you're just experimenting with C code or making a software version (albeit not as fast as hardware) the preprocessor macros & the pointers are useful, besides you can always just preparse the file after the experiments to unroll the macros before parsing the result through the intended parser, I bet it would be a ton easier to offload macro support etc into a proper compiler and focus whatever parser you're using on the just the preparsed output. Anyways I concede your point about the parser have a harder time with macros, though if you meant to the human eye I would beg to differ in the example I gave (besides the fact I made typos in the names), I mean the code is literally right there in front of the developer, if they really can't make heads or tails of what the macro does despite that then they probably shouldn't be dealing with making hardware versions of the code until much later (like maybe a year or 2 later).

As for the diagrams, while I do find them interesting and have a rough understanding of what they're doing, I'm more into code than circuits so I don't fully grasp them (also I'm too lazy to check whatever it is I can sense I don't understand despite only giving them a minor look for 10 or so seconds), thanks anyways, it's still appreciated, pity I don't seem to be of help in this case. The only other idea I have for fixing those 2 weak tests is to maybe lookup an existing random number generator that does pass them then pass the output of your tausworthe function/circuit and see if that resolves it, by the sounds of it your being paid to design & make the circuit, I imagine the contractor or whoever won't mind a minor increase in the circuit's price so long as it doesn't require some additional license fee.