As I’m currently learning to do chip verification with I came across the SystemVerilog feature named Clocking blocks. It is simply put, a block that samples and pushes its inputs and outputs. A nice thing about the clocking blocks is the ability to await an input to become a given value and await the event of the next event of the clocking block, which in the following case is the posedge of the clock. This really helps me with keeping my verification code synchronously written.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

interface my_interface (
    input clock
);
    logic write;
    logic read;

    clocking my_cb @(posedge clock);
        // Set `default skew`. Sample 1 step before and pushes 1 step after
        // the posedge of the clock. If no `default skew` is set the default
        // will be 1 step input and 0 step output
        default input #1 output #1;

        // Outputs can be assigned values which will be pushed to any modules
        // hooked up to the `write` logic of this interface at 1 step after the
        // posedge of the `clock`. It is WRITE-ONLY and any attempt to read the
        // current value of the output will cause an error.
        output write;

        // Inputs can NOT be assigned values but instead the value of logic `read`
        // will be sampled to the input at 1 step before the posedge of the
        // `clock`. It is READ-ONLY and any attempt to assign the input a new
        // value will cause an error.
        input read; // Input 
    endclocking

endinterface

task some_task();

    @(if_instance.my_cb); // blocks untill next posedge clock

    wait(if_instance.my_cb.read == 1); // blocks untill read has become 1

endtask

Generate your key

1

gpg --full-generate-key

follow the wizard, and you should end with seeing the following

1
2
3
4
5
6
7

...
public and secret key created and signed.

pub   rsa3072 2022-01-03 [SC] [expires: 2022-02-02]
      <your-pub-key>
uid                      <your-id>
sub   rsa3072 2022-01-03 [E] [expires: 2022-02-02]

Configure Git

Take your public key and add is as signing key for Git.

1

git config --global user.signingkey <your-pub-key>

Make signed commit

1

git commit -S -m "my commit"

but it gets annoying to remember that -S flag all the time, so you can tell Git to always sign it for you.

1

git config --global commit.gpgSign true

Get verified on GitHub

Create PGP public kye block

1

gpg --armor --export <your-pub-key>

and then you’ll need to add it to Github like this.

I’ve recently started to look at and play around with DPDK and try to understand it all. Let’s just say that I’m far from understanding all of it yet, as most of my experience has been with the transport layer and up in the OSI stack. But one thing I do know is that getting some hands-on experience whilst learning new technologies is one of the best ways to get answers for all one’s questions and thesis on how the inner workings actually fit together. Of course looking at the source code of the technology being used will tell you it better, but with all the new terms being thrown at you, it’s good to just play around and get inspired instead of being overwhelmed and discouraged by the task of learning all the new concepts and namings.

So to start playing around I would like to use CMake as my build configuration tool and not Meson that DPDK is built with. Meson looks great, but I’m really comfortable with CMake as of now, and it also works great with CLion, which is my IDE of choice.

DPDK comes with support for pkg-config which I’ll be using to link my application with the DPDK SDK. This means that I’ve built and installed the DPDK libraries on my machine so that they are located in the usr/local.

Next is a template for CMake to link your application with the SDK. There are two options, shared or static linking.

CMake DPDK Template

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

cmake_minimum_required(VERSION 3.20)
project(test_dpdk)

find_package(PkgConfig REQUIRED)
pkg_check_modules(LIBDPDK REQUIRED libdpdk)

add_executable(test_dpdk main.cpp)

# Use the following for SHARED linking
target_compile_options(test_dpdk PRIVATE ${LIBDPDK_CFLAGS})
target_link_libraries(test_dpdk ${LIBDPDK_LDFLAGS})

# or use the following for STATIC linking
target_compile_options(test_dpdk PRIVATE ${LIBDPDK_STATIC_CFLAGS})
target_link_libraries(test_dpdk ${LIBDPDK_STATIC_LDFLAGS})

I hope this may become a handy simple template for you to start off your new DPDK projects.

So I recently had to use a StarTech ethernet USB adapter to get two extra ports for networking stuff I’m doing. So those two plus my laptop internal port I have three ports in total. The StarTech adapter worked right out of the box and can definitely recommend it. You can find it on their website with the item number USB32000SPT.

I’m using Ubuntu with the Gnome, but the Gnome network settings only allow me to use a single interface at a time, even though the other interfaces was visible. To fix this I used the dhclient to get ip’s assigned to my two new interfaces and now I have all three interfaces connected. Even the Gnome network settings acknowledge them as all being connected, but if I try to change anything in there it disconnects the two others than the one being configured. So the Gnome network settings are out of the picture from now on. Next I was pretty annoyed by the constant need to call dhclient <interface name> every time I rebooted my machine, and also the interface names was long and hard to remember. So I did some searching and found some different solutions to my problem. There were some more old school solutions such as using udev, which worked but seemed a bit too out dated and the configuration format, in my opinion is bad. So I looked a bit further and stumbled across Netplan.

Netplan is a tool that can help you set up all kinds of network stuff for you by just making a YAML configuration file. Well I’m not going to explain the tool any further as they do it so well themselves on their website, so I’m just going to show how I used it to set up my interface with persistent names and dhcp4 enabled.

First of I found the YAML config file in /etc/netplan/…, which in my case was /etc/netplan/01-netcfg.yaml, and then edited the file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      match:
         macaddress: "00:0a:cd:3e:17:9a"
      dhcp4: yes
      set-name: eth0
    eth1:
      match:
         macaddress: "00:0a:cd:3e:17:9b"
      dhcp4: yes
      set-name: eth1
    eth2:
      match:
         macaddress: "00:0a:cd:3e:17:9c"
      dhcp4: yes
      set-name: eth2

and then I ran netplan apply with root permission to apply the configuration on my machine. This is also a nice thing about Netplan, as it’s possible to make the changes without having to reboot. If you want to know more about the configuration options take a look at the Netplan references page.

As you can see I took my three interfaces and gave them the names eth0, eth1, and eth2 and also enabled dhcp for each of them. The interfaces are identified by the macaddress.

But enabling dhcp for them all gave me three default routes and this was not always desirable for me, as these three interfaces sometimes are connected to the same network. So in this case I use a bond to solve the problem and use eth0 as the primary interface. You can read more about what bonds are here. In my case I added the following configuration to my Netplan config file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

network:
  version: 2
  renderer: networkd
  # ... ethernets here

  # Use a bond for when the interfaces are on the same network.
  bonds:
    bond0:
      dhcp4: yes
      interfaces:
      - eth0
      - eth1
      - eth2
      parameters:
        mode: active-backup
        primary: eth0

And that’s pretty much it. Hope this was somewhat helpful for you.