Skip to contentSkip to author details
Michael Earls's Picture

Michael Earls

Michael has been a computer nerd since he was ten years old and he begged his parents to buy him a computer for Christmas. In 1982, he was the proud owner of a TI-99/4A. He's been coding since.

Montgomery, AL, USA (map)

@cerkit
Facebook
175 posts

Welcome our newest author on cerkit.com - Jeff Tyler

Written by Michael Earls

We have a new author on the Cerebral Kitchen - Jeff Tyler. Jeff is a professional software developer and will be contributing to the site with more of the same topics you're already used to.

Jeff's first two articles have been posted:

Creating a calendar control with Aurelia part 1

Creating a calendar control with Aurelia part 2

Please welcome Jeff to the site. I look forward to his contributions.

I will still be writing for the site, so look for more from me, as well.

Have a great day.

Michael Earls

ASP.NET Core, JWT Tokens, and the User.Identity.Name property - A Discovery

Written by Michael Earls
 ASP.NET  programming  .NET Core

I've been working on creating a token-based auth system and I wanted to write about a discovery that I made. I've been following the excellent ASP.NET Core Token Authentication Guide.

I was able to get everything up and running as suggested in the guide, but when I accessed the User.Identity.Name property, it was null. I was hoping to find the Name of the user there, but it wasn't. After some exploration, I was able to determine the solution. You simply add the following code in Startup.cs. I added this to the TokenValidationParameters area as outlined in the Guide.

var tokenValidationParameters = new TokenValidationParameters
{
    // Ensure that User.Identity.Name is set correctly after login
    NameClaimType = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",

    ... Existing code here ...

};

If you want to use a different claim as your User.Identity.Name, then use that claim name instead of the XmlSoap schema above. We're actually not using username, we're using an Id number that identifies the user.

My Second Gundam Model Build - Barbatos Lupus

Written by Michael Earls
 hobbies  Gundam  Gunpla  models

I just finished building the Gundam Barbatos Lupus (021) kit from Bandai. It costs me $12 on Amazon and I spent about three hours total building it.

I finally see the differences in the models as this one was a much different experience than my first model.

This model is a little more stiff and doesn't have the same articulation variability as the Try Burning Gundam does.

However, it has a cool sword that it can hold.

Also, there are a lot more areas that require panel lining on this model. None of my pictures have the panel lining in them (yet), but I've been adding a little here and there since taking the photos. I may update this post with some panel lining after shots.

It's all about the quiet time

Once again, I really enjoyed the quiet time building this model. I woke up early on a Saturday and Sunday and worked on it in the silence of the morning. It was a very relaxing activity. It's amazing that these models require no glue (so far). I did add cement to the side of the head of my first model in an attempt to cover a seam line, but it didn't work. There's no glue or cement in this model.

Low standards for appearance

I'm also not cleaning or painting my models to any particular high specification. I'm currently just satisfied with having an assembled model. It's easy to see areas where I need to clean the edges on the model. I'm also not going to paint these models just yet as I'm not sure I want to go that deep into the hobby yet. I also used the supplied decals. A lot of really good model builders on YouTube don't use the decals, but paint the model instead. I'm not ready for that at this point.

Summary

All in all, this has been a fun hobby. I have to admit that I was a bit reluctant to start building this one right before I started, but once I got through the first few steps, I started enjoying it again.

I may buy a higher grade model in the near future (more parts and longer build times), but I still have a few High Grade models on my list at Amazon.

Build photos

Box art Box Art

Head Head

Head (side view) Head (side view)

Head (with eyes visible) Head (with eyes visible)

Upper body Upper body

Back of upper body Back of upper body

Legs Legs (I forgot a panel on the back of the left leg when this photo was taken).

Assembled upper body Assembled upper body

Here are some pictures of the model after I did some panel lining:

Panel Lining 1

Panel lining 2

Panel lining 3

Panel lining 4

Panel lining 5

Strange VGA Effects on an FPGA

Written by Michael Earls
 electronics  FPGA

