Previous discussion:
Verilog Is Weird
61–70 of 131 posts
Re: Verilog Is Weird
#62I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or what…
>> always @(posedge clk) Is there an option for bothedge clk?
always @(posedge clk or negedge clk)
Re: Verilog Is Weird
#63Re: Verilog Is Weird
#64I wonder why building circuits doesn't use a language comparable to the nand2tetris course. For those who haven't seen it: It gives building blocks like NAND, wires, and an abstraction method, allowing to treat a group of wires and building blocks as a new building block. So you wire up a few gates to, say, an adder, then you can use adders in your circuit. Things like circuit synthesis and timing analysis get trivia…
I think you mean block based designs where you define blocks as inputs and outputs with the logic inside, and then you can piece together and group blocks with wires possibly in some sort of visual editor or similar format? This is already how Verilog and VHDL work, they are oriented around functional blocks that you wire together to build up more complex units. Often HDL environments ship libraries of pre-made block…
The different would be that it is never possible to have an unsynthesable design, as long as everything connects together. So the problem designed in the article can't happen if you only have blocks and wires.
Maybe a rephrased question is, what causes Verilog or VHDL to be unsynthesable if they are based on this style of block design
Re: Verilog Is Weird
#65Earlier quoted context omitted.
> Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from th…
> "you need to work out what you want in this other paradigm and then translate it" Not really. You wouldn't expect good programs from someone who has no idea how a computer works. The language is the knobs and dials. You need to know what the knobs and dials do in the machine.
> Not really. You wouldn't expect good programs from someone who has no idea how a computer works.
I wouldn't expect them to write a good operating system, but for the vast majority of code that is being written you can get pretty far with "your cpu is faster than your memory" as the only bit of knowledge about how computers work.
Re: Verilog Is Weird
#66I wonder why building circuits doesn't use a language comparable to the nand2tetris course. For those who haven't seen it: It gives building blocks like NAND, wires, and an abstraction method, allowing to treat a group of wires and building blocks as a new building block. So you wire up a few gates to, say, an adder, then you can use adders in your circuit. Things like circuit synthesis and timing analysis get trivia…
HDL (hardware description languages - Verilog and VHDL the most representative ones) do actually work like that.
They give you access to structural descriptions for bitwise control, but also and mostly behavioural descriptions which allows hierarchies of modules (the blocks you described) and abstraction up to anywhere basically. This last part is generally referred to as RTL (register transfer level) design.
To make a circuit from this RTL description you usually need more steps: synthesis (where RTL gets "compiled" into the actual gates and flops to be used) and implementation (where the logic gates of the previous step are actually translated in the "fabric" you have available - FPGA logic blocks, a foundry's standard cell library ...).
Re: Verilog Is Weird
#67Earlier quoted context omitted.
> "always X" just means loop waiting for X I think this is actually not right. There's not any kind of loop that is running, it's triggered by signal edges. That's the fundamental difference between hardware and software that makes hardware difficult for software people. Everything happens simultaneously.
I think the loop term is OK, it's just gated by the event sensitivity list for each iteration. If you have an always without a sensitivity list then it is a while(1) equivalent.
This is not exactly true, because the event you expect in software, the loop ticking over, can itself happen at any time. posedge(*) will trigger on _any_ change in the always block, and those changes can happen at the same, slightly different, or much different times.
Re: Verilog Is Weird
#68If anyone is interested in alternatives to Verilog, check out PipelineC. Great for software folks getting into hardware, helps avoid issues like blocking vs non blocking confusion, whats a register, etc. Lots of other features too.
Re: Verilog Is Weird
#69Earlier quoted context omitted.
always @(posedge clk or negedge clk)
This is the correct syntax, though many FPGA architectures don't support double edge registers
True, I directly answered the syntax-related question, but talking about implementation this would be a bad description - be it FPGA or ASIC.
As the parent's-parent comment said in other words, think circuit first.
Re: Verilog Is Weird
#70I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or what…
> Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from th…
> you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it"
Senior JavaScript developers will. They'll be thinking in terms of types and allocations, even if the language doesn't enforce them. Even junior javascript developers will usually have some concept of async IO execution.