dr 🛠️🛰️📡🎧
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?
Remi@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.)
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.
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.
poleguy looking for lost tools@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
@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
@davidr @poleguy
So there are "semantic models" that take a code structure and a synthesizer will create a particular structure out of it. I'll do a #VHDL one:
process (clk, reset) is
begin
if (reset = '1') then
q <= '0';
elsif rising_edge(clk) then
q <= d;
end if;
end process;
(Sad I don't have Markdown fixed case.) That's a D Flipflop with an asynchronous reset. There's a lot of other things I can add to that model, but it'll generically evaluate to a flop. 2/2
@davidr @poleguy
So, once you know what the semantic models are, you can sketch out a schematic and map that to a bit of code and maybe that gets you down the road further to complete understanding of what you're trying to accomplish! 3/2 (because I'm wordy as fuck when I get going on a subject I enjoy 😆)
So, once you know what the semantic models are, you can sketch out a schematic and map that to a bit of code and maybe that gets you down the road further to complete understanding of what you're trying to accomplish! 3/2 (because I'm wordy as fuck when I get going on a subject I enjoy 😆)
@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.)
@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.
@davidr
You can ramp up your knowledge quickly. Start with an edge detector.
That's an inverter, an and gate a register or two. Draw out the logic tables and a time waveform. Then hdl. Also draw circuit. Google edge detector circuit.
But if you can't start to think of fpga as hardware, you'll have trouble getting past the level of "connect other peoples blocks with wires"...
@remi
@davidr
Contention: you're driving constant zero somewhere?
Contention: you're driving constant zero somewhere?