In order to make Red Pitaya simulate Knight Rider light sequence we will use Verilog language to write a custom module that will provide logic behind the continuous light sequence. There are two popular hardware description languages: VHDL <\/a>and Verilog<\/a>. We will choose the later since most of the official Red Pitaya FPGA code is written in Verilog and because it is somewhat similar to C programming language which some readers might be familiar with. Once knight_rider<\/em> module will be written we will test it and then incorporate it in the block design we created in the previous project<\/a>. We will also demonstrate how to use the parallel nature of a FPGA to create a double Knight Rider light sequence.<\/p>\n To start off open or create LED blinker project 1 in Vivado as described in the previous post<\/a>. Once the project is opened create a new source file (Project Manager -> Add Sources -> Add or create design sources<\/em>), choose file type: Verilog<\/em> and file name: knight_rider<\/em>. When asked to set modules ports click OK and confirm to use default settings. Open the newly created source file by double clicking on the knight_rider.v<\/em> under Design Sources<\/em> in Sources<\/em> tab.<\/p>\n We are ready to enter our Verilog code. Replace the content of the file with the following code:<\/p>\n At the top of the code we first declare the module’s name knight_rider<\/em> with clk<\/em> as input and 8-bit wide led_out <\/em>as output port.<\/em> Below the module’s declaration we find definition of internal registers. Here, for example, reg<\/em> [3:0] position<\/em> means that position<\/em> is a 4-bit register with reg[3]<\/em> being the most- (MSB) and reg[0]<\/em> being the least-significant bit (LSB). The parameters LEDS_INIT<\/em> and DIR_INIT<\/em> are constants defined at the design level.<\/p>\n Below the internal register definitions one can find the first always@(sensitivity_list)<\/em> block. This procedural block is executed at each change of the signals listed in the sensitivity list. In our case the block will be executed on each positive edge of the clk<\/em> signal. Following the always statement is the begin<\/em>–end<\/em> block where the code is executed sequentially as we are used in the procedural programming. Keep in mind that the code will be ultimately implemented as logic circuits with gates, flip-flops and wires. In the same way there can be several independent circuits on the FPGA we can use several always<\/em> blocks in a module, all running in parallel. A good practice is to write several short procedural blocks, for which it is almost possible to guess their implementation, and then connect them so they perform a task.<\/p>\n Our first always<\/em> block assigns a new value to leds<\/em> and position<\/em> registers at each clock cycle depending on the value of the direction<\/em> register. We use bit-shift operators (>>, <<) to achieve Knight Rider’s sliding effect. In this block we only use non-blocking assignment<\/em> (<=) which assigns the values only when all the right-hand side expressions are evaluated, effectively at the end of the block. In this case the order of assignment is not defined and we should be careful that our code does not depend on that.<\/p>\n The second always<\/em> block is sensitive to any signals in the always block. During the first 8 clock cycles direction of bit-shifts will be towards the left and in the second 8 cycles direction will be towards the right. Since\u00a0position<\/em> is a 4-bit register it will reset to 0 as soon as it will exceed its largest value (15). This will reset and start over the 16-count sequence where two lit LEDs move from one end to the other and back. In the second always<\/em> block we use blocking assignment<\/em> (=) to assign to direction<\/em> register. As the name suggests this will block the execution until the right-hand side of the expression is evaluated and then immediately assign the value to the register on the left-hand side. In this way the register will be updated at the next line in code. Blocking assignment is usually used within the always<\/em> blocks when we want to get a logic circuit made of gates and not latches or flip-flops. It is a good practice not to mix blocking and non-blocking assignments within one always<\/em> block.<\/p>\n The last line in the module uses the third assignment method using an assign<\/em> keyword. This assignment is used to directly wire registers and ports or in our case the subset of bits from the leds<\/em> register to the led_out<\/em> port. Due to the direct wiring any change in the leds<\/em> register will be immediately propagated to the output port.<\/p>\n This was a very quick introduction to some of the Verilog language concepts. To get a more complete introduction there is a number of good\u00a0online tutorials and books that can help you. Some of the links can be found in the Literature section at the end of this post. Now, that we wrote our first module we need to test it.<\/p>\n We will use Vivado’s integrated Simulator<\/em> to test the module\u00a0and\u00a0debug the code. Simulation is done using a new test bench module where we define a time dependent input signals, instantiate the module under test and collect the output signals. To create a test bench module click on Add Sources<\/em> -> Add or create simulation sources<\/em>, then create a file with file type: Verilog and file name: knight_rider_tb.v.<\/em> No ports need to be defined under Define Module dialog.<\/p>\n Once the knight_rider_tb.v<\/em> file is created open it and replace its content with the following code:<\/p>\n The test bench module defines a register called clock<\/em> and 8-bit wire called out.<\/em> After the register and wire declaration we define (on line 8) an instance of knight_rider<\/em> module with a name kr<\/em> and connect register clock<\/em> to knight_rider’s port clk <\/em> and wire out<\/em> to knight_rider’s port led_out<\/em>. Note that we use wire<\/em> for the out <\/em>register since we only need to display it on the Simulator’s waveform graph.<\/p>\n The final part of the test bench module is the initial<\/em> block where we set the initial value of the clock register and then toggle it forever with 1 ns delay specified by #1<\/em> after forever<\/em> keyword. The unit of time and the simulation resolution is defined at the top of the code with the statement: `timescale 1ns \/ 1ps<\/em>.<\/p>\n We are ready to simulate the behavior of our module. Save the test bench file and set it as top by right clicking on the file in the Source tab<\/em> and choose Set as Top<\/em>. Next, we click on Run Simulation<\/em> button on the left hand side of the window and choose Run Behavioral Simulation. <\/em>To properly display the results use View->Zoom in<\/em> or View-><\/em>Zoom fit<\/em> functions to zoom in to the first 50 ns of the simulated waveform. You can also expand wire out<\/em> to see the value of individual bits. We can add internal registers of knight_rider<\/em> module to our waveform by dragging them from knight_rider->kr<\/em> icon under Scopes<\/em> panel to the list of signals at the left-hand side of the black waveform region. In the picture below you can see that we added position<\/em> and direction<\/em> registers. To update the waveform click on Run->Restart<\/em> and Run->Run For …<\/em>\u00a0buttons in the main menu. You can change the format of displayed numbers in the waveform by right clicking on the signal name in the waveform region and choosing for example Radix -> Unsigned Decimal<\/em>.<\/p>\n knight_rider’s simulation waveform<\/p><\/div>\n In Vivado we can also debug our code by inserting breakpoints in Verilog’s code. This can be done by clicking on the empty circles that appear right from the line numbers in Vivado’s text editor. Other debugging functions such as Restart …<\/em>, Run For …<\/em>, Step<\/em>, Break<\/em>, etc.\u00a0can be found in the toolbar or in the Run<\/em> menu. Fore more information on simulation and debugging see Xilinx’s logic simulation tutorial<\/a>.<\/p>\n After inspecting the simulated waveform we happily conclude that the knight_rider<\/em> module performs as expected. We are ready to incorporate it into the block design.<\/p>\n Any module in the Vivado’s source folder can be added to the block diagram by right-clicking on the block design’s white canvas and choosing Add Module …<\/em> Click on the knight_rider<\/em> module and confirm. A new block with RTL icon appears in the block diagram. To incorporate it into the structure we connect clk<\/em> port to the output of xlslice_0<\/em> block and led_out<\/em> port to the led_o<\/em> external port as shown in the figure below. Note that from Vivado 2016.3 util_ds_buf_1<\/em> and util_ds_buf_2<\/em> have to be connected for a successful implementation. We can set the constant parameters of the module by double-clicking on the knight_rider_0<\/em> block and setting the two parameters as shown below.<\/p>\n Knight rider module uses all 8 available LEDs on the Red Pitaya board. To connect the module’s output to all of them we need to change the width of the external led_o<\/em> port from currently 1 to 8 bits. This can be done by setting led_o<\/em> port’s LEFT parameter to 7 under the port properties (select the led_o<\/em> port on the block design and locate properties dialogue at the left-hand side of the IP Integrator<\/em>). In the xlslice_0<\/em> block set both Din From<\/em> and Din Down To<\/em> fields to 23.<\/p>\n The project is ready for synthesis, implementation and generating bitstream. As we learned in the previous project<\/a> copy the bitstream file to the linux home folder on Red Pitaya and write it to the FPGA using<\/p>\n The LEDs on your Red Pitaya should now blink in the famous Knight Rider fashion.<\/p>\n We can make the another Knight Rider light sequence where two sets of light streams move in opposite, mirrored direction. This can be done by adding another instance of the knight_rider<\/em> module to the block design. The input clk<\/em> of the new block is connected to the same clock as the first knight_rider<\/em> module. The outputs of the two modules have to be first joined by a vector logic OR block whose output is then wired to the led_o<\/em> port. As we have learned in the previous project<\/a> the vector logic block can be found under Xilinx’s IP cores (Right click on the white block design canvas and choose Add IP …<\/em>). It will perform a pair-wise logic operation for each pair of elements in the two input vectors. To get a mirrored behavior of the second knight_rider<\/em> block its parameters should be set as<\/p>\n The block design for the Double Knight Rider is shown in the following figure. Note that from Vivado 2016.3 util_ds_buf_1<\/em> and util_ds_buf_2<\/em> have to be connected for a successful implementation.<\/p>\n Double Knight Rider light sequence is a great demonstration of parallel nature of the FPGA. We simply added another instance of the module and connect it to the clock. Both blocks are implemented as separate logic circuits on the FPGA running perfectly in parallel.<\/p>\n The project is again ready for synthesis, implementation and bitstream generation. Enjoy the light show on your Red Pitaya! You can of course change the frequency of the blinking LEDs by changing the parameter in xlslice_0<\/em> block.<\/p>\n In this project we built a simple but nontrivial FPGA application \u2013 Knight Rider Lights, ideal for learning the basic concepts of FPGA programming.\u00a0 In this post we got familiar with Verilog language which we used to create our own module. We tested this module using Vivado\u2019s simulator and finally inserted one or more instances into the block diagram. For the first time we had to think in terms of circuits were wires connect different parts of the system and where different blocks can run independent from each other. This inherent parallelism is one of the reasons why FPGAs are so popular for example in the high-performance computing<\/a>.<\/p>\n In the first two projects FPGA programs were completely determined at the design level, without control during the execution. We will learn in the next project how to interface programmable logic with external signals, for example ADCs, and how to write to and read data from registers on the FPGA using Linux running on the Zynq ARM processor.<\/p>\n![\"knight_rider_img\"](\"https:\/\/antonpotocnik.com\/wp-content\/uploads\/2016\/10\/KnightRiderImg.jpg\")
<\/a><\/p>\nVerilog Module<\/h2>\n
\r\nmodule knight_rider(\r\n input clk,\r\n output [7:0] led_out\r\n );\r\n \r\n parameter LEDS_INIT = 10'b1100000000;\r\n parameter DIR_INIT = 1;\r\n \r\n reg [9:0] leds = LEDS_INIT; \/\/ register for led output\r\n reg [3:0] position = DIR_INIT*8; \/\/ state counter 0-15 \r\n reg direction = DIR_INIT; \/\/ direction indicator\r\n\r\n always @ (posedge clk) \r\n begin\r\n if (direction == 0) begin\r\n leds <= leds << 1; \/\/ bit-shift leds register\r\n end else begin\r\n leds <= leds >> 1; \/\/ bit-shift leds register\r\n end\r\n position <= position + 1;\r\n end\r\n\r\n always @* \/\/ change direction \r\n begin \r\n if (position < 8) begin \/\/ in the second half \r\n direction = 0;\r\n end else begin\r\n direction = 1;\r\n end\r\n end\r\n\r\n assign led_out = leds[8:1]; \/\/ wire output and leds register\r\n \r\nendmodule\r\n<\/pre>\n
Simulation<\/h2>\n
\r\n`timescale 1ns \/ 1ps\r\n\r\nmodule knight_rider_tb();\r\n \r\n reg clock;\r\n wire [7:0] out;\r\n\r\n knight_rider kr (.clk(clock),\r\n .led_out(out)\r\n );\r\n \r\n initial begin\r\n clock = 0;\r\n forever #1 clock = ~clock;\r\n end\r\n \r\nendmodule\r\n<\/pre>\n
![](\"https:\/\/antonpotocnik.com\/wp-content\/uploads\/2016\/10\/knight_rider_2_-1.png\")
<\/a>Block Design<\/h3>\n
\n![\"knight_rider\"](\"https:\/\/antonpotocnik.com\/wp-content\/uploads\/2016\/10\/knight_rider.png\")
<\/a><\/p>\n\r\nLEDS_INIT = "1100000000"\r\nDIR_INIT = 0\r\n<\/pre>\n
\r\ncat \/root\/tmp\/your_bitstream.bit > \/dev\/xdevcfg\r\n<\/pre>\n
Double Knight Rider<\/h2>\n
\r\nLEDS_INIT = "0000000011"\r\nDIR_INIT = 1\r\n<\/pre>\n
![](\"https:\/\/antonpotocnik.com\/wp-content\/uploads\/2016\/10\/knight_rider_2_.png\")
<\/a><\/p>\nConclusion<\/h2>\n