Why, #gtkwave, why? What don't you like? You see the values from the sim #fpga and you correctly know that they aren't 0. And you seem to know it's a string of bits. What does that leave? Why are you angry/confused by 1s and only in this variable?
@davidr Multiple drivers on a line causing it to be unresolved.

@remi Aha! I really have to stop thinking serially.

I "initialized the variable" in the testbench and then the actual module was setting the value. With the clue about multiple drivers, I just dropped the "initialization" and it's allll green.

@davidr
It's not so much serially as it is literally wires despite the convenience of assigning a wire a logic level rather than a voltage source physically. Useful in some cases with tri-state values that will resolve. I don't know how #verilog does resolution. #vhdl has typing and explicit behavior for signal state resolution (or explicitly unresolved which will generate a helpful compilation error.)

@remi I guess I mean I need to stop thinking about threads of execution, or at least part of the time. It's really more like a "create connections" step and then a "stand back and watch data flow" step.

I was thinking of the "variable initialization" as happening "before" the things the module was doing. But I only typed it first, it was happening at the same time.

Instead of writing a script for a play, I'm writing a set of rules for a game. Or traffic rules is probably a better metaphor.

@davidr
Ahh yes. Concurrency. Unless you're in an always block (#verilog) or a process with sensitivity (#vhdl) every line can be generally thought of as happening simultaneously. There are simulation conventions to cope with this (delta cycles) but generally just understand everything is concurrent. If you are coming from a programming background, think of everything as asynchronous processes perhaps.