Learning FPGAs: wrong approach?

[Mattjd]

- "The level of abstraction in HDLs is too low". You can break out of low level HDL programming if you want, but at the cost of doing things somebody else's way, and most likely paying a lot for IP blocks that are huge, complex and costly. However if your needs are unique, then you need to work at low levels of abstraction, for at least part of the design. The 80/20 rule applies.

Well you can go to extremely high levels of abstraction in VHDL, so its possible to have a higher level language by using the existing tools better. But the core issue is that programming for simultaneous execution is radically different to programming for sequential execution.

There have been some good attempts at C-hdl and they work well at matching some patterns, but remain poor at improving all code. So even with the high level tools you still end up needing to understand the flow and patterns that fit into logic, just as if you were programming HDL to begin with.

This is exactly the point.  There is a difference between writing sequential C code and designing hardware  and hardware design is, well, hard.  That's why it's called hardware.

Software speaks for itself  - soft.

It doesn't seem to me that CS majors are going to do well with HDL unless they also took some EE courses.  HDL is an entirely different thing.

Yes, without a course in digital logic/design a CS major will not be able to do well with HDL at all. You don't necessarily have to know how to design an IC at the transistor level, but you sure a shit need to know the boolean algebra to be able to multiplex, decode, encode, create registers, etc. and most importantly the graph theory for state machines.

I don't think people are realize that when doing HDL, you create a module, that module is essentially an IC, lets call it IC

• . IC
• can be dropped into a solder-less breadboard or be put on a surface mount board, or whatever. Every time you "instantiate" a module, you're plugging another one of IC
• into a breadboard.

See this guy



He built an 8 bit computer on a huge breadboard. When I created a 64 bit processor on my FPGA, I described each and every one of those IC he has on that board and described how to wire them together using HDL. The HDL then interpreted what I described, synthesized it, and wired the transistors of the FPGA to create those IC and connections that it interpreted.

[AndyC_772]

Yes, without a course in digital logic/design a CS major will not be able to do well with HDL at all. You don't necessarily have to know how to design an IC at the transistor level, but you sure a shit need to know the boolean algebra to be able to multiplex, decode, encode, create registers, etc. and most importantly the graph theory for state machines.

I'm not sure I'd agree with that. When you design using HDL, you're describing the behaviour of the finished design in terms of what you want it to do. The synthesis tool might infer the need for multiplexers and D-types, but that's not the way the designer has to think. We're a level abstracted.

For example, suppose you're writing an SPI slave, which needs to be able to return one of a number of different values depending on which address is being read. If you're well versed in fundamental digital building blocks, then you might start thinking about how this would be realised using multiplexers and latches. It's fine to be aware, at a very general level, that these are the components which will be required, but you don't need to actually work out how to implement your desired logic using them.

Your code might look something like this:

Code: [Select]

IF sclk'event AND sclk = '1' THEN
  IF reset_n = '0' THEN
    spi_result <= 0;
  ELSE
    CASE spi_addr IS
    WHEN 0 =>
      spi_result <= version_register;
    WHEN 1 =>
      spi_result <= bytes_remaining;
    WHEN 2 =>
      spi_result <= irq_outstanding;
      irq_clear_sig <= NOT irq_clear_ack;
      counter <= 0;
    WHEN 3 =>
      spi_result <= measured_value (counter);
      counter <= counter + 1;
    WHEN 4 =>
      counter <= spi_written_value;
    END CASE;
  END IF;
END IF;

In this example, reading different register addresses should return different values, so clearly a multiplexer is required. Some values stored in latches are also clearly going to be needed.

But: there's quite a bit more to it than that. Reading the interrupt flag at address 2 also has the effect of clearing the flag and resetting a counter, so the design also requires a comparator and some reset logic for the counter. The counter also increments every time a result is read, so we need an adder, and it can also be directly updated by writing another register address.

Trying to work out the underlying building blocks required to implement this rapidly gets out of hand, but thankfully that's the job of the synthesis tool. I only need to be vaguely aware that X number of bits need to be preserved from one clock to the next, so I can estimate the logic usage of the design - and only then if it's big enough compared to the capacity of the chip for that to even possibly be an issue.

