| kristianpaul | lekernel_: but you crititics include the lastest openrisc iplementations? like https://github.com/openrisc/mor1kx | 00:37 |
|---|---|---|
| kristianpaul | azonenberg: indeed what happened witht the cmos.. you were're building some tools last time i heard | 00:38 |
| kristianpaul | homecmos* | 00:39 |
| azonenberg | kristianpaul: Yes, things are going slow because of school | 00:41 |
| azonenberg | i'm still working on the spin coater and CNC microscope stage | 00:41 |
| wolfspra1l | and because azonenberg is doing 20 things in parallel :-) | 00:41 |
| wolfspra1l | no | 00:41 |
| wolfspra1l | 50 | 00:41 |
| kristianpaul | ;-) | 00:41 |
| azonenberg | wolfspra1l: I'm a bit of a barrel processor | 00:42 |
| azonenberg | I need lots of threads to get maximal utilization | 00:42 |
| kristianpaul | cde: in my enormous ignorance i think the kernel should be incharge of memory management anyway | 00:42 |
| wolfspra1l | I somehow think I must be days or maybe 1 week away from generating my first simple designs that can run in an slx9 | 00:45 |
| wolfspra1l | then I will bug xiangfu about why they don't run, and/or ruin his chips :-) | 00:45 |
| azonenberg | wolfspra1l: :) | 00:48 |
| wolfspra1l | what's missing now is essentially to fill in more pieces everywhere, the architecture is all fine | 00:49 |
| wolfspra1l | better autotester | 00:49 |
| azonenberg | Nice | 00:49 |
| wolfspra1l | just lots of implementation details | 00:49 |
| wolfspra1l | more routing switches | 00:49 |
| azonenberg | I'm going to work on higher level tooling stuff for now | 00:49 |
| wolfspra1l | more inter-tile connections | 00:49 |
| wolfspra1l | auto-crc | 00:49 |
| azonenberg | and 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 tools | 00:49 |
| wolfspra1l | (maybe I can ask the chip to skip auto-crc checks for now) | 00:49 |
| wolfspra1l | that is fine, I continue and also very open about how far I am | 00:50 |
| wolfspra1l | at this point, the only bitstream I can generate is still "the empty bitstream" | 00:50 |
| wolfspra1l | :-) | 00:50 |
| wolfspra1l | I must have implemented the most inefficient way to generate an empty bitstream | 00:51 |
| wolfspra1l | there's about 100 switches in the routing switchbox that bug me right now | 00:53 |
| wolfspra1l | between the long (4-tile) wires | 00:53 |
| wolfspra1l | back to work... | 00:53 |
| kristianpaul | nice indeed :) | 01:07 |
| kristianpaul | cde: 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 mmu | 01:13 |
| lekernel | kristianpaul: that's the "recent reimplementation" I mentioned | 06:59 |
| GitHub111 | [migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/3b3e2f19eb21...2e14569b5c64 | 08:05 |
| GitHub111 | [migen/master] fhdl: list signals in execution order - Sebastien Bourdeauducq | 08:05 |
| GitHub111 | [migen/master] fhdl/verilog: sort clock domains by name - Sebastien Bourdeauducq | 08:05 |
| wpwrak | hellekin: welcome back ! indeed an extended world tour ;-) | 11:05 |
| wpwrak | hellekin: so you'll be here in time for the protest march (cacerolazo) on thursday :) | 11:06 |
| cde | wolfspra1l: https://github.com/sbourdeauducq/llhdl is 404 :( referenced from http://www.milkymist.org/fpgatools/ . is there a newer repo? | 11:18 |
| cde | I guess https://github.com/weidu/llhdl and https://github.com/weidu/antares | 11:26 |
| larsc | maybe lekernel deleted it | 11:29 |
| Fallenou | yes it has been deleted | 11:37 |
| lekernel | seems wolfspra1l and azonenberg are doing better tools anyway :) | 11:44 |
| cde | oh cool! are they currently on github? | 11:51 |
| Fallenou | yes | 11:51 |
| Fallenou | https://github.com/Wolfgang-Spraul/fpgatools | 11:51 |
| cde | thanks a lot | 11:51 |
| cde | btw I created my github account, https://github.com/rxos (currently empty) | 11:51 |
| cde | sadly, cde was already taken | 11:52 |
| cde | I thought fpgatools would support primarily xc6slx45, but it targets xc6slx9? | 11:53 |
| cde | well it shouldn't be very add to add support for bigger chips I guess ;) | 11:55 |
| Fallenou | it's xiangfu 's board which is using slx9 IIRC | 11:57 |
| Fallenou | a very very "simple" (meaning minimalist) board | 11:57 |
| Fallenou | http://en.qi-hardware.com/wiki/Mini-slx9 | 11:57 |
| cde | thanks. was there a particular requirement for the slx9 as opposed to using the M1 as a testbed? | 12:00 |
| cde | I guess you can experiment more wildly with it, in particular wrt/ I/O since it would cost less if destroyed | 12:01 |
| Fallenou | slx9 is much more "simple" than M1 | 12:02 |
| Fallenou | and fpga is smaller, simpler I guess | 12:02 |
| Fallenou | easier to do bitstream generation experiment on small fpga + small board | 12:02 |
| wolfspra1l | I 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 |
| wolfspra1l | and no, fpgatools is not much better today, also just experimental | 12:05 |
| wolfspra1l | but I will never delete it for sure, worst case there will be a note in the README in case it goes nowhere | 12:05 |
| wolfspra1l | it's pouring cats and dogs in beijing right now, so tomorrow the roads will be flooded - yay! :-) | 12:06 |
| wolfspra1l | cde: if you have questions about fpgatools, please let me know as I need to collect some to write the FAQ... | 12:09 |
| wolfspra1l | that would be very helpful - thanks! | 12:10 |
| lekernel | wolfspra1l: reconsidered your "no documentation - read the source" line? :) | 12:11 |
| wolfspra1l | yes, of course | 12:12 |
| wolfspra1l | that was just at the beginning | 12:12 |
| wolfspra1l | making the start easy is my real passion | 12:12 |
| wolfspra1l | if it's not easy to get started, it doesn't work | 12:12 |
| wolfspra1l | but nothing works today, so no need to waste time looking at it except to ask questions maybe... | 12:13 |
| cde | wolfspra1l: oh, it's not so though. the IRC channel is quite helpful :) I'll be sure to ask here if I have questions | 12:18 |
| cde | *tough | 12:19 |
| cde | what are the major blocking points in fpgatools today, that is areas that need assistance? | 12:22 |
| wolfspra1l | if you are a good C programmer, you can start playing with the code today | 12:25 |
| wolfspra1l | the next working items are more or less describe in the todo, as | 12:25 |
| wolfspra1l | more routing switches | 12:25 |
| wolfspra1l | more inter-tile connections | 12:25 |
| wolfspra1l | more iob and lut configurations | 12:25 |
| wolfspra1l | auto-crc | 12:25 |
| wolfspra1l | better autotester | 12:25 |
| wolfspra1l | all 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 so | 12:26 |
| wolfspra1l | that's the next milestone | 12:26 |
| wolfspra1l | after that is reached - fix loose ends everywhere, start with clocks, dcm/pll | 12:26 |
| wolfspra1l | and then simple reusable design elements | 12:27 |
| wolfspra1l | then support for larger xc6 chips, maybe something with a ftg256 or fgg484 packaging | 12:27 |
| cde | hmm 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 |
| wolfspra1l | I will definitely want to try it myself | 12:27 |
| wolfspra1l | and/or switch to the xc7a100 | 12:27 |
| wolfspra1l | that's all months out though, just describing the roadmap | 12:27 |
| wolfspra1l | no it won't "do", because there is a lot of work everywhere | 12:28 |
| wolfspra1l | like months full-time | 12:28 |
| wolfspra1l | you can join if you like but pretty much nothing works today or soon | 12:28 |
| lekernel | if that works, then it'll be better than DARPA-funded jbits :) | 12:28 |
| wolfspra1l | I will continue with the slx9 until at least let's say 10% of the features of that chip are really working well with fpgatools | 12:29 |
| wolfspra1l | better more | 12:29 |
| wolfspra1l | it makes no sense for me to jump to larger chips early on | 12:29 |
| wolfspra1l | only slows me down | 12:29 |
| wpwrak | and costs more money when you fry them :) | 12:29 |
| wolfspra1l | and the bigger ones don't come in qfp144 packaging, and and and | 12:30 |
| cde | how hard would it be to fry an fpga through incorrect configuration? | 12:30 |
| wolfspra1l | but even if the slx9 is working well, (well=10%), going to say the slx45 is at least another full-time month of work | 12:30 |
| wolfspra1l | the 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 |
| wolfspra1l | and that wont' just magically appear by changing an integer somewhere from '9' to '45' | 12:31 |
| wolfspra1l | probably relatively easy to fry one | 12:31 |
| wolfspra1l | but I shall have more real-world data on that soon | 12:32 |
| cde | you seem very pessimistic! don't be :D | 12:32 |
| wolfspra1l | I would think that if you configure the routing bits badly, electrical overload may flow in all sorts of directions | 12:32 |
| wolfspra1l | I'm an enternal optimist, but I try to describe this in the most realistic way | 12:32 |
| wolfspra1l | you are very welcome to come in and help | 12:32 |
| wolfspra1l | from a 10% working slx9 to a 10% working slx45 is 1+ months full-time work | 12:33 |
| wolfspra1l | that is a fact | 12:33 |
| wolfspra1l | not pessimistic or optimistic | 12:33 |
| wolfspra1l | it's developing nicely btw | 12:33 |
| wpwrak | wolfgang is an optimist - by expecting the worst, he hopes for pleasant surprises :) | 12:33 |
| wolfspra1l | I learned an enormous amount already | 12:33 |
| wolfspra1l | yes | 12:33 |
| wolfspra1l | you can join today | 12:33 |
| wolfspra1l | I think you mainly need 2 things to make a significant contribution: | 12:33 |
| wolfspra1l | 1) plenty of time | 12:33 |
| wolfspra1l | 2) good C programming skills | 12:34 |
| wolfspra1l | that's all | 12:34 |
| cde | well I'm currently on vacation, for only for the rest of week. after that I'll have much less free time | 12:34 |
| wolfspra1l | I can supply you with cheap slx9 testing boards if we make it there in the next weeks hopefully, at cost | 12:34 |
| wolfspra1l | there you go :-) | 12:35 |
| wolfspra1l | that's real life, perfectly fine | 12:35 |
| wolfspra1l | so just wait, and ping me once in a while :-) | 12:35 |
| Fallenou | 14:34 < wolfspra1l> you can join today < reminds me TV ads | 12:35 |
| cde | ok. I'll see what I can decipher of the source code in the meantime ;) | 12:35 |
| wolfspra1l | Fallenou: and look, the mmu fits as well | 12:35 |
| wolfspra1l | :-) | 12:36 |
| Fallenou | fits in what ? | 12:36 |
| wolfspra1l | I was playing on the TV ad | 12:36 |
| wolfspra1l | those knife ads | 12:36 |
| Fallenou | hehe | 12:36 |
| cde | I vaguely remember there is a working project for compiling bitstreams for the Spartan 3. or is my memory wrong? | 12:37 |
| wolfspra1l | sorry can't help | 12:39 |
| wolfspra1l | all I know is historic and I purged it from my mind | 12:39 |
| Fallenou | are you still drawning in paper sheets ? | 12:39 |
| wolfspra1l | getting better, more and more running in sw now :-) | 12:39 |
| Fallenou | hehe =) | 12:40 |
| wolfspra1l | routing now, more routing | 12:40 |
| wolfspra1l | there is so much routing in the chip | 12:40 |
| cde | hmm, has the infrared support been done? | 13:44 |
| lekernel | there's very basic support https://github.com/milkymist/milkymist/blob/master/cores/rc5/rtl/rc5.v | 13:46 |
| cde | ok. I was afraid my remote wasn't working ;) | 13:46 |
| cde | is there a repository for the datasheets for all ICs on the M1? | 16:44 |
| wpwrak | sort of. you can find links here: http://en.qi-hardware.com/wiki/Milkymist_One_RC3_BOM | 16:44 |
| cde | awesome! | 16:45 |
| cde | hmm the micro ddr is capable of running at 200 mhz, are we using it at that frequency? | 16:49 |
| cde | *micron | 16:49 |
| kristianpaul | i think ng uses no lekernel ? | 17:04 |
| kristianpaul | or at least 160mhz | 17:04 |
| lekernel | ng runs the ddr at 166MHz, ys | 17:08 |
| lekernel | 333Mbps per data pin | 17:09 |
| cde | that's twice the frequency of the cpu? what a wierd coincidence | 17:09 |
| cde | (or maybe not! ;) | 17:09 |
| lekernel | yes, I'm using a doubled and phase aligned clock | 17:09 |
| lekernel | phase alignment enables low-latency clock domain transfers | 17:10 |
| cde | btw 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 |
| lekernel | DQS 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 signal | 17:12 |
| lekernel | #1 of course encompasses the fact that the read latency becomes unpredictable, which adds to the difficulty of scheduling transfers | 17:14 |
| lekernel | I pity the Intel engineers :) | 17:14 |
| lekernel | cde: you need some phase alignment, and then sample the all data with sufficient setup/hold time. | 17:16 |
| lekernel | without phase alignment, you need double latching (sometimes included in a FIFO control system), which adds a lot of latency | 17:16 |
| cde | thanks | 17:17 |
| lekernel | and that latency varies, of course, depending on what phase the two clocks happen to have when data enters the FIFO | 17:17 |
| lekernel | in short - it's great that micron guarantees a tight clock-to-DQS skew for the parts we're using | 17:19 |
| cde | btw this document is interesting: http://www.latticesemi.com/lit/docs/generalinfo/memory_ddr_interface_wp.pdf | 17:20 |
| lekernel | I hope we can find DDR3 parts with similar specs for the M3... | 17:21 |
| lekernel | cde: http://www.fpga4fun.com/CrossClockDomain.html | 17:22 |
| lekernel | the point of phase alignment (and integer frequency ratios) is to avoid this technique, which adds latency and unpredictability | 17:24 |
| cde | doesn't the artix 7 have a built-in memory controller? that could be useful | 17:25 |
| lekernel | it has an undocumented "phaser", which handles some DQS- and read/write leveling-related gory details | 17:26 |
| lekernel | we 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 utilization | 17:26 |
| lekernel | and I hope to get rid of DQS problems in a similar way (still need to read some datasheets...) | 17:27 |
| cde | btw http://download.micron.com/pdf/technotes/ddr2/TN4723.pdf in case you haven't seen it | 17:27 |
| lekernel | ftp://ftp.macrogroup.ru/DigiEl/Xilinx/XLX_Seminar_NewElectronics/7series_Clocking_SelectIO_Tech_Module_Thomas_Klein.pdf | 17:28 |
| lekernel | scroll down for phaser info | 17:28 |
| cde | it looks like the phaser is primarily for meeting the very precise ddr2/3 timing requirements? other interfaces (hdmi, ...) will not require it | 17:33 |
| lekernel | hdmi data rates per pin are the same or higher than ddr2/3 | 17:56 |
| lekernel | the 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 |
| cde | lattice also has a DDR3 ip core, I guess it costs money like other vendors (and is not open-source) | 18:01 |
| lekernel | reading lattice paper p. 20 | 18:15 |
| lekernel | interesting way of transferring from DQS to system clock | 18:15 |
| lekernel | it actually avoids that annoying FIFO... | 18:15 |
| lekernel | not usable on xilinx arch though (I'd even bet someone patented this...) | 18:15 |
| lekernel | this scores another point for lattice. too bad their software is so horrible. | 18:16 |
| --- Wed Sep 12 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!