| --- Log opened Fri Oct 28 00:00:16 2016 | ||
| -!- Netsplit *.net <-> *.split quits: simoncoo1, shorne | 08:20 | |
| vidya | Hello all, Can anyone tell how to do RTL simulation of mor1kx cores in linux? | 08:28 |
|---|---|---|
| ZipCPU | vidya: I use verilator. | 08:32 |
| ZipCPU | The command line, and options, that worked for me was: fusesoc sim --sim=verilator mor1kx-generic --elf-load=<program> | 08:34 |
| ZipCPU | Where <program> needs to be replaced with the actual name of the ELF program you wish to run. | 08:34 |
| vidya | Can you share any link which talks about verilator tutorial? | 08:35 |
| -!- Netsplit over, joins: shorne | 08:36 | |
| ZipCPU | Jeremy wrote a tutorial here: http://www.embecosm.com/resources/appnotes/#EAN6 | 08:37 |
| ZipCPU | I've never tried it though. | 08:37 |
| ZipCPU | He's often on the channel, but I don't seem him here today. | 08:38 |
| ZipCPU | I learned Verilator both from the documentation itself, www.veripool.org/projects/verilator/wiki/Manual-verilator | 08:39 |
| ZipCPU | as well as from looking at what it produces. | 08:39 |
| ZipCPU | That's the neat thing about open source: you _can_ debug someone else's work if you need to. | 08:39 |
| ZipCPU | In my case, I've not found any bugs in Verilator, but diving through Verilator produced code has helped me find bugs in my own. | 08:40 |
| vidya | Cool, thanks a lot. I will try it out :) | 08:40 |
| vidya | @ZipCPU I get this error - ERROR: Failed to build simulation model ERROR: "make -f Vorpsoc_top.mk Vorpsoc_top" exited with an error code. ERROR: See stderr for details. | 09:33 |
| SMDwrk | vidya: what is your verilator version? | 09:33 |
| vidya | My verilator version is Verilator 3.874 2015-06-06 rev verilator_3_872-20-g0d43051 | 09:34 |
| SMDwrk | check err file: I bet there are errors related to unknown "v" object or something | 09:35 |
| SMDwrk | am I right? | 09:36 |
| vidya | where can I find the err file, I mean which location? | 09:44 |
| ZipCPU | kc5tja: Are you working with iCE chips? If so, are you using yosys? | 10:15 |
| vidya | i'm able to remove that error by editing ~/.local/share/orpsoc-cores/systems/mor1kx-generic/bench/verilator/tb.cpp and replace all "top->v->" with "top->orpsoc_top->" | 10:32 |
| vidya | but after running simulation it says : Can't open Error loading elf file | 10:33 |
| ZipCPU | Ah ... okay, that's a different problem. | 10:33 |
| ZipCPU | Let's start at the top: do you know what an elf file is? Do you know what program generates it? | 10:34 |
| vidya | elf is an executable file generated from a c code i compiled for openrisc ? | 10:54 |
| ZipCPU | Okay, good. Sorry if I was talking down to you at all, but I wanted to make sure the easy mistakes were eliminated before trying to help further. | 10:55 |
| ZipCPU | Then, looking more closely at your error, ... did you leave a space between the = and the elf filename? | 10:56 |
| ZipCPU | Why was it that it didn't name the elf file in it's error message? | 10:56 |
| vidya | yes there was a space, now i'm getting this INFO: Running simulation Loading ~/or1k/c_codes/hello.elf Can't open ~/or1k/c_codes/hello.elf Error loading elf file | 10:57 |
| SMDwrk | vidya: don't use relative path for verilator | 10:59 |
| vidya | Thanku SMDwrk , relative path was the problem | 11:03 |
| vidya | simulation was success | 11:03 |
| vidya | Thank you ZipCPU for help too :). I will try to see if I can see the simulation results in waveform | 11:04 |
| ZipCPU | Gosh, my pleasure. | 11:05 |
| ZipCPU | (Although it is kind of goofy to think that I'm helping people run a competing processor to my own ... ;) | 11:05 |
| SMDwrk | vidya: for vcd you have to pass --vcd before --load-elf afair | 11:07 |
| SMDwrk | apparently options order does matter | 11:07 |
| vidya | Oh ok, will keep that in mind. | 11:10 |
| kc5tja | ZipCPU: I use yosys, but so far do not have any iCE chips of my own. | 12:16 |
| ZipCPU | Then ... it can't be for the kestrel project you are working on, can it? | 12:17 |
| kc5tja | At one point, I could not get any FPGA dev environment for my Nexys2 to work. | 12:18 |
| kc5tja | So I decided on using a multi-chip iCE40-based computer instead. | 12:18 |
| kc5tja | One iCE40 for the CPU, one for the I/O hardware (audio, video, GPIO, etc.), and one for RAM controller and bus arbiter. | 12:18 |
| ZipCPU | So ... how are you testing your logic, if you don't have the chips to put it on yet? | 12:18 |
| kc5tja | I write bench-tests in Verilog and run them using iverilog. | 12:19 |
| kc5tja | I follow test-driven development practices: I write the test first, make sure it fails, then write just enough Verilog or SMG to make it pass. | 12:19 |
| ZipCPU | Okay. That's valid. But then, your computer has no hardware ... yet, right? | 12:19 |
| kc5tja | But, let's be honest: I *only* got so far as the CPU. I don't have other components yet. But they'd be tested in a similar fashion. | 12:20 |
| kc5tja | Correct. | 12:20 |
| ZipCPU | That's fine, all well and good too. It's exactly how I would start. | 12:20 |
| kc5tja | I wanted to have hardware in time for the 5th workshop, but this year has been a *total* productivity bust. | 12:20 |
| ZipCPU | Give me a holler when you need peripherals. I have quite a stash by now. | 12:21 |
| kc5tja | I'm going to re-use the Kestrel-2's peripherals to start. Then I'll replace the MGIA video core with a CGIA color graphics core. | 12:22 |
| kc5tja | Do you have an SPI core that supports DMA by any chance? | 12:22 |
| ZipCPU | I have a SPI core, yes. I have a DMA core as well, yes. The DMA core can use the SPI core. | 12:22 |
| ZipCPU | I'm wondering if you were attempting to ask something else, though, 'cause I don't feel like my answer was anywhere profound. | 12:23 |
| kc5tja | Well, I was eventually going to replace the use of the GPIO for bit-banging the SPI port with a dedicated core capable of supporting SD cards with as little CPU intervention as possible. | 12:23 |
| ZipCPU | I should mention, though, that the SPI core I have is for QSPI memories ... and the DMA doesn't issue SPI commands, but "memory" access types of commands ... | 12:23 |
| ZipCPU | Ah ... ok. I have a SD-card core that runs off of a SPI bus. | 12:24 |
| kc5tja | That's not what I'll be needing unfortunately. | 12:24 |
| ZipCPU | You're looking for something simpler, it sounds like. | 12:24 |
| kc5tja | Does the SD card core fetch and store blocks of data w/out CPU? | 12:24 |
| ZipCPU | Yes. | 12:24 |
| kc5tja | That's what I'm looking for. | 12:25 |
| ZipCPU | Then that's what I have. | 12:25 |
| kc5tja | And, preferably, something that supports SDHC/SDXC protocol as well, since it's getting hard to find plain-vanilla SD protocol cards these days. | 12:25 |
| ZipCPU | Oh, no ... this controller is pretty sparse. It's designed to work closely with the CPU. | 12:26 |
| ZipCPU | The CPU can issue commands to the controller (48-bits), and read statuses. Whether or not you issue SDHC or SDXC commands is up to you. | 12:26 |
| ZipCPU | It runs off of four registers: | 12:26 |
| kc5tja | OK, but I can definitely configure it to save 512 to 1024 byte blocks of data to memory w/out the CPU executing a tight loop, right? | 12:27 |
| ZipCPU | 1) A control register. When written to it starts an SD operation. | 12:27 |
| ZipCPU | 2) A data register, used as the argument for the control word and may contain status as the result. | 12:27 |
| ZipCPU | 3 & 4) FIFO words. After a block read, you can read N times from the register you selected to get your data. You can also write N times to one of these before writing your sector, and then send it via the command register. | 12:28 |
| ZipCPU | Memory block size is configurable. | 12:28 |
| ZipCPU | Gosh, it's even configurable on a command by command basis. | 12:28 |
| kc5tja | Ahh, OK. That's still an epic step up from where I am. ;) | 12:28 |
| ZipCPU | Oh ... the memory it saves to is local to itself. You may wish to use your DMA, once the command is complete, to place it where you want it. | 12:29 |
| kc5tja | Sounds like I can just make a DMA controller front-end for it easily enough. | 12:29 |
| ZipCPU | That was sort of the plan. | 12:29 |
| kc5tja | Kind of like how AGNUS chip relates to DENISE in the Amiga. | 12:29 |
| ZipCPU | You can even set the DMA controller to start on a SD card generated interrupt if you'd like. | 12:29 |
| ZipCPU | Not familiar with either AGNUS nor DENISE. | 12:30 |
| kc5tja | These chips were designed by the same guy who made the Atari 2600 and Atari 800 computer. | 12:30 |
| kc5tja | The DENISE chip (a backronym standing for Display ENabler Interrupts, and more I forgot) is the video chip. | 12:31 |
| kc5tja | However it has no ability to fetch video frame buffer data on its own. It depends on the CPU (!!) to feed it data. | 12:31 |
| kc5tja | However, the 68000 is obviously way too slow. :) | 12:31 |
| kc5tja | So the AGNUS chip (Address GeNerator) takes on the responsibility for handling the Amiga's 25 (!!) DMA channels, the majority of which fetch framebuffer data (the playfield registers) and sprite data. | 12:32 |
| kc5tja | AGNUS is also the CRT controller as well; it generates HSYNC and VSYNC signals. | 12:33 |
| kc5tja | BRB; gotta get food before morning videoconference starts. | 12:33 |
| kc5tja | back | 12:52 |
| kc5tja | To whomever is creating computers built on RISC-V or OpenRISC technology. | 13:36 |
| kc5tja | For the love of whatever you consider holy, PLEASE do not make your computers suffer a 5+ minute boot-up delay. >:( | 13:36 |
| --- Log closed Sat Oct 29 00:00:18 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!