--- Log opened Sat Dec 17 00:00:31 2016 | ||
kc5tja | ZipCPU|Laptop: I'm rather *shocked*. My entire Kestrel-3 design had only three UNOPTFLAT warnings, all in the CPU, and all related to ACK_I influencing which signals are driven back out of the Wishbone interconnect. | 12:10 |
---|---|---|
kc5tja | Resolved those, and Verilator compiles the (almost) entire Kestrel-3 computer from Verilog. | 12:10 |
kc5tja | Of course, now I have to figure out how to actually drive it and hopefully we'll see it boot into eForth. | 12:11 |
kc5tja | ls -la | 12:11 |
kc5tja | err | 12:11 |
ZipCPU | kc5tja: You mean ... you are shocked that it builds with Verilator now? | 12:13 |
ZipCPU | The difficulty of building the rest of it really then depends upon 1) the number of peripherals you need to support/simulate, 2) how you wish to load an ELF program into memory to boot up, and 3) how you wish to interact with/debug an ongoing simulation. | 12:14 |
kc5tja | I'm shocked that I only had three UNOPTFLAT issues to resolve. | 12:16 |
kc5tja | Considering how much I rely on asynchronous logic in my designs, I would have expected more. | 12:17 |
kc5tja | I need to emulate RAM and the MGIA, and eventually, the SD card and PS/2 interfaces. | 12:17 |
ZipCPU | But ... if it is written properly, you shouldn't have any of those warnings, so having only three is a good thing. | 12:18 |
kc5tja | But, I might not even go that far. If I see it boot into eForth with a detached keyboard, I might just try to synthesize it onto an FPGA right away. | 12:18 |
ZipCPU | Block RAM is easy. I don't know about MGIA. I have a simulation you can use for the SD card using the SPI protocol if you want it. | 12:18 |
kc5tja | I'm not emulating block RAM. | 12:18 |
kc5tja | I'm emulating external RAM. | 12:18 |
ZipCPU | I can emulate SDRAM, and even DDR3 SDRAM, but not Xilinx's interactions with DDR3 SDRAM. | 12:19 |
kc5tja | Asynchronous RAM. | 12:19 |
kc5tja | My goal with this is, "Does my Verilog describe a physical computer compatible with the emulator I've been working in for the last three years?" | 12:19 |
ZipCPU | Yeah, I don't have any asynchronous RAM emulator routines. | 12:20 |
kc5tja | It's just array access. A ROM with write capability. ;) | 12:20 |
kc5tja | But, the reason I'm emulating it instead of letting Verilog simulate it is because the RAM also serves as a frame buffer for the MGIA, and I want the MGIA to (every vsync) refresh an SDL window. | 12:21 |
kc5tja | In a reasonable time frame. | 12:21 |
kc5tja | MGIA + RAM are "theoretically perfect" at this stage of development. | 12:22 |
ZipCPU | Oh, and I have a QSPI simulator that can emulate quad-SPI flash as well. | 12:22 |
kc5tja | I don't have any QSPI devices. | 12:22 |
kc5tja | Ostensibly the BlackIce board has a QSPI channel back to the ARM processor, but I don't yet have plans of making use of that justyet. | 12:22 |
kc5tja | (eventually, but not at the moment) | 12:23 |
kc5tja | It's not clear from Verilator's documentation. I'm guessing we must create our main.cpp file *inside* obj_dir? | 12:27 |
kc5tja | uugh. Their tutorial is useless. | 12:29 |
ZipCPU | kc5tja: Can I offer you a simple example? | 12:30 |
ZipCPU | Look at helloworld.cpp inside https://github.com/ZipCPU/wbuart32 ... it'll be in the bench/cpp directory. | 12:31 |
ZipCPU | It runs a hello world Verilog demo found in bench/verilog, that uses verilog found in the rtl/ directory. | 12:31 |
ZipCPU | Makefiles throughout make all of this possible. | 12:31 |
kc5tja | Oh, no, my mistake. VComputer versus Vcomputer. | 12:33 |
kc5tja | Gahh. | 12:33 |
kc5tja | And now I need to turn a binary image into a Verilog hex dump. | 12:33 |
kc5tja | You would think a convenient utility for this would already exist somewhere. | 12:34 |
kc5tja | Easy enough to write, I guess. | 12:34 |
ZipCPU | kc5tja: I use libelf to turn an ELF executable into writes to memory, which my Verilog controller can read and set appropriately. | 12:36 |
kc5tja | Too complex for me feeble brain. | 12:41 |
kc5tja | Pretty much anything involving ELF is a brick wall learning curve for me. | 12:41 |
ZipCPU | kc5tja: It's not really that hard. I built the loader in an afternoon as I recall. | 12:46 |
kc5tja | It's been a never-ending source of problems for me. First and foremost, it works great if, and only if, your virtual load address = physical load address. In any other condition, ELF complexity sky-rockets. | 12:47 |
ZipCPU | Hmm ... that may be the difference. I haven't done anything (yet) with virtual addresses. | 12:50 |
kc5tja | If you created a ld-script, you already did. | 12:53 |
kc5tja | The addresses used in a ld script are virtual addresses from ELF's point of view. | 12:53 |
kc5tja | OK, I'm pretty much convinced I'm a retard or something. | 21:21 |
kc5tja | Because I just cannot get libSDL to link against my C/C++ code at all via Verilator. | 21:21 |
ZipCPU | What is it this time? | 21:21 |
kc5tja | Walls upon walls upon walls of unresolved symbols. | 21:37 |
kc5tja | I'm --><-- that close to just giving up. | 21:41 |
kc5tja | ZipCPU: I've managed to resolve virtually all of the unresolved symbol errors (all 54KB of them!!), but this is continuously eluding me. https://gist.github.com/sam-falvo/2158a13537f60dfc1799e4ffc586bd99 | 21:48 |
kc5tja | Any ideas? | 21:48 |
ZipCPU|Laptop | kc5tja: Taking a look now. | 22:25 |
ZipCPU|Laptop | So ... you didn't use the make files Verilator gave you, which would've turned Vcomputer into a library that you could then work with? | 22:27 |
ZipCPU|Laptop | Go into that obj_dir directory, and type "make -f Vcomputer.mk" | 22:28 |
ZipCPU|Laptop | That should give you a Vcomputer__ALL.a file that you can then reference on your gcc/link line. | 22:28 |
kc5tja | I did, you're seeing the result of the failing make step. | 23:32 |
kc5tja | The problem is, that .a file doesn't have the definitions referenced. | 23:32 |
--- Log closed Sun Dec 18 00:00:13 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!