IRC logs for #openrisc Saturday, 2016-12-17

--- Log opened Sat Dec 17 00:00:31 2016
kc5tjaZipCPU|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
kc5tjaResolved those, and Verilator compiles the (almost) entire Kestrel-3 computer from Verilog.12:10
kc5tjaOf course, now I have to figure out how to actually drive it and hopefully we'll see it boot into eForth.12:11
kc5tjals -la12:11
kc5tjaerr12:11
ZipCPUkc5tja: You mean ... you are shocked that it builds with Verilator now?12:13
ZipCPUThe 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
kc5tjaI'm shocked that I only had three UNOPTFLAT issues to resolve.12:16
kc5tjaConsidering how much I rely on asynchronous logic in my designs, I would have expected more.12:17
kc5tjaI need to emulate RAM and the MGIA, and eventually, the SD card and PS/2 interfaces.12:17
ZipCPUBut ... if it is written properly, you shouldn't have any of those warnings, so having only three is a good thing.12:18
kc5tjaBut, 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
ZipCPUBlock 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
kc5tjaI'm not emulating block RAM.12:18
kc5tjaI'm emulating external RAM.12:18
ZipCPUI can emulate SDRAM, and even DDR3 SDRAM, but not Xilinx's interactions with DDR3 SDRAM.12:19
kc5tjaAsynchronous RAM.12:19
kc5tjaMy 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
ZipCPUYeah, I don't have any asynchronous RAM emulator routines.12:20
kc5tjaIt's just array access.  A ROM with write capability.  ;)12:20
kc5tjaBut, 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
kc5tjaIn a reasonable time frame.12:21
kc5tjaMGIA + RAM are "theoretically perfect" at this stage of development.12:22
ZipCPUOh, and I have a QSPI simulator that can emulate quad-SPI flash as well.12:22
kc5tjaI don't have any QSPI devices.12:22
kc5tjaOstensibly 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
kc5tjaIt's not clear from Verilator's documentation.  I'm guessing we must create our main.cpp file *inside* obj_dir?12:27
kc5tjauugh.  Their tutorial is useless.12:29
ZipCPUkc5tja: Can I offer you a simple example?12:30
ZipCPULook at helloworld.cpp inside https://github.com/ZipCPU/wbuart32 ... it'll be in the bench/cpp directory.12:31
ZipCPUIt runs a hello world Verilog demo found in bench/verilog, that uses verilog found in the rtl/ directory.12:31
ZipCPUMakefiles throughout make all of this possible.12:31
kc5tjaOh, no, my mistake.  VComputer versus Vcomputer.12:33
kc5tjaGahh.12:33
kc5tjaAnd now I need to turn a binary image into a Verilog hex dump.12:33
kc5tjaYou would think a convenient utility for this would already exist somewhere.12:34
kc5tjaEasy enough to write, I guess.12:34
ZipCPUkc5tja: I use libelf to turn an ELF executable into writes to memory, which my Verilog controller can read and set appropriately.12:36
kc5tjaToo complex for me feeble brain.12:41
kc5tjaPretty much anything involving ELF is a brick wall learning curve for me.12:41
ZipCPUkc5tja: It's not really that hard.  I built the loader in an afternoon as I recall.12:46
kc5tjaIt'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
ZipCPUHmm ... that may be the difference.  I haven't done anything (yet) with virtual addresses.12:50
kc5tjaIf you created a ld-script, you already did.12:53
kc5tjaThe addresses used in a ld script are virtual addresses from ELF's point of view.12:53
kc5tjaOK, I'm pretty much convinced I'm a retard or something.21:21
kc5tjaBecause I just cannot get libSDL to link against my C/C++ code at all via Verilator.21:21
ZipCPUWhat is it this time?21:21
kc5tjaWalls upon walls upon walls of unresolved symbols.21:37
kc5tjaI'm --><-- that close to just giving up.21:41
kc5tjaZipCPU: 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/2158a13537f60dfc1799e4ffc586bd9921:48
kc5tjaAny ideas?21:48
ZipCPU|Laptopkc5tja: Taking a look now.22:25
ZipCPU|LaptopSo ... 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|LaptopGo into that obj_dir directory, and type "make -f Vcomputer.mk"22:28
ZipCPU|LaptopThat should give you a Vcomputer__ALL.a file that you can then reference on your gcc/link line.22:28
kc5tjaI did, you're seeing the result of the failing make step.23:32
kc5tjaThe 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!