When I assembled my VGA implementation on my Mojo FPGA, I did so with only a single wire for each of the color signals (Red, Green, and Blue). This limited my color choices to 8 colors. I read about using Pulse width modulation to send other values to a wire, so I gave it a try. The results were interesting, but not what I was looking for.

Here is a video of the results:

Here is my VHDL code:

----------------------------------------------------------------------------------  
-- Company: 
-- Engineer: 
-- 
-- Create Date:    04:37:23 05/27/2017 
-- Design Name: 
-- Module Name:    img_gen - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description: 
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;  
use IEEE.STD_LOGIC_1164.ALL;  
use IEEE.STD_LOGIC_ARITH.ALL;  
use IEEE.STD_LOGIC_UNSIGNED.ALL;


entity img_gen is  
     Port ( clk : in STD_LOGIC;
                x_control : in STD_LOGIC_VECTOR(9 downto 0);
                paddle : in STD_LOGIC_VECTOR(9 downto 0);
                y_control : in STD_LOGIC_VECTOR(9 downto 0);
                video_on : in STD_LOGIC;
                rgb : out STD_LOGIC_VECTOR(2 downto 0));
end img_gen;

architecture Behavioral of img_gen is

signal  PWM_R_Accumulator : std_logic_vector(8 downto 0);  
signal  PWM_G_Accumulator : std_logic_vector(8 downto 0);  
signal  PWM_B_Accumulator : std_logic_vector(8 downto 0);

--wall
constant wall_l:integer :=10;--the distance between wall and left side of screen  
constant wall_t:integer :=10;--the distance between wall and top side of screen  
constant wall_k:integer :=10;--wall thickness  
signal wall_on:std_logic;  
signal rgb_wall:std_logic_vector(23 downto 0); 

--bar
signal bar_l, bar_l_next: integer:=100;  
constant bar_t:integer :=420;--the distance between bar and top side of screen  
constant bar_k:integer :=10;--bar thickness  
constant bar_w:integer:=120;--bar width  
constant bar_v:integer:=10;--velocity of the bar  
signal bar_on:std_logic;  
signal rgb_bar:std_logic_vector(23 downto 0); 

--ball
signal ball_l,ball_l_next:integer :=100;--the distance between ball and left side of screen  
signal ball_t,ball_t_next:integer :=100; --the distance between ball and top side of screen  
constant ball_w:integer :=20;--ball Height  
constant ball_u:integer :=20;--ball width  
constant x_v,y_v:integer:=3;-- horizontal and vertical speeds of the ball  
signal ball_on:std_logic;  
signal rgb_ball:std_logic_vector(23 downto 0); 

--refreshing(1/60)
signal refresh_reg,refresh_next:integer;  
constant refresh_constant:integer:=830000;  
signal refresh_tick:std_logic;

--ball animation
signal xv_reg,xv_next:integer:=3;--variable of the horizontal speed  
signal yv_reg,yv_next:integer:=3;--variable of the vertical speed

--x,y pixel cursor
signal x,y:integer range 0 to 650;

--mux
signal vdbt:std_logic_vector(3 downto 0);

--buffer
signal rgb_reg:std_logic_vector(2 downto 0);  
signal rgb_next:std_logic_vector(23 downto 0);

begin

--x,y pixel cursor
x <=conv_integer(x_control);  
y <=conv_integer(y_control );

--refreshing
process(clk)  
begin  
     if clk'event and clk='1' then
          refresh_reg<=refresh_next;
     end if;
end process;  
refresh_next<= 0 when refresh_reg= refresh_constant else  
refresh_reg+1;  
refresh_tick<= '1' when refresh_reg = 0 else  
                           '0';
--register part
process(clk)  
begin  
     if clk'event and clk='1' then
         ball_l<=ball_l_next;
         ball_t<=ball_t_next;
         xv_reg<=xv_next;
         yv_reg<=yv_next;
         bar_l<=bar_l_next;
      end if;
end process;

--bar animation
process(refresh_tick,paddle)  
begin

    if refresh_tick= '1' then
       bar_l_next<= conv_integer(paddle);
    end if;
end process;

