| --- Log opened Tue Jul 26 00:00:56 2016 | ||
| kc5tja | I'm primarily bummed that I wasn't even informed of the effort, much less asked, "Hey, I know you're working on a computer design, want to contribute?" Or, "Can we contribute to Kestrel?" | 00:56 |
|---|---|---|
| kc5tja | The existence of the PC doesn't bother me much, actually. | 00:57 |
| kc5tja | ZipCPU: I've resolved to continue with Kestrel-3 development as planned, and will continue to evolve the design towards a general purpose computer platform over time. | 01:15 |
| wallento | kc5tja: I totally feel you. I think you are facing the difference between the open source community spirit and building a commercial venture | 04:51 |
| wallento | I think I said it before, but in my humble opinion the risc-v project differs from what many people expect from "open source" by the lack of an open community | 04:53 |
| mafm | +1 | 05:16 |
| wallento | but anyways, kc5tja, I think your project goals are different and you should continue your venture | 05:20 |
| mafm | not following all of the conversation, but I think that at least things start to get stabilised now that they have sifive around | 05:25 |
| mafm | but lack of communication even when one asks explicitly and when changes are around the corner is a bit surprising / disappointing / demoralising | 05:26 |
| Finde | I worry they're too NIH | 05:31 |
| mafm | yeah, that too | 05:35 |
| mafm | but I think that for kc5tja and other projects outside of the "inner circle", or some people/projects that have out-of-band communications with them (lowrisc and other "big guns", I suppose), it's frustrating | 05:37 |
| mafm | more for the lack of communication than anything else | 05:37 |
| olofk | Can't disagree on the above :) | 05:54 |
| stekern | me neither | 06:13 |
| olofk | ZipCPU|Laptop: Have you considered using FuseSoC for your OpenArty project? Taking a core design and adapt it to different boards is one of the key benefits of using FuseSoC | 06:18 |
| olofk | Also, you might be interested in the stuff that mithro, _florent_ and others are doing with their migen/misoc (or is it litex now? :)) | 06:19 |
| olofk | I think they got a complete Open Source DDR3 controller for Arty. (Correct me if I'm wrong) | 06:19 |
| wallento | cool | 06:25 |
| -!- Dan is now known as ZipCPU | 06:36 | |
| ZipCPU|Laptop | olofk: No, I have not considered FuseSoC. How would you recommend that it would be useful? As 1) a means of collecting various components and fusing them together into OpenArty, or 2) as a means of making OpenArty able to be fused into other designs, or ... ? | 07:20 |
| mithro | Yes, we have a DDR3 core working on the Arty | 07:41 |
| ZipCPU|Laptop | mithro: Is it published anywhere? | 07:43 |
| olofk | ZipCPU|Laptop: I meant option 1. I assume you will use several existing cores in the design | 08:00 |
| _florent_ | ZipCPULaptop: https://github.com/enjoy-digital/arty-soc : 100MHz CPU (can be lm32 or mor1kx) / DDR3@400Mhz (DDR800) | 08:19 |
| kc5tja | ZipCPU|Laptop: wallento: mafm: olofk: https://hackaday.io/project/10035-kestrel-computer-project/log/42599-kestrel-project-continues-as-planned | 10:25 |
| kc5tja | I've decided to keep plugging on. After a good night's rest and some viewpoints not just from here but other media outlets as well, I've come to realize that Kestrel's value isn't so much the computer as such, but the unique niche it fills in terms of price (when it's done), open availability of information, documentation (both in book form as well as github history; and I guess, my existential angst goes into that as well!), and more. | 10:28 |
| ZipCPU | kc5tja: Looks like you took my advice. Well done. Your welcome. ;) | 10:36 |
| ZipCPU | kc5tja:No, seriously, I like your post. You did a decent job of evaluating what else is out there, and what your differences are. | 10:37 |
| ZipCPU | I think a lot could be said for ISA design. The RISC-V documents are informative, and say a lot, but I ... just don't find them definitive. (Or I wouldn't be doing what I'm doing either ...) | 10:38 |
| kc5tja | Thanks. | 10:38 |
| kc5tja | Sometimes, I get so steeped and involved with my project that it's very easy to lose the overall goal you're striving for. | 10:38 |
| kc5tja | You work very hard, engage the community you depend on, they're super supportive, and then wham-o, they come out with something bigger, better, faster, and arguably "more official" than your project. | 10:39 |
| kc5tja | That hit me pretty hard. | 10:39 |
| kc5tja | It'd've been different if they'd asked me, "Hey, wanna help?" Or even just, "Hey, what do you think about this?" You know? | 10:40 |
| ZipCPU | Yeah. I know. | 10:40 |
| kc5tja | Not so concerned over NIH; I suffer some NIH myself. But the secrecy and lack of return engagement is what really burned me. | 10:40 |
| ZipCPU | My own goal is to be the smallest (resourcewise) 32-bit CPU out their. Then Olof showed me PicoRV. | 10:40 |
| kc5tja | If you go with a stack architecture, you can undercut picorv32's resource count. But, nobody likes stack CPUs. :( | 10:41 |
| kc5tja | (My Kestrel-2 CPU is this: https://github.com/KestrelComputer/kestrel/tree/master/cores/S16X4A | 10:42 |
| kc5tja | This particular design isn't very code-dense, but holy cow is it tiny in terms of resource usage. :) Based on an architecture that originally fit in a CPLD back in 1990s. | 10:43 |
| ZipCPU | No, I'm trying to be more generic: thirty two 32-bit registers, two modes: supervisor and user, etc. | 10:43 |
| kc5tja | Yeah, I figured; I'm just saying nothing beats stack CPUs for small size. | 10:43 |
| ZipCPU | Yeah ... but they don't quite program like the more ... normal computers. | 10:43 |
| ZipCPU | I wanted something that felt more ... normal. (Now, just what does that mean?) | 10:44 |
| kc5tja | Going from S16X4 to 64-bit RISC-V was an exercise in managing expectations, especially when I saw how big the new ALU was going to be. :D | 10:44 |
| ZipCPU | Yeah, I remember hearing your figures. Scary. What was that, 3/4 of your FPGA just for the ALU? | 10:44 |
| kc5tja | Which, BTW, I've discovered is mostly due to the barrel shifters. | 10:44 |
| ZipCPU | Really? | 10:44 |
| kc5tja | Approximately 1/2 | 10:45 |
| kc5tja | Yeah. Without the shifters, the ALU drops down to a mroe reasonable 388 LUTs. | 10:45 |
| ZipCPU | As it is, the shifters I have are ... perhaps not what Xilinx was expecting. In my shifts, I shift 33-bit numbers by a 33-bit number of times. The logic needs to detect overflow, etc. | 10:46 |
| ZipCPU | The 33rd bit is the carry out. | 10:46 |
| ZipCPU | How about a hard number ... if its 388 LUTs without the barrel shifters, what was it again with? 1300? | 10:47 |
| ZipCPU | Still, I've got some unique features to what I'm doing. Mostly things that I look forward to sharing at the upcoming ORCONF. | 10:49 |
| ZipCPU | One is a unique interrupt arrangement, the other is a unique arrangement for memory reads/writes that allows the CPU to use pipelining on the bus. | 10:49 |
| kc5tja | I hand-wrote my own shifters, and managed to drop it down to 1102 LUTs w/ the shifters (left and right, w/ and w/out sign-extension). | 10:58 |
| ZipCPU | So ... did your handwritten shifters work better or worse? | 10:59 |
| kc5tja | But, timing analysis says I'm limited to about 35MHz. | 10:59 |
| kc5tja | Better; using Verilog's own synthesized shifters, it came out to 1400 LUTs in the new ALU design, and 1800-ish in the older ALU design. | 10:59 |
| kc5tja | (didn't think to remove the shifters in the old design, alas.) | 11:00 |
| ZipCPU | Do you think that's because the open source toolchain isn't that mature yet? | 11:00 |
| kc5tja | That's the most likely explanation I can think of. Though, TBH, I've seen Xilinx's own toolchain do similar things in the past. | 11:01 |
| kc5tja | My shifter is a six deep set of switches (almost like a perfect shuffle switch), while the synth tools probably instantiates look-up tables and goes from there. | 11:02 |
| kc5tja | 6 deep b/c of 6-bit shift count. :) | 11:02 |
| kc5tja | https://github.com/sam-falvo/polaris/blob/master/rtl/verilog/alu.v | 11:02 |
| ZipCPU | But ... isn't that then being implemented onto lookup tables? I would've thought that the closer your design matched the ultimate platform, the better the synthesizer tool would've worked? | 11:03 |
| kc5tja | Yes, but it's likely an accident that my approach uses fewer LUTs. | 11:04 |
| ZipCPU | I don't believe in Voodoo computers. Just ... when I don't have time to look into things, they start looking like Voodoo. | 11:05 |
| kc5tja | I'm not sure Yosys is smart enough to realize, "Oh, I can sacrifice speed for size in this application and use shuffle switches." | 11:05 |
| kc5tja | I think in this case it is just Yosys trading small size for speed, when I want the reverse. :) | 11:07 |
| kc5tja | I strongly suspect the finished design will be fast enough (as long as total CPU runs faster than 30MHz, so I can safely run it at 25MHz, I'm happy). | 11:08 |
| ZipCPU | kc5tja: Looking at the sam-falvo github repository, ... it looks kind of sparse. Does that contain a fully functional CPU, or just components that will be placed into one ... eventually? | 11:11 |
| ZipCPU | olofk: I'm not sure how I would handle any sort of automated core fusing capability. Of the cores of my own that I've incorporated into the project, my 200MHz clock goal has necessitated that I rewrite many of them. | 11:18 |
| ZipCPU | I've had to simplify the wishbone spec, and keep finding cores that need simplification. I've had to rewrite things as simple as a block RAM memory module and more. | 11:19 |
| ZipCPU | I mean, how generic can you get: a wishbone controlled block RAM module, and yet ... to need to rebuild it to get it up to speed? That was a surprise to me. | 11:19 |
| kc5tja | I'm still writing the verilog for it. | 11:37 |
| kc5tja | I only have instruction fetch, register file, and ALU components done. | 11:38 |
| kc5tja | I still need to implement the instruction decode logic | 11:38 |
| ZipCPU | Okay. I was worried I was missing something. That clarifies things. Thanks. | 11:38 |
| kc5tja | No worries. | 11:38 |
| kc5tja | Sorry; I need to head into work now. Bleh. | 11:40 |
| kc5tja | One of the many reasons this project is taking so long. | 11:40 |
| ZipCPU | Yeah, me too. | 11:40 |
| kc5tja | Back in about an hour-ish. | 11:42 |
| mafm | kc5tja: nice that you don't give up :-) I think that even if there were products, it's a nice personal project so it's good for you to continue, as long as you have fun | 11:58 |
| kc5tja | back | 13:34 |
| kc5tja | mafm: Thanks. It's a fun project, but I also want to share it with others too. I was hoping to build a healthy, even if small, community around Kestrel, both software and hardware makers alike. | 13:35 |
| kc5tja | I was worried though that the recent Sifive offerings would erode the already relatively small amount of interest my project has worked hard to get over the years. :) | 13:36 |
| mafm | kc5tja: I think that more RISC-V hardware can only benefit you. the same that rpi benefitted all of the small sbc boards (and not only), even if it gets the biggest piece of the pie (pun maybe intended :P) | 13:41 |
| mafm | and I think that, indirectly, rpi has also something to do with the more recent interest in hardware, the makers getting involved directly in hardware projects and what not | 13:41 |
| mafm | so honestly, even if that happens, and if the lowrisc project gets some silicon out there and what not, it can only benefit the Kestrel | 13:42 |
| mafm | because then the Kestrel would be part of a big ecosystem, more people have the chance to learn about it, there will be more software available, etc | 13:44 |
| mafm | that's what I think anyway, maybe I am completely wrong :) | 13:44 |
| kc5tja | I think you're right; I've also noticed a lot of hardware hacking picked up after RPi was released. | 15:18 |
| olofk | mafm: Yeah, I think that's a good analogy too | 15:31 |
| olofk | And remember that we have been promised open source computers for many, many years, so just because there was a new press release doesn't mean that we will suddenly have silicon | 15:33 |
| * mafm would love free/open source processors, also with [more] free interconnects, even if they are not very powerful... at least they can be used for micro-servers or similar | 15:51 | |
| mafm | also for desktops, but well, that's more difficult, and one step at a time :P | 15:51 |
| kc5tja | mafm: Well, my Backbone project exports Wishbone onto a 96-pin connector. It's only a 16-bit bus though. | 15:53 |
| kc5tja | Not very useful. | 15:53 |
| kc5tja | But it will suit my immediate needs. | 15:54 |
| mafm | kc5tja: do you plan to sell it commercially and hope to make some money/small business out of it (consultancy, crowdfunding, whatever), or it's purely a hobby personal project? | 15:59 |
| kc5tja | Kestrel as-such is just a hobby project, but I was hoping I could recoup development costs by selling kits on Tindie.com. | 16:06 |
| mafm | kc5tja: !!!!! | 16:07 |
| mafm | I'm buy one! :P | 16:08 |
| kc5tja | I need to get one to work first! :-) | 16:08 |
| mafm | kc5tja: get back to work then :P | 16:11 |
| mafm | ... so your comments about having something for the next workshop (will now be in late Nov, not Jan)..., were to have some prototype of this? | 16:11 |
| kc5tja | Yes. I have a Digilent Nexys-2 FPGA development board, which I used 4 years ago to develop my Kestrel-2. | 16:12 |
| kc5tja | (a 16-bit home-brew computer that was close to being useful, but not quite.) | 16:12 |
| kc5tja | I'm just going to re-use that development board to get everything working first, before tackling the more complex task of building a dedicated piece of hardware. | 16:13 |
| kc5tja | https://hackaday.io/project/11928-backbone-bus is the project page for my backbone bus, which I'll use as the backplane for the actual computer hardware. | 16:14 |
| SMDhome | sorry for interfering into your talk but are the any plans on workshops in EU and not US? | 16:14 |
| kc5tja | RISC-V workshops? I think the topic was raised, and there was general support for it. But I know of no particular plans at this moment. | 16:15 |
| kc5tja | By raised, I mean on the mailing list. Not sure if it was discussed at the latest workshop. | 16:16 |
| SMDhome | thanks | 16:17 |
| kc5tja | I remember being asked to give a Kestrel presentation at EuroForth once; I was thinking about it until I saw how expensive it would be. Heh. | 16:18 |
| kc5tja | Which reminds me, I need to find my passport again. The last time I've seen it was four years ago. | 16:18 |
| * mafm browsing tindie, didn't know about it :D | 16:21 | |
| kc5tja | mafm: My inspiration for the Kestrel kit, btw, is the RC2014 computer. | 16:24 |
| kc5tja | I didn't know about Tindie until I found out about RC2014. :) | 16:24 |
| mafm | heh, nice | 16:31 |
| mafm | kc5tja: v3, or are you working on v4 already? ;-) | 16:34 |
| kc5tja | Can you be specific? | 16:35 |
| kc5tja | Not sure what you mean by V3 or V4? | 16:35 |
| mafm | kestrel-3 or kestrel-4 | 16:35 |
| kc5tja | (sorry; I'm also at work, so I'm dividing my time between this and work stuff) | 16:36 |
| mafm | you should update the application portfolio to include computer vision, big data analytics, and pokemon-go :P | 16:36 |
| kc5tja | Heh | 16:36 |
| kc5tja | The Kestrel-3 design has a long life ahead of it. | 16:36 |
| kc5tja | The 6 MIPS performance is just the entry-level performance. | 16:36 |
| kc5tja | I have ambition to bring this up closer to 50 MIPS or so in the future (somehow; not sure how). | 16:36 |
| mafm | (it was a joke, when seeing the rv128 being mentioned, didn't mean to interrupt important work :) ) | 16:36 |
| kc5tja | Ahh | 16:37 |
| kc5tja | But I do have some ideas for a Kestrel-4, but -4 would be more of a mainframe class computer. | 16:37 |
| kc5tja | (e.g., no built-in video display or audio; those would be relegated to external terminals) | 16:37 |
| mafm | oh, I see, I thought that it was just an april fools joke :) | 16:40 |
| mafm | re your blog entry on sifive, apparently one $99 board can be used for the 64-bit version (it's all a bit confusing) | 16:41 |
| ZipCPU | Heheh ... and here I have ideas for a main-frame class computer that has vector registers, out of order execution, and more--Cray inspired if you will. | 16:41 |
| mafm | SMDhome: somebody asked about it in the workshop, maybe people from Pulp (Bologna, ETH Zurich), or lowRISC (Cambridge) would host | 16:41 |
| mafm | SMDhome: but would be at least in a year, I suppose | 16:42 |
| mafm | kc5tja: the lines above were intended for you, in the case that they're lost in the backlog | 16:42 |
| ssvb | any openrisc toolchain developers here? | 16:45 |
| ssvb | I'm trying to run some tests in qemu-user - https://pixman.miraheze.org/wiki/OpenRISC_Support | 16:46 |
| olofk | SMDhome: There have been many RISC-V-related presentations at orconf for the last two years. I counted 11 RISC-V implementations being presented at last year's orconf :) | 16:49 |
| olofk | SMDhome: Also, I think they have more or less settled on running a pure RISC-V workshop in Cambridge (the UK one) as the first european (ha!) one | 16:50 |
| olofk | ssvb: Interesting. Didn't know about that page | 16:51 |
| olofk | What the hell is up with malloc for example? | 16:51 |
| olofk | What... you're running gentoo on OpenRISC? :) | 16:52 |
| olofk | Oh.. you're using gentoo as the host | 16:52 |
| mafm | olofk: they have to be quick, in the next one either they do Cambridge or they do European, but cannot combine the two :) | 16:52 |
| olofk | mafm: Yep :) | 16:54 |
| olofk | ssvb: Oh, or is that malloc problem specific to qemu perhaps? | 16:55 |
| olofk | Does pixman have a lot of dependencies? I wonder if it would be feasible to run the test suite in or1ksim | 16:57 |
| olofk | or perhaps jor1k | 16:57 |
| ssvb | olofk: yes, I suspect that a lot of problems may be related to qemu | 17:00 |
| olofk | ah ok. So things seem to work with the or1k-elf toolchain? EVen more interesting | 17:00 |
| olofk | ssvb: Great page by the way. It's really useful to have a detailed description of the environment and problems | 17:00 |
| ssvb | no, it is poorly worded, or1k-elf is just a speculation | 17:01 |
| olofk | ah ok | 17:01 |
| mafm | kc5tja: also, for when you return... why do you say that kestrel is not going to be interoperable with sifive? you mean at hardware level? if both implement the same userland ABI, it should be the same for most software (except OS kernel or similar), isn't it? | 17:01 |
| ssvb | pixman has no mandatory external dependencies, it is a low level pixel manipulation library for the X server and cairo | 17:02 |
| olofk | ssvb: If I was to try this on a real target, I would need a boat load of packages first, right? | 17:02 |
| olofk | So I can compile it without either the X or cairo backend? | 17:02 |
| ssvb | X and cairo depend on pixman, and not the other way around | 17:03 |
| olofk | Ah, right | 17:03 |
| olofk | So I should be able to fire up a basic linux system with gcc+make and some other stuff and run the test suite there | 17:04 |
| olofk | Looking at the pixman ebuild on my system, there aren't any dependencies at all, other than those hidden in the inherit packages | 17:04 |
| kc5tja | mafm: The Kestrel-4 page I put up is an April Fool's Joke; however, there are elements to it that are based on reality. I might end up calling it the Kestrel-5 to avoid confusion. | 17:05 |
| olofk | kc5tja: Doing a Larry? :) | 17:05 |
| kc5tja | mafm: Re: ABI -- Right now, my CPU only operates in machine-mode. It does not support supervisor or user modes, in the interest of keeping things as simple as possible, since I'm the only contributor to the project so far. | 17:06 |
| olofk | poke53281: Would it perhaps be easiest to run the pixman test suite with the infrastructure you set up for jor1k? | 17:07 |
| kc5tja | However, once I give the demo at the next workshop, I have several directions I want to take the design: 1) finish the CGIA, so we finally get color graphics at higher resolutions. (2) Add an MMU compatible with at least Sv39 (I'll shoot for Sv48 if I can swing it). At this point, I'll need supervisor and user modes of operation. | 17:07 |
| kc5tja | olofk: What is "a Larry?" | 17:08 |
| olofk | ssvb: Is each test case compiled into a stand-alone elf? Could perhaps be worth trying to just run that in anohter system | 17:08 |
| olofk | kc5tja: You know the one with the Leisure Suit who started out in the land of the lounge lizards and kept looking for love in several wrong places | 17:09 |
| kc5tja | mafm: Thing is, adding support for an MMU will probably take me a year at least, because of the complexity of the state-machine, plus all the testing infrastructure I need to build to test it, which may well include new tool chains. | 17:09 |
| kc5tja | Yeah, but I still don't see the relationship. | 17:09 |
| ssvb | olofk: yes, each test is a static binary (if pixman is configured with --enable-static-testprogs option) | 17:10 |
| olofk | Well, Al Lowe promised to never do a fourth Larry game after the three first, so he skipped directly to Larry V instead | 17:10 |
| kc5tja | Oh, I didn't know that. :) | 17:10 |
| olofk | I see now that it might have been a bit far-fetched :) | 17:10 |
| ssvb | olofk: and it returns 0 if the test is successful and non-zero exit code in the case of an error | 17:10 |
| kc5tja | I only played the one LLL game, so I wasn't aware there wasn't a fourth game. | 17:11 |
| olofk | ssvb: If you can make those available as static files, I could take a look at that to start with | 17:11 |
| olofk | I don't think I have the time right now to set up something more advanced unfortunately | 17:12 |
| mafm | kc5tja: I see... so no MMU means no Linux? (I'm purely a software guy myself, no idea about hardware :D) | 17:12 |
| olofk | kc5tja: I played most of them, being a huge adventure game nerd, but the first one is really the best one | 17:12 |
| olofk | mafm: I guess you could run ucLinux. That's basically why ucLinux was created | 17:13 |
| kc5tja | mafm: Sorry, by non-interoperable, I mean that my memory map will be different, my CPU boots to a different address than theirs upon reset, etc. If you found or ported Linux for the Kestrel, then yes, the user-mode stuff should work. But supervisor-level code, like device drivers, aren't guaranteed to work. | 17:13 |
| kc5tja | mafm: Correct; Linux depends on the MMU to isolate processes from each other. | 17:13 |
| kc5tja | olofk: Yeah, but it's not really intended as an end-user OS. | 17:14 |
| mafm | olofk: it seems that uclinux was upstreamed, mostly (but perhaps needs porting for new arches) | 17:15 |
| kc5tja | Clifford has ported Contiki to picorv32; I might consider porting that to the Kestrel just to play with it. | 17:18 |
| mafm | kc5tja: the MMU cannot be copied from sifive, boom or some librecores design? (I assume that at least boom and librecores would be FOSS-like, and the ones in boom would be compatible with the addressing modes??) | 17:18 |
| kc5tja | mafm: Their designs are tightly integrated, and if I wanted to use them, I'd have to use their entire core. Which is doable, but it won't fit in an iCE40HX-4K or -8K FPGA. | 17:19 |
| kc5tja | OTOH, they're all written in Chisel, which I've *never* gotten working even once, *with* help from Yunsup himself on the mailing list. | 17:20 |
| kc5tja | That's what motivated me to write my own CPU design to begin with. | 17:20 |
| kc5tja | Believe me, I'd MUCH rather focus on Kestrel-specific peripherals than on the CPU right now. RISC-V is a complexity disaster, and yet it's considered a *simple* design. :) | 17:21 |
| poke53281 | olofk: The pixman test suite should run in jor1k | 17:23 |
| mafm | kc5tja: oh my :( | 17:24 |
| mafm | sadly I cannot offer much help, I know zero about hardware, FPGAs, etc. | 17:25 |
| mafm | hoped to get some risc-v core with the FPGA in the last workshop, but got nothing done in the end :( | 17:26 |
| olofk | poke53281: Is it just to fire up jor1k, somehow download the source code and start compiling? | 17:26 |
| ssvb | poke53281: yes, I'm in the middle of trying it | 17:29 |
| poke53281 | It might work. Pixman is a relatively simple packages. But it might take ages. | 17:32 |
| poke53281 | curl "https//cairographics.org/releases/pixman-0.34.0.tar.gz" > pixman.tar.gz | 17:37 |
| poke53281 | tar -xvzf pixman.tar.gz | 17:37 |
| poke53281 | cd pixman-0.34.0 | 17:38 |
| poke53281 | ./configure | 17:38 |
| poke53281 | and now please wait. | 17:38 |
| poke53281 | Hmmm, there is some thing really strange going on with the terminal. | 17:39 |
| poke53281 | and I get unnice filesystem errors. | 17:42 |
| poke53281 | Yeah, this configure script seems to use filesystem features which I haven't implemented. | 17:45 |
| kc5tja | mafm: Hoping to start working on the instruction decode logic either tonight or on Thursday evening, depending on my martial arts schedule. | 17:56 |
| olofk | poke53281: That was a bit unexpected to have a configure script doing funky things with the file system :) | 18:13 |
| poke53281 | well, not really. | 18:17 |
| poke53281 | the configure script do relatively complicated things nowadays. | 18:17 |
| poke53281 | Have to work on jor1k again. More than half year I have done almost nothing. | 18:20 |
| poke53281 | Ok, have to sleep now | 18:21 |
| mafm | kc5tja: if you set-up the tindie project, it would be the one with MMU, capable of running linux, right? | 18:26 |
| kc5tja | Probably not right away, but it will be upgradable after the sale. The "hardware" isn't really a computer, so much as it is an FPGA development board in disguise. | 18:38 |
| kc5tja | So as new bitstreams come out, you can literally upgrade your "hardware" in-place. | 18:38 |
| kc5tja | That's the goal, at least. | 18:38 |
| mafm | kc5tja: good enough :-) what would be the amount of ram, the 32MB that you mentioned, or more? and what about speed, this will also improve with the new bitstreams? | 18:45 |
| kc5tja | That depends on what I can get my hands on. I'd like it to be at least 16MB though. All my system firmware and development tools assume 16MB. | 18:50 |
| mafm | I see | 19:43 |
| mafm | lower than 16MB would be extremely limited, yes | 19:43 |
| ZipCPU | kc5tja: mafm: One of my goals with the ZipCPU is to give it an MMU. However, my approach has been different from many other MMU approaches, it that it isn't nearly as tightly integrated. | 21:22 |
| ZipCPU | There are no CPU registers to control the MMU. Everything having to do with MMU control is external to the CPU--so it just basically becomes a "bump" on the wishbone bus between the CPU and main memory/peripherals. | 21:23 |
| ZipCPU | One bit within the CPU determines whether or not the CPU is in supervisor or user mode. That (already existing) bit can be exported to handle permissions regarding whether or not a user process can or should be able to modify the MMU/TLB settings. | 21:24 |
| ZipCPU | This fits within the minimalist architecture of the ZipCPU, in that it should be easily added or removed as desired. | 21:25 |
| kc5tja | ZipCPU: Sounds reasonable. Most RISC-V CPUs have to export whether or not they're running in machine-mode, due to supervisor mode being able to access machine-mode address space through the page table structure. That way, M-mode-only hardware can issue bus errors or otherwise ignore bus transactions if the CPU's not in M-mode. | 21:41 |
| ZipCPU | Of course it sounds reasonable !!!!!! ;) No, seriously, there are some drawbacks to this approach. | 21:44 |
| ZipCPU | The drawbacks all have to deal with how caching is handled. | 21:44 |
| ZipCPU | Is the cache based upon physical or virtual addresses? As described above, it would be based entirely on virtual addresses. Upon any swap of TLB entries, the entire cache would need to be cleared. | 21:45 |
| ZipCPU | (Swap of context, not TLB entries ... sorry.) | 21:45 |
| ZipCPU | So ... it's a tradeoff. Still, having something separable from the CPU is ... cool--if I can pull it off. | 21:46 |
| ZipCPU | (Pieces of this idea are built, but the full functionality is ... not there.) | 21:46 |
| ZipCPU | Hellwig Geisse, of the ECO32 system, has suggested that the MMU should have two implementations: one supporting the data cache, and another supporting the icache. | 21:48 |
| ZipCPU | I'm ... not convinced either way at this point. | 21:48 |
| kc5tja | You could do what POWER architecture does, and translate via a form of segmentation from virtual address to a "linear" address, which has a whole lot more address bits (basically serving as a process ID). | 22:39 |
| kc5tja | That way, you can alter TLBs w/out having to force a clear of the cache, since the cache is only seeing linear addresses. | 22:41 |
| kc5tja | (in other words, while the cache is still virtually addressed, the probability of it seeing an alias between two processes are basically zero unless the OS wants it to be that way for some reason.) | 22:42 |
| --- Log closed Wed Jul 27 00:00:57 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!