Simulation with Verilator

[suarezvictor]

This simulation first generates Verilog files from VHDL files, using Yosys and GHDL plugin ("write_verilog" command)
For details see: http://www.fabienm.eu/flf/convertir-du-vhdl-en-verilog-librement-avec-yosys-et-ghdl/

Commands to run for project generation & translation to verilog:

$ ./src/pipelinec ./examples/blink.c --sim_comb --edaplay
$ cd ./pipelinec_output_edaplay.c_17248/all_vhdl_files
$ ghdl -i `cat ../vhdl_files.txt`
$ ghdl -m top
$ yosys -m ghdl
> ghdl --std=08 top; proc; opt; fsm; opt; memory; opt; write_verilog top.v
> exit

Generate .cpp files & simulator executable (see below main source for simulation)

$ verilator -Wall -cc top.v
$ clang++ -g -O3 -I/usr/share/verilator/include main.cpp -o top

Run simulation (first output is state before clock)

$./top
cycle 0 - led: 0, counter: 0
cycle 1 - led: 0, counter: 1
cycle 2 - led: 0, counter: 2
cycle 3 - led: 1, counter: 0
cycle 4 - led: 1, counter: 1
cycle 5 - led: 1, counter: 2
cycle 6 - led: 0, counter: 0
cycle 7 - led: 0, counter: 1
cycle 8 - led: 0, counter: 2
cycle 9 - led: 1, counter: 0

main source for simulation:

#define clk	clk_None
#define led	led_debug_DEBUG_OUTPUT_MAIN_return_output
#define counter	counter_debug_DEBUG_OUTPUT_MAIN_return_output

#include "verilated.cpp" //verilator library
#include "obj_dir/Vtop.cpp" //generated by verilator
#include "obj_dir/Vtop__Syms.cpp" //generated by verilator

#include <iostream>
using namespace std;

int main(int argc, char *argv[]) {
    Vtop* g_top = new Vtop;

    uint64_t cycle = 0;
    while (cycle < 10)
    {
        bool cur_led        = g_top->led;
        uint32_t counter    = g_top->counter;

        cout << "cycle " << cycle << " - led: " << cur_led << ", counter: " << counter << endl;

        g_top->clk = 0;
        g_top->eval();

        g_top->clk = 1;
        g_top->eval();
        ++cycle;
    }

    return 0;
}

[suarezvictor]

Alternative compilation:

$ verilator -cc top.v -O3 --exe main.cpp
$ make -j4 -C obj_dir -f Vtop.mk
$ obj_dir/Vtop

main.cpp should be modified too, instead of including .cpp fines, you should:

#include "verilated.h"
#include "Vtop.h" //generated by verilator

This avoids dependencies of verilator source file names and directory locations

[suarezvictor]

I was able to simulate the vga pattern generator with verilator (note variables without double underscores __, seems converted to single ones)
It seems the solution was to disable including the std08 floating point packages (maybe they should be included only if needed, or better provide alternative implementations of the minimal set of functions needed)

/*
$ verilator -Wall -cc top.v
$ clang++ -g -O3 -I/usr/share/verilator/include main.cpp -o vtop
*/

#if 0 //build with verilator generated Makefiles
#include "verilated.h"
#include "Vtop.h"
#else //build with clang++ or gcc
#include "verilated.cpp" //verilator library
#include "obj_dir/Vtop.cpp" //generated by verilator
#include "obj_dir/Vtop__Syms.cpp" //generated by verilator
#endif

#define clk clk_148p5
#define _vga_red vga_red_DEBUG_OUTPUT_MAIN_return_output
#define _vga_green vga_green_DEBUG_OUTPUT_MAIN_return_output
#define _vga_blue vga_blue_DEBUG_OUTPUT_MAIN_return_output
#define _vsync vsync_DEBUG_OUTPUT_MAIN_return_output
#define _hsync hsync_DEBUG_OUTPUT_MAIN_return_output

#include <iostream>
using namespace std;
   