--ball animation
process(refresh_tick,ball_l,ball_t,xv_reg,yv_reg)  
begin  
     ball_l_next <=ball_l;
     ball_t_next <=ball_t;
     xv_next<=xv_reg;
     yv_next<=yv_reg;
     if refresh_tick = '1' then
        if ball_t> 400 and ball_l > (bar_l -ball_u) and ball_l < (bar_l +120) then --the ball hits the bar
           yv_next<= -y_v ;
       elsif ball_t< 35 then--The ball hits the wall
           yv_next<= y_v;
       end if;
       if ball_l < 10 then --The ball hits the left side of the screen
          xv_next<= x_v;
       elsif ball_l> 600 then 
          xv_next<= -x_v ; --The ball hits the right side of the screen
       end if; 
       ball_l_next <=ball_l +xv_reg;
       ball_t_next <=ball_t+yv_reg; 
    end if;
end process;

--wall object
wall_on <= '1' when x > wall_l and x < (640-wall_l) and y> wall_t and y < (wall_t+ wall_k) else  
                      '0'; 
rgb_wall<=x"010101";--Black  
--bar object
bar_on <= '1' when x > bar_l and x < (bar_l+bar_w) and y> bar_t and y < (bar_t+ bar_k) else  
                    '0'; 
rgb_bar<=x"0000F1";--blue

--ball object
ball_on <= '1' when x > ball_l and x < (ball_l+ball_u) and y> ball_t and y < (ball_t+ ball_w) else  
                     '0'; 
rgb_ball<=x"00F100"; --Green


--buffer
process(clk)  
begin  
    if clk'event and clk='1' then      
      PWM_R_Accumulator  <=  ("0" & PWM_R_Accumulator(7 downto 0)) + ("0" & rgb_next(23 downto 16));
        PWM_G_Accumulator  <=  ("0" & PWM_G_Accumulator(7 downto 0)) + ("0" & rgb_next(15 downto 8));
        PWM_B_Accumulator  <=  ("0" & PWM_B_Accumulator(7 downto 0)) + ("0" & rgb_next(7 downto 0));
    end if;
     if clk'event and clk='1' then
         --rgb_reg<=rgb_next;

     end if;
end process;

--mux
vdbt<=video_on & wall_on & bar_on &ball_on;  
with vdbt select  
     rgb_next <= x"FFAAAA" when "1000",--Background of the screen is red 
     rgb_wall when "1100",
     rgb_wall when "1101",
     rgb_bar when "1010",
     rgb_bar when "1011",
     rgb_ball when "1001",
      x"000000" when others;
--output

rgb<=PWM_R_Accumulator(8) & PWM_G_Accumulator(8) & PWM_B_Accumulator(8);

end Behavioral;

I added three new signals for the PWMs. One PWM per color. Those are defined starting on line 37. Once those were defined, I then set the colors on the objects on the screen (the wall, the ball, the paddle, and the background). That code starts on line 149 (colors are defined in hexadecimal).

I then defaulted the color to red for things that didn't have a setting (line 178).

On line 187, I set the output of the VGA wires to the most significant bit of the PWM accumulators.

The idea was that the PWM would send a different color to the monitor. I really don't know how (or even if) I can fix it, but the results are interesting.

After watching the video below, I learned that this is a hardware issue. I need to build out the different resistance values to handle each of the bits with a gpio pin on the FPGA.

Here is a 12-bit schematic that I'm going to try next.

