zbasic make error

[kendallgreen]

Using Ubuntu 20.04 LTS on Ryzen 1600 with 8GB ram, Path=usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/ken/zipcpu/sw/install/cross-tools/bin I get the following errors trying to build zbasic after cloning: ar --transform s,^,date +%Y%m%d-zbasic/, -chjf date +%Y%m%d-zbasic.tjz find sw -name "*.cpp" find sw -name "*.c" find sw -name "*.h" find sw -name "*.sh" find sw -name "*.py" find sw -name "*.pl" find sw -name "*.png" find sw -name Makefile find rtl -name "*.v" find rtl -name Makefile find sim -name Makefile find sim -name "*.cpp" find sim -name "*.h" find sim -name "*.c" find . -name "*.txt" find . -name "*.html" find . -name "*.xdc" find auto-data -name "*.txt" README.md verilator -Wall -Wno-TIMESCALEMOD --MMD -O3 --trace -Mdir ./obj_dir -y wbuart -y wbubus -y cpu -y rtc -y sdspi -cc main.v %Error: Unknown warning specified: -Wno-TIMESCALEMOD make[1]: [Makefile:77: obj_dir/Vmain.h] Error 1 make: [Makefile:140: verilated] Error 2

[ZipCPU]

This is a Verilator issue. Verilator didn't used to support the TIMESCALEMOD check, and since adding it things that once passed no longer pass. The -Wno-TIMESCALEMOD was added so that the design would continue to build.

Try removing it and building again.

[ZipCPU]

I should also ask, which version of Verilator are you using? Try running, verilator -V | grep ^verilator. That should give you a version number.

[kendallgreen]

I am using Verilator 4.028 2020-02-06 rev v4.026-92-g890cecc1. I am not sure where to find the -Wno-TIMESCALEMOD. I have built zipcpu, the tool chain and tested it as described successfully in the ZipCPU toolchain page. My aim is to build the zbasic package for my Basys 3 FPGA. I am not sure where to clone the zbasic and autofpga directories. Right now they are in separate directories.

[ZipCPU]

You should be able to find the Wno-TIMESCALEMOD option on line 53 of the rtl/Makefile.

You may consider the ZipCPU, AutoFPGA, and ZBasic projects as separate and independent projects. Neither are subdirectories of any other. They can each be cloned at the same level. The ZBasic project includes a copy of the ZipCPU, breaking the RTL dependence. However, you will need to have the ZipCPU tool chain (zip-gcc, zip-as, zip-ld, zip-objdump, etc.) in your path to build software for ZBasic. You will also need to have AutoFPGA in your path to use rebuild the AutoFPGA built files in ZBasic. Those are the big dependencies.

Beware that the Basys3 board doesn't have a lot of memory. You may find that you don't have enough memory for the C library. You can still use the ZipCPU, but you'll need to carefully manage the memory you have and what you are using it for. You may also want to place a lot of your instruction memory into flash.

Dan

[kendallgreen]

thanks. compiled without error

[ZipCPU]

I'll keep this open for a while in case you have further questions, but you can often get a hold of me faster on IRC. You can find me on both freenode and Libera.chat these days. There's even a #zipcpu channel ...

[kendallgreen]

thanks. I need a lot of help. First, suggestions on modifying zipcpu to fit within the Basys3 memory.

[ZipCPU]

No modifications will be required of the CPU itself--save that you might want to either skip on the caches, or be cautious of how much cache you use. Cache size is determined by the LGICACHE and LGDCACHE parameter settings in zipmaster.txt. Whether or not the cache is used is currently controlled by the cpudefs.v file. I say currently, since I'm hoping to rearrange that so that caching or no caching is controlled by LGICACHE and LGDCACHE--the current repo just isn't there yet.

Next, you'll want to trim down the RAM size to something reasonable. ZBasic is primarily built to be a simulation only demonstration, so it uses a ridiculous amount of block RAM--few chips have that much. You can trim this RAM amount, however, in the bkram.txt configuration file. Specifically, you'll want to adjust the LGMEMSZ (log-based two of the memory size) configuration parameter. The mem_flash_bkram.txt might also need to be adjusted. This file contains a linker file snippet which will be copied and pasted into the linker's configuration file telling it where to find code. You will probably want to adjust that linker snippet to look more like this one. The CMod S6 project, however, is an older one. So you may need to adjust the names of the pointers defined there to match those required by the ZipCPU's crt0.

