#milkymist IRC log for Tuesday, 2012-09-11

kristianpaullekernel_: but you crititics include the  lastest openrisc iplementations? like https://github.com/openrisc/mor1kx00:37
kristianpaulazonenberg: indeed what happened witht the cmos.. you were're building some tools last time i heard00:38
kristianpaulhomecmos*00:39
azonenbergkristianpaul: Yes, things are going slow because of school00:41
azonenbergi'm still working on the spin coater and CNC microscope stage00:41
wolfspra1land because azonenberg is doing 20 things in parallel :-)00:41
wolfspra1lno00:41
wolfspra1l5000:41
kristianpaul;-)00:41
azonenbergwolfspra1l: I'm a bit of a barrel processor00:42
azonenbergI need lots of threads to get maximal utilization00:42
kristianpaulcde: in my enormous ignorance i think the kernel should be incharge of memory management anyway00:42
wolfspra1lI somehow think I must be days or maybe 1 week away from generating my first simple designs that can run in an slx900:45
wolfspra1lthen I will bug xiangfu about why they don't run, and/or ruin his chips :-)00:45
azonenbergwolfspra1l: :)00:48
wolfspra1lwhat's missing now is essentially to fill in more pieces everywhere, the architecture is all fine00:49
wolfspra1lbetter autotester00:49
azonenbergNice00:49
wolfspra1ljust lots of implementation details00:49
wolfspra1lmore routing switches00:49
azonenbergI'm going to work on higher level tooling stuff for now00:49
wolfspra1lmore inter-tile connections00:49
wolfspra1lauto-crc00:49
azonenbergand operate under the assumption that at some point your code will get mature enough that i can generate your native file format instead of XDL output from my tools00:49
wolfspra1l(maybe I can ask the chip to skip auto-crc checks for now)00:49
wolfspra1lthat is fine, I continue and also very open about how far I am00:50
wolfspra1lat this point, the only bitstream I can generate is still "the empty bitstream"00:50
wolfspra1l:-)00:50
wolfspra1lI must have implemented the most inefficient way to generate an empty bitstream00:51
wolfspra1lthere's about 100 switches in the routing switchbox that bug me right now00:53
wolfspra1lbetween the long (4-tile) wires00:53
wolfspra1lback to work...00:53
kristianpaulnice indeed :)01:07
kristianpaulcde: is a fair point this about trully free os, but we cant negate the comodity of having stuff like ELF.. but yeah the binary only thing seems a good excuse for mmu01:13
lekernelkristianpaul: that's the "recent reimplementation" I mentioned06:59
GitHub111[migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/3b3e2f19eb21...2e14569b5c6408:05
GitHub111[migen/master] fhdl: list signals in execution order - Sebastien Bourdeauducq08:05
GitHub111[migen/master] fhdl/verilog: sort clock domains by name - Sebastien Bourdeauducq08:05
wpwrakhellekin: welcome back ! indeed an extended world tour ;-)11:05
wpwrakhellekin: so you'll be here in time for the protest march (cacerolazo) on thursday :)11:06
cdewolfspra1l: https://github.com/sbourdeauducq/llhdl is 404 :( referenced from http://www.milkymist.org/fpgatools/ . is there a newer repo?11:18
cdeI guess https://github.com/weidu/llhdl and https://github.com/weidu/antares11:26
larscmaybe lekernel deleted it11:29
Fallenouyes it has been deleted11:37
lekernelseems wolfspra1l and azonenberg are doing better tools anyway :)11:44
cdeoh cool! are they currently on github?11:51
Fallenouyes11:51
Fallenouhttps://github.com/Wolfgang-Spraul/fpgatools11:51
cdethanks a lot11:51
cdebtw I created my github account, https://github.com/rxos (currently empty)11:51
cdesadly, cde was already taken11:52
cdeI thought fpgatools would support primarily xc6slx45, but it targets xc6slx9?11:53
cdewell it shouldn't be very add to add support for bigger chips I guess ;)11:55
Fallenouit's xiangfu 's board which is using slx9 IIRC11:57
Fallenoua very very "simple" (meaning minimalist) board11:57
Fallenouhttp://en.qi-hardware.com/wiki/Mini-slx911:57
cdethanks. was there a particular requirement for the slx9 as opposed to using the M1 as a testbed?12:00
cdeI guess you can experiment more wildly with it, in particular wrt/ I/O since it would cost less if destroyed12:01
Fallenouslx9 is much more "simple" than M112:02
Fallenouand fpga is smaller, simpler I guess12:02
Fallenoueasier to do bitstream generation experiment on small fpga + small board12:02
wolfspra1lI agree with Sebastien that the llhdl and antares sources are not worth looking at, but a plain 404 is a little cheap imho and there should be some more helpful text for newbies. alas, milkymist was always tough for newbites. if you survive here you survive anywhere :-)12:05
wolfspra1land no, fpgatools is not much better today, also just experimental12:05
wolfspra1lbut I will never delete it for sure, worst case there will be a note in the README in case it goes nowhere12:05
wolfspra1lit's pouring cats and dogs in beijing right now, so tomorrow the roads will be flooded - yay! :-)12:06
wolfspra1lcde: if you have questions about fpgatools, please let me know as I need to collect some to write the FAQ...12:09
wolfspra1lthat would be very helpful - thanks!12:10
lekernelwolfspra1l: reconsidered your "no documentation - read the source" line? :)12:11
wolfspra1lyes, of course12:12
wolfspra1lthat was just at the beginning12:12
wolfspra1lmaking the start easy is my real passion12:12
wolfspra1lif it's not easy to get started, it doesn't work12:12
wolfspra1lbut nothing works today, so no need to waste time looking at it except to ask questions maybe...12:13
cdewolfspra1l: oh, it's not so though. the IRC channel is quite helpful :) I'll be sure to ask here if I have questions12:18
cde*tough12:19
cdewhat are the major blocking points in fpgatools today, that is areas that need assistance?12:22
wolfspra1lif you are a good C programmer, you can start playing with the code today12:25
wolfspra1lthe next working items are more or less describe in the todo, as12:25
wolfspra1lmore routing switches12:25
wolfspra1lmore inter-tile connections12:25
wolfspra1lmore iob and lut configurations12:25
wolfspra1lauto-crc12:25
wolfspra1lbetter autotester12:25
wolfspra1lall of this leading to the first simple 'design' (=bitstream) that can load and run in a physical slx9 successfully, something as simple as an AND gate or so12:26
wolfspra1lthat's the next milestone12:26
wolfspra1lafter that is reached - fix loose ends everywhere, start with clocks, dcm/pll12:26
wolfspra1land then simple reusable design elements12:27
wolfspra1lthen support for larger xc6 chips, maybe something with a ftg256 or fgg484 packaging12:27
cdehmm I don't have an slx9 at hand, however the slx45 should do I guess. has the bitstream format been reverse-engineered yet?12:27
wolfspra1lI will definitely want to try it myself12:27
wolfspra1land/or switch to the xc7a10012:27
wolfspra1lthat's all months out though, just describing the roadmap12:27
wolfspra1lno it won't "do", because there is a lot of work everywhere12:28
wolfspra1llike months full-time12:28
wolfspra1lyou can join if you like but pretty much nothing works today or soon12:28
lekernelif that works, then it'll be better than DARPA-funded jbits :)12:28
wolfspra1lI will continue with the slx9 until at least let's say 10% of the features of that chip are really working well with fpgatools12:29
wolfspra1lbetter more12:29
wolfspra1lit makes no sense for me to jump to larger chips early on12:29
wolfspra1lonly slows me down12:29
wpwrakand costs more money when you fry them :)12:29
wolfspra1land the bigger ones don't come in qfp144 packaging, and and and12:30
cdehow hard would it be to fry an fpga through incorrect configuration?12:30
wolfspra1lbut even if the slx9 is working well, (well=10%), going to say the slx45 is at least another full-time month of work12:30
wolfspra1lthe overall structure is the same, and a lot of stuff is reusable, but the whole thing needs to grow and there are many new/different corner cases, new features, etc.12:31
wolfspra1land that wont' just magically appear by changing an integer somewhere from '9' to '45'12:31
wolfspra1lprobably relatively easy to fry one12:31
wolfspra1lbut I shall have more real-world data on that soon12:32
cdeyou seem very pessimistic! don't be :D12:32
wolfspra1lI would think that if you configure the routing bits badly, electrical overload may flow in all sorts of directions12:32
wolfspra1lI'm an enternal optimist, but I try to describe this in the most realistic way12:32
wolfspra1lyou are very welcome to come in and help12:32
wolfspra1lfrom a 10% working slx9 to a 10% working slx45 is 1+ months full-time work12:33
wolfspra1lthat is a fact12:33
wolfspra1lnot pessimistic or optimistic12:33
wolfspra1lit's developing nicely btw12:33
wpwrakwolfgang is an optimist - by expecting the worst, he hopes for pleasant surprises :)12:33
wolfspra1lI learned an enormous amount already12:33
wolfspra1lyes12:33
wolfspra1lyou can join today12:33
wolfspra1lI think you mainly need 2 things to make a significant contribution:12:33
wolfspra1l1) plenty of time12:33
wolfspra1l2) good C programming skills12:34
wolfspra1lthat's all12:34
cdewell I'm currently on vacation, for only for the rest of week. after that I'll have much less free time12:34
wolfspra1lI can supply you with cheap slx9 testing boards if we make it there in the next weeks hopefully, at cost12:34
wolfspra1lthere you go :-)12:35
wolfspra1lthat's real life, perfectly fine12:35
wolfspra1lso just wait, and ping me once in a while :-)12:35
Fallenou14:34 < wolfspra1l> you can join today < reminds me TV ads12:35
cdeok. I'll see what I can decipher of the source code in the meantime ;)12:35
wolfspra1lFallenou: and look, the mmu fits as well12:35
wolfspra1l:-)12:36
Fallenoufits in what ?12:36
wolfspra1lI was playing on the TV ad12:36
wolfspra1lthose knife ads12:36
Fallenouhehe12:36
cdeI vaguely remember there is a working project for compiling bitstreams for the Spartan 3. or is my memory wrong?12:37
wolfspra1lsorry can't help12:39
wolfspra1lall I know is historic and I purged it from my mind12:39
Fallenouare you still drawning in paper sheets ?12:39
wolfspra1lgetting better, more and more running in sw now :-)12:39
Fallenouhehe =)12:40
wolfspra1lrouting now, more routing12:40
wolfspra1lthere is so much routing in the chip12:40
cdehmm, has the infrared support been done?13:44
lekernelthere's very basic support https://github.com/milkymist/milkymist/blob/master/cores/rc5/rtl/rc5.v13:46
cdeok. I was afraid my remote wasn't working ;)13:46
cdeis there a repository for the datasheets for all ICs on the M1?16:44
wpwraksort of. you can find links here: http://en.qi-hardware.com/wiki/Milkymist_One_RC3_BOM16:44
cdeawesome!16:45
cdehmm the micro ddr is capable of running at 200 mhz, are we using it at that frequency?16:49
cde*micron16:49
kristianpauli think ng uses no lekernel ?17:04
kristianpaulor at least 160mhz17:04
lekernelng runs the ddr at 166MHz, ys17:08
lekernel333Mbps per data pin17:09
cdethat's twice the frequency of the cpu? what a wierd coincidence17:09
cde(or maybe not! ;)17:09
lekernelyes, I'm using a doubled and phase aligned clock17:09
lekernelphase alignment enables low-latency clock domain transfers17:10
cdebtw is there a trick for data transfer between clock domaine A and B where B is between 1 and 2 the frequency of A ?17:12
lekernelDQS is not used for reading of course, but according to the micron datasheet you only lose about 60ps of timing budget. it's a small price to pay to avoid 1) a big design mess 2) a good 2 cycles of additional read latency for using this imbecilic signal17:12
lekernel#1 of course encompasses the fact that the read latency becomes unpredictable, which adds to the difficulty of scheduling transfers17:14
lekernelI pity the Intel engineers :)17:14
lekernelcde: you need some phase alignment, and then sample the all data with sufficient setup/hold time.17:16
lekernelwithout phase alignment, you need double latching (sometimes included in a FIFO control system), which adds a lot of latency17:16
cdethanks17:17
lekerneland that latency varies, of course, depending on what phase the two clocks happen to have when data enters the FIFO17:17
lekernelin short - it's great that micron guarantees a tight clock-to-DQS skew for the parts we're using17:19
cdebtw this document is interesting: http://www.latticesemi.com/lit/docs/generalinfo/memory_ddr_interface_wp.pdf17:20
lekernelI hope we can find DDR3 parts with similar specs for the M3...17:21
lekernelcde: http://www.fpga4fun.com/CrossClockDomain.html17:22
lekernelthe point of phase alignment (and integer frequency ratios) is to avoid this technique, which adds latency and unpredictability17:24
cdedoesn't the artix 7 have a built-in memory controller? that could be useful17:25
lekernelit has an undocumented "phaser", which handles some DQS- and read/write leveling-related gory details17:26
lekernelwe won't need read/write leveling on the M3 since we are connecting individual chips to the FPGA (which also increases the page hit rate), at an expense of increased I/Os utilization17:26
lekerneland I hope to get rid of DQS problems in a similar way (still need to read some datasheets...)17:27
cdebtw http://download.micron.com/pdf/technotes/ddr2/TN4723.pdf in case you haven't seen it17:27
lekernelftp://ftp.macrogroup.ru/DigiEl/Xilinx/XLX_Seminar_NewElectronics/7series_Clocking_SelectIO_Tech_Module_Thomas_Klein.pdf17:28
lekernelscroll down for phaser info17:28
cdeit looks like the phaser is primarily for meeting the very precise ddr2/3 timing requirements? other interfaces (hdmi, ...) will not require it17:33
lekernelhdmi data rates per pin are the same or higher than ddr2/317:56
lekernelthe fundamental problems with ddr is that you have a lot more signals, and data can go both ways (eg DRAM component answers a read request that was transmitted from the fpga, as opposed to a unidirectional data flow in hdmi)17:58
cdelattice also has a DDR3 ip core, I guess it costs money like other vendors (and is not open-source)18:01
lekernelreading lattice paper p. 2018:15
lekernelinteresting way of transferring from DQS to system clock18:15
lekernelit actually avoids that annoying FIFO...18:15
lekernelnot usable on xilinx arch though (I'd even bet someone patented this...)18:15
lekernelthis scores another point for lattice. too bad their software is so horrible.18:16
--- Wed Sep 12 201200:00

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