IRC logs for #openrisc Thursday, 2016-06-02

--- Log opened Thu Jun 02 00:00:34 2016
olofkZipCPU: Just read the backlog and saw some interesting discussions. Got some input that might be helpful07:11
olofkRegarding 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 wires07:12
olofkAnd 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 improvements07:12
olofkAnd 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 toolchains07:15
olofkSo maybe there's hope for your arch anyway :)07:15
jeremybennettolofk: 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
jeremybennettAAP is certainly a vehicle for exploring different addressing. Look forward to comments on how it could help.07:47
stekernjeremybennett: tell me about it, I worked 5 years with a DSP that has 16-bit char07:56
jeremybennettstekern: 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
stekernthese ones to be precise07:57
jeremybennettTakes me back to my youth :)07:58
ZipCPU|LaptopWow!  A fascinating conversation.  I'll come back and join in in a few.07:59
ZipCPUjeremybennett: 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
ZipCPUThe problem is/was that those DSP's had COFF support only, and (sigh) I had made the decision to use ELF support.08:15
ZipCPUThere remain bugs that I haven't pushed up stream.08:15
ZipCPUDid I see the briefing on AAP from the videos of the last ORCONF?  It looks familiar ...08:17
ZipCPUHmmm ... looks like I got embecosm confused with ENCOM for a moment (  (ENCOM is fictional)08:32
ZipCPUolof: Thank you for the notes on the DMA.  As I recall, I looked through your DMA a while ago.08:33
ZipCPUIn my case, I tore it apart yesterday in an attempt to learn something about designing logic.08:33
ZipCPUI 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
ZipCPUI think I needed the lesson.08:34
ZipCPUolofk: 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
ZipCPUThis fits nicely into a 6-LUT.08:37
ZipCPUIt 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
olofkkaaliakahn: I just noticed that you're going to the next RISC-V workshop. Looking forward to see you there08: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
olofkZipCPU: 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 there08:41
ZipCPUSo ... you haven't done the research on the "optimal" addresses?  I figured someone had ...08:41
olofkZipCPU: That sounds nice. Haven't been to a country fair, but I visited this one a few years ago :)
olofkZipCPU: 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 set08:43
olofkgtg. My daugter is dragging me away :)08:43
ZipCPUAnd 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
ZipCPUolofk: 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
olofkOh, looks like I need to buy those, and get into the car :)09:40
olofkAnd yeah... those country fairs are huge. Millions of people visit them ;)09:41
kaaliakahnolofk: Sounds like a plan.10:05
kaaliakahnwhere do you see Beaglebone black fit in the SoC spectrum as I think it is completely opensource SoC board?10:06
olofkIs anything about Beaglebone Open Souce?10:06
kaaliakahnI am trying to write a tutorial where I want to introduce beginners to microcontrollers, ASIC, FPGA, SoC?10:07
olofkI don't think the schematics are open source, and the ARM SoC most definitely isn't10:07
kaaliakahnin SoC there are a lot of choices like openRISC, RISC-V, lowRISC, Plasma, Amber etc10:07
kaaliakahnHas anyone compared these?10:08
olofkThere have been some comparasions, but no recent ones10:09
olofkAnd lowRISC uses RISC-V. Not sure if anyone is using Plasma or Amber10:09
kaaliakahnI assume you have heard about Plasma core and Amber10:09
olofkThis one compares four soft cores10:09
kaaliakahnAmber has been recently updated10:10
kaaliakahnlet me see the link10:10
olofkAh ok. So Amber is an ARM clone. I know that ARM has been quite hard at killing off Open Source clones of their cores10:11
olofkand Plasma is a MIPS1 clone from what I can see10:11
kaaliakahnyes absolutely and Plasma is in Vhdl :(10:12
SMDwrk and his other projects10:13
olofkI think the most popular Open Source soft cores would be OpenRISC (mor1kx+or1200), Leon (which is SPARC), the different RISC-V cores and lm3210:13
olofkIn no particular order10:13
ZipCPUAnyone 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
olofkZipCPU: Don't think I've heard of that10:15
ZipCPUIf 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
ZipCPUHere it is:,up_core_list10:17
ZipCPUIt's a must read for anyone interested in comparing one core against another.10:17
kaaliakahnZipCPU: Thanks. Very useful10:20
ZipCPUI've been over his charts multiple times, and even now continue to go over them.10:20
olofkJesus fucking christ. That's a big list10:58
ZipCPUolofk: Watch your language!  (Please?)10:58
olofkSorry about that11:00
ZipCPUYes, 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
ZipCPUFor 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
olofkYeah, I searched for a few items, but as you say, it's hard to make your own comparasions11:01
ZipCPUWell, 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
ZipCPUI 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
jeremybennettZipCPU: 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
jeremybennettWe found the biggest problems getting newlib to run.11:05
ZipCPUI haven't gotten newlib to run yet.  int16, uint16, int8, and uint8's have been a bit of a problem there.11:05
ZipCPUStill ... 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
ZipCPUAddresses are supposed to be in bytes, while sizes within the file are in octets.  An address plus a size mixes units.11:08
jeremybennettZipCPU: Good luck with that. We've never tried to force the byte versus octet stuff.11:48
ZipCPUjeremybennett: Thanks.  As I've already stated, the whole process is and has been ... an adventure.  ;)11:49
jeremybennettOn 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
ZipCPUIn my case, str[0] and str[1] point to two separate 32-bit words, hence &(str[1])-&(str[0]) = 1.11:50
ZipCPUI 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
ZipCPUMy 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
olofkJust released a new blog post
--- Log closed Fri Jun 03 00:00:35 2016

Generated by 2.15.2 by Marius Gedminas - find it at!