IRC logs for #openrisc Thursday, 2014-10-23

--- Log opened Thu Oct 23 00:00:49 2014
-!- Netsplit *.net <-> *.split quits: blueCmd, tariq786, rokka07:06
-!- Netsplit over, joins: tariq78607:11
olofkHmm... looks like I will need to add an extra FIFO between the memory controller and cached arbiter08:59
juliusbmaybe I'm behind the times but just found some cool stuff09:59
juliusb(actually going to OSHUG tonight in London to see a presentation on cocotb)09:59
olofkI've seen edaplayground before. Never really got to use it, but now when I think of it, it could be useful for testing shady language constructs in different tools10:16
olofkI might have come across cocotb at some point too. If I have understood things correctly, it's similar to what sb0 does with migen10:17
sb0migen is much more synthesis-oriented. verification is boring ;)10:22
sb0aaaand... verification doesn't spot the usual problems (bloat & slowness) that plague most fpga designs10:23
olofksb0: But you have some Python-VPI-embedded-bridge-thing-a-mob too, right?10:23
olofksb0: We should play gate golf some time. See who can implement a task with the least resources :)10:23
olofkI take pride in my resource usage10:24
sb0which I should refactor, now that python has a "yield from" statement10:24
sb0you can save more than thousand luts by switching to lm32 :p10:25
sb0*a thousand10:25
olofkI can save a thousand years of software porting by staying with OpenRISC10:37
olofk...more or less... but who's counting10:38
sb0yes, it's very frustrating that so many people, myself included, invest in an inferior architecture10:38
olofkYeah. We should have gone with x8610:38
olofkThey have excellent sw support10:38
olofkand a clean instruction set10:39
sb0yes, and I propose we implement ACPI into the SoC too10:42
juliusbsb0: what I don't get is why worry so much about "bloat" and "inefficiency" when you're implementing your design on an inherently bloated and inefficient thing in the first place; an FPGA. On every performance metric it loses out to ASIC. I think there's certainly an art to tuning for FPGA, but why worry about even 100% "bloat" when FPGAs are getting bigger and cheaper with every generation?12:21
juliusbFPGA, in a lot of places, is used to prove and verify the design12:21
juliusbthat's what it's useful for. OK if you're making product with FPGA, worry, but otherwise, don't.12:22
juliusband, also that "verification is boring" thing is hurting open source RTL development I think. The *first* thing people say when open source RTL is proposed isn't "omg how many gates is it", it's "how do I know it works, prove it to me".12:22
sb0juliusb, my entire artiq development environment is usable on a lx9 papilio pro board and a netbook. and I like it that way.12:23
juliusbthat's not helpful12:24
juliusbyou know what I'm saying. I think the obsession isn't constructive, and other things are way more helpful12:24
juliusbsuch as the verification stuff. I think that's a very cool it of work, so too migen, that's the sort of stuff which I think people are interested in, not how much 100s of technology cells no one cares about are shaved off a commodity core12:25
juliusbs/it of work/bit of work/12:25
sb0and yes, fpgas are painfully slow already. please don't make it even worse.12:28
juliusbbig != slow12:28
sb0well, density is a problem too, though I will admit they have gotten better12:33
sb0though some people, like the risc-v guys, tend to make it a problem again12:34
juliusbSo if you're using an FPGA in a product it's either because 1) you need it quickly 2) you get all you need at the cost point 3) not necessarily 1 or 2 but can't justify ASIC development. In either case, you're easily going to be able to afford to price in even 20% of overhead of LUTs for your design, and you're going to want to do that becuase you're not going to want to go back and sort out buying a different part when you figure out that your design doesn't fit.12:35
juliusbthe architecture also already encourages overhead - the "80% full to PAR" rule of thumb12:35
juliusbthus, who cares about a little bit of bloat12:36
juliusbthe case may be that you like a challenge, fitting things into small spaces, OK, that's fine, but not a reason to impose those design constraints on others12:36
juliusbyou're talking about the rocket core? I think they made their point that it's an ASIC-specific implementation.12:37
juliusband, if anything, the risc-v architecture has been designed to minimise muxing in the smallest possible implementation (spec makes that clear), so not sure you could even level the argument that they designed a poor ISA for low-area implementations12:38
sb0I know about this and that's why mor1kx is tolerable in my design12:40
sb0but it takes most of the fpga for itself on the smallest target (lx9)12:41
juliusbanyway, I'm keen to find out of it the overhead of calls into the Python interpreter in cocotb will make the "faster" simulators slower.12:41
sb0another thing I dislike about or1k (besides the bloat) is the ISA and ABI are a bit messy12:42
juliusbdo tell12:43
sb0lm32 definitely improves on that, maybe risc-v does too - but what I mostly see about risc-v is >10x lm32, slower, PAR failures, and a FSM-based implementation with a CPI of 3 which is 2x lm3212:48
sb0so I'm not convinced12:49
sb0(2x lm32 area-wise)12:51
juliusbyou're talking about rocket, right?12:56
juliusbcan you distinguish between an implementation and a document?12:56
juliusbbecuase I'm not sure you can from what you're saying12:56
sb0rocket and another implementation from scratch that someone posted on the ML13:02
juliusboh which one?13:06
sb0anyway. I'm just very, very frustrated that after 10+ years of opencores & co no open softcore has at the same time a good FPGA implementation, good ISA, and good software support - and that risc-v does not change that fact13:06
juliusbya, who knows how the risc-v will go, but I would argue the or1k stuff is technically the goods for what it is (an ISA from a 1980s textbook, implementations and tools developed and maintained by non-commerical contributors)14:16
stekernjuliusb: 3) in your list is when you want one pcb for several products, and an fpga cut it. i.e. you want the reconfigurability15:23
--- Log closed Fri Oct 24 00:00:51 2014

Generated by 2.15.2 by Marius Gedminas - find it at!