Monthly Archives: F Y

Installer le système embarqué POSIX, Apache NuttX sur une carte basée sur un RISC-V ESP32-C3 avec Arch Linux

Table of content

Apache NuttX logo
* Introduction
* System packages
* NuttX sources and tools
* Configuration of devkit project, compilation and flash
* Connexion to NSH via (USB) serial
* The ostest and other basic sets (UPDATE)
* The apps examples (UPDATE)
* GPIO (UPDATE)
* SPIflash, SMARTFS and file fsystems (UPDATE)
* TMPFS (UPDATE)
* NSH scripting (UPDATE)

Introduction

Apache NuttX is a POSIX embedded system available on a lot of microcontrollers boards and architectures. After seeing some articles from Lup Yuen Lee, installing and working with NuttX on Bouffalo BL602 and BL604 RISC-V microcontroller boards, I discovered it can be installed on one of my boards. So I tried and managed to install it this evening on my recently acquired 3.5€ ESP32-C3S SoC nodeMCU board. ESP32-C3 is a SoC with RISC-V RV32IMC microcontroller, integrated 2.4GHz WiFi and Bluetooth LTE. The board contains a CH340 serial-USB converter, so it can easily be used/flashed/debugged from a computer. I already made a post about installing ESP-IDF tools and flashing examples on this RISC-V board.

For people that already know Espressif SoCs, here is a table of the power usage of some of their ESP models:

SoC        Modem sleep  Light sleep mode  Deep sleep mode
ESP8266          20 mA          2,000 µA            20 µA
ESP32            20 mA            800 µA            20 µA
ESP32-C3         20 mA            130 µA             5 µA

