mirror of
https://github.com/Derisis13/derisis13.github.io.git
synced 2025-12-06 22:12:48 +01:00
Compare commits
2 Commits
e980486f27
...
93673c46b2
| Author | SHA1 | Date | |
|---|---|---|---|
93673c46b2
|
|||
| 0efe1e7cdb |
257
_posts/2025-02-10-open-source-fpga-development.md
Normal file
257
_posts/2025-02-10-open-source-fpga-development.md
Normal file
@@ -0,0 +1,257 @@
|
||||
---
|
||||
layout: post
|
||||
title: "How I got started with open-source FPGA development"
|
||||
tag: "FPGA"
|
||||
---
|
||||
|
||||
In the software world, open-source toolchains are taken for granted.
|
||||
In the FPGA/hardware world, the situation is not as good, but with the right choice of FPGA, it is feasible.
|
||||
Allow me to tell my tale about how I succeeded in bringing up my Artix devboard with only open-source programs.
|
||||
|
||||
|
||||
# Writing VHDL in Neovim
|
||||
|
||||
My go-to text editor is Neovim.
|
||||
I've been using it for years (I think I picked it up in 2022), and it stuck with me.
|
||||
I'm not particularly good at it (I only know the basic keybinds), but it's already better than anything else I've tried.
|
||||
The most important tools for VHDL are the language server: `vhdl-ls` (also known as `rust_hdl`), the Treesitter VHDL grammar, and my snippets.
|
||||
My config—based on NvChad—can be found in my dotfiles repository.
|
||||
|
||||
For the sake of trying out the toolchains, I made the simplest possible LED blinking example:
|
||||
```vhdl
|
||||
-- Test entity for synthesis
|
||||
|
||||
library ieee;
|
||||
use ieee.std_logic_1164.all;
|
||||
use ieee.NUMERIC_STD.all;
|
||||
|
||||
entity blink is
|
||||
port (
|
||||
led_o : out std_logic;
|
||||
clk : in std_logic;
|
||||
areset : in std_logic
|
||||
);
|
||||
end entity blink;
|
||||
|
||||
architecture rtl of blink is
|
||||
signal counter : unsigned(23 downto 0); -- around 1 Hz with 12 MHz oscillator
|
||||
signal led_state : std_logic;
|
||||
begin
|
||||
|
||||
L_BLINK_PROC: process(clk)
|
||||
begin
|
||||
if rising_edge(clk) then
|
||||
if areset = '1' then
|
||||
counter <= (others => '0');
|
||||
led_state <= '0';
|
||||
else
|
||||
counter <= counter + 1;
|
||||
if counter = 0 then
|
||||
led_state <= not led_state;
|
||||
end if;
|
||||
end if;
|
||||
end if;
|
||||
end process L_BLINK_PROC;
|
||||
led_o <= led_state;
|
||||
|
||||
end architecture rtl;
|
||||
```
|
||||
I also made a simple testbench so I could try simulation too:
|
||||
```vhdl
|
||||
-- Testbench for the blink example
|
||||
|
||||
entity tb_blink is
|
||||
end entity tb_blink;
|
||||
|
||||
library ieee;
|
||||
use ieee.std_logic_1164.all;
|
||||
|
||||
architecture tb of tb_blink is
|
||||
signal clk : std_logic := '0';
|
||||
signal areset_n : std_logic;
|
||||
signal led : std_logic;
|
||||
begin
|
||||
areset_n <= '1', '0' after 100 ns;
|
||||
L_STIM: process
|
||||
begin
|
||||
for i in 0 to 2**24 + 5 loop
|
||||
wait for 10 ns;
|
||||
clk <= '1';
|
||||
wait for 10 ns;
|
||||
clk <= '0';
|
||||
end loop;
|
||||
wait;
|
||||
end process L_STIM;
|
||||
|
||||
L_DUT: entity work.blink
|
||||
port map(
|
||||
led_o => led,
|
||||
clk => clk,
|
||||
areset => areset
|
||||
);
|
||||
end architecture tb;
|
||||
```
|
||||
The two files are named `blink.vhd` and `tb_blink.vhd`.
|
||||
For `vhdl-ls`, I also made a descriptor file (`vhdl-ls.toml`):
|
||||
```toml
|
||||
[libraries]
|
||||
defaultlib.files = [
|
||||
"*.vhd",
|
||||
]
|
||||
```
|
||||
|
||||
|
||||
# Simulation with GHDL and GTKWave
|
||||
|
||||
Apart from creating my sources, simulating was one of the easiest steps—it just worked.
|
||||
The only requirements here are GHDL for elaboration and running the simulation, and GTKWave for viewing the output waveform.
|
||||
The process is well documented in [GHDL's documentation](https://ghdl.github.io/ghdl/using/Simulation.html).
|
||||
All I had to do was:
|
||||
```sh
|
||||
mkdir ./workdir
|
||||
ghdl -a --workdir=./workdir blink.vhd tb_blink.vhd
|
||||
ghdl -e --workdir=./workdir tb_blink
|
||||
ghdl -r --workdir=./workdir tb_blink --wave=wave.ghw
|
||||
```
|
||||
The first GHDL command (`-a`) analyzes the source files into the directory we just created (`./workdir`).
|
||||
The second GHDL command (`-e`) elaborates the top-level entity, creating the simulation binary.
|
||||
The third one runs the simulation, writing the output waveform into `wave.ghw`.
|
||||
|
||||
Do note that for analysis, source files are referenced, but for elaboration and running, entity names have to be specified instead of filenames.
|
||||
Additionally, elaboration and running can be combined into a single command:
|
||||
```sh
|
||||
ghdl --elab-run --workdir=./workdir tb_blink --wave=wave.ghw
|
||||
```
|
||||
To view the output, I could open GTKWave graphically and then open the file from the picker, or run it from the CLI like this (this still opens a GUI window):
|
||||
```sh
|
||||
gtkwave wave.ghw
|
||||
```
|
||||
GTKWave is an OK viewer; at least I don't have to re-run the simulation when I want to look at a new signal, unlike with ModelSim.
|
||||
|
||||
|
||||
# Synthesis with GHDL and Yosys
|
||||
|
||||
But GHDL isn't just a simulator.
|
||||
It can also do—albeit experimental—synthesis and technology mapping by hooking into Yosys.
|
||||
This is so much in development that not many packages are provided—I was lucky that someone had already made a [Copr repo](https://copr.fedorainfracloud.org/coprs/rezso/HDL/) for it, so I didn't have to compile it on my Fedora machine.
|
||||
I also saw an AUR package for `ghdl-yosys-plugin`, so following along on Arch is probably easy too.
|
||||
I do not know anything about Debian/Ubuntu; there may be a PPA, but if you have to build from source, check this page: [https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain\_arty.md](https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md)
|
||||
|
||||
To keep the clutter away from source files, I made a build directory:
|
||||
```sh
|
||||
mkdir ./build
|
||||
```
|
||||
To use the GHDL Yosys plugin, I launched Yosys like this:
|
||||
```sh
|
||||
yosys -m ghdl
|
||||
```
|
||||
Unless you specify `-m ghdl`, its plugin will be missing when you run Yosys.
|
||||
In its console, I first issued `ghdl blink.vhd -e blink` to elaborate my source(s), with `blink` as the top-level entity.
|
||||
Then, I ran `synth_xilinx -json ./build/blink.json` to synthesize a netlist into a JSON file, using technology mapping to the Xilinx 7 family.
|
||||
|
||||
Alternatively, a single script for the same commands can be written like:
|
||||
```sh
|
||||
yosys -m ghdl -p "ghdl blink.vhd -e blink; synth_xilinx -json ./build/blink.json"
|
||||
```
|
||||
One downside is that VHDL 2008 is not—or not completely—supported.
|
||||
To stay safe, I omitted the `std=08` flag everywhere.
|
||||
|
||||
|
||||
# Place & route with NextPNR
|
||||
|
||||
Once I had a netlist, I proceeded to use NextPNR to place and route it to actual components in the FPGA.
|
||||
My device is an Artix 7 (XC7A35T CPG236-1) as part of a Digilent CMOD A7 devboard.
|
||||
I first made the mistake of using the `nextpnr-xilinx` fork, which is not maintained regularly and refused to work for me.
|
||||
A bit of information that was unnecessarily hard to find is that the himbaechel backend of NextPNR (which is built into the `nextpnr` package provided by the Copr repo) supports Xilinx 7 FPGAs—including my Artix 7.
|
||||
|
||||
An `xdc` file is required to map top-level inputs and outputs to physical pins.
|
||||
I derived this from the [CMOD A7's xdc file](https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc) provided by Digilent:
|
||||
```xdc
|
||||
set_property LOC L17 [get_ports {clk}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {clk}]
|
||||
create_clock -add -name sys_clk_pin -period 83.33 -waveform {0 41.66} [get_ports {clk}]
|
||||
|
||||
set_property LOC A17 [get_ports {led_o}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {led_o}]
|
||||
|
||||
set_property LOC A18 [get_ports {areset}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {areset}]
|
||||
```
|
||||
I spent an embarrassing amount of time debugging an error caused by comments (and semicolons) at the end of the xdc file's lines.
|
||||
These completely break NextPNR's xdc parser, so they had to go.
|
||||
|
||||
I also used the this file to specify my timing constraints (the 12 MHz clock of the CMOD A7) but due to limitations of NextPNR isn't used for static timing analysis (STA).
|
||||
To check if my design can operate at the required frequency, I had to specify an additional argument.
|
||||
NextPNR doesn't know the `-add`, `-name` and `-waveform` arguments (I guess they are used by Vivado for simulation), but only shows a warning if they are left in.
|
||||
My final place and route command thus looked like this:
|
||||
```sh
|
||||
nextpnr-himbaechel --device xc7a35tcpg236-1 --json ./build/blink.json -o xdc="Cmod-A7-Master.xdc" --write ./build/blink_routed.json -o fasm=./build/blink.fasm --router router2 --freq 12
|
||||
```
|
||||
The `--router` argument had little effect on my design, but it was in the NextPNR GitHUB repo's example code so I left it there assuming it does no harm.
|
||||
The `--freq` argument specifies the clock frequency (in megahertz) for STA.
|
||||
The output file I'm going to work with in the following section is `blink.fasm`.
|
||||
|
||||
|
||||
# Bitstream generation with Project X-Ray
|
||||
|
||||
To write the configuration to the FPGA I needed it in a loadable format.
|
||||
For Xilinx devices it's a bitstream, also known as `.bit` files.
|
||||
I achieved this in two steps: first I converted the `fasm` file to `frames`, then `frames` to `bit`.
|
||||
The software collection that's going to help me generate programming files for the Artix 7 (and for Xilinx FPGAs in general) is called Project X-Ray.
|
||||
I preformet the first step with Xray's `fasm2frames` tool, which is sadly broken in the package form the Copr repo.
|
||||
As a dirty fix, I cloned the [Project X-Ray GitHUB repo](https://github.com/f4pga/prjxray) (to `~/.local/bin/build_stage/`) then used the script in its sources like this:
|
||||
```sh
|
||||
python ~/.local/bin/build_stage/prjxray/utils/fasm2frames.py --db-root /usr/share/xray/database/artix7 --part xc7a35tcpg236-1 ./build/blink.fasm ./build/blink.frames
|
||||
```
|
||||
I still had to source database from the `projectxray-data` package, as it's not stored in the GitHUB repo directly.
|
||||
|
||||
For step two, I employed the tool `xc7frames2bit` that worked from the installation.
|
||||
This saved me some time as I would have had to compile this program otherwise (since it's written in C, unlike `fasm2frames`).
|
||||
The command I used for the conversion is what you'd expect:
|
||||
```sh
|
||||
xc7frames2bit --part_file /usr/share/xray/database/artix7/xc7a35tcpg236-1/part.yaml --frm_file ./build/blink.frames --output_file ./build/blink.bit
|
||||
```
|
||||
Note that depending on the installation of Project X-Ray, the database directory may be different from mine; find or locate commands can be used to determine the exact path.
|
||||
Same goes for the part number: different FPGAs from different families need different databases/partfiles.
|
||||
|
||||
|
||||
# Programming with openFPGAloader
|
||||
|
||||
At last I have my bitstream.
|
||||
Getting this on the FPGA required the `openFPGAloader` package, also provided by the Copr repo.
|
||||
For now I loaded the configuration into SRAM, but the CMOD A7 also comes with a serial flash memory to store the config.
|
||||
The command I used to write the sram looked like this:
|
||||
```sh
|
||||
/usr/bin/openFPGALoader -b cmoda7_35t ./build/blink.bit
|
||||
```
|
||||
And flashing would've looked like this:
|
||||
```sh
|
||||
/usr/bin/openFPGALoader -b cmoda7_35t -f blink.bit
|
||||
```
|
||||
Once this was complete, I had a led blinking at approximately 0.5 Hz.
|
||||
Project success!
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
While it's a far cry from proprietary integrated development environments, fully open-source FPGA synthesis is possible.
|
||||
It's limited to Xilinx, Lattice and some other manufacturers (and even here the supported devices/families are limited too).
|
||||
The weak points are no or limited VHDL 2008 support, the difficulty of hunting down every component (and their documentation).
|
||||
Thus the barrier to entry is quite high, it took me roughly a day to get it all sorted out with prior knowledge of FPGAs and minimal prior knowledge of the software used.
|
||||
Advanced features like post-layout synthesis, IP core wizzards and graphical pin planners are either non-existent or not practical.
|
||||
|
||||
On the other hand, these tools feel very fast, especially the synthesis workflow.
|
||||
I haven't done any benchmarks, but especially with Modelsim's free edition slowing down significantly over 10000 lines GHDL should be able to compete with it.
|
||||
Also, since all of them (except GTKWave) are command-line tools, their outputs are mostly in plain text, they fit the general tools of open-source development rather well (eg. git and make).
|
||||
This makes them feel more ergonomic for a nerd like me, who even edits text in the terminal.
|
||||
All in all I wouldn't use them in my dayjob (they are just not on par with vendor IDEs), but they'll do fine for my hobby projects.
|
||||
|
||||
|
||||
# Sources:
|
||||
nextpnr-himbaechel usage: [https://github.com/YosysHQ/nextpnr/tree/master/himbaechel/uarch/xilinx/examples/arty-a35](https://github.com/YosysHQ/nextpnr/tree/master/himbaechel/uarch/xilinx/examples/arty-a35)
|
||||
general workflow: [https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md](https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md), [https://github.com/BrunoLevy/learn-fpga/blob/master/Basic/ARTY/ARTY_blink/makeit.sh](https://github.com/BrunoLevy/learn-fpga/blob/master/Basic/ARTY/ARTY_blink/makeit.sh)
|
||||
CMOD A7 docs: [https://digilent.com/reference/_media/reference/programmable-logic/cmod-a7/cmod_a7_rm.pdf](https://digilent.com/reference/_media/reference/programmable-logic/cmod-a7/cmod_a7_rm.pdf)
|
||||
CMOD a7 xdc file: [https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc](https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc)
|
||||
GHDL Simulation: [https://ghdl.github.io/ghdl/using/Simulation.html](https://ghdl.github.io/ghdl/using/Simulation.html)
|
||||
GHDL synthesis: [https://github.com/ghdl/ghdl-yosys-plugin](https://github.com/ghdl/ghdl-yosys-plugin), [https://wiki.f-si.org/images/b/b3/Ghdl-FSiC2022.pdf](https://wiki.f-si.org/images/b/b3/Ghdl-FSiC2022.pdf)
|
||||
Project X-Ray: [https://github.com/f4pga/prjxray](https://github.com/f4pga/prjxray)
|
||||
286
_site/feed.xml
286
_site/feed.xml
@@ -1,4 +1,231 @@
|
||||
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.0">Jekyll</generator><link href="http://localhost:4000/feed.xml" rel="self" type="application/atom+xml" /><link href="http://localhost:4000/" rel="alternate" type="text/html" /><updated>2025-01-09T22:40:03+01:00</updated><id>http://localhost:4000/feed.xml</id><title type="html">Derisis13’s temporary blog</title><subtitle>Just some nerd rambling</subtitle><entry><title type="html">The Self-Contradiction of Spice and Wolf</title><link href="http://localhost:4000/2025/01/09/Spice-and-Wolf.html" rel="alternate" type="text/html" title="The Self-Contradiction of Spice and Wolf" /><published>2025-01-09T00:00:00+01:00</published><updated>2025-01-09T00:00:00+01:00</updated><id>http://localhost:4000/2025/01/09/Spice-and-Wolf</id><content type="html" xml:base="http://localhost:4000/2025/01/09/Spice-and-Wolf.html"><p>I really enjoyed the 2008 <em>Spice and Wolf</em> series when I watched it, so I was excited to hear it was being worked on again.
|
||||
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.0">Jekyll</generator><link href="http://localhost:4000/feed.xml" rel="self" type="application/atom+xml" /><link href="http://localhost:4000/" rel="alternate" type="text/html" /><updated>2025-02-10T01:56:26+01:00</updated><id>http://localhost:4000/feed.xml</id><title type="html">Derisis13’s temporary blog</title><subtitle>Just some nerd rambling</subtitle><entry><title type="html">How I got started with open-source FPGA development</title><link href="http://localhost:4000/2025/02/10/open-source-fpga-development.html" rel="alternate" type="text/html" title="How I got started with open-source FPGA development" /><published>2025-02-10T00:00:00+01:00</published><updated>2025-02-10T00:00:00+01:00</updated><id>http://localhost:4000/2025/02/10/open-source-fpga-development</id><content type="html" xml:base="http://localhost:4000/2025/02/10/open-source-fpga-development.html"><p>In the software world, open-source toolchains are taken for granted.
|
||||
In the FPGA/hardware world, the situation is not as good, but with the right choice of FPGA, it is feasible.
|
||||
Allow me to tell my tale about how I succeeded in bringing up my Artix devboard with only open-source programs.</p>
|
||||
|
||||
<h1 id="writing-vhdl-in-neovim">Writing VHDL in Neovim</h1>
|
||||
|
||||
<p>My go-to text editor is Neovim.
|
||||
I’ve been using it for years (I think I picked it up in 2022), and it stuck with me.
|
||||
I’m not particularly good at it (I only know the basic keybinds), but it’s already better than anything else I’ve tried.
|
||||
The most important tools for VHDL are the language server: <code class="language-plaintext highlighter-rouge">vhdl-ls</code> (also known as <code class="language-plaintext highlighter-rouge">rust_hdl</code>), the Treesitter VHDL grammar, and my snippets.
|
||||
My config—based on NvChad—can be found in my dotfiles repository.</p>
|
||||
|
||||
<p>For the sake of trying out the toolchains, I made the simplest possible LED blinking example:</p>
|
||||
<div class="language-vhdl highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">-- Test entity for synthesis</span>
|
||||
|
||||
<span class="k">library</span> <span class="n">ieee</span><span class="p">;</span>
|
||||
<span class="k">use</span> <span class="n">ieee</span><span class="o">.</span><span class="n">std_logic_1164</span><span class="o">.</span><span class="k">all</span><span class="p">;</span>
|
||||
<span class="k">use</span> <span class="n">ieee</span><span class="o">.</span><span class="n">NUMERIC_STD</span><span class="o">.</span><span class="k">all</span><span class="p">;</span>
|
||||
|
||||
<span class="k">entity</span> <span class="n">blink</span> <span class="k">is</span>
|
||||
<span class="k">port</span> <span class="p">(</span>
|
||||
<span class="n">led_o</span> <span class="p">:</span> <span class="k">out</span> <span class="kt">std_logic</span><span class="p">;</span>
|
||||
<span class="n">clk</span> <span class="p">:</span> <span class="k">in</span> <span class="kt">std_logic</span><span class="p">;</span>
|
||||
<span class="n">areset</span> <span class="p">:</span> <span class="k">in</span> <span class="kt">std_logic</span>
|
||||
<span class="p">);</span>
|
||||
<span class="k">end</span> <span class="k">entity</span> <span class="n">blink</span><span class="p">;</span>
|
||||
|
||||
<span class="k">architecture</span> <span class="n">rtl</span> <span class="k">of</span> <span class="n">blink</span> <span class="k">is</span>
|
||||
<span class="k">signal</span> <span class="n">counter</span> <span class="p">:</span> <span class="kt">unsigned</span><span class="p">(</span><span class="mi">23</span> <span class="k">downto</span> <span class="mi">0</span><span class="p">);</span> <span class="c1">-- around 1 Hz with 12 MHz oscillator</span>
|
||||
<span class="k">signal</span> <span class="n">led_state</span> <span class="p">:</span> <span class="kt">std_logic</span><span class="p">;</span>
|
||||
<span class="k">begin</span>
|
||||
|
||||
<span class="n">L_BLINK_PROC</span><span class="p">:</span> <span class="k">process</span><span class="p">(</span><span class="n">clk</span><span class="p">)</span>
|
||||
<span class="k">begin</span>
|
||||
<span class="k">if</span> <span class="n">rising_edge</span><span class="p">(</span><span class="n">clk</span><span class="p">)</span> <span class="k">then</span>
|
||||
<span class="k">if</span> <span class="n">areset</span> <span class="o">=</span> <span class="sc">'1'</span> <span class="k">then</span>
|
||||
<span class="n">counter</span> <span class="o">&lt;=</span> <span class="p">(</span><span class="k">others</span> <span class="o">=&gt;</span> <span class="sc">'0'</span><span class="p">);</span>
|
||||
<span class="n">led_state</span> <span class="o">&lt;=</span> <span class="sc">'0'</span><span class="p">;</span>
|
||||
<span class="k">else</span>
|
||||
<span class="n">counter</span> <span class="o">&lt;=</span> <span class="n">counter</span> <span class="o">+</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="k">if</span> <span class="n">counter</span> <span class="o">=</span> <span class="mi">0</span> <span class="k">then</span>
|
||||
<span class="n">led_state</span> <span class="o">&lt;=</span> <span class="ow">not</span> <span class="n">led_state</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">if</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">if</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">if</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">process</span> <span class="n">L_BLINK_PROC</span><span class="p">;</span>
|
||||
<span class="n">led_o</span> <span class="o">&lt;=</span> <span class="n">led_state</span><span class="p">;</span>
|
||||
|
||||
<span class="k">end</span> <span class="k">architecture</span> <span class="n">rtl</span><span class="p">;</span>
|
||||
</code></pre></div></div>
|
||||
<p>I also made a simple testbench so I could try simulation too:</p>
|
||||
<div class="language-vhdl highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">-- Testbench for the blink example</span>
|
||||
|
||||
<span class="k">entity</span> <span class="n">tb_blink</span> <span class="k">is</span>
|
||||
<span class="k">end</span> <span class="k">entity</span> <span class="n">tb_blink</span><span class="p">;</span>
|
||||
|
||||
<span class="k">library</span> <span class="n">ieee</span><span class="p">;</span>
|
||||
<span class="k">use</span> <span class="n">ieee</span><span class="o">.</span><span class="n">std_logic_1164</span><span class="o">.</span><span class="k">all</span><span class="p">;</span>
|
||||
|
||||
<span class="k">architecture</span> <span class="n">tb</span> <span class="k">of</span> <span class="n">tb_blink</span> <span class="k">is</span>
|
||||
<span class="k">signal</span> <span class="n">clk</span> <span class="p">:</span> <span class="kt">std_logic</span> <span class="p">:</span><span class="o">=</span> <span class="sc">'0'</span><span class="p">;</span>
|
||||
<span class="k">signal</span> <span class="n">areset_n</span> <span class="p">:</span> <span class="kt">std_logic</span><span class="p">;</span>
|
||||
<span class="k">signal</span> <span class="n">led</span> <span class="p">:</span> <span class="kt">std_logic</span><span class="p">;</span>
|
||||
<span class="k">begin</span>
|
||||
<span class="n">areset_n</span> <span class="o">&lt;=</span> <span class="sc">'1'</span><span class="p">,</span> <span class="sc">'0'</span> <span class="k">after</span> <span class="mi">100</span> <span class="n">ns</span><span class="p">;</span>
|
||||
<span class="n">L_STIM</span><span class="p">:</span> <span class="k">process</span>
|
||||
<span class="k">begin</span>
|
||||
<span class="k">for</span> <span class="n">i</span> <span class="k">in</span> <span class="mi">0</span> <span class="k">to</span> <span class="mi">2</span><span class="o">**</span><span class="mi">24</span> <span class="o">+</span> <span class="mi">5</span> <span class="k">loop</span>
|
||||
<span class="k">wait</span> <span class="k">for</span> <span class="mi">10</span> <span class="n">ns</span><span class="p">;</span>
|
||||
<span class="n">clk</span> <span class="o">&lt;=</span> <span class="sc">'1'</span><span class="p">;</span>
|
||||
<span class="k">wait</span> <span class="k">for</span> <span class="mi">10</span> <span class="n">ns</span><span class="p">;</span>
|
||||
<span class="n">clk</span> <span class="o">&lt;=</span> <span class="sc">'0'</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">loop</span><span class="p">;</span>
|
||||
<span class="k">wait</span><span class="p">;</span>
|
||||
<span class="k">end</span> <span class="k">process</span> <span class="n">L_STIM</span><span class="p">;</span>
|
||||
|
||||
<span class="n">L_DUT</span><span class="p">:</span> <span class="k">entity</span> <span class="n">work</span><span class="o">.</span><span class="n">blink</span>
|
||||
<span class="k">port</span> <span class="k">map</span><span class="p">(</span>
|
||||
<span class="n">led_o</span> <span class="o">=&gt;</span> <span class="n">led</span><span class="p">,</span>
|
||||
<span class="n">clk</span> <span class="o">=&gt;</span> <span class="n">clk</span><span class="p">,</span>
|
||||
<span class="n">areset</span> <span class="o">=&gt;</span> <span class="n">areset</span>
|
||||
<span class="p">);</span>
|
||||
<span class="k">end</span> <span class="k">architecture</span> <span class="n">tb</span><span class="p">;</span>
|
||||
</code></pre></div></div>
|
||||
<p>The two files are named <code class="language-plaintext highlighter-rouge">blink.vhd</code> and <code class="language-plaintext highlighter-rouge">tb_blink.vhd</code>.
|
||||
For <code class="language-plaintext highlighter-rouge">vhdl-ls</code>, I also made a descriptor file (<code class="language-plaintext highlighter-rouge">vhdl-ls.toml</code>):</p>
|
||||
<div class="language-toml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nn">[libraries]</span>
|
||||
<span class="py">defaultlib.files</span> <span class="p">=</span> <span class="p">[</span>
|
||||
<span class="s">"*.vhd"</span><span class="p">,</span>
|
||||
<span class="p">]</span>
|
||||
</code></pre></div></div>
|
||||
|
||||
<h1 id="simulation-with-ghdl-and-gtkwave">Simulation with GHDL and GTKWave</h1>
|
||||
|
||||
<p>Apart from creating my sources, simulating was one of the easiest steps—it just worked.
|
||||
The only requirements here are GHDL for elaboration and running the simulation, and GTKWave for viewing the output waveform.
|
||||
The process is well documented in <a href="https://ghdl.github.io/ghdl/using/Simulation.html">GHDL’s documentation</a>.
|
||||
All I had to do was:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">mkdir</span> ./workdir
|
||||
ghdl <span class="nt">-a</span> <span class="nt">--workdir</span><span class="o">=</span>./workdir blink.vhd tb_blink.vhd
|
||||
ghdl <span class="nt">-e</span> <span class="nt">--workdir</span><span class="o">=</span>./workdir tb_blink
|
||||
ghdl <span class="nt">-r</span> <span class="nt">--workdir</span><span class="o">=</span>./workdir tb_blink <span class="nt">--wave</span><span class="o">=</span>wave.ghw
|
||||
</code></pre></div></div>
|
||||
<p>The first GHDL command (<code class="language-plaintext highlighter-rouge">-a</code>) analyzes the source files into the directory we just created (<code class="language-plaintext highlighter-rouge">./workdir</code>).
|
||||
The second GHDL command (<code class="language-plaintext highlighter-rouge">-e</code>) elaborates the top-level entity, creating the simulation binary.
|
||||
The third one runs the simulation, writing the output waveform into <code class="language-plaintext highlighter-rouge">wave.ghw</code>.</p>
|
||||
|
||||
<p>Do note that for analysis, source files are referenced, but for elaboration and running, entity names have to be specified instead of filenames.
|
||||
Additionally, elaboration and running can be combined into a single command:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ghdl <span class="nt">--elab-run</span> <span class="nt">--workdir</span><span class="o">=</span>./workdir tb_blink <span class="nt">--wave</span><span class="o">=</span>wave.ghw
|
||||
</code></pre></div></div>
|
||||
<p>To view the output, I could open GTKWave graphically and then open the file from the picker, or run it from the CLI like this (this still opens a GUI window):</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>gtkwave wave.ghw
|
||||
</code></pre></div></div>
|
||||
<p>GTKWave is an OK viewer; at least I don’t have to re-run the simulation when I want to look at a new signal, unlike with ModelSim.</p>
|
||||
|
||||
<h1 id="synthesis-with-ghdl-and-yosys">Synthesis with GHDL and Yosys</h1>
|
||||
|
||||
<p>But GHDL isn’t just a simulator.
|
||||
It can also do—albeit experimental—synthesis and technology mapping by hooking into Yosys.
|
||||
This is so much in development that not many packages are provided—I was lucky that someone had already made a <a href="https://copr.fedorainfracloud.org/coprs/rezso/HDL/">Copr repo</a> for it, so I didn’t have to compile it on my Fedora machine.
|
||||
I also saw an AUR package for <code class="language-plaintext highlighter-rouge">ghdl-yosys-plugin</code>, so following along on Arch is probably easy too.
|
||||
I do not know anything about Debian/Ubuntu; there may be a PPA, but if you have to build from source, check this page: <a href="https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md">https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md</a></p>
|
||||
|
||||
<p>To keep the clutter away from source files, I made a build directory:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">mkdir</span> ./build
|
||||
</code></pre></div></div>
|
||||
<p>To use the GHDL Yosys plugin, I launched Yosys like this:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>yosys <span class="nt">-m</span> ghdl
|
||||
</code></pre></div></div>
|
||||
<p>Unless you specify <code class="language-plaintext highlighter-rouge">-m ghdl</code>, its plugin will be missing when you run Yosys.
|
||||
In its console, I first issued <code class="language-plaintext highlighter-rouge">ghdl blink.vhd -e blink</code> to elaborate my source(s), with <code class="language-plaintext highlighter-rouge">blink</code> as the top-level entity.
|
||||
Then, I ran <code class="language-plaintext highlighter-rouge">synth_xilinx -json ./build/blink.json</code> to synthesize a netlist into a JSON file, using technology mapping to the Xilinx 7 family.</p>
|
||||
|
||||
<p>Alternatively, a single script for the same commands can be written like:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>yosys <span class="nt">-m</span> ghdl <span class="nt">-p</span> <span class="s2">"ghdl blink.vhd -e blink; synth_xilinx -json ./build/blink.json"</span>
|
||||
</code></pre></div></div>
|
||||
<p>One downside is that VHDL 2008 is not—or not completely—supported.
|
||||
To stay safe, I omitted the <code class="language-plaintext highlighter-rouge">std=08</code> flag everywhere.</p>
|
||||
|
||||
<h1 id="place--route-with-nextpnr">Place &amp; route with NextPNR</h1>
|
||||
|
||||
<p>Once I had a netlist, I proceeded to use NextPNR to place and route it to actual components in the FPGA.
|
||||
My device is an Artix 7 (XC7A35T CPG236-1) as part of a Digilent CMOD A7 devboard.
|
||||
I first made the mistake of using the <code class="language-plaintext highlighter-rouge">nextpnr-xilinx</code> fork, which is not maintained regularly and refused to work for me.
|
||||
A bit of information that was unnecessarily hard to find is that the himbaechel backend of NextPNR (which is built into the <code class="language-plaintext highlighter-rouge">nextpnr</code> package provided by the Copr repo) supports Xilinx 7 FPGAs—including my Artix 7.</p>
|
||||
|
||||
<p>An <code class="language-plaintext highlighter-rouge">xdc</code> file is required to map top-level inputs and outputs to physical pins.
|
||||
I derived this from the <a href="https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc">CMOD A7’s xdc file</a> provided by Digilent:</p>
|
||||
<pre><code class="language-xdc">set_property LOC L17 [get_ports {clk}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {clk}]
|
||||
create_clock -add -name sys_clk_pin -period 83.33 -waveform {0 41.66} [get_ports {clk}]
|
||||
|
||||
set_property LOC A17 [get_ports {led_o}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {led_o}]
|
||||
|
||||
set_property LOC A18 [get_ports {areset}]
|
||||
set_property IOSTANDARD LVCMOS33 [get_ports {areset}]
|
||||
</code></pre>
|
||||
<p>I spent an embarrassing amount of time debugging an error caused by comments (and semicolons) at the end of the xdc file’s lines.
|
||||
These completely break NextPNR’s xdc parser, so they had to go.</p>
|
||||
|
||||
<p>I also used the this file to specify my timing constraints (the 12 MHz clock of the CMOD A7) but due to limitations of NextPNR isn’t used for static timing analysis (STA).
|
||||
To check if my design can operate at the required frequency, I had to specify an additional argument.
|
||||
NextPNR doesn’t know the <code class="language-plaintext highlighter-rouge">-add</code>, <code class="language-plaintext highlighter-rouge">-name</code> and <code class="language-plaintext highlighter-rouge">-waveform</code> arguments (I guess they are used by Vivado for simulation), but only shows a warning if they are left in.
|
||||
My final place and route command thus looked like this:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>nextpnr-himbaechel <span class="nt">--device</span> xc7a35tcpg236-1 <span class="nt">--json</span> ./build/blink.json <span class="nt">-o</span> <span class="nv">xdc</span><span class="o">=</span><span class="s2">"Cmod-A7-Master.xdc"</span> <span class="nt">--write</span> ./build/blink_routed.json <span class="nt">-o</span> <span class="nv">fasm</span><span class="o">=</span>./build/blink.fasm <span class="nt">--router</span> router2 <span class="nt">--freq</span> 12
|
||||
</code></pre></div></div>
|
||||
<p>The <code class="language-plaintext highlighter-rouge">--router</code> argument had little effect on my design, but it was in the NextPNR GitHUB repo’s example code so I left it there assuming it does no harm.
|
||||
The <code class="language-plaintext highlighter-rouge">--freq</code> argument specifies the clock frequency (in megahertz) for STA.
|
||||
The output file I’m going to work with in the following section is <code class="language-plaintext highlighter-rouge">blink.fasm</code>.</p>
|
||||
|
||||
<h1 id="bitstream-generation-with-project-x-ray">Bitstream generation with Project X-Ray</h1>
|
||||
|
||||
<p>To write the configuration to the FPGA I needed it in a loadable format.
|
||||
For Xilinx devices it’s a bitstream, also known as <code class="language-plaintext highlighter-rouge">.bit</code> files.
|
||||
I achieved this in two steps: first I converted the <code class="language-plaintext highlighter-rouge">fasm</code> file to <code class="language-plaintext highlighter-rouge">frames</code>, then <code class="language-plaintext highlighter-rouge">frames</code> to <code class="language-plaintext highlighter-rouge">bit</code>.
|
||||
The software collection that’s going to help me generate programming files for the Artix 7 (and for Xilinx FPGAs in general) is called Project X-Ray.
|
||||
I preformet the first step with Xray’s <code class="language-plaintext highlighter-rouge">fasm2frames</code> tool, which is sadly broken in the package form the Copr repo.
|
||||
As a dirty fix, I cloned the <a href="https://github.com/f4pga/prjxray">Project X-Ray GitHUB repo</a> (to <code class="language-plaintext highlighter-rouge">~/.local/bin/build_stage/</code>) then used the script in its sources like this:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>python ~/.local/bin/build_stage/prjxray/utils/fasm2frames.py <span class="nt">--db-root</span> /usr/share/xray/database/artix7 <span class="nt">--part</span> xc7a35tcpg236-1 ./build/blink.fasm ./build/blink.frames
|
||||
</code></pre></div></div>
|
||||
<p>I still had to source database from the <code class="language-plaintext highlighter-rouge">projectxray-data</code> package, as it’s not stored in the GitHUB repo directly.</p>
|
||||
|
||||
<p>For step two, I employed the tool <code class="language-plaintext highlighter-rouge">xc7frames2bit</code> that worked from the installation.
|
||||
This saved me some time as I would have had to compile this program otherwise (since it’s written in C, unlike <code class="language-plaintext highlighter-rouge">fasm2frames</code>).
|
||||
The command I used for the conversion is what you’d expect:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>xc7frames2bit <span class="nt">--part_file</span> /usr/share/xray/database/artix7/xc7a35tcpg236-1/part.yaml <span class="nt">--frm_file</span> ./build/blink.frames <span class="nt">--output_file</span> ./build/blink.bit
|
||||
</code></pre></div></div>
|
||||
<p>Note that depending on the installation of Project X-Ray, the database directory may be different from mine; find or locate commands can be used to determine the exact path.
|
||||
Same goes for the part number: different FPGAs from different families need different databases/partfiles.</p>
|
||||
|
||||
<h1 id="programming-with-openfpgaloader">Programming with openFPGAloader</h1>
|
||||
|
||||
<p>At last I have my bitstream.
|
||||
Getting this on the FPGA required the <code class="language-plaintext highlighter-rouge">openFPGAloader</code> package, also provided by the Copr repo.
|
||||
For now I loaded the configuration into SRAM, but the CMOD A7 also comes with a serial flash memory to store the config.
|
||||
The command I used to write the sram looked like this:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/usr/bin/openFPGALoader <span class="nt">-b</span> cmoda7_35t ./build/blink.bit
|
||||
</code></pre></div></div>
|
||||
<p>And flashing would’ve looked like this:</p>
|
||||
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/usr/bin/openFPGALoader <span class="nt">-b</span> cmoda7_35t <span class="nt">-f</span> blink.bit
|
||||
</code></pre></div></div>
|
||||
<p>Once this was complete, I had a led blinking at approximately 0.5 Hz.
|
||||
Project success!</p>
|
||||
|
||||
<h1 id="conclusion">Conclusion</h1>
|
||||
|
||||
<p>While it’s a far cry from proprietary integrated development environments, fully open-source FPGA synthesis is possible.
|
||||
It’s limited to Xilinx, Lattice and some other manufacturers (and even here the supported devices/families are limited too).
|
||||
The weak points are no or limited VHDL 2008 support, the difficulty of hunting down every component (and their documentation).
|
||||
Thus the barrier to entry is quite high, it took me roughly a day to get it all sorted out with prior knowledge of FPGAs and minimal prior knowledge of the software used.
|
||||
Advanced features like post-layout synthesis, IP core wizzards and graphical pin planners are either non-existent or not practical.</p>
|
||||
|
||||
<p>On the other hand, these tools feel very fast, especially the synthesis workflow.
|
||||
I haven’t done any benchmarks, but especially with Modelsim’s free edition slowing down significantly over 10000 lines GHDL should be able to compete with it.
|
||||
Also, since all of them (except GTKWave) are command-line tools, their outputs are mostly in plain text, they fit the general tools of open-source development rather well (eg. git and make).
|
||||
This makes them feel more ergonomic for a nerd like me, who even edits text in the terminal.
|
||||
All in all I wouldn’t use them in my dayjob (they are just not on par with vendor IDEs), but they’ll do fine for my hobby projects.</p>
|
||||
|
||||
<h1 id="sources">Sources:</h1>
|
||||
<p>nextpnr-himbaechel usage: <a href="https://github.com/YosysHQ/nextpnr/tree/master/himbaechel/uarch/xilinx/examples/arty-a35">https://github.com/YosysHQ/nextpnr/tree/master/himbaechel/uarch/xilinx/examples/arty-a35</a>
|
||||
general workflow: <a href="https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md">https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/TUTORIALS/toolchain_arty.md</a>, <a href="https://github.com/BrunoLevy/learn-fpga/blob/master/Basic/ARTY/ARTY_blink/makeit.sh">https://github.com/BrunoLevy/learn-fpga/blob/master/Basic/ARTY/ARTY_blink/makeit.sh</a>
|
||||
CMOD A7 docs: <a href="https://digilent.com/reference/_media/reference/programmable-logic/cmod-a7/cmod_a7_rm.pdf">https://digilent.com/reference/_media/reference/programmable-logic/cmod-a7/cmod_a7_rm.pdf</a>
|
||||
CMOD a7 xdc file: <a href="https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc">https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc</a>
|
||||
GHDL Simulation: <a href="https://ghdl.github.io/ghdl/using/Simulation.html">https://ghdl.github.io/ghdl/using/Simulation.html</a>
|
||||
GHDL synthesis: <a href="https://github.com/ghdl/ghdl-yosys-plugin">https://github.com/ghdl/ghdl-yosys-plugin</a>, <a href="https://wiki.f-si.org/images/b/b3/Ghdl-FSiC2022.pdf">https://wiki.f-si.org/images/b/b3/Ghdl-FSiC2022.pdf</a>
|
||||
Project X-Ray: <a href="https://github.com/f4pga/prjxray">https://github.com/f4pga/prjxray</a></p></content><author><name></name></author><category term="FPGA" /><summary type="html">In the software world, open-source toolchains are taken for granted. In the FPGA/hardware world, the situation is not as good, but with the right choice of FPGA, it is feasible. Allow me to tell my tale about how I succeeded in bringing up my Artix devboard with only open-source programs.</summary></entry><entry><title type="html">The Self-Contradiction of Spice and Wolf</title><link href="http://localhost:4000/2025/01/09/Spice-and-Wolf.html" rel="alternate" type="text/html" title="The Self-Contradiction of Spice and Wolf" /><published>2025-01-09T00:00:00+01:00</published><updated>2025-01-09T00:00:00+01:00</updated><id>http://localhost:4000/2025/01/09/Spice-and-Wolf</id><content type="html" xml:base="http://localhost:4000/2025/01/09/Spice-and-Wolf.html"><p>I really enjoyed the 2008 <em>Spice and Wolf</em> series when I watched it, so I was excited to hear it was being worked on again.
|
||||
After watching <em>Spice and Wolf: MERCHANT MEETS THE WISE WOLF</em>, I felt the reboot was completely justified.
|
||||
I had to get used to the new art style initially, but all in all, it looked good.
|
||||
The sounds (the effects, the soundtrack, and the voice acting) were generally very good, and they get extra points for re-casting the voice actors from the 2008 series.</p>
|
||||
@@ -590,59 +817,4 @@ This device would have provided its wielder eternal life (much like Transhumanis
|
||||
|
||||
<p>Even though the alchemists never succeeded in their original goals (now we see why they didn’t even have a chance) their contribution to natural sciences is not negligible, and they had a comparable impact on the arts and literature.
|
||||
They never reached eternal life nor infinite wealth, but from their “failed” experiments came fragments of knowledge, on which modern science is built.
|
||||
So I keep smiling at the Transhumanists - as long as their methods are kept clean, I want them to carry out their experiments, and even though they won’t succeed, we can still be grateful for their “failed” attempts.</p></content><author><name></name></author><category term="philosophy" /><summary type="html">In this short essay, I’ll examine the idea of the Singularity Feedback Loop. I’ll touch on Trans- and Posthumanism (which I’ll shorten to Transhumanism) but the focus will be this discipline’s dreaded and awaited messiah: the Technological Singularity.</summary></entry><entry><title type="html">Server Setup Part 0 - Status Quo</title><link href="http://localhost:4000/2023/12/08/statusquo.html" rel="alternate" type="text/html" title="Server Setup Part 0 - Status Quo" /><published>2023-12-08T00:00:00+01:00</published><updated>2023-12-08T00:00:00+01:00</updated><id>http://localhost:4000/2023/12/08/statusquo</id><content type="html" xml:base="http://localhost:4000/2023/12/08/statusquo.html"><p>Since August I’ve been upgrading my home server setup.
|
||||
It’s not yet 100% complete, but most of the architectural decisions are already behind me.
|
||||
I wish to document this process so that others can learn from it and as a reminder for myself if I ever forget how I did something.
|
||||
This is part zero of my writeup, which’ll be about the hardware and software used prior to the upgrade.
|
||||
This should serve as a comparison baseline.</p>
|
||||
|
||||
<h2 id="nas">NAS</h2>
|
||||
|
||||
<p>I had a 2-bay Synology NAS for some years now.
|
||||
It has been passed down to me from a family member along with drives to populate it.
|
||||
It’s configured in RAID-1 with 2x 3TB HDDs.
|
||||
This capacity was almost filled up, which meant it was time to migrate from it.</p>
|
||||
|
||||
<p>This NAS ran an SMB server, an ISCSI target, a VPN server, a DDNS updater, streamed music and had a BitTorrent client.
|
||||
The processor and RAM limitations crippled the responsiveness of these services, and the configuration was very limited as well.
|
||||
It was a good computer, but it no longer satisfied my needs - at least not for the price I wanted to pay.</p>
|
||||
|
||||
<h2 id="linux-server">Linux server</h2>
|
||||
|
||||
<p>To expand into additional services that my NAS couldn’t provide, I got a cheap laptop with a broken hinge (from a family member as well) and installed the XFCE spin of Fedora workstation on it.
|
||||
I like this device for how simple it is: 5W idle power draw, 4-core Intel CPU (passively cooled by a piece of metal), the entire board being just one card, except the socketed RAM and the WLAN card (which I found has no black/whitelist).
|
||||
Its IO is limited to 2 USB, 2 SATA (one for ODD) and 100MB internet.
|
||||
The keyboard and screen were nice to have when I started out, and the battery came in useful during power outages.</p>
|
||||
|
||||
<p>This would have been a terrible fileserver but it ran PiHole and HomeAssistant in docker with great stability until recently the network interface started having issues.
|
||||
Fun fact: this was also the machine I used for building Fedora packages for ani-cli.</p>
|
||||
|
||||
<h2 id="what-wont-change-now">What won’t change now</h2>
|
||||
|
||||
<p>I’ll go over a few devices I use at home but won’t change now.
|
||||
They are still relevant as services will interact with them.</p>
|
||||
|
||||
<p>I picked up a decent-size UPS from the trash a few years ago - it turned out to only need a new battery.
|
||||
Now it has backup power for my NAS and router.</p>
|
||||
|
||||
<p>My networking is done by an ISP-provided all-in-one, which I hate but don’t want to change just now.
|
||||
There’s also an unmanaged network switch to provide extra wired connections.</p>
|
||||
|
||||
<p>For media, I have a Chromecast (TV is not smart), a Pi 3 with Kodi and a Pi 1 with Volumio.
|
||||
With the exception of the Chromecast they get their files trough mounted SMB shares.</p>
|
||||
|
||||
<p>There are a few IoT devices with open firmware I use for home automation and some that aren’t connected to the internet because their firmware is proprietary, outdated and they would be a security risk to my network.</p>
|
||||
|
||||
<h2 id="comming-up">Comming up</h2>
|
||||
|
||||
<ol>
|
||||
<li>Host System - the metal that’ll run my services</li>
|
||||
<li>Filesystem layout - from disks to directories</li>
|
||||
<li>Networking - connecting to the web</li>
|
||||
<li>Docker and nextcloud - how not to get in your own way</li>
|
||||
<li>Torrent and media management - My Lord, is that legal?</li>
|
||||
<li>Media serving - the forgotten world of DLNA and UPNP/AV</li>
|
||||
<li>Home automation - my home is smart</li>
|
||||
<li>Backup strategy - because RAID is not a backup</li>
|
||||
<li>Migration - moving it all in</li>
|
||||
</ol></content><author><name></name></author><category term="home server" /><summary type="html">Since August I’ve been upgrading my home server setup. It’s not yet 100% complete, but most of the architectural decisions are already behind me. I wish to document this process so that others can learn from it and as a reminder for myself if I ever forget how I did something. This is part zero of my writeup, which’ll be about the hardware and software used prior to the upgrade. This should serve as a comparison baseline.</summary></entry></feed>
|
||||
So I keep smiling at the Transhumanists - as long as their methods are kept clean, I want them to carry out their experiments, and even though they won’t succeed, we can still be grateful for their “failed” attempts.</p></content><author><name></name></author><category term="philosophy" /><summary type="html">In this short essay, I’ll examine the idea of the Singularity Feedback Loop. I’ll touch on Trans- and Posthumanism (which I’ll shorten to Transhumanism) but the focus will be this discipline’s dreaded and awaited messiah: the Technological Singularity.</summary></entry></feed>
|
||||
@@ -38,7 +38,12 @@
|
||||
<div class="wrapper">
|
||||
<div class="home">
|
||||
<h2 class="post-list-heading">Posts</h2>
|
||||
<ul class="post-list"><li><span class="post-meta">Jan 9, 2025</span>
|
||||
<ul class="post-list"><li><span class="post-meta">Feb 10, 2025</span>
|
||||
<h3>
|
||||
<a class="post-link" href="/2025/02/10/open-source-fpga-development.html">
|
||||
How I got started with open-source FPGA development
|
||||
</a>
|
||||
</h3></li><li><span class="post-meta">Jan 9, 2025</span>
|
||||
<h3>
|
||||
<a class="post-link" href="/2025/01/09/Spice-and-Wolf.html">
|
||||
The Self-Contradiction of Spice and Wolf
|
||||
|
||||
Reference in New Issue
Block a user