How do they make Verilog code for unknown ICs?

[Eric Smith]

On Mon, Jun 20, 2016 at 2:56 PM, Swift Griggs <swiftgriggs at 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).