When I created a 64 bit processor on my FPGA, I described each and every one of those IC he has on that board and described how to wire them together using HDL. The HDL then interpreted what I described, synthesized it, and wired the transistors of the FPGA to create those IC and connections that it interpreted.

Oh, my. I do hope that something has got lost in translation somewhere, because describing individual discrete ICs (ie. standard, low level logic functions) and then joining them up is a terrible, terrible way to program an FPGA. HDL allows us to describe what we actually want a device to do, not how we think the thing we want could be built up out of basic logic elements.

[chris_leyson]

Oh, my. I do hope that something has got lost in translation somewhere, because describing individual discrete ICs (ie. standard, low level logic functions) and then joining them up is a terrible, terrible way to program an FPGA. HDL allows us to describe what we actually want a device to do, not how we think the thing we want could be built up out of basic logic elements.

I once described the Cinematronics CPU as a bunch of individual TTL ICs for a simulation test bench but gave up trying to write a behavioral model as it was just taking far too long. Ended up turning the simulation model into something that could be synthesized and it worked. I totally agree it's the wrong approach but it was quick and dirty and just for fun.

[Bruce Abbott]

When you design using HDL, you're describing the behavior of the finished design in terms of what you want it to do. The synthesis tool might infer the need for multiplexers and D-types, but that's not the way the designer has to think. We're a level abstracted.

When designing any logic circuit you should start out with what you want it to do. HDL just skips the boring part of having to decide what gates to use and how to wire them.

describing individual discrete ICs (ie. standard, low level logic functions) and then joining them up is a terrible, terrible way to program an FPGA.

It has one valid use - converting an existing discrete design. But for a new design it's working backwards. The purpose of HDL is to avoid having to describe the circuit at individual gate level. Being aware of what type of logic circuit you are creating is good, but trying to reproduce specific 'discrete' logic chips is unnecessarily limiting. Unfortunately many tutorials start out by doing that, presumably to give the student something they are familiar with (not a bad thing in itself, by may give a wrong impression of how best to create a design).

However as a rank beginner who so far has only used WinCUPL - and tried to understand VHDL - the main problem I have is getting to grips with the language itself. Most of the tutorials I have tried  threw in new concepts without adequate explanation, and assumed you will pick up clues to the required syntax just by looking at examples. The result is I can read a piece of VHDL code and almost understand what is going on, but little details trip me up.

[AndyC_772]

It has one valid use - converting an existing discrete design. But for a new design it's working backwards.

I can see that there might be justification for working this way if:

• a known working design already exists, and
• the new design must be a drop-in functional equivalent of the existing one, and
• it must be formally proved, for some reason, that the new functionality exactly replicates the old under all conditions

Then I can see an argument for building a new HDL design based on existing circuits. In any other case, I do think that describing the desired behaviour is the way to go.

the main problem I have is getting to grips with the language itself. Most of the tutorials I have tried  threw in new concepts without adequate explanation, and assumed you will pick up clues to the required syntax just by looking at examples. The result is I can read a piece of VHDL code and almost understand what is going on, but little details trip me up.

There's a lot to be tripped up on, especially if you try to read VHDL the same way as you might try to read and interpret a sequentially executed language that runs on a microprocessor. Most of us do, of course, because it's entirely natural to read it from top to bottom, and in some instances things which happen towards the end of the source file (note: most definitely not "later" in the file!) do take precedence over things which happen nearer the beginning (not "earlier"!).

The complete absence of any correlation between time of execution, and position in the source file, can easily do anyone's head in.

I'm not sure there's an easy way round this, other than asking questions when you get stuck - sorry.

[Cerebus]

It has one valid use - converting an existing discrete design. But for a new design it's working backwards.

I can see that there might be justification for working this way if:

• a known working design already exists, and
• the new design must be a drop-in functional equivalent of the existing one, and
• it must be formally proved, for some reason, that the new functionality exactly replicates the old under all conditions

Then I can see an argument for building a new HDL design based on existing circuits. In any other case, I do think that describing the desired behaviour is the way to go.

Lest we forget, this is the very reason that VHDL exists. The US Department of Gung-ho and Killin' Furruners found that it was increasingly relying on systems full of VLSI chips that might disappear from the supply chain before the weapons system they were in reached end-of-life. They wanted a way of formally documenting chip designs to allow them to re-create these chips as necessary to keep systems in operation. The use of HDL as primary design tool and fodder for synthesis came later.