That should at least get you a lot closer.

Dan

[kendallgreen]

Thanks, but I think that this is way beyond my abilities. I got zipcpu and zbasic to compile, but autofpga demo fails at make autodata. I was hoping that I could program zipcpu into my Basys3, understand what was involved in programming a cpu into my fpga. then I could try a more detailed cpu like RISC-V. But I don't understand where to get the many files (.v and .h) that I would need. I don't know how to make the Basys3_Master.xdc file into these files. Thanks for your help.

On 7/26/21, Dan Gisselquist @.***> wrote:

No modifications will be required of the CPU itself--save that you might want to either skip on the caches, or be cautious of how much cache you use. Cache size is determined by the LGICACHE and LGDCACHE parameter settings in zipmaster.txt. Whether or not the cache is used is currently controlled by the cpudefs.v file. I say currently, since I'm hoping to rearrange that so that caching or no caching is controlled by LGICACHE and LGDCACHE--the current repo just isn't there yet.

Next, you'll want to trim down the RAM size to something reasonable. ZBasic is primarily built to be a simulation only demonstration, so it uses a ridiculous amount of block RAM--few chips have that much. You can trim this RAM amount, however, in the bkram.txt configuration file. Specifically, you'll want to adjust the LGMEMSZ (log-based two of the memory size) configuration parameter. The mem_flash_bkram.txt might also need to be adjusted. This file contains a linker file snippet which will be copied and pasted into the linker's configuration file telling it where to find code. You will probably want to adjust that linker snippet to look more like this one. The CMod S6 project, however, is an older one. So you may need to adjust the names of the pointers defined there to match those required by the ZipCPU's crt0.

That should at least get you a lot closer.

Dan

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/ZipCPU/zbasic/issues/8#issuecomment-887051630

-- Kendall B. Green 5B2761669EF47F65

[ZipCPU]

Make autodata will fail if you haven't put autofpga into your path somewhere.

export PATH=/path/to/autofpga/sw:$PATH

The main makefile for zbasic puts the files, generated by AutoFPGA, into their appropriate places within the project after they have been generated. You don't need to do anything more--once AutoFPGA is running.

Dan

[kendallgreen]

my PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/ken/zipcpu/sw/install/cross-tools/bin:/home/ken/autofpga/sw running make autodata results in make: *** No rule to make target 'autodata'. Stop. I have successfully run make in zbasic. the relevant portion of the makefile for autofpga is .PHONY: all all: sw YYMMDD:=date +%Y%m%d

.PHONY: archive

{{{

archive: tar --transform s,^,$(YYMMDD)-video/, -chjf $(YYMMDD)-autofpga.tjz sw/ auto-data/ demo-out/ doc/

}}}

.PHONY: autofpga autofpga: sw

.PHONY: sw

{{{

sw: $(MAKE) --no-print-directory --directory=sw

}}}

.PHONY: clean

{{{

clean: $(MAKE) --no-print-directory --directory=sw clean

}}}

no target for autodata

make all yeilds make --no-print-directory --directory=sw bash runme.sh Opened autofpga.dbg WARNING: Too many interrupts assigned to PIC altpic Clock: hdmi_out_clk, is i_hdmi_out_clk at 148500 kHz preset != NULL Clock: clk, is i_clk at 100 MHz, w/ associated reset i_reset Clock: net_rx_clk, is i_net_rx_clk at 125 MHz Clock: hdmi_in_clk, is i_hdmi_in_clk at 148500 kHz Clock: hdmi_in_hsclk, is i_hdmi_in_hsclk at 1485 MHz All clocks enumerated Bus: rambus exit code 0

Again thanks for your help.

[ZipCPU]

That's the autofpga make file. It looks like it built fine--although I may need to look at interrupt assignments.

Now try the zbasic make file. From the root zbasic directory, type make autodata.

Dan

[kendallgreen]

