Heading

wget -r -p -k -U Mozilla URL

Heading 2

This is a paragraph.

Heading 3

This is an emphasis test

Creating the Project

This describes starting the project.

Top-Level File and Pin Assignment

This is some verilog -> stuff.

Put the following Verilog code in “sockit_test.v”.

module sockit_test (
    input CLOCK_50,
    input [3:0] KEY,
    output [3:0] LED
);

endmodule

If you’re not familiar with Verilog, a “module” is a hardware block. In this code, we are simply specifying what the inputs and outputs of the block are. For the top-level module, the inputs and outputs are the pins of the FPGA. For our example, we only need the 4 push button keys, 4 LEDs, and the 50 MHz clock. You can assign the pins on the FPGA to your inputs and outputs by going to “Assignments” -> “Pin Planner” and entering in the following assignments.

Controlling the LEDs

Now that the pins have been assigned, you can start putting together the different modules to make the circuit work. The first module we will make is the one driving the LEDs. We will call it “blinker.v”.

module blinker (
    input clk,
    input [3:0] delay,
    output reg [3:0] led,
    input reset,
    input pause
);

reg [23:0] count = 24'b0;
reg [2:0] pos = 3'b000;
reg running = 1'b1;

always @(pos) begin
    case (pos)
        3'b000: led <= 4'b0001;
        3'b001: led <= 4'b0010;
        3'b010: led <= 4'b0100;
        3'b011: led <= 4'b1000;
        3'b100: led <= 4'b0100;
        3'b101: led <= 4'b0010;
        default: led <= 4'b0000;
    endcase
end

