#milkymist IRC log for Thursday, 2013-10-03

barmstrongsb0: 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 delays06:28
barmstrongso, 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/HeME2CaX06:36
barmstrongand didn't want to stir stuff up there if this does something dumb :)06:37
barmstrongi 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/SpT0uJVW06:41
kristianpauljust in case20:14
ysionneauI'm trying to remember something, was there a "fpga on fpga" project? what's its name?20:29
kristianpaulbut looks quite overhead20:32
kristianpaulconstraints on contraints :)20:32
ysionneaukristianpaul: thanks for the blog post, nice post !20:51
ysionneaukristianpaul: well, the idea of having a FPGA on FPGA would allow to describe an "open source" FPGA architecture, and then develop the open source toolchain20:51
ysionneauand then you have the whole chain which is free and open source20:52
ysionneauyou ave control over everything20:52
ysionneauwhen you have everything working well, you can try to make deals do turn this FPGA into an "ASIC" FPGA20:52
ysionneauand then you have your open source FPGA, with nice tools that you can improve for better resource mapping, place & route, timing issues etc20:53
ysionneauI thought such a project (at least the FPGA on FPGA part) existed20:53
kristianpaulremenber the fpga architecture relly on silicon "geomtry"20:53
ysionneaudunno if I was dreaming :)20:53
ysionneauI'm not sure I follow you20:54
ysionneauindeed this FPGA on FPGA would be terribly slow and very small20:54
ysionneauthat would be just a "proof of concept"20:55
ysionneauto define the architecture and have it "running"20:55
ysionneaujust like having a design run on FPGA before having it built into an ASIC gives you very poor performance20:55
ysionneausame problem20:56
ysionneaubut it's for prototyping20:56
ysionneauit gives you an idea of how it behaves20:56
ysionneauand it helps you finding bugs20:56
ysionneauand it's very cheap20:56
ysionneauexcept that having design run on FPGA can actually carry real job20:56
ysionneaua FPGA on FPGA would not be of any real use I guess20:57
ysionneauexcept for then making a real chip20:57
kristianpaulwell, if built an ASIC could be consider feasible for us, why do need a fpga anyway?20:57
kristianpaulor i think i lost your point :-/20:58
Action: kristianpaul bit asleep20:58
barmstrongare there any open synthesizers? i'm not aware of any, but it certainly seems feasible21:02
barmstronggoing like llvm and having an intermediate representation would be pretty great21:02
ysionneauwell building one ASIC does not mean you have the money to build 100 ASICs :)21:05
ysionneaubut building one open source FPGA allows you then to to useful job21:06
ysionneaubut with an open source FPGA21:06
ysionneauand maybe open source toolchain after that21:06
ysionneaus/to to/to do/21:06
ysionneaubarmstrong: it's considered a difficult problem, even though smart people started a few projects21:07
ysionneaulike reverse engineering bitstream format21:07
ysionneauor FPGA cells by decaping etc21:07
ysionneauvery few tools exist however21:07
ysionneaulike wolfgang spraul project21:08
ysionneaucapable of generating a bitstream that makes a led blink21:08
barmstrongi mean, you can replace the toolchain piecemeal, right?21:08
barmstrongwrite a synthesizer but use your output with proprietary tools21:09
ysionneauthere is no complete open source toolchain yet21:09
barmstrongto do the remaining steps21:09
ysionneauah, yes21:09
ysionneauyou can try to replace just one of the tool and interface with the other existing21:09
ysionneauactually I think you could (or still can?) generate netlist from verilog with iverilog21:09
barmstrongah, i did not know that21:10
barmstrongwhat do the primitives look like?21:10
ysionneauthe missing bits are : a tool which maps to a FPGA device, a place&route tool21:10
barmstrongI 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 art21:10
ysionneauI 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
ysionneauwork like wolfgang's one could be very useful for this last part21:11
barmstrongthe most proprietary, though, right?21:11
ysionneausince it already knows a bit about how the bitstream format works21:11
barmstrongbut yeah, algorithmicly it sounds easy21:11
ysionneauplace&route is, IIUC, the most difficult part21:12
ysionneaueven algorithmically21:12
barmstrongi would believe that21:12
ysionneauthere is a lot of research about that21:12
ysionneaua lot of different heuristics21:12
barmstrongI also don't believe the Xilinx tools necessarily use the best :)21:12
barmstrongit's probably just "good enough"21:13
ysionneauwe don't even know what they do...21:13
barmstrongi think for the synthesizer, LLVM is the way to go21:13
barmstrongsomething like that, i mean21:13
ysionneauyeah, maybe21:13
ysionneauI don't know enough about LLVM to tell :)21:13
barmstrongwhere you can decouple frontend, backend and strategies21:13
ysionneaubut it seems to be the good tool to build compilers21:13
ysionneauso yes I guess21:13
barmstrongI have no idea what I'm talking about though21:14
barmstrongit's a fascinating topic!21:14
ysionneauok, I just checked21:15
ysionneauiverilog can generate code for those targets : vvp (simulation), xnf, fpga21:15
ysionneaufpga means it generate EDIF netlist file21:15
barmstrongoh, neat!21:16
ysionneauyou can then import EDIF into closed source vendor specific tools21:16
ysionneauso you could use iverilog as the first step of your open source toolchain21:16
ysionneauand build from that a tool which takes EDIF as input21:16
ysionneaubut then there is a lot of work :)21:16
barmstrongA lot of work to get something that's correct? That produces a nicely optimized result? That runs quickly? :)21:17
barmstrongthere's a lot of different goals here, i think21:17
ysionneauA lot of work to produce a working toolchain that produces even really small simple designs for say just 1 precise FPGA device target21:18
barmstrongThat's fair21:18
ysionneauclearly not impossible21:19
ysionneaubut a lot of time21:19
ysionneauor needs a few people, full time21:19
ysionneauthis kind of project :)21:19
ysionneauin the software world, I think it would have been done long ago21:19
ysionneaubut FPGA is kind of the "hardware" world.21:20
barmstrongby the way, i'm a software dev by day, so my perspective is kind of strange here :)21:20
barmstrongi totally agree with you21:20
barmstrongwhen i talk to fellow programmers about this, they think it's a skill they wouldn't have21:20
ysionneauI'm a software guy as well21:20
ysionneauI mean, Linux kernel is very complex, it does exist21:20
ysionneauXorg as well21:20
ysionneaulots of very complex software does exist21:21
ysionneaueven though they needed a lot of hours of work and a lot of programmers21:21
barmstrongso one thing i've wondered about is if there are any arduino or raspberry pi boards with fpgas on them21:21
ysionneaubut I don't think there is a lot of software guy using/programming FPGAs21:21
barmstrongbecause i think if a lot of people had cheap fpgas, they'd be more interested in open cores21:22
ysionneauso the amount of motivated enough software guys to start such a big project is even lower21:22
ysionneauThe amount of software guy who needed a X11 server was very high21:22
ysionneauso I bet it was not *that* difficult to find enough motivated guys to start to hack about Xorg21:22
ysionneausame for Linux21:22
barmstrongtrue, but then again, linux started from one person :)21:23
barmstrongand other people joined in as the barrier came down21:23
ysionneauor 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
barmstronggood point21:24
barmstrongthanks for all the info, by the way21:24
barmstrongi'm really trying to get into this in my free time21:24
ysionneausomehow the hardware world is very full of closed source software, and it seems it "works this way"21:24
ysionneauthey do not need to invest in free software to get customers ...21:25
barmstrongthat seems to reflect a lot of engineering mentality in general, though21:25
barmstrongi think that open just hasn't spread to there very well21:25
ysionneauI don't know how such a move toward free software could be started21:25
ysionneauyeah ...21:25
ysionneauno problem21:25
ysionneauI'm trying to understand as well :)21:26
barmstrongI think a big piece of this is actually Moore's law and intel21:26
barmstrongthe cpu keeps getting better, so it reduces the use case for special-use hardware for the average programmer21:26
ysionneaugotta run!21:27
ysionneausee you !21:27
barmstronglater :)21:27
sb0ysionneau, overengineering alone makes monstrosities like Xorg (and USB etc.) complex. they do not not need to be so.22:53
sb0barmstrong, https://github.com/nakengelhardt/mist - progressing slowly though. but the idea is direct migen-to-EDIF synthesis that you feed into the Xilinx P&R22:54
sb0I 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 against22:58
barmstrongah, neat22:59
sb0I 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
barmstrongoh, 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/HeME2CaX23:01
barmstrongusing __del__ in python unlocks the kraken :)23:01
sb0ah, indeed, I had a few issues with __del__ which I didn't fully investigate23:02
barmstrongi'm kind of tempted to go through migen and make everything pythonic, but i feel like i'd be left with a fork23:04
barmstrongand i don't think it's the best use of my time23:04
barmstrongit has been really awesome using it so far, though23:04
sb0well that patch sounds like something I'd merge23:04
barmstrongok, i'll submit it the proper way23:05
sb0thanks for bringing up that issue, and a fix. any other troubles? what are the most un-pythonic things you found?23:05
barmstrongThere was only one other showstopper, which was building vpi on OSX. I realize that probably isn't the top of priorities :) http://pastebin.com/SpT0uJVW23:06
barmstrongthis patch would obviously kill building on linux though23:06
sb0ah, the SOCK_STREAM thing...23:07
barmstrongthat was a fun one23:07
sb0SOCK_SEQPACKET is pretty nice23:07
barmstrongyep, looks like it23:07
sb0it's kinda irritating Apple won't implement it23:07
barmstrongfwiw, 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 moment23:08
barmstrongso i just defaulted to using osx23:08
sb0I'd actually prefer a SOCK_SEQPACKET implementation for OSX...23:08
sb0which could be done underneath with SOCK_STREAM and a code like yours23:08
barmstrongthat would be kind of interesting23:09
sb0does OSX support LD_PRELOAD?23:09
barmstrongas 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
barmstrongit feels silly telling you how to architect this though :)23:10
barmstrongi don't know re: LD_PRELOAD23:10
sb0yes, the imports are a bit messy sometimes23:10
barmstrongi'm actually not too familiar with what sort of unix-likeness you get out of osx23:11
sb0but "from ... import Signal, If, Case, Module"23:11
sb0is a lot of typing23:11
barmstrongi 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 is23:12
sb0and "from ...  import fhdl" then you have to use fhdl.If etc. which is also messy23:12
barmstrongit is, yeah. I dunno, I work on a production python codebase for my day job and we just do the typing23:12
sb0in the end I thought the "import *" was the least bad solution23:12
barmstrongas your codebase gets bigger, I think import * stops scaling23:12
barmstrongas I've been using migen, I just do from migen.fhdl.std import Module, Signal...23:13
sb0yeh, I don't like that verbosity. but that's a valid use case, though.23:13
sb0could also use __all__ ?23:14
barmstrong__all__ definitely works better23:14
barmstrongyou at least get rid of namespace clutter that way23:15
sb0barmstrong, I think a good solution is to provide SOCK_SEQPACKET in a separate library using LD_PRELOAD on OSX, and run migen/icarus with that23:15
barmstrongthat's an interesting perspective23:15
barmstrongi'll have a look23:15
sb0assuming they would actually make the call socket(...SOCK_SEQPACKET...) on OSX...23:15
sb0but I think they would23:16
barmstrongi also changed the build flags in that patch but it wasn't anything major23:16
barmstrongosx is a mess :)23:17
sb0so that sounds possible23:17
--- Fri Oct 4 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!