I'm not sure there's an easy way round this, other than asking questions when you get stuck - sorry.

You can make it less painful by picking Verilog instead of VHDL. [fx: ducks]

[AndyC_772]

I've been doing a new FPGA design from scratch all this week. It's now beer o'clock on Friday evening and I'm completely frazzled. Every time I close my eyes I see traces wiggling in ModelSim.

Does it really show that badly? 

[nctnico]

However as a rank beginner who so far has only used WinCUPL - and tried to understand VHDL - the main problem I have is getting to grips with the language itself. Most of the tutorials I have tried  threw in new concepts without adequate explanation, and assumed you will pick up clues to the required syntax just by looking at examples. The result is I can read a piece of VHDL code and almost understand what is going on, but little details trip me up.

IMHO one of the problems of VHDL is that many don't know how to really take advantage of it and do stupid things like using the std_logic_vector for all multi-bit signals and/or describe logic instead of functionality. That leads to longwinded incomprehensible code very quickly. Above all VHDL is a parallel programming language. Treat it as such and you will discover it has great power.

[NorthGuy]

There's a lot to be tripped up on, especially if you try to read VHDL the same way as you might try to read and interpret a sequentially executed language that runs on a microprocessor. Most of us do, of course, because it's entirely natural to read it from top to bottom, and in some instances things which happen towards the end of the source file (note: most definitely not "later" in the file!) do take precedence over things which happen nearer the beginning (not "earlier"!).

They do happen earlier (or later). However, the things in VHDL don't happen at run time (as in C, for example), they happen at compile (synthesis) time. VHDL is more like Basic where interpreter reads the code and executes it immediately. The circuit being built is the result of this execution.

This is completely different from traditional languages (such as C) where the compiler builds a program, but doesn't execute it. The program executes later at run time.

[AndyC_772]

That's not a distinction I'd have made. BASIC and C may normally be processed into op-codes using different methods, but it's physically possible to compile BASIC and to interpret C if you were so inclined. Regardless of how each is parsed and processed, they both represent a set of instructions to be executed one at a time in a particular order.

Not so with VHDL. The example I like to use is the classic 'how not to swap two values' example found in beginner level textbooks:

Code: [Select]

a <= b;
b <= a;

We're all familiar with how this fails to work. The first assignment makes a equal to b, and the previous value of a is lost forever. The second assignment makes b equal to a, which it was already. Both end up equal to the original value of b.

In VHDL that's not the case. Put these signal assignments into a clocked process, and they do indeed switch values, because the meaning is quite different. "a <= b" means "signal a must, at a time a very short distance in the future, take the value which signal b has right now".

Since no time elapses between one line of code and the next, both signals do indeed switch.

Moreover, it doesn't matter in which order these two lines are written, the meaning is identically the same thing regardless.

However: the order in which commands are placed does affect their precedence in the event of a conflict. For example:

Code: [Select]

a <= b;
a <= a;

...has absolutely no effect whatsoever. The value of a remains completely unchanged, because the later assignment ('a' in the future takes the value of whatever 'a' is right now) simply overrides the earlier one. Synthesize this code, and precisely no FPGA resources at all will be required. There certainly won't be a glitch on the output, as there would be if a similar sequence of operations were to be carried out in order by a microprocessor.

I use this type of construct a lot when dealing with FIFOs. For example:

Code: [Select]

fifo_we <= '0';

IF <interesting set of conditions> THEN
  fifo_data <= new_data_value;
  fifo_we <= '1';
END IF;

This ensures that the FIFO is only ever advanced when there really is new data, and under no other possible conditions.

[nctnico]

I don't like to rely on how expressions are ordered. It will confuse people who are less familiar with VHDL and thus it costs time in the long run. For similar reasons I avoid certain constructs in C like the comma operator.

As a rule I code VHDL in a way so a signal assignment has a single condition. Sometimes this makes things harder at first but after some thinking about what I'm trying to achieve it usually results in less lines of code and a solution which is much easier to follow.

[rstofer]