I think I got zbasic to work, except I can't get the tttt to work on the zipcpu. I got the cputest, contest, hello and sdtest to work. I still don't understand how to get zbasic loaded on the the Basys3. I found that I could only reduce the LGMEMSZ to 17 without creating an error. that equates to 128Kb, which is the limit for Basys3. Any suggestons? Again thanks.

[ZipCPU]

Sure!

You've built a design, you've simulated it, so you should be able to place it into your Basys3 board. The only issue I may not have explained is the issue of how to start the CPU once you have the design, built via Vivado or other synthesis tool, loaded onto your board.

That's the purpose of the zipload program found in the sw/host directory. Here are the steps:

1. Build the RTL into a design that you can then load onto your board. I typically leave the ZIP_START_HALTED parameter to true. Hence, once you load this design on your board the CPU will be in a halted state waiting for you to start it.
2. Build the program you wish to run on the board--cputest for example
3. Run the netuart program to establish communication between you and your board. Leave this program running. It will forward the serial port on your board to a TCP/IP network connection. The details of that network connection can be found in the sw/host/port.h file.
4. To test that this connection works, try running wbregs version. This should read the date stamp from within the design, and so it should return the DATESTAMP value found in the rtl/builddate.v file from when you built the design. This should assure you that you are properly interacting with the design.
5. You can now load your cputest program onto the board: Type zipload -r <path_to_zipcpu_program>, where your path may likely be ../board/cputest. The CPU should now be up and running
6. You'll need to telnet to the CPU's serial port to interact with it. telnet localhost 8846. This will establish a TCP/IP link, local to your machine, to the netuart program (you left it running, right?), which will then forward keys you type to the USB serial port of the FPGA and outputs from the CPU to your console. You can keep this console port up and running across program reloads (i.e. zipload) or even FPGA reloads (i.e. loading a new bitstream via Vivado).
7. You can also run all of these steps via simulation as well. The only difference is that the simulator will take the place of the netuart program--wbregs, zipload, and the console port should all work the same.

As for tttt, you haven't said what your problem was, so it would be hard to know how to help you there.

Dan

[kendallgreen]

I am confused at step 1. I loaded the zbasic/rtl files into Vivado 2020.2 in a New Project called zbasic_project. I ran synthesis which reported that IO had a 198% utilization and implementation which reported the design used 210 IO ports and the board had only 106. I also ran it with the Basys3_Master.xdc constraint file with the same results.

[kendallgreen]

