lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
<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
<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
<barmstrong>
and didn't want to stir stuff up there if this does something dumb :)
<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
mumptai has joined #milkymist
kristianpaul has quit [Ping timeout: 256 seconds]
kristianpaul has joined #milkymist
playthatbeat has quit [Ping timeout: 248 seconds]
playthatbeat has joined #milkymist
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
Flea86 has joined #milkymist
Flea86 has quit [Quit: A fine is a tax for doing wrong. A tax is a fine for doing well]
mrueg has quit [Remote host closed the connection]
<ysionneau>
I'm trying to remember something, was there a "fpga on fpga" project? what's its name?
<kristianpaul>
dunno
<kristianpaul>
but looks quite overhead
<kristianpaul>
constraints on contraints :)
kristianpaul has quit [Quit: Reconnecting]
kristianpaul has joined #milkymist
<ysionneau>
kristianpaul: thanks for the blog post, nice post !
<kristianpaul>
yeap
<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
<ysionneau>
and then you have the whole chain which is free and open source
<ysionneau>
you ave control over everything
<ysionneau>
when you have everything working well, you can try to make deals do turn this FPGA into an "ASIC" FPGA
<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
<ysionneau>
I thought such a project (at least the FPGA on FPGA part) existed
<kristianpaul>
remenber the fpga architecture relly on silicon "geomtry"
<ysionneau>
dunno if I was dreaming :)
<kristianpaul>
s/relly/stand/
<ysionneau>
I'm not sure I follow you
<ysionneau>
indeed this FPGA on FPGA would be terribly slow and very small
<ysionneau>
that would be just a "proof of concept"
<ysionneau>
to define the architecture and have it "running"
<ysionneau>
just like having a design run on FPGA before having it built into an ASIC gives you very poor performance
<ysionneau>
same problem
<ysionneau>
but it's for prototyping
<ysionneau>
it gives you an idea of how it behaves
<ysionneau>
and it helps you finding bugs
<ysionneau>
and it's very cheap
<ysionneau>
except that having design run on FPGA can actually carry real job
<ysionneau>
a FPGA on FPGA would not be of any real use I guess
<ysionneau>
except for then making a real chip
<kristianpaul>
well, if built an ASIC could be consider feasible for us, why do need a fpga anyway?
<kristianpaul>
or i think i lost your point :-/
* kristianpaul
bit asleep
Scopeuk is now known as Scopeuk-AFK
<barmstrong>
are there any open synthesizers? i'm not aware of any, but it certainly seems feasible
<barmstrong>
going like llvm and having an intermediate representation would be pretty great
<ysionneau>
well building one ASIC does not mean you have the money to build 100 ASICs :)
<ysionneau>
but building one open source FPGA allows you then to to useful job
<ysionneau>
but with an open source FPGA
<ysionneau>
and maybe open source toolchain after that
<ysionneau>
s/to to/to do/
<ysionneau>
barmstrong: it's considered a difficult problem, even though smart people started a few projects
<ysionneau>
like reverse engineering bitstream format
<ysionneau>
or FPGA cells by decaping etc
<ysionneau>
very few tools exist however
<ysionneau>
like wolfgang spraul project
<ysionneau>
capable of generating a bitstream that makes a led blink
<barmstrong>
i mean, you can replace the toolchain piecemeal, right?
<ysionneau>
piecemeal?
<barmstrong>
write a synthesizer but use your output with proprietary tools
<ysionneau>
there is no complete open source toolchain yet
<barmstrong>
to do the remaining steps
<ysionneau>
ah, yes
<ysionneau>
you can try to replace just one of the tool and interface with the other existing
<ysionneau>
actually I think you could (or still can?) generate netlist from verilog with iverilog
<barmstrong>
ah, i did not know that
<barmstrong>
what do the primitives look like?
<ysionneau>
the missing bits are : a tool which maps to a FPGA device, a place&route tool
<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
<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.
<ysionneau>
work like wolfgang's one could be very useful for this last part
<barmstrong>
the most proprietary, though, right?
<ysionneau>
since it already knows a bit about how the bitstream format works
<barmstrong>
but yeah, algorithmicly it sounds easy
<ysionneau>
place&route is, IIUC, the most difficult part
<ysionneau>
even algorithmically
<barmstrong>
i would believe that
<ysionneau>
there is a lot of research about that
<ysionneau>
a lot of different heuristics
<barmstrong>
I also don't believe the Xilinx tools necessarily use the best :)
<ysionneau>
indeed
<barmstrong>
it's probably just "good enough"
<ysionneau>
we don't even know what they do...
<barmstrong>
i think for the synthesizer, LLVM is the way to go
<barmstrong>
something like that, i mean
<ysionneau>
yeah, maybe
<ysionneau>
I don't know enough about LLVM to tell :)
<barmstrong>
where you can decouple frontend, backend and strategies
<ysionneau>
but it seems to be the good tool to build compilers
<ysionneau>
so yes I guess
<barmstrong>
I have no idea what I'm talking about though
<barmstrong>
it's a fascinating topic!
<ysionneau>
ok, I just checked
<ysionneau>
iverilog can generate code for those targets : vvp (simulation), xnf, fpga
<ysionneau>
fpga means it generate EDIF netlist file
<barmstrong>
oh, neat!
<ysionneau>
you can then import EDIF into closed source vendor specific tools
<ysionneau>
so you could use iverilog as the first step of your open source toolchain
<ysionneau>
and build from that a tool which takes EDIF as input
<ysionneau>
but then there is a lot of work :)
<barmstrong>
A lot of work to get something that's correct? That produces a nicely optimized result? That runs quickly? :)
<barmstrong>
there's a lot of different goals here, i think
<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
<barmstrong>
That's fair
<ysionneau>
clearly not impossible
<ysionneau>
but a lot of time
<ysionneau>
or needs a few people, full time
<ysionneau>
this kind of project :)
<ysionneau>
in the software world, I think it would have been done long ago
<ysionneau>
but FPGA is kind of the "hardware" world.
<barmstrong>
by the way, i'm a software dev by day, so my perspective is kind of strange here :)
<barmstrong>
i totally agree with you
<barmstrong>
when i talk to fellow programmers about this, they think it's a skill they wouldn't have
<ysionneau>
I'm a software guy as well
<ysionneau>
I mean, Linux kernel is very complex, it does exist
<ysionneau>
Xorg as well
<ysionneau>
etc
<barmstrong>
definitely
<ysionneau>
lots of very complex software does exist
<ysionneau>
even though they needed a lot of hours of work and a lot of programmers
<barmstrong>
so one thing i've wondered about is if there are any arduino or raspberry pi boards with fpgas on them
<ysionneau>
but I don't think there is a lot of software guy using/programming FPGAs
<barmstrong>
because i think if a lot of people had cheap fpgas, they'd be more interested in open cores
<ysionneau>
so the amount of motivated enough software guys to start such a big project is even lower
<ysionneau>
etc
<ysionneau>
The amount of software guy who needed a X11 server was very high
<ysionneau>
so I bet it was not *that* difficult to find enough motivated guys to start to hack about Xorg
<ysionneau>
same for Linux
<barmstrong>
true, but then again, linux started from one person :)
<ysionneau>
yes
<barmstrong>
and other people joined in as the barrier came down
<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...
<ysionneau>
dunno...
<barmstrong>
good point
<barmstrong>
thanks for all the info, by the way
<barmstrong>
i'm really trying to get into this in my free time
<ysionneau>
somehow the hardware world is very full of closed source software, and it seems it "works this way"
<ysionneau>
they do not need to invest in free software to get customers ...
<barmstrong>
that seems to reflect a lot of engineering mentality in general, though
<barmstrong>
i think that open just hasn't spread to there very well
<ysionneau>
I don't know how such a move toward free software could be started
<ysionneau>
yeah ...
<ysionneau>
no problem
<ysionneau>
I'm trying to understand as well :)
<barmstrong>
I think a big piece of this is actually Moore's law and intel
<barmstrong>
the cpu keeps getting better, so it reduces the use case for special-use hardware for the average programmer
<ysionneau>
gotta run!
<ysionneau>
see you !
<barmstrong>
later :)
sb0 has joined #milkymist
<sb0>
ysionneau, overengineering alone makes monstrosities like Xorg (and USB etc.) complex. they do not not need to be so.
<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
<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
<barmstrong>
ah, neat
<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...
<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
<barmstrong>
using __del__ in python unlocks the kraken :)
<sb0>
ah, indeed, I had a few issues with __del__ which I didn't fully investigate
<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
<barmstrong>
and i don't think it's the best use of my time
<barmstrong>
it has been really awesome using it so far, though
<sb0>
well that patch sounds like something I'd merge
<barmstrong>
ok, i'll submit it the proper way
<barmstrong>
thanks
<sb0>
thanks for bringing up that issue, and a fix. any other troubles? what are the most un-pythonic things you found?
<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
<barmstrong>
this patch would obviously kill building on linux though
<sb0>
ah, the SOCK_STREAM thing...
<barmstrong>
that was a fun one
<sb0>
SOCK_SEQPACKET is pretty nice
<barmstrong>
yep, looks like it
<sb0>
it's kinda irritating Apple won't implement it
<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
<barmstrong>
so i just defaulted to using osx
<sb0>
I'd actually prefer a SOCK_SEQPACKET implementation for OSX...
<sb0>
which could be done underneath with SOCK_STREAM and a code like yours
<barmstrong>
that would be kind of interesting
<sb0>
does OSX support LD_PRELOAD?
<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.
<barmstrong>
it feels silly telling you how to architect this though :)
<barmstrong>
i don't know re: LD_PRELOAD
<sb0>
yes, the imports are a bit messy sometimes
<barmstrong>
i'm actually not too familiar with what sort of unix-likeness you get out of osx
<sb0>
but "from ... import Signal, If, Case, Module"
<sb0>
is a lot of typing
<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
<sb0>
and "from ... import fhdl" then you have to use fhdl.If etc. which is also messy
<barmstrong>
it is, yeah. I dunno, I work on a production python codebase for my day job and we just do the typing
<sb0>
in the end I thought the "import *" was the least bad solution
<barmstrong>
as your codebase gets bigger, I think import * stops scaling
<barmstrong>
as I've been using migen, I just do from migen.fhdl.std import Module, Signal...
<sb0>
yeh, I don't like that verbosity. but that's a valid use case, though.
<sb0>
could also use __all__ ?
<barmstrong>
__all__ definitely works better
<barmstrong>
you at least get rid of namespace clutter that way
<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
<barmstrong>
that's an interesting perspective
<barmstrong>
i'll have a look
<sb0>
assuming they would actually make the call socket(...SOCK_SEQPACKET...) on OSX...
<sb0>
but I think they would
<barmstrong>
i also changed the build flags in that patch but it wasn't anything major