However as a rank beginner who so far has only used WinCUPL - and tried to understand VHDL - the main problem I have is getting to grips with the language itself. Most of the tutorials I have tried  threw in new concepts without adequate explanation, and assumed you will pick up clues to the required syntax just by looking at examples. The result is I can read a piece of VHDL code and almost understand what is going on, but little details trip me up.

IMHO one of the problems of VHDL is that many don't know how to really take advantage of it and do stupid things like using the std_logic_vector for all multi-bit signals and/or describe logic instead of functionality. That leads to longwinded incomprehensible code very quickly. Above all VHDL is a parallel programming language. Treat it as such and you will discover it has great power.

Most, if not all, entry level tutorials will use std_logic_vector rather than unsigned and that's how folks get started using std_logic_arith.all in order to implement counters or add vectors.  OTOH, the more pedantic approach of using unsigned simply means that I spend a lot of time writing casts between the types. 

As an example, I can't write the 32 bit unsigned output of an adder to a BlockRam (just to contrive an example) because the BlockRAM, over which I have no control of the definition, expects std_logic_vector.

http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

And, yes, I am moving toward unsigned but I sure don't know why.

[rstofer]

I don't like to rely on how expressions are ordered. It will confuse people who are less familiar with VHDL and thus it costs time in the long run. For similar reasons I avoid certain constructs in C like the comma operator.

Assuming that the code above (FIFO) was part of a larger FSM, the choice is to define a default condition for fifo_we and then override it when necessary or define it at every single state which is a lot of useless typing.

I have been recommending the default value throughout this topic and this is another example where it applies.

Different people use different styles.  I don't shy away from the C comma operator if it means I can avoid an 'else' block containing just a single line.

Again, different styles...

[nctnico]

However as a rank beginner who so far has only used WinCUPL - and tried to understand VHDL - the main problem I have is getting to grips with the language itself. Most of the tutorials I have tried  threw in new concepts without adequate explanation, and assumed you will pick up clues to the required syntax just by looking at examples. The result is I can read a piece of VHDL code and almost understand what is going on, but little details trip me up.

IMHO one of the problems of VHDL is that many don't know how to really take advantage of it and do stupid things like using the std_logic_vector for all multi-bit signals and/or describe logic instead of functionality. That leads to longwinded incomprehensible code very quickly. Above all VHDL is a parallel programming language. Treat it as such and you will discover it has great power.

Most, if not all, entry level tutorials will use std_logic_vector rather than unsigned and that's how folks get started using std_logic_arith.all in order to implement counters or add vectors.  OTOH, the more pedantic approach of using unsigned simply means that I spend a lot of time writing casts between the types. 

As an example, I can't write the 32 bit unsigned output of an adder to a BlockRam (just to contrive an example) because the BlockRAM, over which I have no control of the definition, expects std_logic_vector.

http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

And, yes, I am moving toward unsigned but I sure don't know why.

That is why you should use std_numeric. Basic rule: if it is a number then use the types signed and unsigned. And don't infer blockrams (or any other primitives). Just create an array and the synthesizer will decide whether to use blockrams or other resources.

Then you can do stuff like this to read data from a memory:

Code: [Select]

if rising_edge(clk)
  a <= ram_data(read_pointer);
end if;


[AndyC_772]

I like the general approach of having the usual, most likely value of a signal be defined as a default, then have the code describe those things which are interesting or noteworthy under various conditions.

The FIFO example is one which works well. Another might be a counter, which increments on every clock edge except when some event causes it to reset to zero. You could end up with a lot of paths through a FSM all of which boil down to "do something interesting, and yes, don't forget to increment the bl**dy counter".

[NorthGuy]

"a <= b" means "signal a must, at a time a very short distance in the future, take the value which signal b has right now".

What do you mean by "right now?"

[rstofer]

That is why you should use std_numeric. Basic rule: if it is a number then use the types signed and unsigned. And don't infer blockrams (or any other primitives). Just create an array and the synthesizer will decide whether to use blockrams or other resources.

I don't usually infer BlockRams, I instantiate them and, more often than not, specify the initial contents.  Furthermore, it is easy to initialize contents post bit file generation by using Xilinx's data2mem utility.  This means I don't need to re-synthesize or rerun place/route just to test a different program (assuming a CPU project).

