0
\$\begingroup\$

I'm trying to turn on the LED lights on my FPGA Spartan board one at a time until all lights are on and then turn them off in the reverse order. I could easily do this in other OOP languages by making two for loops and slowly change the values in an array with each for loop reversing the other just like in a simple starter Arduino project. However, Verilog executes in parallel therefore I am confused as to how I could make the loops run sequentially. I know that using a blocking and non blocking statements affects the how the code executes but I do not see the correlation to loops.

example:

for (counter = 0; counter < n; counter = counter + 1)
            #7 lights[counter] = 1b'1;
for (counter = n; counter > 0; counter = counter - 1)
            #7 lights[counter] = 1b'0;
\$\endgroup\$
  • 4
    \$\begingroup\$ Verilog is not a programming language, it's a hardware description language. That said, if you're happy with OOP, think about the state of an object, and how it's stored. Those are your hardware registers. Then think about how you would change the values of those registers depending on the state of other signals. \$\endgroup\$ – Neil_UK Mar 12 at 6:20
  • \$\begingroup\$ So if I understand where you are coming from with your explanation, there should be a new state as to where the LED's start going in reverse as depicted in the second for loop? \$\endgroup\$ – Code4life Mar 12 at 6:39
  • \$\begingroup\$ here is an example: forums.xilinx.com/t5/Spartan-Family-FPGAs/… \$\endgroup\$ – Code4life Mar 12 at 7:02
  • 1
    \$\begingroup\$ You make a state machine which advances by one state each time the counter reaches its max count. In state "zero," no LED's are on. In state "one" the first LED is on. In state "two" the first two LED's are on. Etc. So the overflow condition of the timer controls state progress. The state itself controls which LED's are on. \$\endgroup\$ – mkeith Mar 13 at 3:44
  • 1
    \$\begingroup\$ You have to start learning VLSI Design to even understand whatever we answer here sighs \$\endgroup\$ – Mitu Raj Mar 13 at 20:26
2
\$\begingroup\$

A few things to keep in mind about writing HDL:

  1. HDLs are not programming languages. Your code ultimately describes a schematic, it is not executed or interpreted. Whatever code you write has to correspond to some physical element on the target device. Things like nested if statements become AND gates operating on signals that represent the conditions, mathematical and logical operations become the corresponding hardware (adders, subtractors, logic gates, etc.), array operations can become RAMs and ROMs, etc.
  2. Delays are in general not synthesizable. You have to find some other method to create the functionality you are after. Delays can be useful in simulation for various purposes, but they are ignored by the tools when creating the actual FPGA configuration. Some parts have special primitives for performing delays on individual IO pins, but these are very specialized components with delays on the order of nanoseconds, only usable for signals passing through specific IO pins, and must be manually instantiated and configured as necessary (see Xilinx IODELAY).
  3. Loops are shorthand for replicated statements. Loops in HDLs are very limited as the synthesis engine unrolls them. Therefore, you cannot use things like while loops, break and continue, loop limits based on signals, etc. Everything must be constant at synthesis time (module parameters are OK as they are constant during synthesis).

For your application, it would make sense to build some sort of a state machine that can turn the LEDs on and off in a specific sequence, then add some rather large cycle count delays so that the changes are visible.

\$\endgroup\$
1
\$\begingroup\$

I have quite limited knowledge when it comes to Verilog syntax as I'm only writing VHDL but the idea would be the same.

To achieve something like this, you could run a very small state machine. So the first state would turn the lights on in the order you want, once the end condition is reached, change state and turn the lights off again.

\$\endgroup\$
0
\$\begingroup\$

The answers around here are correct, but probably cover the more broader area of how you should approach HDL; I'll try to present a more fast-forward solution.

In OOP, the sequencing of what you type in code is implicit, so generally you have your code being executed in the same order it goes line by line. In HDL, you are working with a much more low-level description, practically writing parts of circuits. So to have something executed in order, you need a synchronizing source, like a clock. And then you'd also need the circuit to know the sequence you want to switch your LEDs in. The easiest way for this is to have an overflowing clock counter and pick its values as conditions at which you operate. So all converges to (considering here that we have 8 LEDs):

// 3-bit counter from 0 to 7 
reg [7:0] lights;
reg [2:0] clk_cnt;
int i;
always @(posedge clk)
begin
  clk_cnt <= clk_cnt + 1;

  for (i = 0; i < 7; i++)
    if (i == clk_cnt)
      lights[i] <= ~lights[i];
end

This will make lights switch their state in sequence one after another. Note that the for-loop here is just to compact the code, in reality it's expanded into 8 "if"s that compare the counter value to lights index.

To expand this into first switching lights on in one order and then switching them off in reverse order, you'd need two different counter values for each lights index, thus twice the counter.

// 4-bit counter from 0 to 15
reg [7:0] lights;
reg [3:0] clk_cnt;
int i;
always @(posedge clk)
begin
  clk_cnt <= clk_cnt + 1;

  for (i = 0; i < 7; i++)
    if ((clk_cnt < 8) && (i == clk_cnt))
      lights[i] <= 1'b1;
    else if ((clk_cnt >= 8) && (i == (15 - clk_cnt))
      lights[i] <= 1'b0;
end

Of course, if the clock you supply here is of high frequency, you won't be able to observe the LEDs. You need to either divide the clock or use a bigger counter.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.