| barmstrong | sb0: sure, delays are not synthesizable, but I'm trying to use migen to demonstrate some digital logic stuff, and it'd be neat to have handwavey delays | 06:28 |
|---|---|---|
| barmstrong | so, I have a patch against migen that I'd be happy to mail to the dev list, but I didn't know if I was missing something obvious http://pastebin.com/HeME2CaX | 06:36 |
| barmstrong | and didn't want to stir stuff up there if this does something dumb :) | 06:37 |
| barmstrong | i also changed some pieces to make the sim build on osx, but i'm pretty sure it breaks build on linux, and my Makefile-fu isn't too good http://pastebin.com/SpT0uJVW | 06:41 |
| kristianpaul | http://blog.elphel.com/2013/10/fpga-is-for-freedom/ | 20:14 |
| kristianpaul | just in case | 20:14 |
| ysionneau | I'm trying to remember something, was there a "fpga on fpga" project? what's its name? | 20:29 |
| kristianpaul | dunno | 20:32 |
| kristianpaul | but looks quite overhead | 20:32 |
| kristianpaul | constraints on contraints :) | 20:32 |
| ysionneau | kristianpaul: thanks for the blog post, nice post ! | 20:51 |
| kristianpaul | yeap | 20:51 |
| ysionneau | kristianpaul: well, the idea of having a FPGA on FPGA would allow to describe an "open source" FPGA architecture, and then develop the open source toolchain | 20:51 |
| ysionneau | and then you have the whole chain which is free and open source | 20:52 |
| ysionneau | you ave control over everything | 20:52 |
| ysionneau | when you have everything working well, you can try to make deals do turn this FPGA into an "ASIC" FPGA | 20:52 |
| ysionneau | and then you have your open source FPGA, with nice tools that you can improve for better resource mapping, place & route, timing issues etc | 20:53 |
| ysionneau | I thought such a project (at least the FPGA on FPGA part) existed | 20:53 |
| kristianpaul | remenber the fpga architecture relly on silicon "geomtry" | 20:53 |
| ysionneau | dunno if I was dreaming :) | 20:53 |
| kristianpaul | s/relly/stand/ | 20:54 |
| ysionneau | I'm not sure I follow you | 20:54 |
| ysionneau | indeed this FPGA on FPGA would be terribly slow and very small | 20:54 |
| ysionneau | that would be just a "proof of concept" | 20:55 |
| ysionneau | to define the architecture and have it "running" | 20:55 |
| ysionneau | just like having a design run on FPGA before having it built into an ASIC gives you very poor performance | 20:55 |
| ysionneau | same problem | 20:56 |
| ysionneau | but it's for prototyping | 20:56 |
| ysionneau | it gives you an idea of how it behaves | 20:56 |
| ysionneau | and it helps you finding bugs | 20:56 |
| ysionneau | and it's very cheap | 20:56 |
| ysionneau | except that having design run on FPGA can actually carry real job | 20:56 |
| ysionneau | a FPGA on FPGA would not be of any real use I guess | 20:57 |
| ysionneau | except for then making a real chip | 20:57 |
| kristianpaul | well, if built an ASIC could be consider feasible for us, why do need a fpga anyway? | 20:57 |
| kristianpaul | or i think i lost your point :-/ | 20:58 |
| Action: kristianpaul bit asleep | 20:58 | |
| barmstrong | are there any open synthesizers? i'm not aware of any, but it certainly seems feasible | 21:02 |
| barmstrong | going like llvm and having an intermediate representation would be pretty great | 21:02 |
| ysionneau | well building one ASIC does not mean you have the money to build 100 ASICs :) | 21:05 |
| ysionneau | but building one open source FPGA allows you then to to useful job | 21:06 |
| ysionneau | but with an open source FPGA | 21:06 |
| ysionneau | and maybe open source toolchain after that | 21:06 |
| ysionneau | s/to to/to do/ | 21:06 |
| ysionneau | barmstrong: it's considered a difficult problem, even though smart people started a few projects | 21:07 |
| ysionneau | like reverse engineering bitstream format | 21:07 |
| ysionneau | or FPGA cells by decaping etc | 21:07 |
| ysionneau | very few tools exist however | 21:07 |
| ysionneau | like wolfgang spraul project | 21:08 |
| ysionneau | capable of generating a bitstream that makes a led blink | 21:08 |
| barmstrong | i mean, you can replace the toolchain piecemeal, right? | 21:08 |
| ysionneau | piecemeal? | 21:08 |
| barmstrong | write a synthesizer but use your output with proprietary tools | 21:09 |
| ysionneau | there is no complete open source toolchain yet | 21:09 |
| barmstrong | to do the remaining steps | 21:09 |
| ysionneau | ah, yes | 21:09 |
| ysionneau | you can try to replace just one of the tool and interface with the other existing | 21:09 |
| ysionneau | actually I think you could (or still can?) generate netlist from verilog with iverilog | 21:09 |
| barmstrong | ah, i did not know that | 21:10 |
| barmstrong | what do the primitives look like? | 21:10 |
| ysionneau | the missing bits are : a tool which maps to a FPGA device, a place&route tool | 21:10 |
| barmstrong | I am really interested in this topic in general, but I feel like there's a lot of stuff I don't know about the current state of the art | 21:10 |
| ysionneau | I think the last part, generating the bitstream, when you already have a file which describes the mapping to FPGA resources and place and route, it's the easiest part. | 21:11 |
| ysionneau | work like wolfgang's one could be very useful for this last part | 21:11 |
| barmstrong | the most proprietary, though, right? | 21:11 |
| ysionneau | since it already knows a bit about how the bitstream format works | 21:11 |
| barmstrong | but yeah, algorithmicly it sounds easy | 21:11 |
| ysionneau | place&route is, IIUC, the most difficult part | 21:12 |
| ysionneau | even algorithmically | 21:12 |
| barmstrong | i would believe that | 21:12 |
| ysionneau | there is a lot of research about that | 21:12 |
| ysionneau | a lot of different heuristics | 21:12 |
| barmstrong | I also don't believe the Xilinx tools necessarily use the best :) | 21:12 |
| ysionneau | indeed | 21:13 |
| barmstrong | it's probably just "good enough" | 21:13 |
| ysionneau | we don't even know what they do... | 21:13 |
| barmstrong | i think for the synthesizer, LLVM is the way to go | 21:13 |
| barmstrong | something like that, i mean | 21:13 |
| ysionneau | yeah, maybe | 21:13 |
| ysionneau | I don't know enough about LLVM to tell :) | 21:13 |
| barmstrong | where you can decouple frontend, backend and strategies | 21:13 |
| ysionneau | but it seems to be the good tool to build compilers | 21:13 |
| ysionneau | so yes I guess | 21:13 |
| barmstrong | I have no idea what I'm talking about though | 21:14 |
| barmstrong | it's a fascinating topic! | 21:14 |
| ysionneau | ok, I just checked | 21:15 |
| ysionneau | iverilog can generate code for those targets : vvp (simulation), xnf, fpga | 21:15 |
| ysionneau | fpga means it generate EDIF netlist file | 21:15 |
| barmstrong | oh, neat! | 21:16 |
| ysionneau | you can then import EDIF into closed source vendor specific tools | 21:16 |
| ysionneau | so you could use iverilog as the first step of your open source toolchain | 21:16 |
| ysionneau | and build from that a tool which takes EDIF as input | 21:16 |
| ysionneau | but then there is a lot of work :) | 21:16 |
| barmstrong | A lot of work to get something that's correct? That produces a nicely optimized result? That runs quickly? :) | 21:17 |
| barmstrong | there's a lot of different goals here, i think | 21:17 |
| ysionneau | A lot of work to produce a working toolchain that produces even really small simple designs for say just 1 precise FPGA device target | 21:18 |
| barmstrong | That's fair | 21:18 |
| ysionneau | clearly not impossible | 21:19 |
| ysionneau | but a lot of time | 21:19 |
| ysionneau | or needs a few people, full time | 21:19 |
| ysionneau | this kind of project :) | 21:19 |
| ysionneau | in the software world, I think it would have been done long ago | 21:19 |
| ysionneau | but FPGA is kind of the "hardware" world. | 21:20 |
| barmstrong | by the way, i'm a software dev by day, so my perspective is kind of strange here :) | 21:20 |
| barmstrong | i totally agree with you | 21:20 |
| barmstrong | when i talk to fellow programmers about this, they think it's a skill they wouldn't have | 21:20 |
| ysionneau | I'm a software guy as well | 21:20 |
| ysionneau | I mean, Linux kernel is very complex, it does exist | 21:20 |
| ysionneau | Xorg as well | 21:20 |
| ysionneau | etc | 21:21 |
| barmstrong | definitely | 21:21 |
| ysionneau | lots of very complex software does exist | 21:21 |
| ysionneau | even though they needed a lot of hours of work and a lot of programmers | 21:21 |
| barmstrong | so one thing i've wondered about is if there are any arduino or raspberry pi boards with fpgas on them | 21:21 |
| ysionneau | but I don't think there is a lot of software guy using/programming FPGAs | 21:21 |
| barmstrong | because i think if a lot of people had cheap fpgas, they'd be more interested in open cores | 21:22 |
| ysionneau | so the amount of motivated enough software guys to start such a big project is even lower | 21:22 |
| ysionneau | etc | 21:22 |
| ysionneau | The amount of software guy who needed a X11 server was very high | 21:22 |
| ysionneau | so I bet it was not *that* difficult to find enough motivated guys to start to hack about Xorg | 21:22 |
| ysionneau | same for Linux | 21:22 |
| barmstrong | true, but then again, linux started from one person :) | 21:23 |
| ysionneau | yes | 21:23 |
| barmstrong | and other people joined in as the barrier came down | 21:23 |
| ysionneau | or maybe the exemple I stated were successful because the industry needed it and then a lot of people have been paid to work on this as a full time paid job... | 21:24 |
| ysionneau | dunno... | 21:24 |
| barmstrong | good point | 21:24 |
| barmstrong | thanks for all the info, by the way | 21:24 |
| barmstrong | i'm really trying to get into this in my free time | 21:24 |
| ysionneau | somehow the hardware world is very full of closed source software, and it seems it "works this way" | 21:24 |
| ysionneau | they do not need to invest in free software to get customers ... | 21:25 |
| barmstrong | that seems to reflect a lot of engineering mentality in general, though | 21:25 |
| barmstrong | i think that open just hasn't spread to there very well | 21:25 |
| ysionneau | I don't know how such a move toward free software could be started | 21:25 |
| ysionneau | yeah ... | 21:25 |
| ysionneau | no problem | 21:25 |
| ysionneau | I'm trying to understand as well :) | 21:26 |
| barmstrong | I think a big piece of this is actually Moore's law and intel | 21:26 |
| barmstrong | the cpu keeps getting better, so it reduces the use case for special-use hardware for the average programmer | 21:26 |
| ysionneau | gotta run! | 21:27 |
| ysionneau | see you ! | 21:27 |
| barmstrong | later :) | 21:27 |
| sb0 | ysionneau, overengineering alone makes monstrosities like Xorg (and USB etc.) complex. they do not not need to be so. | 22:53 |
| sb0 | barmstrong, https://github.com/nakengelhardt/mist - progressing slowly though. but the idea is direct migen-to-EDIF synthesis that you feed into the Xilinx P&R | 22:54 |
| sb0 | I think the industry could use and pay for suckless FPGA tools. but there's a lot of "we always did it that way" and "we do not want to appear stupid" culture to fight against | 22:58 |
| barmstrong | ah, neat | 22:59 |
| sb0 | I know some people who keep using Simulink and EDK shitware even though I demonstrated that I could do in 1 day with Migen something that took their team weeks for an inferior result... | 23:00 |
| barmstrong | oh, speaking of migen... I have a patch against migen that I'd be happy to mail to the dev list, but I didn't know if I was missing something obvious http://pastebin.com/HeME2CaX | 23:01 |
| barmstrong | using __del__ in python unlocks the kraken :) | 23:01 |
| sb0 | ah, indeed, I had a few issues with __del__ which I didn't fully investigate | 23:02 |
| barmstrong | i'm kind of tempted to go through migen and make everything pythonic, but i feel like i'd be left with a fork | 23:04 |
| barmstrong | and i don't think it's the best use of my time | 23:04 |
| barmstrong | it has been really awesome using it so far, though | 23:04 |
| sb0 | well that patch sounds like something I'd merge | 23:04 |
| barmstrong | ok, i'll submit it the proper way | 23:05 |
| barmstrong | thanks | 23:05 |
| sb0 | thanks for bringing up that issue, and a fix. any other troubles? what are the most un-pythonic things you found? | 23:05 |
| barmstrong | There was only one other showstopper, which was building vpi on OSX. I realize that probably isn't the top of priorities :) http://pastebin.com/SpT0uJVW | 23:06 |
| barmstrong | this patch would obviously kill building on linux though | 23:06 |
| sb0 | ah, the SOCK_STREAM thing... | 23:07 |
| barmstrong | that was a fun one | 23:07 |
| sb0 | SOCK_SEQPACKET is pretty nice | 23:07 |
| barmstrong | yep, looks like it | 23:07 |
| sb0 | it's kinda irritating Apple won't implement it | 23:07 |
| barmstrong | fwiw, I initially tried to just do a new vm for my hardware tinkering, but ubuntu stable is shipping with py 3.2, not 3.3 at the moment | 23:08 |
| barmstrong | so i just defaulted to using osx | 23:08 |
| sb0 | I'd actually prefer a SOCK_SEQPACKET implementation for OSX... | 23:08 |
| sb0 | which could be done underneath with SOCK_STREAM and a code like yours | 23:08 |
| barmstrong | that would be kind of interesting | 23:09 |
| sb0 | does OSX support LD_PRELOAD? | 23:09 |
| barmstrong | as far as unpythonic goes, it's generally a little frowned on to do 'from foo import *', though that's just a nit. i would probably also just subclass Signal to get signed signals etc. | 23:10 |
| barmstrong | it feels silly telling you how to architect this though :) | 23:10 |
| barmstrong | i don't know re: LD_PRELOAD | 23:10 |
| sb0 | yes, the imports are a bit messy sometimes | 23:10 |
| barmstrong | i'm actually not too familiar with what sort of unix-likeness you get out of osx | 23:11 |
| sb0 | but "from ... import Signal, If, Case, Module" | 23:11 |
| sb0 | is a lot of typing | 23:11 |
| barmstrong | i think just in general rather than using isinstance you just want to define a method on that kind of thing that implements whatever method that is | 23:12 |
| sb0 | and "from ... import fhdl" then you have to use fhdl.If etc. which is also messy | 23:12 |
| barmstrong | it is, yeah. I dunno, I work on a production python codebase for my day job and we just do the typing | 23:12 |
| sb0 | in the end I thought the "import *" was the least bad solution | 23:12 |
| barmstrong | as your codebase gets bigger, I think import * stops scaling | 23:12 |
| barmstrong | as I've been using migen, I just do from migen.fhdl.std import Module, Signal... | 23:13 |
| sb0 | yeh, I don't like that verbosity. but that's a valid use case, though. | 23:13 |
| sb0 | could also use __all__ ? | 23:14 |
| barmstrong | __all__ definitely works better | 23:14 |
| barmstrong | you at least get rid of namespace clutter that way | 23:15 |
| sb0 | barmstrong, I think a good solution is to provide SOCK_SEQPACKET in a separate library using LD_PRELOAD on OSX, and run migen/icarus with that | 23:15 |
| barmstrong | that's an interesting perspective | 23:15 |
| barmstrong | i'll have a look | 23:15 |
| sb0 | assuming they would actually make the call socket(...SOCK_SEQPACKET...) on OSX... | 23:15 |
| sb0 | but I think they would | 23:16 |
| barmstrong | i also changed the build flags in that patch but it wasn't anything major | 23:16 |
| sb0 | http://stackoverflow.com/questions/8514783/what-is-the-exact-equivalent-to-ld-preload-on-osx | 23:17 |
| sb0 | https://blogs.oracle.com/DatabaseEmporium/entry/where_is_ld_preload_under | 23:17 |
| barmstrong | osx is a mess :) | 23:17 |
| sb0 | so that sounds possible | 23:17 |
| sb0 | bbl | 23:22 |
| --- Fri Oct 4 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!