At one time, I was specifying the contents in the .ucf file simply because it eliminated having to re-synthesize.  Later on I ran across data2mem and now I don't even need to place/route or generate the bitfile.

These days, playing with the Lattice toolchain, it seems simpler to use their IPexpress to create the memory block and attach a filename for the contents.  Unfortunately, this implies I will have to re-synthesize to update the contents.  I'm not too sure what to think about that.  The good news is that I am only messing around with the Lattice MachXO3 board.  I'll spend most of my time in the Xilinx world.

[AndyC_772]

"a <= b" means "signal a must, at a time a very short distance in the future, take the value which signal b has right now".

What do you mean by "right now?"

I mean, at the precise instant when either:

a) an active clock edge occurs, or
b) at the time when a signal in a process's sensitivity list changes state, causing the process to (for want of a better term) execute.

For example:

Code: [Select]

IF rising_edge (clk) THEN
  b <= a;
  a <= b;
END IF;

...causes the values stored in registers 'a' and 'b' to switch places at the precise time when a rising edge of the clock occurs.

In a real device, there are of course propagation delays to consider, so the values will actually switch a few nsec after the edge. Nevertheless, the meaning of the code is unambiguous, and the synthesis tool will work out the necessary layout to make the real logic behave correctly, including any signals which depend on those which have just been assigned.

[nctnico]

Nitpicking mode: For synchronous processes it will work but for asynchronous processes (depending on other signals than a clock) it will result in a mess and the synthesizer won't be able to do anything about it. You can't rule out the nature of the FPGA fabric entirely so signals won't arrive at the same time.

[NorthGuy]

What do you mean by "right now?"

I mean, at the precise instant when either:

a) an active clock edge occurs, or
b) at the time when a signal in a process's sensitivity list changes state, causing the process to (for want of a better term) execute.

You relate your time to the events which are going to happen on FPGA when you run your program. From this timing viewpoint, VHDL looks weird and non-sequential, which might be a cause of confusion. To see the sequence in VHDL, try to relate to the time when the VHDL compiler goes through your VHDL code.

Imagine, you're building a circuit from ICs on the breadboard. You have inserted the ICs and now you need to connect some wires. You will do this sequentially, but the exact sequence doesn't really matter - you can do it in any order as soon as the end result is the same. The sequence of connecting wires has nothing to do with the sequence of events which will transpire in the circuit when you turn it on.

Same with VHDL. As the VHDL reads your code, it connects wires accordingly (or do other changes to the circuit being buit). These operations are perfectly sequential. But there's no direct relation between the sequence of VHDL statements and the sequence of events in FPGA.

For example, look at the following VHDL code:

Code: [Select]

process(clk)
begin
  if rising_edge(clk) then
    -- Connect 7 wires to produce a shift
    for i in 0 to 6 loop
      a(i) <= a(i+1);
    end loop;
    -- Right Now the 8-th wire is still unconnected, so connect it
    a(7) <= a(0);
  end if;
end process;

Here VHDL goes through the "for" loop, making a single connection on every pass. This loop exists only in VHDL - nothing is going to loop in FPGA. The "i" variable will not exist in FPGA neither. The words "Right Now" in the comment refer to the time during the process of connecting wires (building circuit). This time point will not exist in FPGA. If you look at it this way, VHDL looks perfectly sequential. That's how I look at it.

[BrianHG]

"a <= b" means "signal a must, at a time a very short distance in the future, take the value which signal b has right now".

What do you mean by "right now?"

This is how I like to think about it.  the '<=' means the logic, or math will be performed once every clock cycle.  It's basically a set of D flipflops.  The variable to the left of '<=' is the outputs of the D flipflops.

So, if we say:

a <= b + c;

This means that the variables 'b' and 'c' go through and addition logic and feed the data inputs of flipflops which creates variable a.  This means at the next clock cycle, the value of a which change to the sum of 'b+c'.

If we say:
a <= a + 1;

This still looks like a simple C or Basic program line.  The inputs of 'a' d flipflops are tied to the output of 'a' flipflops added with 1.  Once again, which each clock, the outputs of a will have a new value.

Now, if we say:
a <= b;
b <= a;