This article explains the procedure to prepare environment, on Arch Linux in November 2021. This is for x86_64, but should work on ARM too, only RISC-V toolchains are missing on ALARM, can be compiled, by using x86_64 versions of PKGBUILD (riscv32-elf-binutils, riscv64-elf-gcc). You can find the pricompiled binaries in my ArchLinux ARM archives including a little text about the order of compilation (binlib, gcc-bootstrap, newlib, gcc (and optionnaly, gcc and newlib again). Direct link to the three most usefull archives:
* riscv32-elf-binutils-2.36.1-2-armv7h.pkg.tar.xz
* riscv64-elf-gcc-11.1.0-1-armv7h.pkg.tar.xz
* riscv64-elf-newlib-4.1.0-1-any.pkg.tar.xz

Latest GIT version is needed In November 2021 for ESP32-C3, some other RISC-V architectures are already in stable releases. This is followed by an example of flashing and connect to the NSH shell, via serial on USB terminal. The dependencies for Debian based Linux on the official page, some parts could be incomplete. Some aspects of the NuttX, POSIX compatible Filesystem. OStest, GPIO and SPIflash included examples are also shortly described.

System packages

General system dependencies for NuttX:

sudo pacman -S --needed base-devel ncurses5-compat-libs gperf pkg-config \
   gmp libmpc mpfr libelf expat picocom uboot-tools util-linux git wget

Just press enter to select all packages on the base-devel packages group.

You also need some AUR packages, I still use obsolete Pacaur that some say is obsolete:

pacaur -S --needed  isl kconfig-frontends genromfs

Sadly for my case, there is currently a conflict between kendryte-toolchain-bin (used for Kendryte K210 RV64 SoC), that depend on isl19, currently conflicting with isl, I uninstalled kendryte-toolchain-bin package, hope it would still work from binary archive with last isl version (0.24 now), didn't managed to compile kendryte-toolchain from sources with it.

Specific RISC-V and ESP32 tools, riscv64 GCC is used to compile for both RV64 and RV32 architectures, but we need RV32 specific version of binutils here.:

sudo pacman -S --needed esptool riscv64-elf-gcc riscv32-elf-binutils

Specific RISC-V and ESP32 tools, AUR part (we don't use it in this article, but OpenOCD (Open On-Chip Debugger) can be useful for debugging):

pacaur -S openocd-esp32

You will need a special trick with GNU compilation toolchain, as the current version of NuttX search for riscv64-unknown-elf-* and Arch Linux call them riscv64-elf-* (without unknown-. I just created symlinks in /usr/bin/. Need root privileges for this (UPDATE: g++ was also needed by some optional examples applications):

sudo bash
for tool in gcc ar ld nm objcopy g++
do
  if [ ! -e /usr/bin/riscv64-unknown-elf-${tool} ]; then
    ln -s riscv64-elf-${tool} /usr/bin/riscv64-unknown-elf-${tool}
  fi
done

Or a more radical solution, to have a link for all existing riscv64-elf-* tools:

sudo bash
cd /usr/bin/
ls riscv64-elf-* | while read bin
do tool=${bin//riscv64-elf-}
  if [ ! -e riscv64-unknown-elf-${tool} ]
  then
    ln -s ${bin} riscv64-unknown-elf-${tool}
  fi
done

NuttX sources and tools

Choose a directory where you will install the tools. I choose a directory called nuttx here:

mkdir nuttx
cd nuttx

Some binaries are needed to creating the file system. The booting partition and the partition table. You can compile them by yourself, but I here just chosen to download already compiled ones, I would maybe update this post with compilation process:

wget https://github.com/espressif/esp-nuttx-bootloader/releases/download/latest/bootloader-esp32c3.bin
wget https://github.com/espressif/esp-nuttx-bootloader/releases/download/latest/partition-table-esp32c3.bin

We will just use bootloader and partition-table binaries here, but there is also mcuboot binary in the repository, not sure I will need it later, but I downloaded it to have everything for working in my archives:

wget https://github.com/espressif/esp-nuttx-bootloader/releases/download/latest/mcuboot-esp32.bin

NuttX sources are also needed:

git clone https://github.com/apache/incubator-nuttx nuttx
git clone https://github.com/apache/incubator-nuttx-apps apps

Update November 26, version 10.2.0 stable is out this week with ">esp32-c3 available by default, NuttX and NuttX-apps tarballs (list + download link for each version), Warning they are both called nuttx-version.tar.gz (Github is stupid), but they contain respectively incubator-nuttx-nuttx-version and incubator-nuttx-apps-nuttx-version files trees

So you can just download them this way to avoid problems:

wget -O incubator-nuttx-nuttx-10.2.0.tar.gz https://github.com/apache/incubator-nuttx/archive/refs/tags/nuttx-10.2.0.tar.gz
wget -O incubator-nuttx-apps-nuttx-10.2.0.tar.gz https://github.com/apache/incubator-nuttx-apps/archive/refs/tags/nuttx-10.2.0.tar.gz

And unarchive them this way:

tar xf incubator-nuttx-nuttx-10.2.0.tar.gz
tar xf incubator-nuttx-apps-nuttx-10.2.0.tar.gz
ln -s incubator-nuttx-nuttx-10.2.0 nuttx
ln -s incubator-nuttx-apps-nuttx-10.2.0 apps

So they can be usable the standard way.

Configuration of devkit project, compilation and flash

We have now all necessaries tools to prepare and install a bootable and functional system. We now enter in the nuttx directory:

cd nuttx

This is time to choose a project. You can see a list of existing ones for ESP32-C3 by typing:

./tools/configure.sh -L | grep esp32c3
  esp32c3-devkit:adc
  esp32c3-devkit:autopm
  esp32c3-devkit:ble
  esp32c3-devkit:bmp180
  esp32c3-devkit:efuse
  esp32c3-devkit:elf
  esp32c3-devkit:gpio
  esp32c3-devkit:lvgl
  esp32c3-devkit:mcuboot_confirm
  esp32c3-devkit:module
  esp32c3-devkit:nsh
  esp32c3-devkit:oneshot
  esp32c3-devkit:ostest
  esp32c3-devkit:pm
  esp32c3-devkit:pwm
  esp32c3-devkit:random
  esp32c3-devkit:romfs
  esp32c3-devkit:rtc
  esp32c3-devkit:sotest
  esp32c3-devkit:spiflash
  esp32c3-devkit:sta_softap
  esp32c3-devkit:tickless
  esp32c3-devkit:timer
  esp32c3-devkit:uid
  esp32c3-devkit:usbconsole
  esp32c3-devkit:wapi
  esp32c3-devkit:watchdog
  esp32c3-devkit:watcher

Description of some of them are available in the ESP32 (not C3) specific part of the doc

I choose "usbconsole" that contain NSH shell and allow to easily connect via USB using ttyUSB.

./tools/configure.sh -l esp32c3-devkit:usbconsole

Then you can tune some advanced parameters but I didn't used it, looks like ESP32-C3 is generic enough to not have to do anything special depending on board, so can be passed.

make menuconfig

You can quit it by pressing 2 times esc key.

Time to compile it now. We can compile it with only one CPU core of the computer:

make

Or to compile faster (if you don't have too low memory, else it could be slower), you can can add for example -j4 to use 4 cores or your computer:

make -j4

A long compilation sequence will be printed, ending by the names of the binaries (in colour here). This will be the system to be flashed.

CP: nuttx.hex
CP: nuttx.bin
MKIMAGE: ESP32-C3 binary
esptool.py -c esp32c3 elf2image -fs 4MB -fm dio -ff 40m -o nuttx.bin nuttx
esptool.py v3.2
Generated: nuttx.bin (ESP32-C3 compatible)

For flashing it, you need to first plug your ESP32-C3 based board on your computer, then use esptool.py flashing command. Parameters needed are chip type, (here an esp32c3), serial port where board is connected to (here ttyUSB0) and transfer rate (921600). Following parameters are the memory address where the binaries will be flashed followed by their names (binary files names are coloured here). So bootloader start at 0, partition table start at 0x8000 and NuttX binary we just compiled start at 0x10000. Warning: bootloader and partition-table need to be flashed only when you install for the first time NuttX, the number of write cycle of a flash is limited so only flash what you need:

esptool.py --chip esp32c3 --port /dev/ttyUSB0 --baud 921600 write_flash \
   0x0 ../bootloader-esp32c3.bin \
   0x8000 ../partition-table-esp32c3.bin \
   0x10000 nuttx.bin

Here is the displayed upload, I coloured (and masked) the MAC address. It can be useful to keep it for later. also colored the flashing of the 3 binaries.

esptool.py v3.2
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x00030fff...
Compressed 19120 bytes to 11416...
Wrote 19120 bytes (11416 compressed) at 0x00000000 in 0.5 seconds (effective 324.4 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 69...
Wrote 3072 bytes (69 compressed) at 0x00008000 in 0.1 seconds (effective 433.2 kbit/s)...
Hash of data verified.
Compressed 131264 bytes to 51049...
Wrote 131264 bytes (51049 compressed) at 0x00010000 in 1.9 seconds (effective 542.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Et voilà! The board is flashed (and restarted). In case of errors here, I wrote few lines about most common problems when flashing microcontrollers or FPGA boards using USB on Linux.

Update: I found a new possible problem. If you are already connected to the board by a terminal, the fuse will fail with the following error:

serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

Just have to quit the terminal application, and restart the previous esptool.py command, everything should run fine now.

Connexion to NSH via (USB) serial

You can now connect with any serial terminal tool like screen (yes it has this functionality too), gtkterm (with a GUI), or lot of others. I used Picocom as proposed by NuttX documentation.
One of the interesting aspect of NuttX, is that you have an integrated shell called NSH (for NuttShell).

picocom -b 115200 /dev/ttyUSB0

To escape from Picocom you need to type: ctrl-a then ctrl-x. Picocom man page contains all the needed shortcuts.

After connecting to the terminal, just type on enter key to have a NSH prompt, you have an integrated help, with the help command. See the more detailed NSH commands description in the official documentation.


nsh> help
help usage:  help [-v] []

  .         cd        echo      hexdump   mv        set       truncate
  [         cp        exec      kill      printf    sleep     uname
  ?         cmp       exit      ls        ps        source    umount
  basename  dirname   false     mkdir     pwd       test      unset
  break     dd        free      mkrd      rm        time      usleep
  cat       df        help      mount     rmdir     true      xd

Builtin Apps:
  nsh  sh

NuttX is POSIX, so as any UniX environment, every device can be accessed via files. Like on Linux, you have the 2 important directories; /dev containing the devices files, and /proc containing system and devices parameters.

Update: If you are stuck for any reason, you can send a reset signal to the board by pressing two times the F7 function key in the terminal.

nsh> ls
/:
 dev/
 proc/
nsh> ls -l /dev
/dev:
 crw-rw-rw-       0 console
 crw-rw-rw-       0 null
 crw-rw-rw-       0 ttyS0
 crw-rw-rw-       0 zero
nsh> ls -l /proc
/proc:
 dr--r--r--       0 0/
 dr--r--r--       0 1/
 -r--r--r--       0 meminfo
 dr--r--r--       0 fs/
 dr--r--r--       0 self/
 -r--r--r--       0 uptime
 -r--r--r--       0 version

In the included commands, mkrd allow to create a RAMDISK file system

Update: This was the NuttX version 10.2.0-RC0 c7e604b20b-dirty after cat /proc/version.

The ostest and other basic sets (UPDATE)

The sources of the demo programs can be found in boards/risc-v/esp32c3/esp32c3-devkit/src/ subdirectory and the .config settings, that can also be changed with make menuconfig, for each demo are located in the boards/risc-v/esp32c3/esp32c3-devkit/configs/ directory.

For my second test, I tried esp32c3-devkit:ostest receipe. The system include a command called ostest, that try different systems usage, including memory allocation, timers or multithreading.

If you have already compiled a project and try to compile another one you will have an alert:

Already configured!
Please 'make distclean' and try again.

You only need to follow the instruction and make a distclean to be able to compile another one:

make distclean
[...] <- lot of cleaning
./tools/configure.sh -l esp32c3-devkit:ostest

As we already flashed the boot en partition table and number of write cycle of flash are limited (to some thousand of times, look at the flash eprom specification), you can limit the flash to the nuttx.bin part itself:

esptool.py --chip esp32c3 --port /dev/ttyUSB0 --baud 921600 write_flash \
   0x10000 nuttx.bin

You will only be able to see the name of the command by typing help :

nsh> help
help usage:  help [-v] []
[...] <- standard commands
Builtin Apps:
  nsh     ostest  sh

When the ostest finish on this system image, you will see memory used. and the filesystem will have a new directory /var with a subdirectory /var/mqueue added.

nsh> ostest
[...] <= lot of tests
barrier_func: Thread 6 done
barrier_test: Thread 5 completed with result=0
barrier_test: Thread 6 completed with result=0
barrier_test: Thread 7 completed with result=0

End of test memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena       5d2e0    5d2e0
ordblks         8        8
mxordblk    56710    53ab0
uordblks     5de0     9640
fordblks    57500    53ca0

Final memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena       5d2e0    5d2e0
ordblks         2        8
mxordblk    58ae0    53ab0
uordblks     47f0     9640
fordblks    58af0    53ca0
user_main: Exiting
ostest_main: Exiting with status 0
nsh> ls var/
/var:
 mqueue/

As with Linux, you can know the total, used and free memory by displaying the content of /proc/meminfo. The builtin command free do the same thing.

nsh> cat /proc/meminfo
                   total       used       free    largest  nused  nfree
        Umem:     382752       6128     376624     376624     32      1

Among the other tests, some demos that interest me are:
* esp32c3-devkit:gpio to access to GPIO (general purpose Input/Output) via command line.
* esp32c3-devkit:spiflash to access the flash disk using NuttX SMART Flash file system via SPI1. The command mksmartfs can be used to make the FS, and the FS can be mounted the POSIX way (like Linux for example) by typing mount -t smartfs /dev/... /mntpoint. It add mksmartfs command and flash_eraseall and fstest builtin apps.
* esp32c3-devkit:lvgl demo, LVGL is a small graphic and GUI library that help to make interfaces in small memory embedded board systems. Demos include drivers for Sitronix ST7735 (262K Color Single-Chip TFT Controller/Driver) and ST7789 SPI displays controllers in esp32c3_st7735.c and esp32c3_st7789.c in boards/risc-v/esp32c3/esp32c3-devkit/src/. I need to figure out how to connect one. Breadboards will help for this test. Another solution is probably to try it using Qemu?? With this demo the RGB led of the board is set to orange. There is a Youtube video of this demo on an ESP32 (Xtensa) version monothread and multithread, side by side. The ESP32-C3 has only one core. The command in the system is called lvgldemo. Nothing appear on terminal console, so I don't know at all what this demo do. There are some documentation about NuttX and LVGL on the LVGL documentation site. There is also LVGL.academy tutorial site.

The apps examples (UPDATE)

We previously downloaded the git apps repository beside the nuttx repository. The apps, contains examples beyond the basic vital functionalities of the system. These resources can be set in the .config file (flags starting with CONFIG_EXAMPLES_) or by using make menuconfig.

In the menu config the apps are in the last entry. Go down with cursor keys and when you are on the last entry, just press enter:

Then the application configuration submenu will display. Warning, you have generally limited resources on the board, select options with parsimony. The best is to first choose the already prepared set for your platform and then to activate some if they work:
* Cryptographic Library Support contains LibTomCrypt and Mbed TLS Cryptography libraries support.
* The Examples subset contains interesting tools like, audio generator (need external dependencies), uIP web server (implementation on uIP TCP/IP stack, that include a DHCP client), tools to blink LEDs (warning PowerLED needs external dependencies), battery monitor, camera driver, the LVGdemo, pdcurses (a GUI text lib).
* The filesystem utilities contains mkgpt, mkbr (for managing fs), a password file support (need external dependencies) etc... :
* The network utilities contains, a chat tool, a sJSON and CODEC libraries, an FTP client, MQTT-C (a MQTT messages client), and a remote execution server and client.
* The NSH library allow you to tune NSH parameters, including MOTD management, a more heavy and complete Command Line Editor, instead of the minimal readline(), or backslash of characters.
* The System Libraries of NSH add-ons, allow to enable system() interface (and so call of NSH function from C), Terminal Curses control support an hexadecimal file editor, or a minimal CU terminal editor. There are also options to use Emacs, VIM or Ncurses mode interface. Zmodem and GPIO u-Block modem., SPI tools, etc...
* Wireless Libraries and NSH Add-ons, contains Bluetoot and IEEE 802.15.4 applications including both version of "Swiss army knife".

GPIO (UPDATE)

The esp32c3-devkit:gpio add a command to access to GPIO (general purpose Input/Output) via command line. It can be set in make menuconfig by Application configuration ---> Examples ---> [*] GPIO driver example, or by setting the .config file.

To have GPIO activated:

CONFIG_ESP32C3_GPIO_IRQ=y
# IO Expander/GPIO Support
CONFIG_DEV_GPIO=y
CONFIG_DEV_GPIO_NSIGNALS=1

To have the command example:

CONFIG_EXAMPLES_GPIO=y
CONFIG_EXAMPLES_GPIO_PROGNAME="gpio"
CONFIG_EXAMPLES_GPIO_PRIORITY=100
CONFIG_EXAMPLES_GPIO_STACKSIZE=2048

With this a new gpio command appear, if you type it without arguments, it will help you (-h argument works too):

nsh> gpio
ERROR: Missing required arguments
USAGE: gpio [-w ] [-o ] 
       gpio -h
Where:
	: The full path to the GPIO pin driver.
	-w : Wait for an signal if this is an interrupt pin.
	-o :  Write this value (0 or 1) if this is an output pin.
	-h: Print this usage information and exit.

You can list the available devices (driver path in the help). Here is a long (-l) listing, and you can see they are character devices files with the initial c:

nsh> ls -l /dev
/dev:
 crw-rw-rw-       0 console
 crw-rw-rw-       0 gpint0
 crw-rw-rw-       0 gpout0
 crw-rw-rw-       0 gpout1
 crw-rw-rw-       0 null
 crw-rw-rw-       0 ttyS0
 crw-rw-rw-       0 zero

In the example source boards/risc-v/esp32c3/esp32c3-devkit/src/esp32c3_gpio.c, we can see than the pins 1 and 2 are set to the two first gpout, here gpout0 and gpout1 and that only the pin 9 is used for the interrupts gpint0:

/* Pin 1 and 2 are used for this example as GPIO outputs. */

#define GPIO_OUT1  1
#define GPIO_OUT2  2
[...]
/* Interrupt pins.  GPIO9 is used as an example, any other inputs could be
 * used.
 */

#define GPIO_IRQPIN  9

Here is a map of the pins on my board, thanks to J-C. François, licence CC-BY-SA:

The pins 1 and 2 are at the upper left, and the pin 9 at the upper right

The current state of a GPIO can be know by a cat. here for example 0 state (the result is without return carriage so just touch by nsh:

nsh> cat /dev/gpout0
0nsh> 

Writing a value 1 to the first pin defined (so pin 1) the example display the current value, then change it and verify its state:

nsh> >gpio -o 1 /dev/gpout0
Driver: /dev/gpout0
  Output pin:    Value=0
  Writing:       Value=1
  Verify:        Value=1

SPIflash, SMARTFS and file systems (UPDATE)

The SPIflash recipe ( esp32c3-devkit:spiflash ), add the commands mksmartfs and the builtin apps flash_eraseall and fstest.

To use fstest, you need to prepare the fs and mount it.

In the default included commands, mkrd allow to create a RAMDISK file system. It can be used for tests and avoid to waste flash writing cycles.

The syntax is (help mkrd to display it):

mkrd usage:  mkrd [-m ] [-s ] 

Default secteur size is 512 bytes. We can simply create a 10KB RAM disk, so 512×20 = 10240 bytes = 10 kilobytes bytes, by typing:

mkrd 20

A ramdisk device will appear in /dev called ram0. Filesystems are blocks devices (shown by the initial b, c is character device):

nsh> ls -l /dev
/dev:
 crw-rw-rw-       0 console
 crw-rw-rw-       0 null
 brw-rw-rw-   10240 ram0
 brw-rw-rw-  983040 smart0
 crw-rw-rw-       0 ttyS0
 crw-rw-rw-       0 zero

You can also see the smart0 device corresponding to the disk, is also available with the SPIflash recipe. sadly RAM disk isn't supported by smartFS so it can't be formatted as is. VFat is supported, but need to add it at configure time. You can activate TMPFS (see below) that also use RAM, as on Linux, for working on temporary RAM disk.

* SmartFS support can be activated by make menuconfig in File Systems ---> -*- SMART file system
* smartfs application can be selected by make menuconfig in Application Configuration ---> File System Utilities ---> mksmartfs.

Flags set in .config, for SMARTFS support:

CONFIG_ESP32C3_SPIFLASH_SMARTFS=y
CONFIG_FS_SMARTFS=y
CONFIG_SMARTFS_ERASEDSTATE=0xff
CONFIG_SMARTFS_MAXNAMLEN=48
# CONFIG_SMARTFS_MULTI_ROOT_DIRS is not set
# CONFIG_SMARTFS_ALIGNED_ACCESS is not set
# CONFIG_FS_PROCFS_EXCLUDE_SMARTFS is not set

And for command utilities:

CONFIG_FSUTILS_MKSMARTFS=y
# CONFIG_NSH_DISABLE_MKSMARTFS is not set

smart0 need to be formated before mounting it. The data will be kept on it after reboot, or flashing a new code.

nsh> mksmartfs /dev/smart0

In POSIX systems, we need to create an empty directory used as a mount point, then mount the partition. The type of filesystem isn't auto-detected, so we need to pass it to mount command here:

mkdir /mnt
mount -t smartfs /dev/smart0 /mnt

It will make a test loop of 100 iterations, of writing and then deleting files in the mountpoint, I put the ouput. If you really want to test the fs you can use it, but you will waste write cycles of the flash :

The commande is:

fstest

Here is a sample of the output, I stopped it by resetting the card (2 times F7:

=== FILLING 4 =============================
[...]
168. Type[8]: File  Name: iJaUkEIwgSG4cAyl8J
169. Type[8]: File  Name: FNLd0XaTSYF8TV3YtO
170. Type[8]: File  Name: SV0Lrtmigq9Yg4SauoD4f
171. Type[8]: File  Name: GJfbQ0bFaowO0ep
[...]
Total file size: 427496

=== DELETING 4 ============================
Deleted some files
  Number of files: 215
  Number deleted:  108
Directory:
 1. Type[8]: File  Name: PRMIRHz9ZwgHga
 2. Type[8]: File  Name: 9LH4Uf67RL4bFXVCykg3
Total file size: 427496
File System:
  Block Size:      1024
  No. Blocks:      960
  Free Blocks:     457
  Avail. Blocks:   457
  No. File Nodes:  0
  Free File Nodes: 457

End of loop memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena       58fb0    58fb0
ordblks        41       57
mxordblk    510a0    510a0
uordblks     77d0     6f40
fordblks    517e0    52070[...]

As I stopped it during the loop the files are still on the fs. Wildcard are not supported by the rm command.

As we can see with the df (disk free) command, after deleting some file, this still uses lot of blocks:

nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
  1024        960        725         235 /mnt
     0          0          0           0 /proc

I used the flash_eraseall builtin app to erase evrything:

nsh> flash_eraseall /dev/smart0

This remove the files but don't free the blocks. I needed to force a mksmartfs with the option -f to free the blocks:

It removed the files but didn't cleaned the block. I need to format again the device using:

nsh> mksmartfs -f /dev/smart0

Now All the blocks are available again:

nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
  1024        960         10         950 /mnt
     0          0          0           0 /proc

For example, write a single file to be kept after reboot. we can write the content of the file with cat or echo commands for example. I write here a simple sentence this is kept datas in the test.txt file, using the file redirection character (>):

nsh> echo "this is kept datas" >/mnt/test.txt
nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
  1024        960         11         949 /mnt
     0          0          0           0 /proc

As you can see this took an entire 512 bytes block even if it's an only 18 bytes string file. Every file written use a full block, so try to choose the sector-size when you use mksmartfs.

After rebooting the device (2 times F7) or unplug/replug it. You can still see the data on the file. Note that after each reboot, you need to mount afain the filesystem:

nsh> mount -t smartfs /dev/smart0 /mnt
nsh> cat /mnt/test.txt
this is kept datas

Removing files by rm command effectively free the blocks:

nsh> rm test.txt
nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
  1024        960         10         950 /mnt

Among the other available file systems in NuttX, there is LittleFS, CNX-Software made an article about it. It is very compact and reliable, but there is no utilies to manage them in applications, need to use libs or code a shell compatible command. The Source Git repository shows an exemple usage in C

By make menuconfig select Board Selection ---> [*] Mount SPI Flash MTD on bring-up (LittleFS) ---> (X) LittleFS (Only one file system can be set at a time here), and

In the .config, if the file sustem is not set for the board:

# CONFIG_ARCH_CHIP_LITEX is not set
# CONFIG_ESP32C3_SPIFLASH_LITTLEFS is not set

or if set: CONFIG_ESP32C3_SPIFLASH_LITTLEFS=y

For the more general LITTLEFS support, by make menuconfig, in File Systems ---> -*- LITTLEFS File System (several can be selected in this part).

Options in .config:

CONFIG_FS_LITTLEFS=y
CONFIG_FS_LITTLEFS_BLOCK_FACTOR=4
CONFIG_FS_LITTLEFS_BLOCK_CYCLE=200

With this setting (after selecting SPIflash), there is a esp32c3flash device that replace smart0.

And The smartFS can't be mounted. The error message is a bit erroneous:

nsh> mount -t smartfs /dev/esp32c3flash /mnt
nsh: mount: mount failed: No such device

TMPFS (UPDATE)

If you choose in make menuconfig the option File Systems -> [*] TMPFS file system

Default TMPFS option in .config

CONFIG_FS_TMPFS=y
CONFIG_FS_TMPFS_BLOCKSIZE=512
CONFIG_FS_TMPFS_DIRECTORY_ALLOCGUARD=64
CONFIG_FS_TMPFS_DIRECTORY_FREEGUARD=128
CONFIG_FS_TMPFS_FILE_ALLOCGUARD=512
CONFIG_FS_TMPFS_FILE_FREEGUARD=1024

You will see an automounted /tmp, it is 512 blocks wide on my board (so 512×512/1024=512/2=256KB of RAM disk. 1 block is used for the file system root directory (mounted in /tmp):

nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
     0          0          0           0 /proc
   512          1          1           0 /tmp

TMPfs allow to use the free memory, but don't really use it until your write files inside:

nsh> cat /proc/meminfo
                   total       used       free    largest  nused  nfree
        Umem:     364464      10016

354448 354448 38 1

I cd (change directory) in /tmp here and write a file, it will take one more 512 bytes block and so, 10016 + 512 (block) + 176 (probably some references in filesystem dictionnary) = 10704 bytes of memory will be used. The size of the refs vary it took only 96 bytes on another test.

nsh> cd /tmp
nsh> echo "This is a test" >test
nsh> df
  Block    Number
  Size     Blocks       Used   Available Mounted on
     0          0          0           0 /proc
   512          2          0           2 /tmp
nsh> cat /proc/meminfo
                   total       used       free    largest  nused  nfree
        Umem:     364464      10704     353760     353744     42      2

NSH scripting (UPDATE)

You can make simple shell script in NSH. For exemple this one lie exemple test if /dev/ram0 exists and then print the result of the test.

if [ -e /dev/ram0 ]; then echo "ram0 exists"; else echo "no ram0"; fi

Variable can be set and unset

nsh> set foo bar
nsh> echo $foo
bar

script can be put in files. I didn't found an easy way to put them. The cat function, seems to be limited to go from one file to another, it doesn't manage STDIN a standard way, and there is no editor. The only solution is to echo line by line, or to transfer files by network or serial (need to search more).
If you have activated the TMPFS as explained previously or formatted and mounted SMARTFS partition, you can write files inside. Here is an exempla with TMPFS, available in /tmp by default I removed the initial nsh> here, so it will be easier to copy paste:

echo if [ -e /dev/ram0 ] >/tmp/script.sh 
echo then >>/tmp/script.sh
echo "  echo ram0 exists" >>/tmp/script.sh
echo else >>/tmp/script.sh
echo "  echo ram0 doesn't exist" >>/tmp/script.sh
echo fi >>/tmp/script.sh

The >> symbol means you append lines to an existing file instead of overwriting it.
you can now see the script by a cat:

nsh> cat /tmp/script.sh
if [ -e /dev/ram0 ]
then
  echo ram0 exists
else
  echo ram0 doesn't exist
fi

And it can be executed by two means, sh or source, the difference,

nsh> sh /tmp/script.sh
ram0 doesn't exist

Now, if we create ram0 by using mkrd:

nsh> mkrd 20
nsh> sh /tmp/script.sh
ram0 exists

Using ESP-IDF with RISC-V ESP32-C3 nodeMCU module on a Linux system

>NodeMCU ESP32-C3S »></a></p>
<h2 id=Table of Content

* Introduction
* Step 1, install dependencies
* Step 2, install ESP-IDF
* Step 3, setup working environment
* Step 4, test « Hello World » example
* Step 5, tune the target, if needed
* Step 6, flash the project
* Step 7, viewing the output
* Troubleshooting
** Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′
** libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c
** Flashing errors
*** Detection, power, and device that disappear
*** usbfs: interface 0 claimed by ch341 while ‘brltty’ sets config #1
** Problem with CA certificates bundle

Introduction

The list of existing ESP32-C3 SoC modules (with their specs) is very interesting, This one RISC-V core SoC has lower computing power than the ESP32-S3 (dual-core Xtensa ISA based, with a RISC-V co-processor core for « ultra low power » (ULP) mode), but RISC-V architecture is also far more efficient and will for sure have longer lifetime support and evolution due to its openness. ESP32-C3 use an RV32IMC (Integer, Multiplication/division and Compressed extensions) core.

I bought for my test a ESP-C3-32S-Kit on AliExpress (for ~3.4€). There is also an interesting option, where you can use really tiny 3~4 € ESP-C3-01M-Kit programmer interface/mother board, with a SoC included alone on a daughter (ESP32-C3M with an on PCB antenna). This allows, to flash several pads one only one programmer board. This reduce size of the needed system for final application to just the SoC and it’s power supply and peripherals. Pads of the SoC daughter board are wide enough to be easily soldered.

ESP-IDF is a tool to develop in C language on Espressif platforms, including ESP8266 and ESP32 series. It uses FreeRTOS free and open source embedded real-time OS for its SoCs. Sadly the official documentation for installing it is incomplete with the current state (November 2021) of GIT repository. Here is the mean to install a working ESP-IDF for this SoC series on Linux. This will be more compact and straight forward that the official with Linux+Windows installation.

About RISC-V more generally, I created this week a list of available Open Source RISC-V implementations, and open sources tools to build them or work with them.

Step 1, install dependencies

Instruction for Arch Linux, CentOS and Debian, based Linux systems:

* Debian/Ubuntu/…

sudo apt-get install git wget flex bison gperf python3 python3-pip python3-setuptools cmake \
  ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

* CentOS

sudo yum -y update && sudo yum install git wget flex bison gperf python3 python3-pip python3-setuptools \
  cmake ninja-build ccache dfu-util libusbx

* Arch Linux/Manjaro/…

sudo pacman -S --needed gcc git make flex bison gperf python-pip cmake ninja ccache dfu-util libusb

Step 2, install ESP-IDF

This will take at least 1.2GB of disk space (size of the git clone at the time I write this article).

mkdir -p ~/esp
cd ~/esp
git clone --recursive https://github.com/espressif/esp-idf.git

They didn’t mention, that 4.3 is required to use ESP32-C3. At the time I tried it, version 4.2 is currently (November 2021) the default branch, you can see the current version by this commands. Warning: This start the environment, so you will probably need to log again or simply start another shell to avoid problems when finishing the installation.:

cd ~/esp/esp-idf
. ./export.sh
idf.py --version

So you need to checkout the 4.3 branch to have a working version with ESP32-C3, and then update submodule to match the new version:

cd ~/esp/esp-idf
git checkout release/v4.3
git submodule update --init --recursive

Then you need to install some binaries/libs. Warning, it will create a ~/.expressif directory to place all downloaded files inside, don’t forget to create the directory + a link to a partition with enough place (about 1GB needed for all versions).

cd ~/esp/esp-idf
./install.sh esp32c3

After the installation, the following command is suggested to enter in the working (python pyenv) environment (don’t forget the first . and space)

Step 3, setup working environment

. ./export.sh

A message will be displayed that explain to you how to compile a program:

Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

  idf.py build

They suggest in the documentation to add an alias to your .bashrc:

alias get_idf='. $HOME/esp/esp-idf/export.sh'

So you will only have to type get_idf to get ready to use it.

Step 4, test « Hello World » example

I would personally make it this way:

cd ~/esp/
mkdir tests
cd tests
cp -a ~/esp/esp-idf/examples/get-started/hello_world .
cd hello_world
idf.py set-target esp32c3

Errors possible, see:
* Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′
* libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

Step 5, tune the target, if needed

You need now to use menuconfig if you want to setup some parameters, default one should just work fine.

idf.py menuconfig

This show you an interactive cli menu interface like for the Linux kernel, that allow you to tune some parameters. You don’t need to tune them for this test.

You can navigate with cursor keys, validate or enter submenus with enter, and quit them without modification with esc key. When you quit it, it will say you if you didn’t done any modification:

No changes to save (for '~/esp/test/hello_world/sdkconfig')

Step 5 build the project

Now as everything is setup, you only need to build the project, this could take some time, as it, at first time, compile, the whole embedded system:

idf.py build

It will end with a message displaying the location of the binary to be flashed and the instruction to type to flash it, the long explicit way and the short implicit way (I coloured them here):

Generated >/data/arc/esp/test/hello_world/build/hello-world.bin

Project build complete. To flash, run this command:
/home/popolon/.espressif/python_env/idf4.3_py3.9_env/bin/python ../../esp-idf/components/esptool_py/esptool/esptool.py -p (PORT) -b 460800 --before default_reset --after hard_reset --chip esp32c3  write_flash --flash_mode dio --flash_size detect --flash_freq 80m 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/hello-world.bin
or run 'idf.py -p (PORT) flash'

* Problem with CA certificates

Step 6, flash the project

If you didn’t have plugged your board in the USB port it’s the time to do. Then (by default white colour RGB led is enlighten. Type then the suggested command. I choose the short way here:

idf.py --port /dev/ttyUSB0 flash

It should now do the flashing sequence. I show only some important steps. In color you MAC address is given, it can be useful to detect if everything run fine.

Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
[...] <- lot of output
Writing at 0x00010000... (20 %)
[...] <- lot of output
Leaving...
Hard resetting via RTS pin...
Done

Read this if you have some troubles at flashing.

Step 7, viewing the output

You can connect to the board, still with its ttyUSB0 port, need to connect at speed 115200. I previously wrote an article about how to control a remote board, including serial

I use TinySerial here:

com /dev/ttyUSB0 115200

You can also use idf.py to monitor the output like this (idf.py monitor shortcuts and launching GDB with GDBStub:

idf.py -p /dev/ttyUSB0 monitor

In both case, you will see a booting sequence, an Hello World! some characteristics of your board, then a 10 seconds counter and a reboot. This is looping until you unplug or flash again the board.

Hello world!
This is esp32c3 chip with 1 CPU core(s), WiFi/BLE, silicon revision 3, 2MB external flash
Minimum free heap size: 327588 bytes
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...

You can quit by typing: the 2 keys ctrl-c followed then by a

Building, flashing and monitor can be combined by one command:
idf.py -p /dev/ttyUSB0 flash monitor

Troubleshooting

I don’t want to pollute too much the reading of the workflow and keep it as reference, so people can found answer when they encouter the same errors.

Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′

If you have the following error, you didn’t checkout the 4.3 branch at Step 2

Usage: /data/arc/esp/esp-idf/tools/idf.py set-target [OPTIONS] {esp32|esp32s2}
Try '/data/arc/esp/esp-idf/tools/idf.py set-target --help' for help.

Error: Invalid value for '{esp32|esp32s2}': 'esp32c3' is not one of 'esp32', 'esp32s2'.

libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

If during the set-target you have the following error:

CMake Error at ~/esp/esp-idf/tools/cmake/component.cmake:475 (add_library):
  Cannot find source file:

    ~/esp/esp-idf/components/libsodium/libsodium/src/libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

This mean you didn’t made the git submodules update in Step 2. So return in ~/esp/esp-idf and git submodule update.

You will then need to remove the hello_world directory and copy it again in tests: cd ~/esp/tests/; rm -R hello_word; cp -a ~/esp/esp-idf/examples/get-started/hello_world ..

Flashing errors

There are several problems possible for flashing part, most of them are about ttyUSB0 detection/usage.

Detection, power, and device that disappear

NodeMCU ESP32-C3S

First look if your board is detected by lsusb.

* If the device isn’t detected at all, verify if you USB wire is not a powering only wire. Try by connecting other USB devices, if all of them aren’t detected by the wire, this is probably the case, if you use a wire for your phone with the same kind of connector, try if it detected with it, then your board.

* Another case, a board that worked perfectly the first day, was not detected any more the second day. I looked at it with artisanal microscope using phone zoom + cheap lens, and seen a hair or wire, like on the detail picture at left, just above two pins of the USB connector. After removing it, the board work again.

* If the interface is displayed by lsusb but disappear when flashing it, try to disable power saving (autosuspend) for this device or all USB devices, lots of old mother boards have problems with USB devices power saving. Some mouses keep stuck, some flashable devices disappear, etc…

usbfs: interface 0 claimed by ch341 while ‘brltty’ sets config #1

If it fails with a long error message including around the 10th line:

FileNotFoundError: [Errno 2] No such file or directory: '/dev/ttyUSB0'

Then there is a problem with the USB detection in your system configuration.

You can dig in kernel message with dmesg | less then search for ttyUSB0 (just type /ttyUSB0 to found the problem.

In my case for example, the brtty (tty for braille) driver tried to get the serial device and then disconnected it:

[36767.028312] usb 1-1.6: ch341-uart converter now attached to ttyUSB0
[36767.252867] audit: type=1130 audit(1637441179.890:468): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty-device@sys-devices-pci0000:00-0000:00:1a.0-usb1-1\x2d1-1\x2d1.6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[36767.878792] audit: type=1130 audit(1637441180.513:469): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty@-sys-devices-pci0000:00-0000:00:1a.0-usb1-1\x2d1-1\x2d1.6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[36767.883002] usb 1-1.6: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[36767.883975] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[36767.883998] ch341 1-1.6:1.0: device disconnected

You can in this case not the device id with the following command (the ID in the result is coloured here:

lsusb | grep CH340
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter

Then edit the 90-brltty-device.rules:

>code>sudo vi /usr/lib/udev/rules.d/90-brltty-device.rules

Search the line containing 1a86/7523 by typing /1a86/7523, then comment the line by adding a # at start:

#ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

save and quit by typing :x if you use vi/vim/nvim… and then reload udev rules by typing:

systemctl reload systemd-udevd

It should now be ok, by just unplugging and replugging the USB wire from your computer.

Generally all the kind of (tty)USB connection problem can be solved by tuning /etc/udev/rules.d/

Problem with CA certificates bundle

With the 4.2 version of ESP-IDF, some FAILED are thrown in relation with a x509_crt_bundle and cacrt_all.pem invalid certificate.

Updating the Certificate Bundle section has a link to himself as solution. ^^. Looks like the problem is on ESP-IF 4.2, 4.3 runs just fine, see install + upgrade process.

My system CA-certificates are already up to date but it want a specific version to put somewhere (not documented) to be able to push it on the board firmware. Ca-certificates, are certificates about CA (Certificate Authorities) that you need to be sure that this authorities are still be considered as valid. anyway ESP-IF 4.3 works just fine.

Courte introduction pratique à FPGA, Verilog et Verilator et quelques mots à propos de SystemVerilog

→ English version here

Attention, Je suis un débutant de moins d’un mois en Verilog, Verilator et FPGA, que j’ai étudié comme un loisir, si il y a des erreurs je les corrigerais. Vous pouvez me contacter sur le Fediverse.

Sommaire


* Introduction
** Process complet dans le monde réel
** Choses à connaître et comprendre
** Comment se programme un FPGA
* Verilog
** Valeurs
** Types
** Portes
** Modules
** Exemple simple, écrire une porte « et »
** Blocs initial et always
* Exemple simple en Verilator
** Effectuer le test avec Verilator
** Tracer l’exemple avec GTKWave
** À propos des exemples de Verilator
** Exemple pratique de base avec Verilator
* Pour aller plus loin

The text in strong are here to help diagonal reading.

Introduction

Je continue de descendre dans les couches avec le mode des FPGA (en anglais, « Field Processors Gateway Array », il existe différentes traductions). Ce sont des circuits itnégrés programmables, permettant de réaliser des circuilts logiques comme des processeurs. Ils sont notamment utilisés pour développer et tester des processeurs. Lorsque le processeur est validé en FPGA, ils peuvent être produit en ASIC (en anglais : « Application-specific integrated circuit »), processeur finaux, avec circuits cablés en durs et n’étant plus modifiables, tels qu’on les trouves dans les ordinateurs et périphériques informatiques de tous les jours. Les FPGA sont également utilisés tels quels dans différentes applications industrielles (avionique, traitement audio, vidéo, etc…) pour leur parallélisme et rapidité supérieure à un ASIC comportant un processeur général interprétent un logiciel, dans ces domaines et la possibilité de les mettre à jour facilement en cas de problème. Ce billet est une petite intrduction aux FPGA, au langage HDL (en anglais : « Hardware description language », signifiant, « langage de description de matériel ») standard IEEE, appelé Verilog, et la façon de le tester avec un logiciel libre à sources ouvertes (FOSS), le simulateur Verilator. Si vous désirez utiliser VHDL, GHDL est un simulateur libre équivalant VHDL.

Process complet dans le monde réel

Les étapes de l’implémentation d’un circuit sur un FGPA après sa conceptions son (des logiciels libres sont donnés comme outils de référence à chaque étape) :
* Implémentation de la logique (dans un HDL), donc Verilog ici, n’importe quel éditeur de text ou de programme peut être utilisé (j’utilise les très ampibien VIM et NeoVIM et parfois Geany, un environnement de programmation à interface très léger, mais également très puissant.
* SimulationVerilator ici, permettant de faire des bancs d’essai (anglais : testbench, parfois traduit en banc de test). C’est également un bon premier pas dans la vérification.
* Vérification formelleYoSYS est un système de vérification formelle et de synthèse de circuit. C’est une vérification plus formelle que celle de Verilator (vérification du temps d’execution et de la cohérence notamment). On ne va pas aborder ce point ici.
, Synthesis — créer les route et placer les blocs logiques, avec les contraites physiques et de temps (voir les principes de base des blocs logiques (CLB) et implémentations aujourd’hui) blocs depuis les sources en HDL et sortie d’un bitstream au format spécifique au FPGA utilisé, YoSYS de nouveau.
* Programmation/flashage du FPGAopenFPGAloader fait le travail sur la plupart des FPGA (utiliser la version Git si votre carte n’est pas autodetectée).
* Test dans le monde réel avec le FPGA.

On va se content de tester sur simulateur ici, pour comprendre les bases. Lorsque vous les aurez compris, vous pourrez aller plus loin, chosir un FPGA qui vous convient, et commencer à travailler avec.

Choses à connaître et comprendre

Les principaux concepts à comprendre et à savoir manipuler pour produire un circuit de FPGA de base sont:
* 0, 1 : Électricité passant par un circuit, ou non, pouvant être interprété en numérique par 1 ou 0, vrai ou faux, etc…
* Opéraeurs booléens (pour les portes logiques), qui est l’outil principal dans leurs manipulations. Vous n’avez pas besoin de notion d’électronique plus poussées. Les portes les plus basiques sont ou (OR), et (AND), non (NOT), et ou exclusif (XOR). Vous pouvez réaliser toutes ces portes en chaînant uniquement la porte non-et (NAND == AND+NOT), mais ça n’est probablement pas la façon la plus efficace de le faire. Si vous maîtrisez les propriétés algébriques des booléens cela pourra vous aider à simplifier les circuits, et donc de les rendre plus efficace, maiss ça n’est pas indispensable pour réaliser un circuit.
* Additionneur (ALU) (arithmetics logical unit), permettant des simples additions
* Bascule D (flip-flop) : Circuit spécial utilisé pour mémoriser les infromations (états) et les changer en fonction du signal d’enetrée et des changements d’état de l’horloge.
* Verrou (Latch) : Circuit logique séquentiel ne dépendant pas de l’horloge
* Horloge (Clock) : Donnant le rythme du temps. Les opérations sont dépendantes du temps, et ont besoin d’être synchronisées pour avoir un comportement cohérent. Les horloges sont comme un percussionniste dans un groupe de musique, Ils donne le rythme de base nécessaire à toute construction relative au temps. Les autres instruments, les chanteurs et les danceurs suivent son signal de temps. Appellés signaux d’horloge ici.
* Multipléxeurs (Multiplexers or MUX) qui peuvent aggréger différents signaux en un seul, et les démultipléxeurs (demultiplexer) qui font l’opposé.
Toutes ces fonctions sont intégrées dans une chaque bloc logique d’un FPGA.

Les autres parties importantes d’un FPGA sont :
* Un a quelques PLL (anglais : « Phase-locked loop », signifiant boucle, vérouillé sur la phase). Ils permettent d’avoir des signaux d’horloge secondaires, soit à des multiples de la fréquence de l’horloge principale, soit pour se synchroniser à des horloges (et donc signaux) externes.
* A Mémoire flash permettant de garder le bitstream (circuit) sur la carte après sa mise hors tension. Le bitstream sera automatiquement chargé au démarrage.
* De nombres blocs d’entrées/sorties (I/O blocks) périphériques à la puce contenant le FPGA, pour communiquer avec le monde extérieur.

Comment se programme un FPGA

Il existe trois principales méthodes pour développer un circuit de FPGA, et elles peuvent être mélangées, selon les besoins:
* Tracer le schéma avec outil graphique representant les opérateurs logiques et autres éléments de base (bascules, MUX, etc,) donnés plus haut.
* En utilisant un HDL (hardware description language), comme Verilog ou VHDL pour les plus connus. Les synthétiseurs sont là pour construire le circuit correspondant au programme en HDL, à la façon d’un assembleur pour transformer un du langage assembleur, facilement lisible par un humain en langage machine, ou comme les compilateurs ou interpréteurs des langages de plus haut niveau (C/C++, Python, Lua, JavaScript, FORTRAN, BASIC, Pascal, Camel, LISP, etc) qui les convertissent également en langage machine. Il existe également des langage de plus haut niveau pour les FPGA, tels que Chisel, un lanage HDL de très haut niveau qui est transpilé en Verilog ou VHDL, pour être ensuite synthétisé par les outils habituels.
* En utilisant OpenCL (Open Computing Language). Un langage conçu à la base pour le calcul intensif, pouvant être réparti simultanément sur les GPGPU et CPU .

Lors de l’utilisation de HDL, des outils sont donc là pour calculer automatiquement le routage du circuit pour vous. Des outils tels que VTR (Verilog To Routing) et NextPNR, optimisent également leur placement pour vous.

Symbiyosys est un outil de vérification.

OpenFPGAloader est un logiciel libre pour programmer/flasher le bitstream ainsi généré sur le FPGA lui même.

Il est possible de d’obtenir des résultats intéressants quelques heures après avoir commencé à étudier un HDL, Il permet de crée un circuit simple avec du code, proche de certains langages de haut niveau, avec des variables, constantes, registres, tests conditionnels, ainsi que des calculs de booléens des additions et des manipulations de bits et champs de bits. Il faut comprendre qu’un registre est déjà lui même un circuit de plusieurs portes logiques. Ce type d’outil est souvent construit sous forme d’ASIC au sein des blocs logiqus des FGPA, afin de gagner en performances et consommation électrique.

Verilog

Nous choisissons donc ici Verilog (Specifications officielles IEEE Std 1364-2001), c’est un langage très répandu avec de nombreux outils, VHDL est également un langage très répandu. Quoi qu’il en soit, il est toujours intéressant de regarder à des alternatives qui pourraient avoir des aspects intéressants. Je l’ai choisi comme langage de démarrage, parce qu’il est utilisé dans les quelques projets et exemples qui m’intéressent, et parce qu’il y a tous les outils en Logiciels libres et open source (FOSS) nécessaire pour écrire, simuler, vérifier, ainsi que différentes implémentation légères du processeur RISC-V pour l’embarqué (SERV and PicoRV32 (Github) (dont l’implémentation pour Sipeed Lichee Tang (carte FPGA à 20 €) implementation (J’ai personnellement choisi la Sipeed Tang Nano 4K (à 12 €) comme première carte, la Tang Nano coûte 3 € mais n’a que 1000 blocs logiques). Il y a également le très pratique et efficace simulateur Verilator et l’optimiseur de route VTR (Verilog to Routing.

Valeurs

Par défaut, les nombres sont des entiers en Verilog. Il est possible de forcer le nombre de bits (en le précisant avant le caractère apostrophe ') et de le choisir signé (caractère s, signé signifiant pouvant voir un signe négatif) ou non-signé (c’est le cas par défaut). En binaire b, octal o, hexadécimal h, ou encore de forcer décimal d (c’est déjà le cas par défaut). Les données peuvent également être données sous forme de chaînes de caractères.

32'hFFFF00FF  // Valeur RVBA 32 bits non signée en hexadécimal, correspondant à du jaune opaque ( rouge+vert+alpha à 100 %)
8'b00101010   // 42 (binaire non-signé sur 8 bits)
8'b0010_1010  // 42 (binaire non-signé sur 8 bits) version plus facile à lire
8'sb1010_1010 // -86 (binaire signé sur 8 bits)
-8'sd42       // -42 (décimal signé sur 8 bits)
12'o0754      // -rwxr-x-r-- pour les droits (octal non signé sur 12 bits) sur les systèmes de fichiers compatible Unix.
"Hello"       // Une chaine de caractères

Les constantes peuvent être définies en les précédent par une apostrophe suivie du terme define : 'define:

'define mavaleur -8'sd42;

Types

Il existe deux classes différentes de types réseau et logique. Nous ne couvrons ici que :
* wire, qui est de type réseau, implémente juste un fil électrique (wire) pour lier deux composants.
* reg, qui est de type logique, qui peut être défini ou indéifini pour mémoriser des valeurs (comme un registre).

wire w; // un simple fil, appelé w, entre 2 composants
reg r0; // Une mémoire (registre) de 1 bit appelé r0 (registre 0)

La valeur d’un wire est modifiée dynamiquement par les composants qui lui sont liés, mais il est également possible de leur donner une valeur permanente en dur avec la fonction assign :

assign a = 1;

Il existe également des types de plus haut niveau qui agglomèrent plusieurs des éléments précédents, comme par exemple :

integer i,j; // Deux entiers 32 bis signés, appelés i et j
real num;    // Un nombre flottant 64 bits appelé num
time t;      // Un nombre entier non-signé 64 bits représentant le temps (en signaux d'horloge)
realtime rt; // Un nombre flottant 64 bits représentant le temps

À propos du temps, il est intéressant de savoir que le terme #entier peut être utiliser pour attendre n signaux d’horloge. Il ne faut pas mettre ici de point-virgule (;) après la valeur, mais à la place, sur la même ligne, l’instruction qui sera executée après le délai définit. Par exemple :

#20 out = a & b;// Attend 20 signaux, puis calcule la valeur de a ET b

Les éléments de bit simples, wire et reg peuvent être organisés en vecteurs, les bits sont alors notés par convention, du MSB (anglais : « most significant bit » traduit par, « bit de plus fort poids » ) au LSB (anglais : « less significant bit », traduit par : « bit de plus faible poids »).

wire [7:0] Bus0; // Un bus 8 bits appelé Bus0 et connecté au système
reg [31:0] R0;   // un registre 32 bits appelé R0

Il est possible d’utiliser des expressions arithmétiques pour les définire, dans ce cas, l’utilisation de tableaux (voir ci-dessous) est plus pertinent:

reg[8*256:1] texte;   // Une chaîne de caractères de 256 octets. Pour simplfier son utilisation nous commencons à 1, comme nous n'y accéderons pas bits à bits
reg[16*16-1:0] sprite; // un sprite monochrome de 16×16 pixels, il est mieux d'utiliser -1 et de commencer par 0 dans ce cas

Après ces déclarations on peut accéder à des bits en particuliers ou des groupes de bits de la façon suivante :

Bus0[0];   // Accès au LSB de Bus0
Bus0[7:5]; // Accès aux 3 MSB de Bus0 (défini comme 8 bits de 0 à 7)

Verilog permet également de concaténer plusieurs ensembles de bits vers un autre. Par example, ici, on convertir une valeur 16 bit encodée au format de donnée Little Endian en valaur 16 bit au format Big Endian:

BigEndian[15:0] = {LittleEndian[7:0], LittleEndian[15,8]};

Si le bus de destination est de 16 bits ici [15:0] n’est alors pas nécessaire, puisque cela correspond à l’ensemble des bits fournis en entrée (8 + 8).

Et tous ces types peuvent être organisés en tableaux.

Tous les types complexes (dans le sens évolués, pas dans le sens mathématique) et vecteurs peuvent être organsiés en tableaux.

reg[7:0] curseur[0:7];            // Bitmap nonochrome d'un curseur de 8x8 pixels. Ici, curseur est le nom donné
reg[15:0] sprite[0:15];          // Le bitmap monochrome d'un sprite de 16*16 pixels
reg[31:0] palette[0:15];         // Palettes de 16 couleus RGBA8 (RVBA8)
reg[31:0] FrameBuffer[0:307199]; // Un tampon graphique d'écran de 640×480 pixels RGBA8

Les tableaux, contrairement aux vecteurs de bits, sont notés de leur adresse la plus basse à leur plus haute.

Portes

Voicil les portes (et opérateurs) logiques disponibles dans ce langage, ils opèrent sur un bit, mais on peut l’appliquer aux bits d’un vecteur en parallèle:

~a     // NON (NOT)
a & b  // ET (AND)
a | b  // OU (OR)
a ^ b  // OU-x (XOR)
a ~^ b // X-N-OU (XNOR), peut également être écrit ^~

tables de vérité des portes logiques

Il exxiste également deux opérateurs de décalage de bits :

>> // Décalage à droite
<< // Décalage à gauche

Modules

Verilog est organisé par module (un peu comme des classes en programmation objet, ou bien un circuit intégré sur un circuit imprié). Un module comporte :
* Un nom de module
* Son interface entre l’intérieur et l’extérieur du module (penser aux variables ou méthodes publiques en programmation objet, ou aux branches d’un CI en électronique), est une liste de ports définis entre parenthèses comme pour les fonctions dans les langages fonctionnels module module_name (wire a, wire b, wire out); ... endmodule.
* Par défaut, les déclarations sont des blocs logiques exécutés en parallèle.
* Pour éxecuter du code séquentiellement et conditionnellement, les sous-blocs always (et initial dans les bancs d’essai) doivent être utilisés (vir plus bas pour d’avantage de détails).

Exemple simple, écrire une porte « et »

AND
Les opérateurs de bases sont déjà présent en Verilog, mais voici comment ils pourraient être écrits. Dans les fonctions booléennes de Verilog, l’argument de gauche est la sortie (valeur retournée). Une porte « et » (AND), peut donc être réimplémentée de la façon suivante :

module and(f,a,b); // Le caractère ; n'est pas une erreur ici
  output f;
  input a,b;

  assign f = a & b; // ^ est une porte AND
endomdule

Cet exemple devrait être mis dans un fichier nommé "and.v".
* Le type par défaut est wire
* Depius Verilog 2005, les entrées (input) et sorties (output) peuvent être placer dans l’entête du module comme ceci, vous trouverez les 2 versions selon les goûts des développeurs :

module and(output f, input a,b);

Cet exemple est une porte permanente inconditionnelle, il est possible de les utiliser pour faire des circuits complets, mais Verilog est une langage de haut niveau, permettant de programmer des choes plus complexes de façon simple. Les blocs always pour des porticiels (anglais : gatewares) plus complexes.

Blocs initial et always

Il existe deux types de blocs à connaître pour commencer Verilog :
* Les blocs always (toujours) peuvent être synthétisés, et donc utilisés dans les circuits et sont executés à chaque fois que les conditions sont remplies, donc déclenchés par un évenement (en anglais : event), donné entre parenthèses always @(event).
* Les blocs initial (initial) ne peuvent être synthétisés, ils sont donc utilisés uniquement dans les bancs d’essai et exécués une seule fois et inconditionnellement. Ils permettent de donner des condtions et valeurs initiales au test. Il est possible d’avoir plusieurs blocs initial. Cela permet également de tester ou prototyper une fonction simple rapidement grace à la sortie texte du vérificateur/simulateur, avant de le mettre dans un bloc always d’un circuit.

Ils permenttent tous deux de :Front montant (Posedge) et descendant (negedge) sur un signal d'horloge
* exécuter un code séquentiel
* des conditionnels, if else
* des boucles while, for, etc

Un élément typique pour déclencher un always peut être par exemple :
* Un front montant d’horloge (positive clock edge (posedge)
* Un front descendant d’horloge negative clock edge (negedge)

always @(posedge clk)
  ...
end

Mais peut également être un test logique conditionnel :

always @(a or b)
  ...
end

Exemple simple en Verilator

Un exemple simple fourni avec Verilator (j’ai traduit les commentaires) :

module our (clk);
  input clk;  // L'horloge est requise pour obtenir une activation initiale
  always @(posedge clk)
    begin $display("Hello World!"); $finish;
  end
endmodule

Ici, le bloc always est déclench au premier front montant (posedge), il sort à l’écran ($display) une chaîne de caractères « Hello World! », puis termine ($finish) la simulation.

Il est posssible de tester et valider de nombreuses choses avec Verilator avant d’aller plus loin dans le processus de création du FPGA (vérification formelle, conversion en bitstream (qui peut être très long) et écriture sur le FPGA). Une bonne façon de démarrer est de faire une copie de l’exemple donné ci-dessus, puis de modifier le fichier top.v en jouant avec.

Effectuer le test avec Verilator

Les exemples sont installés sur :
* Arch Linux ou Manjaro, dans : /usr/share/verilator/examples/
* Debian ou Ubuntu, dans : /usr/share/doc/verilator/examples/

Donc pour les tester, copier simple le dossier dans votre répertoir personnel ou de travail, où vous avez un accès en écriture, puis construisez le modèle et executez le avec un simple make (Verilator le transpile en C puis le compile, ce qui permet d’avoir une simulation très rapide):

Sur les distributions basés Arch Linux :

cp -a /usr/share/verilator/examples/make_hello_c ~/

Sur les distributions basées sur Debian:

cp -a /usr/share/doc/verilator/examples/make_hello_c ~/

Puis, sur ma distribution:

cd ~/make_hello_c
make

make permet de reconstruire depuis les sources si nécessaire, et exécute immédiatement le banc d’essai.

La sortie du banc est de ce type:

-- RUN ---------------------
obj_dir/Vtop
Hello World!
- top.v:11: Verilog $finish
-- DONE --------------------

Le reste du texte est à propos de la compilation et une proposition d’uitliser le tuto suivant.

Tracer l’exemple avec GTKWave

GTKwave est un outil compagnon à Verilator. Il permet de voir et vérifier le chronographe résultant de la simulation, afin de comprendre le fonctionnement temporel du circuit, et de visualiser ce que pourrait être la source d’un problème possible. Il utilise le fichier .vcd (Value Change Dump), pour tracer. Ce fichier est utilisé comme source pour tracer le chronogramme (Le résultat de sortie de make_tracing_c se trouve dans le sous-répertoire logs/. Le fichier est logs/vlt_dump.vcd, crée après avoir utilisé la commande make).

Pour utiliser l’exemple de tracé avec GTKwave, vous devez avoir installé le paquet GTKwave, puis, comme dans le premier exemple, avoir dupliqué le dossier dans un répertoire dans lequel vous avez les droits en écriture:
* Sur les distributions basées sur Arch Linux :

cp -a /usr/share/verilator/examples/make_tracing_c ~/

* Sur les distributions basées sur Debian :

cp -a /usr/share/doc/verilator/examples/make_tracing_c ~/

Puis, dans tous les cas :

cd ~/make_tracing_c
make
gktwave logs/vlt_dump.vcd

GTKwave
La sortie texte pendant la phase make fournit également des informations intéressantes :

-- RUN ---------------------
obj_dir/Vtop +trace
[1] Tracing to logs/vlt_dump.vcd...

[1] Model running...

[1] clk=1 rstl=1 iquad=1234 -> oquad=1235 owide=3_22222222_11111112
[2] clk=0 rstl=0 iquad=1246 -> oquad=0 owide=0_00000000_00000000
[3] clk=1 rstl=0 iquad=1246 -> oquad=0 owide=0_00000000_00000000
[4] clk=0 rstl=0 iquad=1258 -> oquad=0 owide=0_00000000_00000000
[5] clk=1 rstl=0 iquad=1258 -> oquad=0 owide=0_00000000_00000000
[6] clk=0 rstl=0 iquad=126a -> oquad=0 owide=0_00000000_00000000
[7] clk=1 rstl=0 iquad=126a -> oquad=0 owide=0_00000000_00000000
[8] clk=0 rstl=0 iquad=127c -> oquad=0 owide=0_00000000_00000000
[9] clk=1 rstl=0 iquad=127c -> oquad=0 owide=0_00000000_00000000
[10] clk=0 rstl=1 iquad=128e -> oquad=128f owide=3_22222222_11111112
[11] clk=1 rstl=1 iquad=128e -> oquad=128f owide=3_22222222_11111112
[12] clk=0 rstl=1 iquad=12a0 -> oquad=12a1 owide=3_22222222_11111112
[13] clk=1 rstl=1 iquad=12a0 -> oquad=12a1 owide=3_22222222_11111112
[14] clk=0 rstl=1 iquad=12b2 -> oquad=12b3 owide=3_22222222_11111112
[15] clk=1 rstl=1 iquad=12b2 -> oquad=12b3 owide=3_22222222_11111112
[16] clk=0 rstl=1 iquad=12c4 -> oquad=12c5 owide=3_22222222_11111112
*-* All Finished *-*
- sub.v:29: Verilog $finish
[17] clk=1 rstl=1 iquad=12c4 -> oquad=12c5 owide=3_22222222_11111112

On peut voir ici, chaque étape de l’exécution avec l’horloge (clk) oscillant entre l’état 0 et l’état 1.

Le temps est en tic d’horloge, et celle du banc d’essai peut être défini par la directive timescale, permettant un temps granulaire de plus grande précision. Cela ne nous est pas utile pour le moment.

Le fichier de trace .vcd (Value Change Dump) est défini dans top.v:

$dumpfile("logs/vlt_dump.vcd");

Toutes les étapes se trouvent dans le dossier logs/annotated/ et le fichier de rapport (coverage) dans logs/coverage.dat:

-- COVERAGE ----------------
verilator_coverage --annotate logs/annotated logs/coverage.dat
Total coverage (2/31) 6.00%
See lines with '%00' in logs/annotated

-- DONE --------------------

Le dernier est définit dans sim_main.cpp.

À propos des exemples de Verilator

Dans chaque exemple, il y a un petit code d’interface en C++. La modification du code C++ n’est pas nécessaire pour les tests de base. Lorsque les concepts de bases sont acquis, la partie C++ peut être adaptée pour s’interfacer avec des bibliothèques système, et permetter de simuler les échanges avec des périphériques de communications, audio, graphisme, vidéo etc.

Dans ces simples exemples d’introduction, les plus intéressant pour débuter sont tous disponible en Verilog :
* make_hello_c Hellow World Verilog avec Makefile
* make_hello_sc Hello World Verilog utilisant SystemC et un Makefile
* cmake_hello_c Hello World Verilog avec cmake.
* cmake_hello_sc Hello World Verilog utilisant SystemC et cmake.

SystemC est un ensemble de classes et macros C++ fournissant une interface de simulation pilotée par les évenements, simule les processus concurrents dans un environnement temps-réel.

Les autres exemples sont (avec leurs variantes cmake|make et c|sc) :
* make_tracing_c pour le tracage de l’execution (comme dit au dessus avec l’exemple GTKWave).
* make_protect_lib pour créer une bibliothèque protégée DPI (Direct Programming Interface), une interface entre SystemVerilog et des fonctions dans un langage comme C ou C++.

fSystem Verilog est une évolution de Verilog, c’est donc un HDL avec d’avantage de fonctionnalités, et également classé comme un HVL (Hardware Verification Language), il ajoute différents types et blocs séquenciels, et permet la programmation orientée objet avec une syntaxe proche de C sur certains points.

Quelques extensions de fichiers que vous trouverez dans le domaine de Verilog, System Verilog et simulateurs liés sont :
* .v comme Verilog.
* .vc (verilog ???) ou .f comme File, utilisé pour les projets importants, comportant des argiments à passer à Verilator (ou un autre simulateur) tels que les drapeaux (flags), des dossiers d’include, et des bibliothèques liées pour la simulation.
* .vcd comme Value Change Dump file, contient les sorties de traces de la simulation pour leur analyse (voir au dessus).
* .vo comme Verilog Output file.
* .sv comme System Verilog,

Exemple pratique de base avec Verilator


Nous allons donc réutiliser le simple exemple avec Make (vous pouvez choisirles exemples avec cmake à la place, dans ce cas, vous n’aurez qu’à invoquer la commande cmake à la place de la commande make.

J’ai dans ce cas, copié l’exemple make_hello_c dans un repertoire avec droits en écriture :

cp -a /usr/share/verilator/examples/make_hello_c verilator_test
cd verilator_test

puis ai édité top.v ( vim, emacs, gedit, ou n’importe quel éditeur de texte de votre choix fait l’affaire), puis remplacé son contenu.

Voici un simple exemple que j’ai utilisé pour mes tests. Je voulais comprendre comment fonctionnait les accès aux registres Verilog simples, et à différent types de données, dont un sprite (celui affiché à côté du titre de cette section), vous povuez décharger cette version de top.v ici. Je traduis ici les commentaires :

module top;
 reg [8*11:1] str1;
 reg [8*25:1] str2;  // remplit à gauche par des espaces
 reg a,b,c;
 reg [7:0] sprite[0:7];  // utilise un octet par ligne
 reg [15:0] sprite2;  // sprite sous forme de champs de bits
 integer i;

 initial begin
   str1 = "Hello World"; // tests d'initialisations de chaîne de caractère
   str2 = "Hello World";

   a = 1'b1; // Tests d'initialisation de bits
   b = a^1;
   c = a^0;

   sprite[0] = 8'b10011000; // Tests d'initialisation de sprites
   sprite[1] = 8'b00100100;
   sprite[2] = 8'b01000010;
   sprite[3] = 8'b10011001;
   sprite[4] = 8'b10011001;
   sprite[5] = 8'b01000010;
   sprite[6] = 8'b00100100;
   sprite[7] = 8'b00011000;

   sprite2[ 7:0] = 8'b10011000;
   sprite2[15:8] = 8'b00100100;

   $display ("str1 = %s", str1); // Affichage des chaînes de caractères
   $display ("str2 = %s", str2);

   $display ("a = %d", a);       // Affichage des bits
   $display ("b = a^1 = %d", b);
   $display ("c = a^0 = %d", c);

   for ( i=0; i<8; i=i+1) begin  // Affichage des sprites
    $display ("sprite[%2d] = %b",i,sprite[i]);
   end
   for ( i=0; i<2; i=i+1) begin  // essaie de lire des rangées de bits, en tantant des sorties du domaine
    $display ("sprite2[8*i(%1d) +: 8] = %8b",i,sprite2[8*i +:8]);
    $display ("sprite2[8*i(%1d) -: 8] = %8b",i,sprite2[8*i -:8]);
    $display ("sprite2[4*i(%1d) -: 8] = %8b",i,sprite2[4*i -:8]);
   end
 end 
endmodule

Pour le tester, lancer juste la commande make. Ici, les commentaires en bleu sont des commentaires de la sorti uniquement dans ce billet de blog, il ne seront pas visible à l’execution:

make
-- VERILATE & BUILD -------- 
[...]  Cette partie est le log de compilation, je ne l'ai pas collé
-- RUN ---------------------   C'est ici que c'est intéressant
obj_dir/Vtop
str1 = Hello World
str2 =               Hello World    str2 de 25 caractères rempli par des espaces
a = 1
b = a^1 = 0
c = a^0 = 1
sprite[ 0] = 10011000    Huits lignes du sprite
sprite[ 1] = 00100100
sprite[ 2] = 01000010
sprite[ 3] = 10011001
sprite[ 4] = 10011001
sprite[ 5] = 01000010
sprite[ 6] = 00100100
sprite[ 7] = 00011000
sprite2[8*i(0) +: 8] = 10011000      Quelques acces de tests à des plages de bits
sprite2[8*i(0) -: 8] = x0010010      Nous sortons des domaines du registre ici, des x sont affichés
sprite2[4*i(0) -: 8] = x0010010
sprite2[8*i(1) +: 8] = 00100100
sprite2[8*i(1) -: 8] = 01001100
sprite2[4*i(1) -: 8] = xxxxx001

Pour aller plus loin

Documentation relativement complètes en ligne :

À propos de Verilog :
* Anglais : Un manuel Verilog complet sur Chip Verify
* Anglais : Tutorial Verilog pour les débutants sur ReferenceDesigner.com
* Anglais : Survol de Verilog en quelques écrans de présentation (format PDF) sur euler.ecs.umass.edu
* Anglais : Verilog Quick Reference Card.pdf
* Anglais :
Verilog HDL Quick reference Guide
* Français : Syntaxe de Verilog à hdl.telecom-paristech.fr

Bancs d’essai en Verilog, SystemC et System Verilog:
* Anglais : Comment écrire un banc d’essai de base en Verilog, en utilisant un template en C++. Ce site, FPGA tutorial, à trois sujets principaux, VHDL, Verilog & System Verilog.
* Anglais : Tutoriels sur Systemverilog et SystemC.
* Anglais : Quelques tutoriels sur System Verilog.
* Français : SystemVerilog en 13 minutes sur sen.enst.fr
* Verilog Simulation with Verilator and SDL Utilisation de la bibliothèque SDL pour simuler une sortie graphique VGA, avec Verilator. Utilise Verilog et un peu de SystemVerilog.

Quelques projets FPGA intéressants:
* Anglais : From Nand To Tetris (De Nand à Tetris), toutes les étapes pour faire, en quelques exercices, un ordinateur basé sur un CPU 16 bits, en n’utilisant que des portes NAND (jeu intéressant et formateur), puis construction d’un jeu Tetris avec ce petit système. Ils utilisent un HDL développé par cette université, mais il existe déjà des ports, comme exemples, comme celui-ci en Verilog utilisant Ikarus Verilog simulator (également logiciel libre de simulation, c’était la référence avnat Verilator), un autre en Verilog pour le Lattice ICE40 FPGA, dont tous les outils pour la programmation sont libres (testé avec une carte en matériel libre/ouvert Olimex) et des outils open source (YoSYS comme synthétiseur), encore en Verilog pour la carte De0-nano (utilisant Altera Cyclone IV FPGA).
*
Implementation de UART/port série/interface RS-232 pour FPGA (versions Verilog et VHDL).
* Consolite, une console de jeu légère en Verilog pour FPGA, programmable en assembleur. Un émulateur est également disponible.
* FloPoCoUnité de caclculs arithmétique à virgule flottante pour FPGA dévelopée par l’INRIA.
* Anglais : Tang nano MIDI Sounder, un synthétiseur MIDI, à la sonorité 8 bits sympa.
* Japonais : Processor RISC-V SERV pour Tang Nano
* Japonais : Tetris pour Tang Nano en Verilog
* ZipCPU Un blog pour le CPU ZipCPU avec un des exemples de banc d’ssai Verilator intéressant, utilisant des patrons C++ pour des bancs d’essai génériques.

Pour les hackers amoureux des logiciels libres :
* Apicula project, un projet d’ouvertur d’ouverture des bitstream des FPGA Gow1n.