Skip to contentSkip to author details

Welcome our newest author on - 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

Creating an Aurelia Bootstrap Calendar Of Events - Part 2 Create a custom element

Written by Jeff Tyler

This is part two of a multi-part tutorial on how to build a bootstrap calendar with Aurelia
Aurelia Calendar Part 1

Aurelia has a built in custom element modeled after web components. This will allow us to create a calendar widget that is isolated and reusable.

First we are going to create a folder called elements
Inside of the folder we will create another folder called calendar and a file called index.ts.
Inside of the calendar folder we will create two files
calendar.html and calendar.ts

We will start with the calendar.ts file. This file is the backing class for the custom element.

we'll break down the pieces and explain what it all is doing.

import { customElement, bindable, inject } from "aurelia-framework";  
import * as moment from 'moment';  
import * as $ from 'jQuery'  
export class Calendar {


import tells it what extra classes we are going to need. If it's typescript then we can just name the class. Most things related to Aurelia is found in the aurelia-framework namespace. We are going to be using the customElement, bindable, and inject classes from aurelia-framework.

IF you are calling a pure JavaScript library then you import it by calling import * as (alias) from where you are getting it. We will be using the Javascript libraries from moment.js and jQuery.

@customElement('calendar') let's Aurelia know that this is going to be a customElement and that when we create an calendar element that we mean this.

@inject(Element) @inject is the Aurelia way of doing dependency injection. Anything in there will be automatically injected into the constructor. Element tells Aurelia to inject the actual Dom element into our constructor.

import { customElement, bindable, inject } from "aurelia-framework";  
import * as moment from 'moment';  
import * as $ from 'jQuery'  
export class Calendar {  
    private today: moment.Moment;

    currentDate: Date;