What's going on here is that 'a' data inputs are tied to 'b' flipflop's outputs.  And 'b' data inputs are tied to 'a' data outputs.  Now, since Verilog/VHDL runs all the logic in parallel, when 1 single clock cycle comes, 'a' data in will latch 'b' outputs and 'b' data inputs will latch data 'a' outputs.  This effectively swaps the contents 'a' & 'b' each and every clock.

Now, if we say:
a <= b;
b <= c;
c <= a;

Just follow the above rules and you will see we sort of made a circular 3 word buffer, where every clock, all 3 variables a,b,c move all at once, at every clock, not one after the other.

Now, for that pesky line 'at a time a very short distance in the future'.  This has to do with how fast the clock is going.  If the clock is slower than the time for the wiring and logic gates on the silicon to setup all the data inputs, the formula on the right hand side of the '<=', then when the clock cycles, the output register being set on the left hand side of the '<=' will have the correct results.  If your clock is going too fast, errors in some or all of the bits feeding the data inputs of the d flipflop registers on the left side of the '<=' will have the wrong results.

[BrianHG]

Just as a note to HDL developers VS software developers.  I do develop in both, and I do see how some of my HDL debugging can drive me nuts finding that tiny logic error which always creeps up somewhere in a sophisticated design, and it does take me longer to work with due to compile times for those designs which evolve to large to simulate on a small home setup.  However, I think I thoroughly enjoy the work and effort put into working FPGA just for the raw awesome potential to make anything happen, even at all the costs involved.

How many of you feel this way?
Or, do you go to FPGA just because you have no other choice and would prefer a simple MCU only solution?

[Bruce Abbott]

There's a lot to be tripped up on, especially if you try to read VHDL the same way as you might try to read and interpret a sequentially executed language that runs on a microprocessor... The complete absence of any correlation between time of execution, and position in the source file, can easily do anyone's head in.

I don't have a problem with that. It's obvious that hardware operates sequentially only when it is wired sequentially, and why should the position in the source file matter? 

What I am talking about is stuff like this:-

A VHDL Tutorial from Green Mountain Computing Systems, Inc. introduces you to VHDL with this:-

entity latch is
  port (s,r: in bit;
        q,nq: out bit);
end latch;

The first line indicates a definition of a new entity, whose name is latch. The last line marks the end of the definition. The lines in between, called the port clause, describe the interface to the design. The port clause contains a list of interface declarations. Each interface declaration defines one or more signals that are inputs or outputs to the design.

Each interface declaration contains a list of names, a mode, and a type. In the first interface declaration of the example, two input signals are defined, s and r. The list to the left of the colon contains the names of the signals, and to the right of the colon is the mode and type of the signals. The mode specifies whether this is an input (in), output (out), or both (inout). The type specifies what kind of values the signal can have. The signals s and r are of mode in (inputs) and type bit. Next the signals q and nq are defined to be of the mode out (outputs) and of the type bit (binary). Notice the particular use of the semicolon in the port clause. Each interface declaration is followed by a semicolon, except the last one, and the entire port clause has a semicolon at the end.

That's a lot to take in for your very first exposure to VHDL - a dense paragraph that introduces many new concepts but expects you to infer others (what is the meaning of 'is'? where is whitespace permitted? etc.) 

Then they follow it with this:-

architecture dataflow of latch is
  signal q0 : bit := '0';
  signal nq0 : bit := '1';
begin
  q0<=r nor nq0;
  nq0<=s nor q0;

  nq<=nq0;
  q<=q0;
end dataflow;

The first line of the declaration indicates that this is the definition of a new architecture called dataflow and it belongs to the entity named latch. So this architecture describes the operation of the latch entity. The lines in between the begin and end describe the latch's operation.

What does 'signal' mean in this context? Why is there no mode? What does ':=' mean? Why do we need 'begin'? nq is less than or equal to nq0?

I am currently reading this tutorial, which is making a lot more sense to me so far...
 

[Mattjd]

Now i feel like everything i've learned about HDL is wrong.

[BrianHG]

Now i feel like everything i've learned about HDL is wrong.

I use Verilog to make my life soooo much easier.  Especially if you use a simple single synchronous clock for everything, nothing asynchronous.  Coding this way make very portable designs across all FPGAs and PLDs.  As for the above VHDL example, it twists my head and I avoid it at all cost and wont ever use it.