int main()
{
    Vtop* g_top = new Vtop;

    uint64_t cycle = 0;
    while (cycle < 2048)
    {
       g_top->clk = 0;
       g_top->eval(); //starts with an evaluation (to reflect reset values)
   
       bool vsync = g_top->_vsync;
       bool hsync = g_top->_hsync;
       unsigned red = g_top->_vga_red;
       unsigned green = g_top->_vga_green;
       unsigned blue = g_top->_vga_blue;
       cout << "cycle " << cycle 
            << " vsync: " << vsync
            << " hsync: " << hsync
            << " red: " << red
            << " green: " << green
            << " blue: " << blue
            << endl;

       g_top->clk = 1;
       g_top->eval();
       ++cycle;
    }
    return 0;
}

Results

$ ./vtop
cycle 0 vsync: 0 hsync: 0 red: 0 green: 0 blue: 0
cycle 1 vsync: 0 hsync: 0 red: 0 green: 0 blue: 0
cycle 2 vsync: 0 hsync: 0 red: 0 green: 0 blue: 0
[...]
cycle 69 vsync: 0 hsync: 0 red: 0 green: 0 blue: 1
cycle 70 vsync: 0 hsync: 0 red: 0 green: 0 blue: 1
cycle 71 vsync: 0 hsync: 0 red: 0 green: 0 blue: 1
[...]
cycle 2008 vsync: 0 hsync: 0 red: 0 green: 0 blue: 0
cycle 2009 vsync: 0 hsync: 1 red: 0 green: 0 blue: 0
cycle 2010 vsync: 0 hsync: 1 red: 0 green: 0 blue: 0

[suarezvictor]