The errors I got trying to build tttt for zipcpu are as follows (100 lines) /board$ make tttt CROSS=zip- ARCH=zip make --no-print-directory -C tttt/src ARCH=zip CROSS=zip- zip-tttt Building dependency file zip-gcc -T../../../zlib/../board/board.ld obj-zip/comborow.o obj-zip/comboset.o obj-zip/gboard.o obj-zip/strategy.o obj-zip/vset.o obj-zip/main.o -L../../../zlib -Wl,--start-group -Wl,--Map=zip-tttt.map -lzbasic -lc -o zip-tttt /home/ken/zipcpu/sw/install/cross-tools/lib/gcc/zip/6.2.0/../../../../zip/lib/libc.a(lib_a-vfprintf.o): In function _vfprintf_r': vfprintf.c:(.text+0x648): undefined reference tounorddf2' vfprintf.c:(.text+0x664): undefined reference to `ledf2' vfprintf.c:(.text+0x7f8): undefined reference to __eqdf2' vfprintf.c:(.text+0x1470): undefined reference toeqdf2' vfprintf.c:(.text+0x1b1c): undefined reference to `nedf2' vfprintf.c:(.text+0x1f28): undefined reference to __unorddf2' vfprintf.c:(.text+0x1f48): undefined reference toltdf2' vfprintf.c:(.text+0x2004): undefined reference to `nedf2' /home/ken/zipcpu/sw/install/cross-tools/lib/gcc/zip/6.2.0/../../../../zip/lib/libc.a(lib_a-dtoa.o): In function _dtoa_r': dtoa.c:(.text+0x2c4): undefined reference toeqdf2' dtoa.c:(.text+0x3a0): undefined reference to `floatunsidf' dtoa.c:(.text+0x3c0): undefined reference to __subdf3' dtoa.c:(.text+0x3d8): undefined reference tomuldf3' dtoa.c:(.text+0x3f0): undefined reference to `adddf3' dtoa.c:(.text+0x400): undefined reference to __floatsidf' dtoa.c:(.text+0x418): undefined reference tomuldf3' dtoa.c:(.text+0x428): undefined reference to `adddf3' dtoa.c:(.text+0x434): undefined reference to __fixdfsi' dtoa.c:(.text+0x448): undefined reference toltdf2' dtoa.c:(.text+0x45c): undefined reference to `floatsidf' dtoa.c:(.text+0x46c): undefined reference to __nedf2' dtoa.c:(.text+0x4a8): undefined reference toltdf2' dtoa.c:(.text+0x61c): undefined reference to `divdf3' dtoa.c:(.text+0x65c): undefined reference to __muldf3' dtoa.c:(.text+0x67c): undefined reference todivdf3' dtoa.c:(.text+0x6b8): undefined reference to `muldf3' dtoa.c:(.text+0x6e8): undefined reference to __muldf3' dtoa.c:(.text+0x728): undefined reference toltdf2' dtoa.c:(.text+0x75c): undefined reference to `muldf3' dtoa.c:(.text+0x76c): undefined reference to __floatsidf' dtoa.c:(.text+0x778): undefined reference tomuldf3' dtoa.c:(.text+0x788): undefined reference to `adddf3' dtoa.c:(.text+0x7a8): undefined reference to __floatsidf' dtoa.c:(.text+0x7b4): undefined reference tomuldf3' dtoa.c:(.text+0x7c4): undefined reference to `adddf3' dtoa.c:(.text+0x7ec): undefined reference to __subdf3' dtoa.c:(.text+0x7fc): undefined reference togtdf2' dtoa.c:(.text+0x820): undefined reference to `ltdf2' dtoa.c:(.text+0x868): undefined reference to __divdf3' dtoa.c:(.text+0x874): undefined reference tosubdf3' dtoa.c:(.text+0x884): undefined reference to `fixdfsi' dtoa.c:(.text+0x890): undefined reference to __floatsidf' dtoa.c:(.text+0x8a0): undefined reference tosubdf3' dtoa.c:(.text+0x8c8): undefined reference to `gtdf2' dtoa.c:(.text+0x8e4): undefined reference to __subdf3' dtoa.c:(.text+0x8f4): undefined reference togtdf2' dtoa.c:(.text+0x91c): undefined reference to `subdf3' dtoa.c:(.text+0x928): undefined reference to __ltdf2' dtoa.c:(.text+0x95c): undefined reference tomuldf3' dtoa.c:(.text+0x974): undefined reference to `muldf3' dtoa.c:(.text+0x980): undefined reference to __fixdfsi' dtoa.c:(.text+0x98c): undefined reference tofloatsidf' dtoa.c:(.text+0x99c): undefined reference to `subdf3' dtoa.c:(.text+0x9b8): undefined reference to __ltdf2' dtoa.c:(.text+0x9ec): undefined reference tomuldf3' dtoa.c:(.text+0xa00): undefined reference to `fixdfsi' dtoa.c:(.text+0xa0c): undefined reference to __floatsidf' dtoa.c:(.text+0xa1c): undefined reference tosubdf3' dtoa.c:(.text+0xa58): undefined reference to `adddf3' dtoa.c:(.text+0xa64): undefined reference to __ltdf2' dtoa.c:(.text+0xa84): undefined reference tosubdf3' dtoa.c:(.text+0xa90): undefined reference to `gtdf2' dtoa.c:(.text+0xad0): undefined reference to __muldf3' dtoa.c:(.text+0xadc): undefined reference tofixdfsi' dtoa.c:(.text+0xae8): undefined reference to `floatsidf' dtoa.c:(.text+0xaf8): undefined reference to __subdf3' dtoa.c:(.text+0xb94): undefined reference todivdf3' dtoa.c:(.text+0xb9c): undefined reference to `fixdfsi' dtoa.c:(.text+0xba8): undefined reference to __floatsidf' dtoa.c:(.text+0xbb4): undefined reference tomuldf3' dtoa.c:(.text+0xbc4): undefined reference to `subdf3' dtoa.c:(.text+0xc04): undefined reference to __muldf3' dtoa.c:(.text+0xc14): undefined reference toledf2' dtoa.c:(.text+0xc34): undefined reference to `muldf3' dtoa.c:(.text+0xc44): undefined reference to __eqdf2' dtoa.c:(.text+0xc5c): undefined reference toadddf3' dtoa.c:(.text+0xc70): undefined reference to `ltdf2' dtoa.c:(.text+0xc88): undefined reference to __eqdf2' dtoa.c:(.text+0xd3c): undefined reference tomuldf3' dtoa.c:(.text+0xd50): undefined reference to `eqdf2' dtoa.c:(.text+0xd80): undefined reference to __divdf3' dtoa.c:(.text+0xd88): undefined reference tofixdfsi' dtoa.c:(.text+0xd94): undefined reference to `floatsidf' dtoa.c:(.text+0xda0): undefined reference to __muldf3' dtoa.c:(.text+0xdb0): undefined reference tosubdf3' dtoa.c:(.text+0x15c4): undefined reference to `floatsidf' dtoa.c:(.text+0x15d0): undefined reference to __muldf3' dtoa.c:(.text+0x15e0): undefined reference toadddf3' /home/ken/zipcpu/sw/install/cross-tools/lib/gcc/zip/6.2.0/../../../../zip/lib/libc.a(lib_a-mprec.o): In function __ratio': mprec.c:(.text+0x19d8): undefined reference to__divdf3' /home/ken/zipcpu/sw/install/cross-tools/lib/gcc/zip/6.2.0/../../../../zip/lib/libc.a(lib_a-mprec.o): In function _mprec_log10': mprec.c:(.text+0x1ac0): undefined reference tomuldf3' collect2: error: ld returned 1 exit status make[1]: [Makefile:130: zip-tttt] Error 1 make: [Makefile:136: tttt] Error 2

