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
Sorry, I somehow didn't see the whole thread. To do fpga you need to design hardware. You should not think "serial, concurrent, process, assignment, variable" at all, you should think "clock, wire, gate, driver, load, setup, hold, delay, etc."

@remi

@poleguy @remi I'm going to have to keep working with this to really absorb the central metaphor. I'm getting pieces of it, but it isn't fully fleshed yet.

@davidr
I'd draw out the circuit for a few simple things and the equivalent hdl. Maybe do a rising edge detector, an accumulator and a mux.

Don't ever do anything outside of a clocked process. There are ~zero real cases where that is useful.

Every signal should be assigned in only one process.
Every conditional case should assign every output unless you want a register.

Code up violations of these rules and draw the resulting circuit to see why they are good rules.
@remi

@poleguy @remi I think you might be overestimating my electronics knowledge. I like the basic idea, though. Multi-modal learning is the best way and trying-but-failing to do something can be better than succeeding.

@davidr @poleguy Well if you know what a logic gate does, and if you know what a flip-flop does, you're like... 95% of the way there! 😆

Remember that these HDL languages (whatever flavor you like) are MODELING languages. Remember back when I said, in simulation you can do whatever you like? Well the flipside is that in RTL (register transfer level -- basically "going to become real") you can't. It may be useful to find some examples that connect cod e to schematic. 1/2

@remi @poleguy I really like this idea of real-izing a design. Except not a schematic--I have to be concrete.

I'll build some things side-by-side and see what clicks. Logic gates, flip-flops, Ben Eater's 6502 PS2 keyboard interface...

I have to stick to the tutorials long enough to get some basic syntax and building/debugging techniques. Then I'll branch out.

@davidr @poleguy
I realize this may be throwing you a little in the deep end, but if you go slowly, you should be able to glean some general patterns. This document is Intel's HDL recommended coding guidelines. It ought to have most of the basic semantic models that translate into real logic gate and register structures (and probably more, but just take it slow.)

https://www.intel.com/content/www/us/en/docs/programmable/683323/18-1/recommended-hdl-coding-styles.html

#vhdl #verilog #fpga

2. Recommended HDL Coding Styles

Intel
@remi @poleguy This might be pretty useful. I've been wondering about design patterns and how modules should be designed, source managed, etc.
@davidr @poleguy This won't tell you much about those, these are lower level design patterns. As far as top level device design -- well that's an ongoing conversation and open to discussion about verification, maintenance, code review, etc :D. But you got to know what you're dealing with at a lower level before you can integrate the larger notions.