Below is convenience class for manipulation of integer of different sizes than natives (i.e. uint6_t), based on operator overloading. Correctly handles for example automatic wrap around if the required number of bits.
Useful for running the PipelineC algorithms with a normal C++ compiler. Includes a "fast version mode" that always use native sizes (for algorithms that doesn't depend on exact register sizes)

#ifndef __BITREGS_H_
#define __BITREGS_H_
//based on https://blog.codef00.com/2014/12/06/portable-bitfields-using-c11/
//License: "Feel free to use it for any purpose you like"

#include <cstdint>
#include <cstddef>
#include <type_traits>

template <size_t LastBit>
struct MinimumTypeHelper {
    typedef
        typename std::conditional<LastBit == 0 , void,
        typename std::conditional<LastBit <= 8 , uint8_t,
        typename std::conditional<LastBit <= 16, uint16_t,
        typename std::conditional<LastBit <= 32, uint32_t,
        typename std::conditional<LastBit <= 64, uint64_t,
        void>::type>::type>::type>::type>::type type;
};

#if 0
//fast version: native types, doesn't enforce bit sizes
#define DEFUINT(N) typedef MinimumTypeHelper<N>::type uint##N##_t
#define XYZbit(a, X, Y, Z) (((a)>>(Z)) & ((1<<((Y)-(Z)+1))-1))
#else


template <size_t Bits>
class BitField {
    typedef typename MinimumTypeHelper<Bits>::type T;

public:
    BitField() : value_(0) { }
    BitField(T value) : value_(value) { }
    template <class T2> BitField &operator=(T2 value) { value_ = value; return *this; }
    operator T() const { return value_; }
    operator bool() const { return value_; }
    BitField &operator++() { return *this = *this+1; }
    T operator++(int) { T r = *this; ++*this; return r; }
    BitField &operator--() { return *this = *this-1; }
    T operator--(int) { T r = *this; --*this; return r; }

    template <size_t START, size_t END> BitField<START-END+1> slice() const { return value_>>END; } 
    T operator()(size_t Y, size_t Z) const { return (((value_)>>(Z)) & ((1<<((Y)-(Z)+1))-1)); } 

private:
    union { T rawvalue; struct {T value_ :Bits;};};
};

#define DEFUINT(N) typedef BitField<N> uint##N##_t
#define XYZbit(a,X,Y,Z) BitField<(X)>(a).slice<(Y),(Z)>()

#endif


             DEFUINT( 1); DEFUINT( 2); DEFUINT( 3); DEFUINT( 4); DEFUINT( 5); DEFUINT( 6); DEFUINT( 7);              DEFUINT( 9);
DEFUINT(10); DEFUINT(11); DEFUINT(12); DEFUINT(13); DEFUINT(14); DEFUINT(15);              DEFUINT(17); DEFUINT(18); DEFUINT(19);
DEFUINT(20); DEFUINT(21); DEFUINT(22); DEFUINT(23); DEFUINT(24); DEFUINT(25); DEFUINT(26); DEFUINT(27); DEFUINT(28); DEFUINT(29);
DEFUINT(30); DEFUINT(31);              DEFUINT(33); DEFUINT(34); DEFUINT(35); DEFUINT(36); DEFUINT(37); DEFUINT(38); DEFUINT(39);
DEFUINT(40); DEFUINT(41); DEFUINT(42); DEFUINT(43); DEFUINT(44); DEFUINT(45); DEFUINT(46); DEFUINT(47); DEFUINT(48); DEFUINT(49);
DEFUINT(50); DEFUINT(51); DEFUINT(52); DEFUINT(53); DEFUINT(54); DEFUINT(55); DEFUINT(56); DEFUINT(57); DEFUINT(58); DEFUINT(59);
DEFUINT(60); DEFUINT(61); DEFUINT(62); DEFUINT(63);


//some bit access shortcuts
#define uint12_5_2(a) XYZbit(a, 12, 5, 2)
#define uint12_5_2(a) XYZbit(a, 12, 5, 2)
#define uint12_8_8(a) XYZbit(a, 12, 8, 8)
#define uint12_7_7(a) XYZbit(a, 12, 7, 7)
#define uint12_3_3(a) XYZbit(a, 12, 3, 3)
#define uint12_6_6(a) XYZbit(a, 12, 6, 6)

#endif // __BITREGS_H_

[JulianKemmerer]

This is excellent - getting that bit accurate checking+behavior is very tricky sometimes

[JulianKemmerer]

@suarezvictor basics for
./src/pipelinec ./examples/blink_verilator.c --sim_comb --verilator should be working on master. It should be using tool executables from your PATH as reported by which

I want to also support the "extract and done" install of the oss-cad-suite tar ball releases
https://github.com/YosysHQ/oss-cad-suite-build

[suarezvictor]

It seems there's a directoty changing issue. The command on "verilator.sh" raises an error:

elaborate top
/usr/bin/ld: no se puede abrir el fichero de salida top: Es un directorio
collect2: error: ld returned 1 exit status
/usr/local/bin/ghdl:error: compilation error

That is, the direcroty "top" already exists. The solution is to change to such directory "top" before executing "/usr/local/bin/ghdl -i" (not forgetting to reference ../vhdl_files.txt that now would be in parent directory), and execute "cd .." before executing verilator. This can be appreciated if running the commands manually

Luckily at least for the blink example there are no memory errors in GHDL

[JulianKemmerer]

Hmm I was not seeing that error with my local install - but I was seeing that with oss cad install

[JulianKemmerer]

@suarezvictor this commit should fix that
6b911fe
It puts verilator stuff in its own directory for now pipelinec_output/verilator/

[suarezvictor]

worked!

================== Doing Verilator Simulation ================================
Compiling...
Starting simulation...
cycle 0: counter_debug: 0 led_debug: 0
cycle 1: counter_debug: 1 led_debug: 0
cycle 2: counter_debug: 2 led_debug: 0

[JulianKemmerer]

But now @suarezvictor with the oss cad suite only I am getting

Command failed:
bash /home/julian/pipelinec_output/verilator/verilator.sh
ERROR: Can't load module `./ghdl': /media/1TB/Programs/Linux/oss-cad-suite/lib/../share/yosys/plugins/ghdl.so: cannot open shared object file: No such file or directory

I dont think the oss cad suite uses ghdl as a plugin as we have been?

[suarezvictor]

I think the yosys ghdl plugin needs to be compiled and installed manually, I'm not sure if it comes preinstalled.
I was installing all my tools mostly by hand

[JulianKemmerer]

yeah it has to with ghdl being compiled-in in or included as a module
Fixed to do differently for local installs vs oss cad suite for now
5bf6072

[JulianKemmerer]

OK I can now
./src/pipelinec ./examples/arty/src/vga/test_pattern.c --sim_comb --verilator

And get

================== Doing Verilator Simulation ================================
Compiling...
Starting simulation...
cycle 0: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 1: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 2: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 3: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 4: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 5: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 6: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 7: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 8: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0
cycle 9: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0

Can you share the code for how you got vga display output?

[suarezvictor]

Yes, let me clean it a bit. Would you help me on simulating the rsqrt function with cxxrtl or verilator, so I can check results is same as with the compiler? I was unable to reach that yet El jue., 30 sep. 2021 01:16, Julian Kemmerer ***@***.***> escribió:

…

OK I can now ./src/pipelinec ./examples/arty/src/vga/test_pattern.c --sim_comb --verilator And get ================== Doing Verilator Simulation ================================ Compiling... Starting simulation... cycle 0: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 1: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 2: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 3: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 4: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 5: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 6: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 7: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 8: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 cycle 9: vga_red: 0 vga_green: 0 vga_blue: 0 vsync: 0 hsync: 0 Can you share the code for how you got vga display output? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBHVWMGYEVUBJFPFNFICXDUEPQBHANCNFSM5E6FSUZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[JulianKemmerer]

@suarezvictor Very happy to help - just trying to catch up on everything going on :)