[ZipCPU]

You may need to do some editing on your XDC file. AutoFPGA also produces a toplevel.v file for your top level. You'll need to make sure Vivado knows that's the top level file. (That toplevel.v file doesn't have 210 I/Os, so you've made something else your toplevel.) You'll also need to make certain the ports in that toplevel.v file match those in your XDC file.

As for the GCC errors, try adding -lgcc to the end of the GCC command line in the make file.

Dan

[kendallgreen]

My initial thoughts are since Basys3 doesn't have an SD card or RTC , I think that I should remove the references to those in zbasis/rtl/main.v and add @XDC.FILE=Basys3_Master.xdc in zbasis/rtl/global.txt. In the Basys3_Master.xdc, the clock and QSPI Flash ports should uncommented to match the expected ports in the auotfpga generated toplevel.v file in zbasis/rtl. I will make sure that Vivado recognizes that toplevel.v is the toplevel. Any other suggestions? Again thanks.

[ZipCPU]

No, don't edit main.v or toplevel.v. Instead, remove the reference to the SD card from the auto-data/Makefile. This will then remove it from the main.v file, toplevel.v, main_tb.cpp, the board.h file, etc. By doing it this way, you'll be spared from re-doing these edits again later should you run AutoFPGA again.

You should not ever need to edit main.v or toplevel.v. Edits to those files can be accomplished by editing the respective AutoFPGA configuration file. So, for example, to adjust how the flash is handled in the top level file you'll want to adjust the @TOP.INSERT tag. This will then adjust how the toplevel.v file is made, since this data is (essentially) directly copied into toplevel.v to create it.

As for the RTL ... you can remove that from the config if you want to, but you don't need to. As built, it's an internal (logic-only) device that you can include or not at your call. There are no I/O's associated with it. To remove, just remove it from the AutoFPGA Makefile again--same as you did with the SD card.

As an example of removing things, here you can see how I removed some (optional) Wishbone scopes (i.e. I commented them out), while still leaving a reminder to me that they can be added back into the design again later. You can read more about the basics of these scope (they're really a form of internal logic analyzer) here. They're very useful for debugging designs.

Dan

[ZipCPU]

It's been a month without further comment. I'm going to close this issue as "Solved". Indeed, the issue was solved several comments ago. If you have further issues, please feel free to open a new github issue. Dan