<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>hdlmake &amp;mdash; csantosb</title>
    <link>https://infosec.press/csantosb/tag:hdlmake</link>
    <description>Random thoughts</description>
    <pubDate>Wed, 13 May 2026 23:34:28 +0000</pubDate>
    <item>
      <title>ci (sourcehut): alu</title>
      <link>https://infosec.press/csantosb/ci-sourcehut-alu</link>
      <description>&lt;![CDATA[img br/&#xA;Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see how to implement it with detail using sourcehut and a real world example. !--more-- br/&#xA;Sourcehut is a lightweight #gitforge where I host my #git repositories. Not only it is based on a paradigm perfectly adapted to #modernhw, but also its builds service includes support for guix (x8664) images. This means that we will be able to execute all of our testing online inside guix profiles, shells or natively on top of the bare-bones image. br/&#xA;&#xA;Alu&#xA;&#xA;Let’s consider now a variant of the previous example with open-logic. Here, we concentrate on a toy design only for demonstration purposes, a dummy alu emulator, which uses #osvvm as verification framework and relies on a few #openlogic blocs. In this case, its dependencies are defined in a manifest.scm file, including both fw-open-logic and osvvm, among other dependencies. br/&#xA;Install dependencies locally, in a new profile with br/&#xA;&#xA;cd alu&#xA;mkdir deps&#xA;export GUIXPROFILE=open-logic/deps&#xA;guix install -P $GUIXPROFILE -m .builds/manifest.scm&#xA;. $GUIXPROFILE/etc/profile&#xA;&#xA;In this case, we will test the design using, first, a custom made makefile. Secondly, we will use hdlmake to automatically produce our makefile. Similarly to previous #openlogic example, two build manifest are used: br/&#xA;&#xA;    profile1 br/&#xA;    profile2 br/&#xA;&#xA;You’ll realise how some of the tasks are common with the case of previous #openlogic example (update channels, auth and update profile). br/&#xA;&#xA;osvvm&#xA;&#xA;In this case, we also need to compile osvvm libraries br/&#xA;&#xA;    compile\_osvvm, produce a compiled version of #osvvm verification libraries; this is necessary as we are using here the tcl  scripts included in the library itself to follow the correct order of compilation. Libraries will appear within the local profile under $GUIXPROFILE/VHDLLIBS/GHDL-X.Y.Z br/&#xA;&#xA;test&#xA;&#xA;    test, for a fully custom made testing pipeline; in this case, using a Makefile br/&#xA;    Just simply, source the .envrc file where the local $GUIXPROFILE variable is defined, cd to the ghdl directory and call make to compile the design and run the simulation in two steps: first, clean all and include sources in its corresponding libraries with br/&#xA;    &#xA;        make cleanall include&#xA;        &#xA;    Then, produce a new Makefile using ghdl. br/&#xA;    &#xA;        ./makefile.sh # ghdl --gen-makefile ...&#xA;        &#xA;    Finally, run the simulation with br/&#xA;    &#xA;        make GHDLRUNFLAGS=&#34;--stop-time=4us --disp-time --ieee-asserts=enable&#34; run&#xA;        &#xA;    This will produce a executable file before running it with the provided parameters. br/&#xA;    You may notice that, in this case, you need to produce somehow your own Makefile, or equivalent pipeline, right ? br/&#xA;&#xA;hdlmake&#xA;&#xA;Wouldn’t it be nice if we had a tool to deploy online which produces makefiles for us ? It exists, and its name is #hdlmake. br/&#xA;&#xA;    test\hdlmake br/&#xA;    Source the .envrc file where the local $GUIXPROFILE variable is defined, cd to the .builds/hdlmake directory where all Manifest.py files are located, and call hdlmake to produce the Makefile. Finally, just run make to compile the design, produce an executable and run it. br/&#xA;&#xA;Check the resulting logs inline here, for example. br/]]&gt;</description>
      <content:encoded><![CDATA[<p><img src="https://git.sr.ht/~csantosb/csbwiki/blob/master/pics/sourcehut.png" alt="img"> <br/>
Remote <a href="/csantosb/tag:ci" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">ci</span></a> is the <a href="https://infosec.press/csantosb/tag:ciseries" rel="nofollow">way to go</a> in <a href="/csantosb/tag:modernhw" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">modernhw</span></a> digital design testing. In this <a href="/csantosb/tag:ciseries" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">ciseries</span></a>, let’s see how to implement it with detail using <a href="https://sourcehut.org/" rel="nofollow">sourcehut</a> and a real world example.  <br/>
<a href="https://infosec.press/csantosb/sourcehut-crash-course" rel="nofollow">Sourcehut</a> is a lightweight <a href="/csantosb/tag:gitforge" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">gitforge</span></a> where I host my <a href="/csantosb/tag:git" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">git</span></a> repositories. Not only it is <a href="https://infosec.press/csantosb/git-forges#sourcehut" rel="nofollow">based on a paradigm</a> perfectly adapted to <a href="/csantosb/tag:modernhw" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">modernhw</span></a>, but also its <a href="https://infosec.press/csantosb/sourcehut-crash-course#builds" rel="nofollow">builds</a> service includes support for <a href="https://man.sr.ht/builds.sr.ht/compatibility.md#guix-system" rel="nofollow">guix</a> (x86_64) images. This means that we will be able to execute all of our testing online inside <a href="https://infosec.press/csantosb/guix-crash-course#profiles-and-generations" rel="nofollow">guix profiles</a>, <a href="https://infosec.press/csantosb/guix-crash-course#shell-containers" rel="nofollow">shells</a> or natively on top of the bare-bones image. <br/></p>

<h1 id="alu">Alu</h1>

<p>Let’s consider now a variant of the <a href="https://infosec.press/csantosb/ci-sourcehut" rel="nofollow">previous example with open-logic</a>. Here, we concentrate on a <a href="https://git.sr.ht/~csantosb/ip.alu/tree" rel="nofollow">toy design</a> only for demonstration purposes, a <a href="https://git.sr.ht/~csantosb/ip.alu/tree/master/item/src/alu.vhd" rel="nofollow">dummy alu emulator</a>, which uses <a href="/csantosb/tag:osvvm" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">osvvm</span></a> as verification framework and relies on a few <a href="/csantosb/tag:openlogic" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">openlogic</span></a> blocs. In this case, its dependencies are defined in a <a href="https://git.sr.ht/~csantosb/ip.alu/tree/test/item/.builds/manifest.scm" rel="nofollow">manifest.scm</a> file, including both <code>fw-open-logic</code> and <code>osvvm</code>, among other dependencies. <br/>
Install dependencies locally, in a new <a href="https://infosec.press/csantosb/guix-crash-course#profiles-and-generations" rel="nofollow">profile</a> with <br/></p>

<pre><code class="language-sh">cd alu
mkdir _deps
export GUIX_PROFILE=open-logic/_deps
guix install -P $GUIX_PROFILE -m .builds/manifest.scm
. $GUIX_PROFILE/etc/profile
</code></pre>

<p>In this case, we will test the design using, first, a custom made makefile. Secondly, we will use <a href="https://hdlmake.readthedocs.io/en/master/" rel="nofollow">hdlmake</a> to automatically produce our makefile. Similarly to <a href="https://infosec.press/csantosb/ci-sourcehut" rel="nofollow">previous</a> <a href="/csantosb/tag:openlogic" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">openlogic</span></a> example, two build manifest are used: <br/></p>

<p>    <a href="https://git.sr.ht/~csantosb/ip.alu/tree/test/item/.builds/profile1.yml" rel="nofollow">profile1</a> <br/>
    <a href="https://git.sr.ht/~csantosb/ip.alu/tree/test/item/.builds/profile2.yml" rel="nofollow">profile2</a> <br/></p>

<p>You’ll realise how some of the tasks are common with the case of previous <a href="/csantosb/tag:openlogic" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">openlogic</span></a> example (update channels, auth and update profile). <br/></p>

<h2 id="osvvm">osvvm</h2>

<p>In this case, we also need to compile osvvm libraries <br/></p>

<p>    <strong>compile__osvvm</strong>, <a href="https://builds.sr.ht/~csantosb/job/1389146#task-compile_osvvm" rel="nofollow">produce a compiled version</a> of <a href="/csantosb/tag:osvvm" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">osvvm</span></a> verification libraries; this is necessary as we are using here the <code>tcl</code>  scripts included in the library itself to follow the correct order of compilation. Libraries will appear within the local profile under <code>$GUIX_PROFILE/VHDL_LIBS/GHDL-X.Y.Z</code> <br/></p>

<h2 id="test">test</h2>

<p>    <strong>test</strong>, for a fully custom made testing pipeline; in this case, using a <code>Makefile</code> <br/>
    Just simply, source the <code>.envrc</code> file where the local <code>$GUIX_PROFILE</code> variable is defined, cd to the <code>ghdl</code> directory and call make to compile the design and run the simulation in two steps: first, clean all and include sources in its corresponding libraries with <br/></p>

<p>    <code>sh
    make __clean_all __include
</code></p>

<p>    Then, produce a new <code>Makefile</code> using <code>ghdl</code>. <br/></p>

<p>    <code>sh
    ./makefile.sh # ghdl --gen-makefile ...
</code></p>

<p>    Finally, run the simulation with <br/></p>

<p>    <code>sh
    make GHDLRUNFLAGS=&#34;--stop-time=4us --disp-time --ieee-asserts=enable&#34; run
</code></p>

<p>    This will produce a executable file before <a href="https://builds.sr.ht/~csantosb/job/1389146#task-test" rel="nofollow">running it</a> with the provided parameters. <br/>
    You may notice that, in this case, you need to produce somehow your own <code>Makefile</code>, or equivalent pipeline, right ? <br/></p>

<h2 id="hdlmake">hdlmake</h2>

<p>Wouldn’t it be nice if we had a tool to deploy online which produces makefiles for us ? It exists, and its name is <a href="/csantosb/tag:hdlmake" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">hdlmake</span></a>. <br/></p>

<p>    <strong>test__hdlmake</strong> <br/>
    <a href="https://git.sr.ht/~csantosb/ip.alu/tree/8324cd0fcb838cfb8303aae9e668b6831a329cbb/.builds/profile1.yml#L39" rel="nofollow">Source</a> the <code>.envrc</code> file where the local <code>$GUIX_PROFILE</code> variable is defined, cd to the <code>.builds/hdlmake</code> directory where all <code>Manifest.py</code> files are located, and call <code>hdlmake</code> to produce the <code>Makefile</code>. Finally, just run make to compile the design, produce an executable and run it. <br/></p>

<p>Check the resulting logs inline <a href="https://builds.sr.ht/~csantosb/job/1389146#task-test_hdlmake" rel="nofollow">here</a>, for example. <br/></p>
]]></content:encoded>
      <guid>https://infosec.press/csantosb/ci-sourcehut-alu</guid>
      <pubDate>Fri, 13 Dec 2024 12:38:24 +0000</pubDate>
    </item>
  </channel>
</rss>