[JulianKemmerer]

Per some other comments ill try to put together a simple uint24 mult demo that interacts with verilator for checking

[suarezvictor]

Do you think the std library (std08) can be skipped by using custom functions for float processing? It seem only a few are needed El jue., 30 sep. 2021 17:15, Julian Kemmerer ***@***.***> escribió:

…

@suarezvictor <https://github.com/suarezvictor> Very happy to help - just trying to catch up on everything going on :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBHVWISXESQDHNGQ7GJ6RTUETAONANCNFSM5E6FSUZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[JulianKemmerer]

@suarezvictor Are you saying your GHDL(yosys?) bugs are related to std08?

I may be able to extract some functionality from the ieee proposed float pkg (not 08) package

[suarezvictor]

I was able to add "use ieee.float_pkg.all;\n" to VHDL.py for GHDL+verilator case, and the only thing that stopped me was the current memory error with ghdl or its yosys plugin. It needed also "ghdl -i --std=08 [files]" command plus "ghdl -m --std=08 top", so it seems the problem is not there. No need to --std=08 would be useful since it seems to require installing the ieee2008 lib, but for the moment maybe we can live with that

[JulianKemmerer]

@suarezvictor maybe we could start off even smaller?
Could we set up an automated test for like an integer multiply using that bit accurate template types code?
idk something like u24xu24 ?
That also wouldnt need float stuff to be resolved yet

I would love to idk 'tag' the function to be verified in the PipelineC code and generate as much C++ to run tests as possible + using that bit accurate lib

[suarezvictor]

YES. I think we need this to get started: the most simple testing project we can imagine. Or even just add two integers of different width. Then move to the float stuff...
Maybe with such a tiny project GHDL stops complaining. The interesting result that we can obtain right away, is to see if the recent 27x27 bit pipelined multiplier works. This would be quite useful, don't you think?

[JulianKemmerer]

@suarezvictor
I just put together a sort-of working example
./src/pipelinec ./examples/verilator/u24mult.c --sim_comb --verilator --main_cpp ./examples/verilator/u24mult_main.cpp
Outputs

================== Doing Verilator Simulation ================================
Compiling...
Starting simulation...
cycle 0: x 0 y 1 sim_result 0 c_result 0 MATCH?: 1
cycle 1: x 1 y 2 sim_result 2 c_result 2 MATCH?: 1
cycle 2: x 2 y 3 sim_result 6 c_result 6 MATCH?: 1
cycle 3: x 3 y 4 sim_result 12 c_result 12 MATCH?: 1
cycle 4: x 4 y 5 sim_result 20 c_result 20 MATCH?: 1
cycle 5: x 5 y 6 sim_result 30 c_result 30 MATCH?: 1
cycle 6: x 6 y 7 sim_result 42 c_result 42 MATCH?: 1
cycle 7: x 7 y 8 sim_result 56 c_result 56 MATCH?: 1
cycle 8: x 8 y 9 sim_result 72 c_result 72 MATCH?: 1
cycle 9: x 9 y 10 sim_result 90 c_result 90 MATCH?: 1

Which has the following problems as we are aware.
uintN types are still done using the simple typedef way, not the bit accurate types way

PipelineC/examples/verilator/u24mult.h

Line 3 in 00e0ef7

#include "/media/1TB/Dropbox/PipelineC/git/PipelineC/uintN_t.h"

But more importantly - maybe you can help
I dont know what command line args to give to the make command in order to include PipelineC generated C files.

PipelineC/examples/verilator/u24mult_main.cpp

