I’m doing a master project with the NOEL-V, I was hoping somebody could help me resolve some doubts. I don’t have an FPGA at the moment, so I’m trying to do a simulation using GHDL. I have changed the TECHLIBS and other technology variables to inferred, but seems like there are some technology dependent components since I get an error because of missing the unisim libraries. What do I have to modify so I don’t require said libraries?
Also, if I get an FPGA in the future, is there support for co-simulation using an smaller Xilinx board? Or alternatively for any Altera board?
Without knowing which design you are trying to simulate and what error message you see it is hard for me to help. The NOEL-V itself should not include any technology specific components when you set the VHDL generic tech (or memtech or favtech) to inferred. It is unclear if you have set the VHDL generic or only set the variable TECHLIBS in the makefile to inferred.
Do you mean by “co-simulation” to run and debug software on the NOEL-V processor running on the Xilinx board? This is possible, at the moment via GRMON (our software debug tool) and in the future also other solutions like OpenOCD. Both supports GDB debugging.
Thanks for your answer, I am using the “noelv-xilinx-kcu105” template design. From what you said I think I did it wrong, I just set the TECHLIBS to inferred in the Makefile and FABTECH, MEMTECH, PADTECH and CLKTECH in the config.vhd file. I guess this is not enough as when executing make ghdl I get the following error: noelvmp.vhd:53:9: cannot find resource library “unisim”. Do I have to also modify the VHDLSYNFILES? Or how do I set the VHDL generic?
When I said “co-simulation” I meant to run a part of the core in a small FPGA and simulate the rest, but I don’t know which boards could I use for that.
This particular template design uses unisim in the top level. The error message suggests shows that the dependency can be found on line 53 in the file noelvmp.vhd. Some hands-on modifications to remove all technology dependencies from the design will be needed.
Hi. I have similar problems. I want try use the GHDL as simulation tool with NOEL-V.
I´m using the noelv-generic design from grlib.
I did “make ghdl” and all looks good.
After I try “make ghdl-run” and in the end I receive this:
testbench
./testbench --assert-level=error --ieee-asserts=disable
make: ./testbench: No such file or directory
make: *** [../../bin/Makefile:502: ghdl-run] Error 127
After I force run the command: ghdl -r --ieee=synopsys --workdir=gnu/work --work=work cat ghdl.path testbench
Hi Marte,
What GHDL version are you using? From my experience, I’m not an expert on the subject, that issue is with the GHDL back-end. Only the GCC one generates the executable.
Try:
GHDL 3.0.0-dev (tarball) [Dunoon edition]
Compiled with GNAT Version: 10.3.0
GCC back-end code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2022 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
I ask about the same issue at GHDL forum and sounds be related with the GRLIB VHDL code style:
But sure when Gaisler/NOEL team develop the Makefile to run “make ghdl-run” everything runs well. Only need know which versions GHDL/GCC are used in that time.
GHDL 1.0.0 (Ubuntu 1.0.0+dfsg-6) [Dunoon edition]
Compiled with GNAT Version: 10.3.1 20211117
GCC back-end code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2021 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
We have made a number of changes to the GRILB code base which now should not lead to a crash. I tired running a simulation on the NOEL-V development branch yesterday and simulation with GHDL 2.0 still has some problems which we are currently looking into but a basic simulation should be working in the next release.
Hi Jonathan,
Thanks for your feedback. Have you idea when the next release will be available?
And a extra question (of topic): the NOEL-V is already ported and working in the BRAVE FPGAs?
You can follow the release schedule here: [NOEL-V](NOEL-V Information)
v8 of GRLIB has its planned release in December.
As for the second topic of BRAVE FPGAs, we offer support for BRAVE in the commercial release of GRLIB, however we do not know if anyone currently has tested NOEL-V with these FPGAs.
I can see that you are using a quite old version (1) of GHDL. I think your best bet is to try something newer, I haven’t tested the mcode version myself but building NOEL-V using the GCC version of GHDL works fine for me. I’m however building GHDL directly from their master branch GHDL 4.0.0-dev (3.0.0.r147.g6c56631a7) [Dunoon edition]. However, I do see that when trying to simulate I am getting a segmentation fault. I’ll look into the latter issue and see if there is something on our end which is causing this.
Hi everybody,
I am having the same issue with the grlib 2023 and ghdl 3.0 on a Mac. The Makefile as @Marte said earlier in this thread are still not working, and I have to force it using ghdl -r --ieee=synopsys --workdir=gnu/work --work=work cat ghdl.pathtestbench --vcd=gtkwave_waveform. This version of the GRLIB makes a segmentation fault, and the simulation stops. GTKwave shows not activity in clock neither reset. I hope @JonathanJ will dig into this and we can have this ready for the next release.
I am also having some troubles using VUNIT+ghdl with the GRLIB, and I wonder if someone is also trying to simulate it using vunit framework. The ghdl analyzer fails with duplicate instances i.e. procedures in grlib.stdio.vhd. This error occurs when vunit runs the analyzer to every file using the command is ghdl -a $path_to_grlib/stdio.vhd If I do not include the files that produce this error, vunit+ghdl simulates well. I just posted about this issue in the vunit gitter. I wonder if Gaisler’s people are aware of this issue.
Thanks!
The issue with vunit+ghdl resides in that the GRLIB does not fully compile with the standard 2008. It does with the standard 2002 though. GHDL uses by default what they call group 93, and it includes the 2002. If the GRLIB is simulated with ghdl, it runs without errors. However, VUNIT uses the standard 2008. It provides the option to pass the standard to libraries and files with add_source_file() and add_library(). This option works well in Modelsim. However, ghdl cannot mix different language standards. Although, I would like to see the GRLIB fully compatible with the std 2008, the work around is to avoid some files the gaisler/stdlib and a few debug only functions in some files i.e. ahbctrl.vhd, basically the ones which prints the information in the Amba bus.
I hope we will have a GRLIB fully compatible with the std 2008, not even mention the std 2019
I had time to dig this issue up today, and the GRLIB finally compiles with VUNIT+GHDL using vhdl-2002. As I pointed out in the previous message, the root cause is the GRLIB and the vhdl-2008. I posted this issue in the vunit gitter, and I messaged with Jim Lewis - who is chair of the IEEE 1076 VHDL Analysis and Standardization Working Group (VASG) and the founder of OSVVM (another great verification framework). He pointed out that the same issue
“For VHDL-2008, the versions of HREAD, HWRITE, … for std_logic_vector conflict (are ambiguous) with the ones for std_ulogic_vector because std_logic_vector is a subtype”. - Jim Lewis
He also suggested to comment the procedures declarations in the package, and just leave the Ulogic type. However, this cannot be done because the file testlib.vhd uses the procedures with the std_logic_vector inside the procedures with the same name but with Ulogic type. The error is easy to solve just updating the stdio package with vhdl-2008. These functions, and other functions in the stdio are used only in simulation. I do not remember if I also had this same error using Modelsim and vhdl-2008, but Jim also mentioned that even the errors are not showed up in other tools, it will be unusable due to ambiguity
“In 2008, other tools may not give you an error for this, but the functions will be unusable due to ambiguity.” - Jim Lewis
The other option that is valid (for me) is to remove the stdio package, and also remove from other files the code that calls to print (or toast) information during simulation. This is not ideally because I would like to see debug information, but once the GRLIB is up and running, that information is irrelevant if VUNIT (or OSVVM, CocoTB, UVM) is used for verification
Hi, I found the reason why the segmentation fault occurred. Our simulated memory model ahbram_sim uses a large signal array, signals and variables in vhdl behave quite differently and in this case the memory footprint is heavily affected. Furthermore, in this case the signal is only used within one process, hence a variable is more suitable. I changed the ram model to be variable based instead and the simulation no longer crashes.
Hopefully this change can make it into the next release, but in the meantime here is a manual patch for /lib/gaisler/sim/ahbram_sim.vhd
--- a/../../../../grlib/lib/gaisler/sim/ahbram_sim.vhd
+++ b/ahbram_sim.vhd
-- Entity: ahbram
-- File: ahbram.vhd
@@ -83,7 +101,7 @@ signal ramdata : std_logic_vector(dw-1 downto 0);
signal hwdata : std_logic_vector(dw-1 downto 0);
type ram_type is array (0 to (2**ramaddr'length)-1) of std_logic_vector(ramdata'range);
-signal ram : ram_type;
+-- signal ram : ram_type;
signal read_address : std_logic_vector(ramaddr'range);
begin
@@ -282,13 +300,14 @@ begin
variable recaddr : std_logic_vector(31 downto 0);
variable reclen : std_logic_vector(7 downto 0);
variable recdata : std_logic_vector(0 to 16*8-1);
+ variable ram : ram_type;
begin
if rising_edge(clk) then
if conv_integer(write) > 0 then
for i in 0 to dw/8-1 loop
if (write(i) = '1') then
- ram(to_integer(unsigned(ramaddr)))(i*8+7 downto i*8) <= hwdata(i*8+7 downto i*8);
+ ram(to_integer(unsigned(ramaddr)))(i*8+7 downto i*8) := hwdata(i*8+7 downto i*8);
end if;
end loop;
end if;
@@ -296,7 +315,7 @@ begin
end if;
if (rst = '0') and (FIRST = true) then
- ram <= (others => (others => '0'));
+ ram := (others => (others => '0'));
L1:= new string'("");
while not endfile(TCF) loop
@@ -332,7 +351,7 @@ begin
ofs := conv_integer(recaddr(log2(dw/32)+2 downto 2));
for i in 0 to wrd-1 loop
- ram((ai+i)/(dw/32))(dw-32-(32*(i+ofs) mod dw)+31 downto (dw-32-32*(i+ofs) mod dw)) <=
+ ram((ai+i)/(dw/32))(dw-32-(32*(i+ofs) mod dw)+31 downto (dw-32-32*(i+ofs) mod dw)) :=
recdata(i*32 to i*32+32-1);
end loop;
@@ -348,9 +367,9 @@ begin
end if;
+ ramdata <= ram(to_integer(unsigned(read_address)));
end process RamProc;
- ramdata <= ram(to_integer(unsigned(read_address)));
reg : process (clk)
begin