12-bit color VGA schematic (image source: https://electronics.stackexchange.com/questions/228825/programming-pattern-to-generate-vga-signal-with-micro-controller)

My First Gundam Plastic Model (Gunpla) - "Try Burning Gundam"

Written by Michael Earls
 Gundam  Gunpla  models  hobbies

After working with electronics for awhile, I wanted to take a break from puzzles and try something new that requires less thinking (and less math). I decided that I wanted to build plastic models. After looking around local hobby shops, all I could find were cars, airplanes, and a few Star Wars snap-tites.

Then, while browsing YouTube, I found what I was looking for: Gundam Mobile Suit plastic models; "Gunpla" for short. I watched a lot of videos from some master Gunpla builders and learned some cool tricks.

The models come in different "grades" that indicate how difficult they are to assemble. I chose to go with High Grade (HG). That's the lowest grade and the easiest to assemble.

My birthday was last week and I received my first Gunpla model as a present. To get started in the hobby, I really only needed a few things: X-Acto hobby knife, nail files of various coarseness, and some liquid cement. I already had the precision tweezers and side cutters from my electronics hobby.

I started the model at around 6:00 AM this morning and finished up around 9:30. It was very relaxing to just follow the instructions and build the model. Once assembled, the model is pose-able and has a lot of points of articulation.

Here are photos that I took at various points along the way.

Chest area Chest area

Right Arm Right Arm

Work Area Work Area

Head (without forehead decal) Head (without forehead decal)

Right Leg Right Leg

Completed Model Completed Model

Completed Model Closeup Completed Model Closeup

I really enjoyed assembling this model. I'm looking forward to the next model.

I haven't added any effects or panel lining yet (lines around the edges of the "panels" on the model). I'm not sure if I'm comfortable trying to do panel lining on my first model. Maybe I'll do it in the future.

Update: I decided to add panel lining to my model. It makes it look much better. The details really shine! Here's a sample from the waist area:

Panel Lining Panel Lining

A Saturday morning puzzle on my FPGA

Written by Michael Earls
 FPGA  electronics  hobbies

I woke up this morning with a desire to solve a puzzle. I decided that I'd make a simple LED chaser on a 7-segment LED display using my Mojo FPGA (now that I have everything working in Windows 10 again thanks to the awesome customer support from Justin at Embedded Micro).

Here's a video of the results:

Here is a breadboard image showing how I've wired up the circuit:

Mojo 7-segment chaser breadboard circuit

Here's my constraints file that shows the wiring of the 7-segment display:

NET "seg<0>" LOC = P51 | IOSTANDARD = LVTTL;  
NET "seg<1>" LOC = P50 | IOSTANDARD = LVTTL;  
NET "seg<2>" LOC = P41 | IOSTANDARD = LVTTL;  
NET "seg<3>" LOC = P40 | IOSTANDARD = LVTTL;  
NET "seg<4>" LOC = P35 | IOSTANDARD = LVTTL;  
NET "seg<5>" LOC = P34 | IOSTANDARD = LVTTL;

Update (8:00 PM): I was able to reach my goal and pull this off using VHDL instead of Lucid. Here is the entire program (no dependencies required). This is much more precise. I really like VHDL.

library IEEE;  
use IEEE.STD_LOGIC_1164.ALL;  
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity circle_chaser is  
    Port ( clk : in  STD_LOGIC;
             rst_n : in STD_LOGIC;            -- reset button (active low)
             led : out STD_LOGIC_VECTOR (7 downto 0); --8 user controllable LEDs
             cclk : in STD_LOGIC;             -- configuration clock, AVR ready when high
             spi_miso : out STD_LOGIC;       -- AVR SPI MISO
             spi_ss : in STD_LOGIC;           -- AVR SPI Slave Select
             spi_mosi : in STD_LOGIC;         -- AVR SPI MOSI
             spi_sck : in STD_LOGIC;          -- AVR SPI Clock
             spi_channel : in STD_LOGIC_VECTOR (3 downto 0); --AVR general purpose pins (used by default to select ADC channel)
             avr_tx : in STD_LOGIC;           -- AVR TX (FPGA RX)
             avr_rx : out STD_LOGIC;          -- AVR RX (FPGA TX)
             avr_rx_busy : in STD_LOGIC;
             seg : out  STD_LOGIC_VECTOR (5 downto 0)
     );
end circle_chaser;

architecture Behavioral of circle_chaser is

signal clk_div   : std_logic_vector(21 downto 0);  
signal shift_reg : std_logic_vector(5 downto 0) := "000001";

begin  
    led <= X"00";
    spi_miso <= '0';
    avr_rx <= '0';

    -- clock divider
    process (clk)
    begin
      if (clk'Event and clk = '1') then
            clk_div <= clk_div + '1';
      end if;
    end process;

    -- LED chaser
    process (clk_div(21))
    begin
      if (clk_div(21)'Event and clk_div(21) = '1') then
            shift_reg <= shift_reg(4 downto 0) & '0';
            if (shift_reg(5) = '1') then
                shift_reg <= "000001";
            end if;
      end if;
    end process;

    -- display the result on the LEDs
    seg <= shift_reg;

end Behavioral;  

Update (6/18 10:00 AM): I completed the HDL trilogy this morning and implemented this chaser in Verilog. Here is the code:

module mojo_top(  
    // 50MHz clock input
    input clk,
    // Input from reset button (active low)
    input rst_n,
    // cclk input from AVR, high when AVR is ready
    input cclk,
    // Outputs to the 8 onboard LEDs
    output[7:0]led,
    // AVR SPI connections
    output spi_miso,
    input spi_ss,
    input spi_mosi,
    input spi_sck,
    // AVR ADC channel select
    output [3:0] spi_channel,
    // Serial connections
    input avr_tx, // AVR Tx => FPGA Rx
    output avr_rx, // AVR Rx => FPGA Tx
    input avr_rx_busy, // AVR Rx buffer full
     output [5:0] seg
    );

wire rst = ~rst_n; // make reset active high  
reg [22:0] clk_div = 22'b0;

// these signals should be high-z when not used
assign spi_miso = 1'bz;  
assign avr_rx = 1'bz;  
assign spi_channel = 4'bzzzz;

assign led = 8'b0;

parameter REG_INIT = 7'b0000001;

    reg [6:0] shift_reg = REG_INIT; // register for led output

    always @ (posedge clk) 
    begin
        clk_div = clk_div + 1;
        if (clk_div[22] == 1) begin
            clk_div = 0;
            shift_reg = shift_reg << 1;
            if (shift_reg[6] == 1) begin
                shift_reg = REG_INIT;
            end
        end
    end

    assign seg = shift_reg[5:0]; // wire output and leds register

endmodule

I had to take a different approach with the shift register to allow for an additional bit to check to see when to reset the shift register (and mirrored LED segments) back to the start. I made the shift register 1 bit larger (line 36) than the LED segments so I could check to see when the MSB was high and then reset. When the shift register was the same size as the LED segments, it would skip lighting one because it got reset before it could be lit up.

Here is the Lucid code (the Mojo-specific HDL):

  
.clk(clk) {
  .rst(rst) {
    circleChase chase(#SPEED(22));
  }
}

always {  
  seg = chase.out;
}

The chaser was a lot easier to implement than I expected...

module circleChase #(  
    MAX_OUT = 6: MAX_OUT > 2,
    SPEED = 25: SPEED > 0 // the lower the SPEED, the faster the counter
  )(
    input clk,  // clock
    input rst,  // reset
    output out[6]
  ) {

  .clk(clk) {   
    .rst(rst) {    
      slowCount count(#SPEED(SPEED));
    }
  }

  const TOP = MAX_OUT;
  counter outCount(.rst(rst), .clk(count.q), #TOP(TOP - 1));

  always {

    out = 6h0; 

    if(count.q) {
        out[outCount.value] = 1;
    }
  }
}

Notice how the clock to the outCount module on line 17 is coming from the slowCount's .q trigger. This goes high each time the slowCount reaches it's limit (the code for this is at the bottom of this post).

I've covered it before, but for completeness, here is the code for the slowCount module (in Lucid, the Mojo-specific HDL):

module slowCount #(  
      SPEED = 25 : SPEED > 0
    )(
    input clk,  // clock
    input rst,  // reset
    output value[8],
    output q
  ) {

  .clk(clk), .rst(rst) {
    dff flip[SPEED];
  }

  const LIMIT = SPEED - 1;
  counter ctr(.rst(rst));

  always {
    ctr.clk = flip.q[LIMIT];

    // toggle the q bit when the counter reaches each end
    q = flip.q[LIMIT] == 0 ? 0 : 1;

    flip.d = flip.q + 1;
    value = ctr.value;
  }
}

Who am I, really?

Written by Michael Earls
 michael  programming

Due to various circumstances, I recently found myself in the job market again. There was a particular job that emerged that I got very excited about. They cold contacted me through LinkedIn, not knowing that I was even looking for a job.

I had to drive two hours for the first interview, but the job was for working remotely with a little travel. Once in the interview, I noticed that they were asking questions based off of my LinkedIn profile, not off of the resume that I had so carefully crafted to be my own representation of myself.

Honestly, I'm was glad they were using LinkedIn and not my resume because I hate resumes. After working in this industry for over twenty years, the resume that I'm most comfortable with has grown to over six pages long. It's my understanding that it's not supposed to exceed two pages.

So, when I became aware that I was going to have to sell myself again, I created a new resume that was going to be my short version. I even named it "Michael Earls resume 2 page.docx". It's terrible. I still have not found the best way to squeeze over twenty years of knowledge, experience, and wisdom onto just two pages.

During the interview, they asked some good questions about my experience and asked about the projects I had worked on. Remember, this is a job that I really wanted to get as it had to do with industrial automation and that was a field I have been interested in for a very long time.

I finished the interview and felt pretty good about it. Days went by and I never heard anything back. So, I sent an email asking if they had any news. They told me that they were still making a decision.

After a few weeks, I finally just gave up all hope and continued with the other job prospects as normal. Then, out of the blue, I got a call from them asking me to drive up for another interview, this time with the president of the company and other executives. I agreed.

This time, however, I was asked to perform one of those in-depth personality profiles that companies pay for. They were serious and I knew it. I get nervous taking these personality profiles because they make me feel like I'm being analyzed (because I am).

When I got to the interview, it was intense. They were armed with 10 reports about my personality and asked me very pointed questions about who I was and how I would respond to certain scenarios.

During both interviews, I specifically remember telling them that I viewed the work that I do as a creative endeavor. I told them that I see programming as an art form and the act of writing code is like painting a picture.

When asked what my greatest gift was, I said "I make order out of chaos".

Utter bullshit.

I never heard back from them after the second interview, even when I sent an email asking if they had made a decision because I had received another job offer. Personally, I think it was unprofessional to not even tell me that I had not been selected, but each company handles things in their own way.

Going back through the interview, I can remember times when they kept trying to get me back on track. All I had to do was confirm to them that I was the same person from my LinkedIn profile. Nowhere in my career have I ever "painted a picture with code".

I am a software engineer, not an artist. But why did I say those things? What led me to spout off so much untruth?

After some self reflection, I finally realized why I had told them that and why I have had that view of myself since the beginning.

It started in 7th grade.

When I was growing up, I used to draw a lot. I even got in trouble in school for drawing during class to the point where most of my artwork ended up in the trash can (the evil teachers tore it up before placing it there).

I was a huge Iron Maiden fan in Junior High. I loved heavy metal music and I used to draw demons, skeletons, skulls, flames, you get the idea. Iron Maiden's "mascot" is a skeleton with rotting flesh falling from his bones.

I used to emulate that style in my drawings and I drew a lot of it. I also drew post-apocalyptic scenes (much like you see now in The Walking Dead TV show).

One day, there was an announcement that students were encouraged to join the art club. Just show up to the art room after school with some of your drawings to get in. When I knocked on the door, the teacher opened the door, looked at my drawings and said "this is Satanic, you can't be in the art club".

I was deflated. I don't think I've drawn another picture since that day. Yet, somehow, I never stopped thinking of myself as an artist. I originally wanted to go to art school and be a 3-D animator, but that was too expensive and very unrealistic coming from the financial demographic that I come from.

I've somehow been lying to myself all these years that I am an artist, yet nothing that I do is art. It's all engineering and science.

I can imagine that I must come across as a dishonest person when I discuss how I view myself because I have been so clueless for so long.

Now I know who I am, I'm a software engineer and I write code for a living. I don't "paint with code". I solve problems. I am a problem solver and I'm a damn good one.

Pong on the Mojo Revisited

Written by Michael Earls
 FPGA  electronics  programming

In my previous post, I briefly discussed the implementation of a pseudo-pong game on my Mojo FPGA developer board.

I was able to implement the VHDL version that I linked to later in the post and it works much better.

The biggest challenge I had with it was converting the two-button input to a potentiometer input. It turns out all I had to do was convert an array to an integer as input to the paddle's left position.

Here is a link to the article describing the implementation that I used:

FPGA Pong From FPGACenter.com.

The VHDL was a big challenge for me because I had to learn it as I went along. It works just like Verilog, but the syntax is so different.

Also, I modified my User Constraints File to make the RGB an array for compatibility with this particular implementation.

Here are the new custom constraints:

NET "hsync" LOC = P50 | IOSTANDARD = LVTTL;  
NET "vsync" LOC = P51 | IOSTANDARD = LVTTL;  
NET "rgb<2>" LOC = P41 | IOSTANDARD = LVTTL;  
NET "rgb<1>" LOC = P40 | IOSTANDARD = LVTTL;  
NET "rgb<0>" LOC = P35 | IOSTANDARD = LVTTL;

Here is the code containing my changes (in the vga_control and img_gen modules):

vga_control:

library IEEE;  
use IEEE.STD_LOGIC_1164.ALL;  
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity vga_control is  
     Port ( clk : in STD_LOGIC;
                start : in STD_LOGIC;
                reset : in STD_LOGIC;
                paddle : IN STD_LOGIC_VECTOR(9 downto 0);
                rgb : out STD_LOGIC_VECTOR (2 downto 0);
                h_s : out STD_LOGIC;
                v_s : out STD_LOGIC);
end vga_control;

architecture Behavioral of vga_control is

COMPONENT img_gen  
       PORT( clk : IN std_logic;
                     x_control : IN std_logic_vector(9 downto 0);
                     paddle : IN std_logic_vector(9 downto 0);
                     y_control : IN std_logic_vector(9 downto 0);
                     video_on : IN std_logic; 
                     rgb : OUT std_logic_vector(2 downto 0) );
END COMPONENT;

COMPONENT sync_mod  
       PORT( clk : IN std_logic;
                     reset : IN std_logic;
                     start : IN std_logic; 
                     y_control : OUT std_logic_vector(9 downto 0);
                     x_control : OUT std_logic_vector(9 downto 0);
                     h_s : OUT std_logic;
                     v_s : OUT std_logic;
                     video_on : OUT std_logic );
END COMPONENT;

signal x,y:std_logic_vector(9 downto 0);  
signal video:std_logic;

begin  
          U1: img_gen PORT MAP( clk =>clk , x_control => x, paddle => paddle , 
                                                         y_control => y, video_on =>video , rgb => rgb );

           U2: sync_mod PORT MAP( clk => clk, reset => reset, start => start, y_control => y, x_control =>x ,
                                                             h_s => h_s , v_s => v_s, video_on =>video );
end Behavioral;

My changes are on lines 9, 20, and 41. This sends the output from the potentiometer hooked up to the ADC on the Mojo to the img_gen module where it's converted to position data for the paddle control.

Here's the modified img_gen code:

library IEEE;  
use IEEE.STD_LOGIC_1164.ALL;  
use IEEE.STD_LOGIC_ARITH.ALL;  
use IEEE.STD_LOGIC_UNSIGNED.ALL;


entity img_gen is  
     Port ( clk : in STD_LOGIC;
                x_control : in STD_LOGIC_VECTOR(9 downto 0);
                paddle : in STD_LOGIC_VECTOR(9 downto 0);
                y_control : in STD_LOGIC_VECTOR(9 downto 0);
                video_on : in STD_LOGIC;
                rgb : out STD_LOGIC_VECTOR(2 downto 0));
end img_gen;

architecture Behavioral of img_gen is

--wall
constant wall_l:integer :=10;--the distance between wall and left side of screen  
constant wall_t:integer :=10;--the distance between wall and top side of screen  
constant wall_k:integer :=10;--wall thickness  
signal wall_on:std_logic;  
signal rgb_wall:std_logic_vector(2 downto 0); 

--bar
signal bar_l, bar_l_next: integer:=100;  
constant bar_t:integer :=420;--the distance between bar and top side of screen  
constant bar_k:integer :=10;--bar thickness  
constant bar_w:integer:=120;--bar width  
constant bar_v:integer:=10;--velocity of the bar  
signal bar_on:std_logic;  
signal rgb_bar:std_logic_vector(2 downto 0); 

--ball
signal ball_l,ball_l_next:integer :=100;--the distance between ball and left side of screen  
signal ball_t,ball_t_next:integer :=100; --the distance between ball and top side of screen  
constant ball_w:integer :=20;--ball Height  
constant ball_u:integer :=20;--ball width  
constant x_v,y_v:integer:=3;-- horizontal and vertical speeds of the ball  
signal ball_on:std_logic;  
signal rgb_ball:std_logic_vector(2 downto 0); 

--refreshing(1/60)
signal refresh_reg,refresh_next:integer;  
constant refresh_constant:integer:=830000;  
signal refresh_tick:std_logic;

--ball animation
signal xv_reg,xv_next:integer:=3;--variable of the horizontal speed  
signal yv_reg,yv_next:integer:=3;--variable of the vertical speed

--x,y pixel cursor
signal x,y:integer range 0 to 650;

--mux
signal vdbt:std_logic_vector(3 downto 0);

--buffer
signal rgb_reg,rgb_next:std_logic_vector(2 downto 0);

begin

--x,y pixel cursor
x <= conv_integer(x_control);  
y <= conv_integer(y_control );

--refreshing
process(clk)  
begin  
     if clk'event and clk='1' then
          refresh_reg<=refresh_next; 
     end if;
end process;  
refresh_next <= 0 when refresh_reg= refresh_constant else  
refresh_reg+1;  
refresh_tick <= '1' when refresh_reg = 0 else  
                           '0';
--register part
process(clk)  
begin  
     if clk'event and clk='1' then
         ball_l <= ball_l_next;
         ball_t <= ball_t_next;
         xv_reg <= xv_next;
         yv_reg <= yv_next;
         bar_l <= bar_l_next;
      end if;
end process;

--bar animation
process(refresh_tick,paddle)  
begin

    if refresh_tick= '1' then
       bar_l_next <= conv_integer(paddle);
    end if;
end process;

--ball animation
process(refresh_tick,ball_l,ball_t,xv_reg,yv_reg)  
begin  
     ball_l_next <=ball_l;
     ball_t_next <=ball_t;
     xv_next <= xv_reg;
     yv_next <= yv_reg;
     if refresh_tick = '1' then
        if ball_t > 400 and ball_l > (bar_l -ball_u) and ball_l < (bar_l +120) then --the ball hits the bar
           yv_next <= -y_v ;
       elsif ball_t < 35 then--The ball hits the wall
           yv_next <= y_v;
       end if;
       if ball_l < 10 then --The ball hits the left side of the screen
          xv_next <= x_v;
       elsif ball_l> 600 then 
          xv_next <= -x_v ; --The ball hits the right side of the screen
       end if; 
       ball_l_next <= ball_l + xv_reg;
       ball_t_next <= ball_t + yv_reg; 
    end if;
end process;

--wall object
wall_on <= '1' when x > wall_l and x < (640-wall_l) and y> wall_t and y < (wall_t+ wall_k) else  
                      '0'; 
rgb_wall <= "000";--Black  
--bar object
bar_on <= '1' when x > bar_l and x < (bar_l+bar_w) and y> bar_t and y < (bar_t+ bar_k) else  
                    '0'; 
rgb_bar <= "001";--blue

--ball object
ball_on <= '1' when x > ball_l and x < (ball_l+ball_u) and y> ball_t and y < (ball_t+ ball_w) else  
                     '0'; 
rgb_ball <= "010"; --Green

--buffer
process(clk)  
begin  
     if clk'event and clk = '1' then
         rgb_reg <= rgb_next;
     end if;
end process;

--mux
vdbt<=video_on & wall_on & bar_on &ball_on;  
with vdbt select  
     rgb_next <= "100" when "1000",--Background of the screen is red 
     rgb_wall when "1100",
     rgb_wall when "1101",
     rgb_bar when "1010",
     rgb_bar when "1011",
     rgb_ball when "1001",
      "000" when others;
--output
rgb <= rgb_reg;

end Behavioral;

My changes are on lines 10 and 95 to make the potentiometer control the paddle.