tgs3 | does normal linux e.g. debian stable work on that example openrisc board? afair it has 32 mb ram? | 11:06 |
---|---|---|
tgs3 | I still want to "get a openrisc copmputer linke thing" and run debian on it | 11:08 |
tgs3 | prefferably 100% open one (e.g. no closed-hardware FPGA) but I guess there isnt any open fpga | 11:08 |
jeremybennett | tgs3: There should be no reason why it wouldn't work. The question will be if you have enough RAM and enough compute cycles. Typically OpenRISC runs at < 100MHz. | 11:10 |
tgs3 | jeremybennett: non-X terminal so yeah. anyone tried to run that? | 11:10 |
tgs3 | I would like to try as a hobby, but I don't know how to get the hardware | 11:10 |
tgs3 | also, is that correct still we don't have 100% open source computer on openrisc, because all existing are on FPGA and all (compatible) FPGA are closed hardware? | 11:11 |
jeremybennett | You can buy a FPGA board from ORSoC for around 150 Euros I think. Not sure how much RAM that has. You can apparently run a Linux kernel on a DE0-nano ($80), but certainly not Debian. | 11:12 |
jeremybennett | No one has come up with an open source FPGA fabrication process. Currently it all becomes closed source at some point when you get close to silicon. At $1Bn or more for a modern fab, It's hard to persuade people to open source their processes! | 11:13 |
tgs3 | ultimatelly I would like to have something like a very slow computer-desktop, but that would be 100% open from hardware specs of each and every chip, through firmware to system | 11:13 |
tgs3 | jeremybennett: I would kickstarter it | 11:13 |
jeremybennett | It's an idea - an open source fab on KickStarter. That would certainly break a few records. | 11:14 |
tgs3 | jeremybennett: there is no other way then either FPGA or ASIC? | 11:14 |
tgs3 | like... some circuit that would not be small and nice like ASIC but would be implementation of openrisc | 11:14 |
jeremybennett | Well you can build a computer from discrete components. But they probably won't tell you how they are made, so even that is not open source at some level. | 11:15 |
tgs3 | why asic must be to expensive? | 11:15 |
jeremybennett | About the only thing you can make that is purely open source is a crystal set, and then only if you use a lump of coal as the detector. | 11:15 |
tgs3 | maybe if it would be some "crappy" asic, e.g. 1 meter × 1 meter board or some other acient process | 11:15 |
jeremybennett | tgs3: Well it is quite hard building structures that are less than 100 atoms across, with gates that must be 4 atoms thick (5 atoms is too thick, 3 atoms and you lose everything to quantum tunnelling). | 11:16 |
jeremybennett | Then doing it 10^9 times over without a mistake. | 11:16 |
tgs3 | how about using acient kind of asic like from first macintosh | 11:16 |
tgs3 | how many transistors are needed for openrisc anyway? | 11:17 |
jeremybennett | You can get ASIC done quite cheaply on old processes - a few tens of thousands of dollars. | 11:17 |
tgs3 | per one asic? | 11:17 |
jeremybennett | I'm not sure about transistors. IIRC the OpenRISC chip Flextronics made 10 years ago was around 150k gates with around 15 memory blocks. So depending on your process that is 600k to 900k transistors + memories. | 11:18 |
LoneTech | good morning | 11:19 |
jeremybennett | that's a prices for an engineering sample run, so you get 10's or possibly 100's of chips. It's not something I actually do, so I don't know the details. | 11:19 |
jeremybennett | LoneTech: Good morning. You probably know more about low cost ASIC runs | 11:19 |
LoneTech | not terribly much, but I did look a bit once | 11:19 |
LoneTech | iirc, it's possible to have a mostly open source toolchain using alliance | 11:20 |
* tgs3 doesnt get why litography must be *so* expensive | 11:21 | |
LoneTech | if you want it reasonably cheaply, I expect structured is the way to go | 11:23 |
tgs3 | structured? | 11:23 |
tgs3 | ok look guys :) | 11:24 |
tgs3 | http://www.pagetable.com/?p=39 | 11:24 |
LoneTech | like altera hardcopy, for instance - they have the same routing options as the fpgas, so they just translate your configuration | 11:24 |
tgs3 | we are able now to take a MOC 6502 from original Apple I | 11:24 |
tgs3 | scan it under microscope(!) | 11:25 |
tgs3 | and emulate it 100% from the scan of the phisical cpu piece | 11:25 |
tgs3 | that is totally awesome | 11:25 |
LoneTech | yep | 11:25 |
tgs3 | I would expect it would be possible to create today MOC 6502 CPU 100% open source (ignoring the imaginary slave property 'rights' on the 6502 design) | 11:25 |
tgs3 | right? | 11:26 |
tgs3 | if it was costing probably... millions(?) to start line and <thousand per piece 30 years ago | 11:26 |
tgs3 | wouldn't it be < 0.5 milion to start line and < 100 usd per piece today | 11:27 |
tgs3 | if yes, then is openRISC so much more complicated that it would be not possible to achieve similar prices, e.g. at cost of running speed or cpu size | 11:28 |
tgs3 | * "is an 8 µm[48] process technology chip with 3510 transistors" .. so x200 more work for OpenRISC.. this does NOT even include the memory chips? | 11:29 |
LoneTech | are you comparing the openrisc to the 6502? | 11:30 |
tgs3 | well, it's a starting point :) | 11:30 |
LoneTech | sure. just be aware that they're looking at the 6502 because it is an extreme example | 11:31 |
tgs3 | I would like if it would be possible to complete understand, own, create a more modern cpu too | 11:31 |
LoneTech | also, code size or logic complexity is nearly a non-issue for current asic production; the connection pads are so much larger | 11:31 |
tgs3 | maybe we should do it in another way: | 11:31 |
LoneTech | it is possible | 11:31 |
tgs3 | make a 100% open FPGA moduel, even small | 11:31 |
tgs3 | and then take 10x10 of them if needed and make openrisc and other opencores stuff on it | 11:32 |
tgs3 | and 100% open memory bank | 11:32 |
tgs3 | if this 2 building blocks can be used to create any open-coures designs (not just openrisc) maybe there would be enough backers to invest into such ASIC as kickstarter project? | 11:33 |
LoneTech | I dearly hope so, but it's a very long road | 11:33 |
LoneTech | you probably want a look at http://www.vlsitechnology.org/html/lib_densities.html ... I believe it's possible to order asics from TSMC by using their library for a reasonable cost | 11:36 |
LoneTech | I've just done a workaround in openOCD which saddens me, because after figuring out how to make it work I don't know why it does. | 11:39 |
_franck_ | LoneTech: :) | 11:45 |
LoneTech | the issue was, with gdb+openocd+virtualjtag+adv_debug_sys (I dearly hope some of that is irrelevant), when halting at a software breakpoint, continuing does not execute the instruction that was overwritten with l.trap. If I make or1k_debug_entry set NPC as dirty, however, it does. | 11:47 |
LoneTech | there's something similar done in or_debug_proxy where it sets NPC to PPC if it finds it hit a breakpoint | 11:49 |
LoneTech | so it looks like adv_debug_sys and dbg_interface (mohor) behave differently on the breakpoint. In addition, openOCD doesn't recognize halt reasons. | 11:50 |
LoneTech | at the point where it halted, however, NPC points to the breakpoint (and in my test case, PPC to a delay slot elsewhere) | 11:51 |
_franck_ | cant' remember the details but we had a hard time making this works | 11:58 |
_franck_ | http://bugzilla.opencores.org/show_bug.cgi?id=104 | 11:58 |
LoneTech | tgs3: I'd appreciate if you find out where http://web.archive.org/web/20100329153111/http://www-asim.lip6.fr/recherche/alliance/doc/design-flow/flow.html went | 11:58 |
_franck_ | LoneTech: did you update your openocd repo (from the github one) ? | 11:59 |
LoneTech | seems so | 12:00 |
LoneTech | your patch is in RTL, however. I'll have a look at it. | 12:01 |
LoneTech | ah. this suggests that debug unit stops do not flush the pipeline like software handled exceptions do, which does explain the behaviour | 12:03 |
_franck_ | yes that's it | 12:03 |
LoneTech | but writing npc works like a jump and causes a reload | 12:04 |
LoneTech | I'm not sure I like this rtl patch | 12:06 |
LoneTech | not that I like mine either :( | 12:09 |
_franck_ | well I'm using this path for a long time now with the openocd version in github and it works like a charm | 12:10 |
_franck_ | but it's may be not that good | 12:11 |
LoneTech | oh, it works | 12:11 |
LoneTech | but it's even more complexity to the genpc and pipeline logic for a special case that already has to be handled by the debugger | 12:11 |
_franck_ | I'll be happy to test an openocd patch ;) | 12:19 |
LoneTech | for instance, I am rather curious what it does to the instruction bus should the debug unit halt the processor for any other reason while the software is trying to jump. | 12:19 |
LoneTech | it's an ugly test version, but here you go: http://donkey.vernier.se/~yann/openrisc-public/openocd-breakpoint-workaround.diff | 12:21 |
_franck_ | ok, I'll test this tonight | 12:33 |
tgs3 | LoneTech: hm me? | 12:53 |
tgs3 | ok | 12:54 |
LoneTech | oh, and mosis.com seems to be the place to actually order asics. looks like that means Tanner is the library to use, too. | 12:58 |
tgs3 | what do you think about mine idea as outsider, | 13:00 |
tgs3 | to focus on creating 100% open source universal FPGA module | 13:00 |
tgs3 | and if we do this, then we can have 100% open source openrisc systems | 13:00 |
tgs3 | probably easier then kickstartering ASIC of 1 project (openrisc) | 13:00 |
LoneTech | I like it, but it will be a long road | 13:01 |
LoneTech | in the past there have been fpgas that were documented, like the 4000 family iirc | 13:04 |
LoneTech | tgs3: a little discussion at http://electronics.stackexchange.com/questions/3107/looking-for-open-source-fpga-hardware-and-dev-tools too (I work for ORSoC nowadays, but we don't make FPGAs) | 13:27 |
stekern | have a look at this too: https://github.com/Wolfgang-Spraul/fpgatools | 13:49 |
LoneTech | ooh, spartan 6 support. that may be a worthy jbits replacement | 13:51 |
LoneTech | I'd like to see the near-instant synthesis of xilinx-lava more widely available | 13:52 |
LoneTech | stekern: thank you! :) | 13:58 |
tgs3 | LoneTech: maybe just gather competent people and kickstat it \o/ | 15:38 |
tgs3 | LoneTech: any price range for funding needed to design 100% open general FPGA capable of being used in modular grid big enough to make openRISC of it? | 15:39 |
tgs3 | as economical ASIC | 15:39 |
LoneTech | I don't know. Just estimating it is a fairly big task I have little experience in. | 15:41 |
tgs3 | on technical level does it make sense to have small FPGAs and combine them together to provide the hardware needed for openrisc cpu? | 16:54 |
tgs3 | e.g. is it common for FPGAs to be joinable, e.g. to connect 4 small FPGAs to create the core of one system like openRISC, and few other to provide e.g. memory or other chips? | 16:55 |
stekern | tgs3: you probably could, but what would be the purpose in this case? | 18:56 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!