    private element: Element
    constructor(element: Element) { = moment();
        this.currentDate =;
        this.element = element;

today will hold today's date, so that we could style it differently if we so choose. @bindable tells aurelia to expose the property as an attribute and to allow them to bind to it. currentDate is the date that we will use for creating the calendar. It's basically a placeholder for the month and year.

element is the property to hold the Dom element.
constructor(element:Element) is a type script constructor and gives Aurelia a place to inject the Dom element.
inside the constructor we set today to moment() which creates a moment.Moment object for today's date.
It defaults currentDate to today by getting the date from the moment version. It will be overridden if someone binds the current-date attribute.

Here comes all of the code.

import { customElement, bindable, inject } from "aurelia-framework";  
import * as moment from 'moment';  
import * as $ from 'jQuery'  
export class Calendar {  
    private today: moment.Moment;

    currentDate: Date;

    element: Element
    constructor(element: Element) { = moment();
        this.currentDate =;
        this.element = element;

    private getDisplayDates(): Array> {
        let dates = new Array>();
        let beginning = moment(this.currentDate).startOf('month').startOf('week');
        let currentMonth = this.currentDate.getMonth();
        for (let r = 0; r < 6; r++) {
            let week = new Array();
            for (let i = 0; i < 7; i++) {
                let date = {
                    dayOfWeek: beginning.format('dddd'),
                    darken: beginning.month() != currentMonth,
                    events: []
//                if ((i * r) % 4 == 0) {
//          { name: i.toString() //+ '-' + r.toString() + 'event', amount: i * r + 10 })
//                }
                beginning.add(1, 'days');
        return dates

    attached() {
        let that = this;
        var test = $(".calendarDay", $(this.element)).on('click', function (event) {
            let clickEvent = new CustomEvent('day-click', {
                detail: { value: },
                bubbles: true

Here we added two new methods. getDisplayDates and attached.

getDisplayDates creates an array of arrays of objects used to render the calendar.

beginning turns takes current date and gets the Sunday of the week that the 1st of the month falls on. So for instance for the month of August 2017 it would start at July 30 2017 in the US. If your are localized in a country that has a different start of the week then it will start there instead.

it loops through 6 weeks of 7 days creating an object that holds the date(30,31,1...), the day of week (Monday, Tuesday...) and darken which is a flag for whether the date is within the month held by currentDate.
It also holds an events array used to hold the events to display for that day. Eventually this would be populated by an ajax call for the data.

The commented out section basically creates some dummy data to see what it might look like with events. Uncomment it if you want to get an idea.


Attached is part of the Aurelia life cycle. It is the last chance to act upon an element. Here we are creating a custom event to be bound to when the a particular day is clicked.
let that = this allows us to access the typescript class from withing the jQuery event.

We add a jQuery event onto all of the calendarDays within this element. Then we create a customEvent and dispatch it so that any listeners can act upon it. It passes the Dom element that was clicked to the event.

Creating an Aurelia Bootstrap Calendar Of Events - Part 1 Getting Started and Overriding Bootstrap

Written by Jeff Tyler

I needed a calendar as a centerpiece for an application that I am working on. After looking through the internet for something that I liked and not finding it. I decided to do what all sane programmers do. Build my own. So let's get started. YeeHaw!!
Here are the requirements that I have set for myself, and how I plan to fix it.

  • Must be responsive: for this I am going to use bootstrap. 7 days on a week for a full screen and 2 for small.
  • Two Headers: header 1: Monday 31. Header 2: Useful Information
  • Must be able to display multiple events on a given day.

Few events truly span multiple days. There is usually a beginning and end of the first day and a beginning and end of the second day. So this is how i intend to treat it.

Getting Started.

I like being explicit so I am going to list my assumptions and what I have done to meet them. If you have the same set up as me, then you can follow exactly, if yours is different then do your own thing where we deviate.

  1. You have an Aurelia Application set up and running.
  2. you have bootstrap 3 less files
  3. You have a LESS compiler set up
  4. You have moment.js
  5. You are using TypeScript

My set up
1. .netcore C# aurelia app by running dotnet new aurelia
2. dotnet automatically includes bootstrap through npm when you create a new aurelia app.
3. less-loader through webpack
4. npm install moment -save

Steps involved
  1. Change bootstrap from a grid of 12 to a grid of 14.
  2. Create an custom element for aurelia.
  3. Create grids and rows to hold the dates
  4. Populate the grids with dates
  5. Remove padding for rows inside of the calendar.
1. Change bootstrap from a grid of 12 to a grid of 14.

There are seven days in a week. So it would make since for seven columns to exist in a row. A seven column bootstrap doesn't give much flexibility for the rest of the application to use for layouts. If we treat the rows and columns inside of the calendar differently then you have a lot of repeated CSS to handle the special case. Twelve columns don't work well when you need seven columns. However with fourteen columns the rest of the application is a little more flexible and you have one grid system throughout everything so there isn't a special case. So we are going to increase the number of columns for bootstrap using LESS.

So first we are going to create a file called myLess.less

open the file and add these three lines of code.

@import '~bootstrap/less/variables.less';  
@grid-columns: 14;
@import '~bootstrap/less/bootstrap.less';

Your path may be different depending on what you use to compile the less files. The tilda in this case tells webpack to look in node_modules.

@import is a less command that allows us to reference other less files.

First we bring in the variables file for bootstrap. This file holds all of the settings bootstrap uses to set it's self up. It's worth looking at the file and seeing what all is there that you could change.

For our purposes we only need to change the @grid-columns variable from the default of 12 to 14

next we import the main bootstrap.less file. This file is a wrapper file around all of the bootstrap components and will give you everything that you would have gotten if you just used the bootstrap.css file directly except now it uses a 14 column grid instead.

Continue on with Aurelia Calendar Part 2

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 = "",

    ... 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.


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;  

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);

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); 

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); 

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); 

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;

signal vdbt:std_logic_vector(3 downto 0);

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


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

     if clk'event and clk='1' then
     end if;
end process;  
refresh_next<= 0 when refresh_reg= refresh_constant else  
refresh_tick<= '1' when refresh_reg = 0 else  
--register part
     if clk'event and clk='1' then
      end if;
end process;

--bar animation

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

--ball animation
     ball_l_next <=ball_l;
     ball_t_next <=ball_t;
     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  
--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  

--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  
rgb_ball<=x"00F100"; --Green

    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

     end if;
end process;

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;

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:

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;  

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";

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

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

    -- LED chaser
    process (clk_div(21))
      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
    // 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) 
        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;

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


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;