Line 5 in 00e0ef7

// TODO: How to compile these without fixed paths? Tried -I{dir}?

Ex. verilator.sh from my system

ghdl -i `cat ../vhdl_files.txt` && ghdl -m top 
yosys -g -p "ghdl top; proc; opt; fsm; opt; memory; opt; write_verilog ../top/top.v" 
verilator -cc ../top/top.v -O3 --exe /media/1TB/Dropbox/PipelineC/git/PipelineC/examples/verilator/u24mult_main.cpp -I/home/julian/pipelinec_output/verilator -I/media/1TB/Dropbox/PipelineC/git/PipelineC 
make -j4 -C obj_dir -f Vtop.mk -I/home/julian/pipelinec_output/verilator -I/media/1TB/Dropbox/PipelineC/git/PipelineC

The -I for verilator seems to work for doing ex. just #include "uintN_t.h" - but it fails during the make flow if the C code doesnt have the path hardcoded in full in the include. Above I tried using -I for make too 🤷 .

Regarding inclusion of bit accurate types and this issue of including other files - do you have any suggestions?

[JulianKemmerer]

Note when we get around to testing more, need to specify to use the FPGA fabric 'implemented in PipelineC' version with --mult
./src/pipelinec ./examples/verilator/u24mult.c --mult fabric --sim_comb --verilator --main_cpp ./examples/verilator/u24mult_main.cpp

[suarezvictor]

I'll see the issue in detail tomorrow, but for the moment consider that the "make" command will ignore the -I flags What is usually done is to set an evironment variable CFLAGS=-I... -I.. (prior to calle make) Or for C++ use the env CXXFLAGS In regards to use bit accurate register you should just include "bitregs.h" and it will define uintX_t for up to 64 bits Hopefully this helps if not please wait until I can test it by myself El jue., 30 sep. 2021 22:07, Julian Kemmerer ***@***.***> escribió:

…

Note when we get around to testing more, need to specify to use the FPGA fabric 'implemented in PipelineC' version with --mult ./src/pipelinec ./examples/verilator/u24mult.c --mult fabric --sim_comb --verilator --main_cpp ./examples/verilator/u24mult_main.cpp — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBHVWJUHK27C6VYBHT7ZMLUEUCT5ANCNFSM5E6FSUZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[JulianKemmerer]

Excellent! CXXFLAGS worked! Hard coded paths removed
a8dd3dd

[suarezvictor]

In regards to C compatibility and continuing what we were talking, for connection to debug registers I suggest changing the current syntax: result(u24mult(x(), y())); To: DEBUG_SET(result, u24mult(DEBUG_GET(x),DEBUG_GET(y)); With #define DEBUG_SET(x, v) x(v) #define DEBUG_GET(x) x() Then when the code is compiled by a regular C compiler the macro would be defined differently. This way C syntax is not changed (an integer variable cannot be called as if it were a function) El jue., 30 sep. 2021 22:31, Victor Suarez Rovere ***@***.***> escribió:

…

I'll see the issue in detail tomorrow, but for the moment consider that the "make" command will ignore the -I flags What is usually done is to set an evironment variable CFLAGS=-I... -I.. (prior to calle make) Or for C++ use the env CXXFLAGS In regards to use bit accurate register you should just include "bitregs.h" and it will define uintX_t for up to 64 bits Hopefully this helps if not please wait until I can test it by myself El jue., 30 sep. 2021 22:07, Julian Kemmerer ***@***.***> escribió: > Note when we get around to testing more, need to specify to use the FPGA > fabric 'implemented in PipelineC' version with --mult > ./src/pipelinec ./examples/verilator/u24mult.c --mult fabric --sim_comb > --verilator --main_cpp ./examples/verilator/u24mult_main.cpp > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#20 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACBHVWJUHK27C6VYBHT7ZMLUEUCT5ANCNFSM5E6FSUZQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > >

[JulianKemmerer]

Sounds good to me
221082c

[suarezvictor]

I was finally able to simulate the floating point function and everything works wonderfully, see #25

Hopefully you can integrate all this so the test that "PASS" can be run with simple commands. Once that done, implementing more math functions will be far simpler... I'll also appreciate we can dig into details in regards to running the optimized 24x24 fixed point multiplication, we are in a better situation with this result