| --- Log opened Thu Jun 02 00:00:34 2016 | ||
| olofk | ZipCPU: Just read the backlog and saw some interesting discussions. Got some input that might be helpful | 07:11 |
|---|---|---|
| olofk | Regarding slave addresses, I have created a python script that creates a wishbone interconnect from a simple configuration file. It takes care of all the boring parts of just routing wires | 07:12 |
| olofk | And I have also created a DMA component if you want to take a look at it. It has a simple bare-metal driver, and shorne was going to look into that to make some improvements | 07:12 |
| olofk | And regarding your unorthodox choice of char size, our friends at embecosm ( jeremybennett , simoncoo1 et. al) have created a CPU arch called AAP, which is designed to have odd char, int pointer sizes etc. to shake out bugs from the toolchains | 07:15 |
| olofk | So maybe there's hope for your arch anyway :) | 07:15 |
| jeremybennett | olofk: ZipCPU: Only just picked up this conversation. We're just working on a DSP with 16-bit data and code spaces. You'd be amazed at quite how much breaks if you try to make char 16-bits long! | 07:46 |
| jeremybennett | (which is allowed by the C standard) | 07:47 |
| jeremybennett | AAP is certainly a vehicle for exploring different addressing. Look forward to comments on how it could help. | 07:47 |
| stekern | jeremybennett: tell me about it, I worked 5 years with a DSP that has 16-bit char | 07:56 |
| stekern | http://www.ti.com/lit/ds/symlink/tms320f2812.pdf | 07:57 |
| jeremybennett | stekern: I think it's quite usual for DSP's. It's just that no one has done much work with LLVM and DSPs (just hexagon) | 07:57 |
| stekern | these ones to be precise | 07:57 |
| jeremybennett | Takes me back to my youth :) | 07:58 |
| ZipCPU|Laptop | Wow! A fascinating conversation. I'll come back and join in in a few. | 07:59 |
| ZipCPU | jeremybennett: The binutils team held up the TI DSP's as examples of how to get binutils running for architectures with other-than 8-bit byte support. | 08:15 |
| ZipCPU | The problem is/was that those DSP's had COFF support only, and (sigh) I had made the decision to use ELF support. | 08:15 |
| ZipCPU | There remain bugs that I haven't pushed up stream. | 08:15 |
| ZipCPU | Did I see the briefing on AAP from the videos of the last ORCONF? It looks familiar ... | 08:17 |
| ZipCPU | Hmmm ... looks like I got embecosm confused with ENCOM for a moment (http://tron.wikia.com/wiki/ENCOM). (ENCOM is fictional) | 08:32 |
| ZipCPU | olof: Thank you for the notes on the DMA. As I recall, I looked through your DMA a while ago. | 08:33 |
| ZipCPU | In my case, I tore it apart yesterday in an attempt to learn something about designing logic. | 08:33 |
| ZipCPU | I wanted the entire state machine to depend upon single wire/register inputs, not on 32-bit comparisons, I wanted an explicit state machine, and ... it turned into a real exercise in building logic. | 08:33 |
| ZipCPU | I think I needed the lesson. | 08:34 |
| ZipCPU | olofk: In hind sight, the real question I have about slave addresses has to do with where they should be placed. I think I've noticed within OpenRISC that the top six bits are often used to determine which slave. | 08:37 |
| ZipCPU | This fits nicely into a 6-LUT. | 08:37 |
| ZipCPU | It also fits nicely into an MMU structure whereby one process may be granted access to a certain portion of the memory space, such as a particular device, and another process may not be granted such access. The MMU taking care of the security. | 08:38 |
| olofk | kaaliakahn: I just noticed that you're going to the next RISC-V workshop. Looking forward to see you there | 08:39 |
| ZipCPU | (July 12-16 just happens to be the county fair week here ... provided the geese and turkeys are still presentable, I think I'll find myself busy) | 08:40 |
| olofk | ZipCPU: There are probably serious research on the topic of where to instantiate slave peripheral cores, but for OpenRISC I think that someone just started at one point and it continued from there | 08:41 |
| ZipCPU | So ... you haven't done the research on the "optimal" addresses? I figured someone had ... | 08:41 |
| olofk | ZipCPU: That sounds nice. Haven't been to a country fair, but I visited this one a few years ago :) http://pccocwv.com/roadkill | 08:42 |
| olofk | ZipCPU: There is actually one thing with the OpenRISC address map. We place all peripherals at above 0x80000000. That way it's easy to tell the CPU to never cache data if the address MSB is set | 08:43 |
| olofk | gtg. My daugter is dragging me away :) | 08:43 |
| ZipCPU | And here I thought determining peripheral vs memory, and what got cached, was a function of how the MMU was setup. I was holding off on the data cache, therefore, until I had the MMU up and running. | 08:44 |
| ZipCPU | olofk: Google search "Roadkill helper" and look at the images. Enjoy the result. ;P (Also, I've been to state fairs and county fairs, but never a country fair ...) | 08:48 |
| olofk | Oh, looks like I need to buy those, and get into the car :) | 09:40 |
| olofk | And yeah... those country fairs are huge. Millions of people visit them ;) | 09:41 |
| kaaliakahn | olofk: Sounds like a plan. | 10:05 |
| kaaliakahn | where do you see Beaglebone black fit in the SoC spectrum as I think it is completely opensource SoC board? | 10:06 |
| olofk | Is anything about Beaglebone Open Souce? | 10:06 |
| kaaliakahn | I am trying to write a tutorial where I want to introduce beginners to microcontrollers, ASIC, FPGA, SoC? | 10:07 |
| olofk | I don't think the schematics are open source, and the ARM SoC most definitely isn't | 10:07 |
| kaaliakahn | ok | 10:07 |
| kaaliakahn | in SoC there are a lot of choices like openRISC, RISC-V, lowRISC, Plasma, Amber etc | 10:07 |
| kaaliakahn | Has anyone compared these? | 10:08 |
| olofk | There have been some comparasions, but no recent ones | 10:09 |
| olofk | And lowRISC uses RISC-V. Not sure if anyone is using Plasma or Amber | 10:09 |
| kaaliakahn | I assume you have heard about Plasma core and Amber | 10:09 |
| olofk | This one compares four soft cores | 10:09 |
| olofk | http://www.eetimes.com/author.asp?section_id=14&doc_id=1286116 | 10:09 |
| kaaliakahn | http://opencores.org/project,plasma | 10:10 |
| kaaliakahn | Amber has been recently updated | 10:10 |
| kaaliakahn | http://opencores.org/project,amber | 10:10 |
| kaaliakahn | let me see the link | 10:10 |
| olofk | Ah ok. So Amber is an ARM clone. I know that ARM has been quite hard at killing off Open Source clones of their cores | 10:11 |
| olofk | and Plasma is a MIPS1 clone from what I can see | 10:11 |
| kaaliakahn | yes absolutely and Plasma is in Vhdl :( | 10:12 |
| SMDwrk | https://github.com/alfikpl/ao486 and his other projects | 10:13 |
| olofk | I think the most popular Open Source soft cores would be OpenRISC (mor1kx+or1200), Leon (which is SPARC), the different RISC-V cores and lm32 | 10:13 |
| olofk | In no particular order | 10:13 |
| ZipCPU | Anyone remember what the name was for Jim Brakefields project cataloging softcores? It needs to be a part of this discussion, and I can't seem to find it on opencores now. (I just don't remember the name.) | 10:14 |
| olofk | ZipCPU: Don't think I've heard of that | 10:15 |
| ZipCPU | If you haven't, you need to. I'll keep looking for it--I know its on open cores. He compares all the cores he had available to him at the time against each other, providing side by side performance metrics for each. | 10:16 |
| ZipCPU | Here it is: opencores.org/project,up_core_list | 10:17 |
| ZipCPU | It's a must read for anyone interested in comparing one core against another. | 10:17 |
| kaaliakahn | ZipCPU: Thanks. Very useful | 10:20 |
| ZipCPU | I've been over his charts multiple times, and even now continue to go over them. | 10:20 |
| olofk | Jesus fucking christ. That's a big list | 10:58 |
| ZipCPU | olofk: Watch your language! (Please?) | 10:58 |
| olofk | Sorry about that | 11:00 |
| ZipCPU | Yes, though, it is a big list. I wish he had published the spreadsheets he drew the list from--it might've made sorting and working with the list easier. | 11:00 |
| ZipCPU | For example, I might wish to compare all 32'bit CPU's against each other, and get rid of the 8'bit and 16'bit CPU's. | 11:01 |
| olofk | Yeah, I searched for a few items, but as you say, it's hard to make your own comparasions | 11:01 |
| ZipCPU | Well, then the other problem is that several CPU's have multiple lines. For example, what is their LUT usage on different FPGA's, or with different configurations. | 11:02 |
| ZipCPU | I know that the ZipCPU has different LUT usage depending upon: 1) whether you are pipelined or not, 2) which pre-fetch and instruction cache you use, 3) whether you include the hardware divide unit, 4) whether you want the CPU peripherals or just the barebones CPU, etc. | 11:03 |
| jeremybennett | ZipCPU: I don't think binutils was where we found the biggest problems. ELF should make that easier, since it is defined to be a (8-bit) byte format, so you have to convert a 16-bit representation anyway. | 11:05 |
| jeremybennett | We found the biggest problems getting newlib to run. | 11:05 |
| ZipCPU | I haven't gotten newlib to run yet. int16, uint16, int8, and uint8's have been a bit of a problem there. | 11:05 |
| ZipCPU | Still ... the ELF format has two units: octets (8-bits) and bytes (system-dependent, 32-bits on ZipCPU). It supports both, but the binutils code doesn't handle all the conversions properly. | 11:07 |
| ZipCPU | Addresses are supposed to be in bytes, while sizes within the file are in octets. An address plus a size mixes units. | 11:08 |
| jeremybennett | ZipCPU: Good luck with that. We've never tried to force the byte versus octet stuff. | 11:48 |
| ZipCPU | jeremybennett: Thanks. As I've already stated, the whole process is and has been ... an adventure. ;) | 11:49 |
| jeremybennett | On the whole DSP's don't care about characters, so we can go with 8-bit packing. It still makes for interesting behavior. What is the difference between &(str[0]) and &(str[1]) if you pack two chars to a 16-bit word. | 11:49 |
| ZipCPU | In my case, str[0] and str[1] point to two separate 32-bit words, hence &(str[1])-&(str[0]) = 1. | 11:50 |
| ZipCPU | I thought that by doing such I could boast of 16GB of addressable memory, even though the minimum addressable unit would be 32-bits. | 11:51 |
| ZipCPU | My other reason for doing so was to simplify both the bus and the instruction set, by allowing only one word size. Endianness should no longer matter. | 11:55 |
| olofk | Just released a new blog post olofkindgren.blogspot.com/2016/06/fusesoc-and-your-custom-workflow.html | 17:02 |
| --- Log closed Fri Jun 03 00:00:35 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!