On Mon, Jun 20, 2016 at 2:56 PM, Swift Griggs <swiftgri...@gmail.com> wrote: > On Mon, 20 Jun 2016, Paul Koning wrote: >> a and b will both equal 1 at the end. But in the VHDL code: >> a <= 1; >> b <= a; > > Whoa. That makes total sense, though. In the real world, I'm guessing the > "less than" just reflects that a signal might not have the level you > expect.
It's not a "less than". In VHDL, "<=" is a token for a left arrow, for signal assignment, as in the quote above. Also "=>" is a token for a right arrow, used for mappings, e.g., signal foo: std_logic_vector (7 downto 0) := (7 downto 4 => '0', others => '1'); is one way to declare a signal that is an 8-bit vector, with the left four bits initialized to 0, and the right four bits initialized to 1. In this specific case, it probably would be more clear to write: signal foo: std_logic_vector (7 downto 0) := "00001111"; but I didn't do that because I wanted to give an example of "=>". "=>" can also be used to map formal to actual parameters of subprograms, and (conceptually similarly) to map ports of components to signals. (VHDL allows indices to be descending, using "downto", or ascending, using "to", but it's usually best not to try to mix them in a design. I almost exclusively use "downto", as it matches the most commonly used bit numbering of busses, where the most significant bit is conceptually on the left, and has the highest bit number, and the place-value weight of each bit is 2^n.) VHDL is often criticized for being more verbose than Verilog. IMHO, it more than makes up for that by offering strong type checking, whereas Verilog makes it easier to shoot yourself in the foot without any warning. (Much like Ada vs. C.) I personally don't find the verbosity to be an issue, because I can type much faster than I can think about anything complicated. I rarely, if ever, find that the verbosity slows me down in the slightest, but certainly YMMV. Originally VHDL was a more expressive language than Verilog, but more recent Verilog standards have closed much of the gap. Both Verilog and VHDL make it easy to write code that cannot be synthesized to hardware (or to "reasonable" hardware), so one learns to stick to a subset of the language capabilities that is synthesizable. AFAIK, there is no formal spec for a synthesizable subset of either language; different synthesizers have variations in what they accept. To some extent, knowing what features of the language can be used in synthesis is a matter of understanding what hardware (gates and flip-flops) you're trying to represent. While VHDL and Verilog can provide a higher abstraction than individual gates and flip-flops, synthesis has to turn everything into those, and if you're writing HDL code and aren't sure how the synthesizer can turn the specific constructs into hardware, it's entirely likely that it can't. A common misconception about both VHDL and Verilog is that they make it trivial for programmers to become hardware developers. Despite all of the hoopla over "high level synthesis", the reality is that if you don't know how to design hardware using gates and flip-flops, anything you try to build in an HDL, even with high-level synthesis, is likely to either not work, or to be extremely inefficient. The parallelism that Paul described in his example is one of the hardest concepts for programmers new to hardware design to grasp. Verilog has an innate distinction between "wires" and "registers". VHDL just has signals. The idiom for a register in VHDL is: process (clock) begin if rising_edge (clock) then b <= a; end if; end process; This shows a signal assignment (b <= a) as a sequential statement, which occurs only when the condition (rising edge of clock) is met. Outside a process, a signal assignment is a concurrent statement, and happens all of the time. Here's an example of a VHDL process that works perfectly well in simulation, but probably not at all in synthesis: process (clock) begin if clock'event then b <= a; end if; end process; That process models a register that is clocked on both edges of the clock input, e.g., any time the clock signal changes. That's easy to simulate, but difficult to synthesize as generally speaking no flip-flops that clock on both edges are available. Another example of a non-synthesizable VHDL construct is: b <= a after 15 ns; That isn't synthesizable because there isn't any time delay element available in logic synthesis. The only way to do it is to have some clock with a cycle time that is a submultiple of 15 ns, and to use a shift register or counter clocked by that to implement the delay. The synthesizer won't do that for you; you have to specify it explicitly. Historically, it seemed that ASIC designers have preferred Verilog, while FPGA designers have preferred VHDL. I'm not sure that's nearly as true as it once was. It's claimed, and perhaps may even be true, that Verilog is easier to learn than VHDL. I still advise learning VHDL first. If you need to know both, it's my opinion that it's easier to learn Verilog after knowing VHDL than vice versa. My favorite VHDL book is Peter Ashenden's _Designer's Guide to VHDL_. I'm not going to claim that it's a particularly great example to study, but one of my recent VHDL projects was to implement IEEE-488 (aka GPIB or HP-IB) in an FPGA: https://github.com/brouhaha/gpib I coded all of the IEEE-488 function state machines other than the newfangled no-handshake transfers, which almost no equipment supports. So far I have only actually tested the L, T, SH, and AH functions, which are the key interface functions required for data transfer, and the only ones that are fully implemented by normal IEEE-488 interface chips (e.g., TI TMS9914, Intel 8291, Motorola MC68488, NEC uPD7210).