always @(posedge clk) begin
    if (reset) begin
        count <= 24'b0;
        pos <= 3'b000;
        running <= 1'b1;
    end else if (pause) begin
        running <= !running;
    end else if (running) begin
        if (count == 24'b0) begin
            count <= {delay, 20'b0};
            if (pos == 3'b101)
                pos <= 3'b000;
            else
                pos <= pos + 1'b1;
        end else begin
            count <= count - 1'b1;
        end
    end
end

endmodule

The first part of this module should look familiar to you. I am stating that this module takes as input a clock clk, a four-bit delay signal (we treat it as a 4-bit unsigned integer), a reset signal, and a pause signal. The reset and pause signals correspond to two of the push buttons on the board. The output is the 4-bit led output. I have declared this as reg, which stands for register. Verilog requires you to declare as reg anything that could hold state. It turns out that the output won’t actually hold any state, but the Verilog compiler is not clever enough to figure this out. If this confuses you, don’t worry. It will make more sense once I explain the always blocks.

The second part of the module are some internal registers count, pos, and running, which are initialized to 0, 0, and 1, respectively. These registers actually will hold state, unlike the output led register.

The third part of the module are the always blocks. These constructs tell our hardware to perform some operation whenever the signals in the sensitivity list (the stuff inside the parenthesis after the @ sign) change. In the first always block, the sensitivity list is the signal pos, so the operations inside the always block will occur whenever pos changes. Inside this always block is a case statement that maps certain values of pos to certain values of led. You will notice that in everything except the default case, exactly one bit in led is high, corresponding to a lit led. With increasing pos, the lit led goes to the left and then back to the right. Since every possible case of pos has been covered, this always block functions as a combinational circuit. If we had left out a case (say, by getting rid of the default case), the compiler would warn us about inferring a latch. That is, if pos happened to be in a case where the behavior was unspecified, the value of led would keeps its previous value. You can see now why led had to be declared a register even though it isn’t one.

The second always block contains in its sensitivity list, posedge clk. This means that the always block is triggered by the rising edge of clk. Inside the always block is a large nested if statement. Here, we state what values each of the internal registers will take at each cycle. If reset is triggered, we change count, pos, and running back to their original values. If pause is triggered, we toggle the value of running. If we are running, then we are under normal operation, during which we want to regularly increment pos until it reaches 5, at which point we wrap around back to 0. However, we want the incrementing of pos to happen slowly at a controlled speed. We accomplish by initially setting the count variable to the value of delay multiplied by 2²⁰, decrementing until it reaches 0, and then resetting it. The value of pos is then only updated when delay is reset. There is no logic specified for when running is false, so in that case all

Setting the delay

So how do we set the delay variable that the blinker module needs? We’ll have to create a different module. Call it “delay_ctrl.v”.

module delay_ctrl (
    input clk,
    input faster,
    input slower,
    output [3:0] delay,
    input reset
);

reg [3:0] delay_intern = 4'b1000;

assign delay = delay_intern;

always @(posedge clk) begin
    if (reset)
        delay_intern <= 4'b1000;
    else if (faster && delay_intern != 4'b0001)
        delay_intern <= delay_intern - 1'b1; 
    else if (slower && delay_intern != 4'b1111)
        delay_intern <= delay_intern + 1'b1;
end

endmodule

This module takes as input the clock, two control signals faster and slower, as well as a reset signal. The control signals correspond to push buttons. The output is the 4-bit delay which will feed into the blinker. We declare an internal register delay_intern and initialize it to 8, which is the halfway point. This internal register is then assigned to the delay output. In our positive-edge triggered always block, we first check to see if a reset is triggered, in which case we set delay_intern back to 8. If faster is pressed, we reduce the delay. If slower is pressed we increase it. If none of the control signals are high, we maintain state.

Handling the Buttons

In our previous two modules, we assumed that our control signals would be high for exactly one cycle after the keys are pressed. Given the speed of the human finger, this would obviously be impossible if the control signals were tied directly to the keys. Therefore, we need a unit to detect when each key is pressed and set the corresponding control signal high for one cycle. We will call it “oneshot.v”.

module oneshot (
    input clk,
    input [3:0] edge_sig,
    output [3:0] level_sig
);

reg [3:0] cur_value;
reg [3:0] last_value;

assign level_sig = ~cur_value & last_value;

always @(posedge clk) begin
    cur_value <= edge_sig;
    last_value <= cur_value;
end

endmodule

Here, edge_sig is the input from our keys and level_sig is the output for our control signals. The trick here is that we keep two 4-bit registers cur_value and last_value. On each cycle, we read the values of the keys into cur_value and the previous value of cur_value into last_value. The signals from the keys are 0 when pressed and 1 when unpressed, so we want each bit of our output to be high when the current value is 0 and the last value was 1, which is what the assign statement is doing. You may think that I have mixed up the order of cur_value and last_value in the always block. But actually, order does not matter when using the non-blocking <= assignment operator. When using <=, the values being read will always be the values from the previous clock cycle.

Tying it All Together

Finally, we must tie our three components together in our top-level module.

module sockit_test (
    input CLOCK_50,
    input [3:0] KEY,
    output [3:0] LED
);

wire [3:0] key_os;
wire [3:0] delay;
wire main_clk = CLOCK_50;

oneshot os (
    .clk (main_clk),
    .edge_sig (KEY),
    .level_sig (key_os)
);

delay_ctrl dc (
    .clk (main_clk),
    .faster (key_os[1]),
    .slower (key_os[0]),
    .delay (delay),
    .reset (key_os[3])
);

blinker b (
    .clk (main_clk),
    .delay (delay),
    .led (LED),
    .reset (key_os[3]),
    .pause (key_os[2])
);

endmodule

We’ve now expanded our original “sockit_test.v” to connect everything together. We have three internal signals, key_os, delay, and main_clk. These signals are marked wire, which is the opposite of reg. Our modules are tied to these signals using “port mappings”, which are statements of the following form.

module_name instance_name (
    .internal_signal (external_signal),
    .internal_signal2 (external_signal2)
);

The module_name is the name we gave to the module, and instance_name is the name we give to this instance of the module. The instance name doesn’t really matter as long as they are unique within a module. The internal_signal name is just the input/output name given inside the port-mapped module. The external_signal name of the wire in the outer module.

Compiling and Programming

Now that we’ve finished our circuit, we can compile our hardware description and program it onto the FPGA. First, though, let’s do a quick static check to make sure we didn’t screw up somewhere. Run “Analysis and Synthesis” by clicking on the icon with a purple triangle and blue check mark in the tool bar (third from left in below image). Wait for the action to complete. You can watch its progress in the “Tasks” window at the middle left. After it’s finished, inspect the log output in the “Messages” window at the bottom. Make sure it doesn’t have any errors or warnings beyond “Parallel compilation is not licensed and has been disabled”. If you do see warnings or errors, look back at your hardware descriptions and make sure there isn’t a typo. “Analysis and Synthesis” will be useful later on for catching syntax mistakes.

Now that you’ve checked the descriptions, you can run a full compilation by clicking the icon with the purple triangle (second from left in the image). Be prepared to wait a little while. Once the compilation is complete, a file called “sockit_test.sof” should be generated in the “output_files” subdirectory of your project folder. This file contains the configuration you will program into the FPGA.

Before you try to program the FPGA, make sure that the USB Blaster drivers are installed correctly (check the Arch Wiki article at the top for Linux, or this article for Windows). Make sure you have the SoCKit connected to your computer correctly. The USB Blaster port is the microUSB port farthest to the right if the ports are facing toward you.

Once you are sure the drivers are working, open up the programmer by double-clicking on “Program Device” in the “Tasks” window, by clicking on “Tools” -> “Programmer” in the menu, or the Programmer button in the toolbar (second from right in the above image). In the new window, go to “Hardware Setup” and make sure “Currently selected hardware” is set to something like “CV SoCKit”. If you cannot find this selection in the dropdown menu, you may want to check that the board is on, the USB blaster is connected, and the drivers are installed properly. Once you’ve selected the correct hardware, press the “Auto Detect” button in the programmer window. It may ask you to choose your device. Choose “5CSXFC6D6”.

You should now see two devices, 5CSXFC6D6F31 and SOCVHPS. The former is the FPGA, the latter is the ARM processor. Right click on the entry for the FPGA and select “Change File”. Pick the “sockit_test.sof” file that was generated during compilation. Now press start, and the .sof file will be programmed onto the FPGA. If you are successful, the SoCKit will look like the following.

Conclusion

Congratulations, you just programmed an FPGA! In my next post, I will take a look at the ARM processor on the Cyclone V and how to install an operating system on it.

Part 2 ->