| --- Log opened Thu Oct 23 00:00:49 2014 | ||
| -!- Netsplit *.net <-> *.split quits: blueCmd, tariq786, rokka | 07:06 | |
| -!- Netsplit over, joins: tariq786 | 07:11 | |
| olofk | Hmm... looks like I will need to add an extra FIFO between the memory controller and cached arbiter | 08:59 |
|---|---|---|
| juliusb | maybe I'm behind the times but just found some cool stuff | 09:59 |
| juliusb | http://www.edaplayground.com/ | 09:59 |
| juliusb | http://potentialventures.github.io/cocotb/ | 09:59 |
| juliusb | (actually going to OSHUG tonight in London to see a presentation on cocotb) | 09:59 |
| olofk | I'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 tools | 10:16 |
| olofk | I might have come across cocotb at some point too. If I have understood things correctly, it's similar to what sb0 does with migen | 10:17 |
| sb0 | migen is much more synthesis-oriented. verification is boring ;) | 10:22 |
| sb0 | aaaand... verification doesn't spot the usual problems (bloat & slowness) that plague most fpga designs | 10:23 |
| olofk | sb0: But you have some Python-VPI-embedded-bridge-thing-a-mob too, right? | 10:23 |
| sb0 | yes | 10:23 |
| olofk | sb0: We should play gate golf some time. See who can implement a task with the least resources :) | 10:23 |
| olofk | I take pride in my resource usage | 10:24 |
| sb0 | which I should refactor, now that python has a "yield from" statement | 10:24 |
| sb0 | you can save more than thousand luts by switching to lm32 :p | 10:25 |
| sb0 | *a thousand | 10:25 |
| olofk | I can save a thousand years of software porting by staying with OpenRISC | 10:37 |
| olofk | ...more or less... but who's counting | 10:38 |
| sb0 | yes, it's very frustrating that so many people, myself included, invest in an inferior architecture | 10:38 |
| olofk | Yeah. We should have gone with x86 | 10:38 |
| olofk | They have excellent sw support | 10:38 |
| olofk | and a clean instruction set | 10:39 |
| sb0 | yes, and I propose we implement ACPI into the SoC too | 10:42 |
| juliusb | sb0: 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 |
| juliusb | FPGA, in a lot of places, is used to prove and verify the design | 12:21 |
| juliusb | that's what it's useful for. OK if you're making product with FPGA, worry, but otherwise, don't. | 12:22 |
| juliusb | and, 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 |
| sb0 | juliusb, my entire artiq development environment is usable on a lx9 papilio pro board and a netbook. and I like it that way. | 12:23 |
| juliusb | that's not helpful | 12:24 |
| juliusb | you know what I'm saying. I think the obsession isn't constructive, and other things are way more helpful | 12:24 |
| juliusb | such 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 core | 12:25 |
| juliusb | s/it of work/bit of work/ | 12:25 |
| sb0 | and yes, fpgas are painfully slow already. please don't make it even worse. | 12:28 |
| juliusb | big != slow | 12:28 |
| sb0 | well, density is a problem too, though I will admit they have gotten better | 12:33 |
| sb0 | though some people, like the risc-v guys, tend to make it a problem again | 12:34 |
| juliusb | So 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 |
| juliusb | the architecture also already encourages overhead - the "80% full to PAR" rule of thumb | 12:35 |
| juliusb | thus, who cares about a little bit of bloat | 12:36 |
| juliusb | the 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 others | 12:36 |
| juliusb | you're talking about the rocket core? I think they made their point that it's an ASIC-specific implementation. | 12:37 |
| juliusb | and, 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 implementations | 12:38 |
| sb0 | I know about this and that's why mor1kx is tolerable in my design | 12:40 |
| sb0 | but it takes most of the fpga for itself on the smallest target (lx9) | 12:41 |
| juliusb | anyway, 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 |
| sb0 | another thing I dislike about or1k (besides the bloat) is the ISA and ABI are a bit messy | 12:42 |
| juliusb | do tell | 12:43 |
| sb0 | lm32 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 lm32 | 12:48 |
| sb0 | so I'm not convinced | 12:49 |
| sb0 | (2x lm32 area-wise) | 12:51 |
| juliusb | you're talking about rocket, right? | 12:56 |
| juliusb | can you distinguish between an implementation and a document? | 12:56 |
| juliusb | becuase I'm not sure you can from what you're saying | 12:56 |
| sb0 | rocket and another implementation from scratch that someone posted on the ML | 13:02 |
| juliusb | oh which one? | 13:06 |
| sb0 | anyway. 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 fact | 13:06 |
| juliusb | ya, 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 |
| stekern | juliusb: 3) in your list is when you want one pcb for several products, and an fpga cut it. i.e. you want the reconfigurability | 15:23 |
| --- Log closed Fri Oct 24 00:00:51 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!