#milkymist IRC log for Monday, 2012-01-16

GitHub75[milkymist] wpwrak pushed 4 new commits to master: https://github.com/milkymist/milkymist/compare/6e3e917...6f346c301:05
GitHub75[milkymist/master] pfpuasm: auto-NOP, pass all regs, and some syntax corrections - Werner Almesberger01:05
GitHub75[milkymist/master] asm/pfpu: new option -v; cleanup - Werner Almesberger01:05
GitHub75[milkymist/master] asm/fpvm: fpvm-like execution engine - Werner Almesberger01:05
azonenbergwant to build an osre lbuejust codingc0dking dev/breakout boardsBut when i write code i d06:22
GitHub54[scripts] xiangfu pushed 1 new commit to master: http://git.io/lC4njA06:24
GitHub54[scripts/master] compile-milkymist-firmware.sh: copy the rtems patches when there is a build - Xiangfu Liu06:24
cladamw( internal usb connection headers for usb ports) hi is there any done idea about this? seems I saw backlogs discussed.08:33
wolfspra1lyes, the latest is 2*5 100mil male header, no usb power switch needed, but usb transceivers needed as on current external ports08:33
cladamwrelated this idea, I think that I'll give feedbacks how many available un-used fpga pins after I finished dvi-i single and new J21 female header and leds.08:36
wolfspra1lyes08:36
cladamwso I'm now going to keep edit sch for not edited parts of those features. then post here to review it.08:37
wolfspra1lyes08:38
cladamwI hope i can finish tomorrow then we maybe just fine re-arrange pins on J21 or else then.08:38
wolfspra1lyes08:39
wolfspra1lI doubt we can finish the entire schematics before your holiday next week, but we should try to get a draft out for review08:39
wolfspra1lbut no rush please, when time is up it's up08:39
wolfspra1la mistake now will cost us dearly later08:40
cladamwwpwrak, i think that I'll take two pictures about which those fpga pins I go for usb C/D ports and dvi-i ports then we think about if those fpga pins are okay firstly.08:40
cladamwyes, i hope a draft out firstly, that's the plan. ;-)08:41
ArtyomHello everyone :) My name is Artyom and I would like to tell my story of experimenting with MM SoC. I've heard about milkymist from kristianpaul. He is working on implementing GPS receiver in hardware and I do the same. Before MM SoC I experimented with FPGA + ARM7 (lpc2478). It worked fine but there was one problem. Correlator wich I try to use was designed to work with synchronous bus and...09:21
Artyom...I had to use async static memory interface in order to connect ARM with correlator. That is why experimenting with MM SoC (with it's synchronous wishbone bus) looked very attractive.09:21
ArtyomI used Digilent s3e500 board for my experiments because I bought this board couple of years ago and I could find working ports for it.09:21
ArtyomAfter two months I finally ported my previos work from ARM+FPGA to FPGA only. I liked the following features of MM SoC: good memory controller, ability to use GDB-debugger, ability to use gcc-compiler (I also used it for ARM). Among disadvantages is not-full-documentation (I had to search a lot among irc-logs + ask a lot of questions on irc). Of course that is understandable. I don't like to...09:21
Artyom...write documentation myself.09:21
ArtyomNow I'm faced with a choise. I have two active projects. First one is developing GPS/GLONASS receiver. And the second is to build a device capable of reliable streaming of data to PC (I need to transfer data from high speed ADC). For the first project I could use milkymist board. But for the second it's difficult. If milkymist would have a cypress USB super speed chip ( http://www.cypress.com/?id=09:21
Artyom3521&source=header ) and expansion connector for many pins (at least 50, but better 80 - 100 like on the Digilent board). If there is no free pins in FPGA may be it is possible to share some pins with other chips (like it is done in Digilent board). For example not everyone need video/sound/midi/... With such additions milkymist could compete with this device ( http[09:58] <Artyom> Well, I must say that I didn't try to think about this task this way... May be this can be a key ;) I need some time to think about such solution... I just got used to PC with mathmatical packages like scilab and all thier functions (ffts, graphs and so on)09:21
lekernelscilab won't process data realtime at 1.3Gbps09:58
ArtyomI don't need real time ;) Just an ability to check different processing algorithms on a data snapshot10:00
lekernelthen you can buffer data into the SDRAM and transfer it to the PC over 100MBps ethernet10:00
wolfspra1lArtyom: thanks a lot for writing this up above, always good to have fresh thoughts...10:01
ArtyomOh yes, this is the plan for the nearest future :)10:01
wolfspra1lthe idea of sharing some existing midi/dmx/audio pins on the (future) expansion headers is new to me10:01
wolfspra1lnot sure what the pros and cons are10:02
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01162012-0937/10:24
wpwrakmy vote would also go to doing as much of the processing close to the source. high-bandwidth and timing critical streams from acquisition devices to PCs tend to be a headache.11:11
wpwrakregarding assured delivery, USB is no better than, say, TCP. if the BER goes up, both exhibit unfriendly properties. TCP hardly ever gives up but you have no way of telling how late your data will be. USB will just drop the link of there are too many retransmissions.11:17
wpwrakah, he left already11:18
wpwrakwolfspra1l: btw, how are your usb-midi adventures going ? it seems that it's more time-consuming to upgrade than it was to implement the stuff in the first place ;-)11:19
wolfspra1lI haven't gone back to it yet. no it's not a lot of trouble, but I'm multitasking11:29
wolfspra1lI would think that pressing the 'update' button still won't get me the latest stuff though...11:29
wpwraki think our official updates don't happen very often11:30
wolfspra1lyes but that has to change, it's not just for me11:31
wpwrakit's not a very flexible mechanism anyway. e.g., if you run into a problem, how do you downgrade ?11:31
wolfspra1lupdates need regression testing, and then 'downgrade' should be something that is rarely if ever needed11:32
wpwrakfamous last words ;-)11:33
wpwrakparticularly if you want to extend this for more experimental and more frequent releases11:33
wpwrake.g., xiangfu's daily builds probably have all the goodies you want ... but the update system doesn't know about them11:34
wpwrakand there's of course no serious testing. so you'll run into regressions every now and then11:34
wpwrakalso, we have known regressions with respect to the july release. so by a "zero regressions" logic, you couldn't have a proper release this month11:35
wpwrakeither way, you end up with manual upgrades. which aren't that bad once you have jtag working11:36
wpwraka more flexible upgrade mechanism would let you choose among versions. also between "official releases" and experimental builds. the latter could be, say, xiangfu's daily builds, or perhaps some topical snapshots.11:42
wpwrake.g., a version that has usb-midi as a new feature but may have issues in other areas. by getting the thing out to people also the debugging should be quicker.11:43
wpwrakbut of course, someone would have to implement such a flexible upgrade mechanism :)11:43
wolfspra1lyes yes. all agree. so the bottom line is we need more upgrade mechanisms, more flexible ones for different cases, better documented, etc.11:58
wolfspra1lto circumvent my jtag problems on fedora, I was planning to boot Debian from a usb stick. the usb stick is right here, but I haven't installed it yet...11:59
wolfspra1lor I spend time fixing the Fedora issues11:59
wpwrakhmm, fixing urjtag sounds like a good idea in general ...12:01
wpwrakdo we have a useful alternative manual upgrade mode, e.g., something via the bios ?12:02
wolfspra1lftp :-)12:15
wolfspra1lI guess12:15
wpwrakwell, there's "netboot" (in the BIOS). but that doesn't change FPGA12:19
lekernelwpwrak: yes, FTP - you can transfer the files, then select them in the GUI12:31
lekerneland it will flash like the web update12:32
xiangfuwpwrak, reflash_m1.sh support --daily-build. checkout the --help :)12:34
xiangfuit's --snapshot12:34
xiangfualso support --local-folder12:34
xiangfujust FYI.12:35
xiangfuit still not easy for end user12:35
xiangfuFTP and reflash_m1.sh can do the downgrade :D12:37
xiangfuwpwrak, after about 50 days. the build server success build milkymist firmware again. :) also I take your advice. revert the rtems back to 12-01. :)12:42
xiangfuwpwrak, I will try to create a wiki page about Milkymist One release test plan.12:43
wpwrakah, via "Update from files". i see.12:47
xiangfuyes.12:47
wpwrak(rtems) heh ;-)12:47
xiangfuhave to revert back to 12-01. make it compile fine.12:48
xiangfumaybe I try to revert the 'static' commit next time.12:48
xiangfuwiki page just start: http://en.qi-hardware.com/wiki/Milkymist_One_Firmware will write more detail tomorrow. tired today. :(12:49
xiangfuwpwrak, Hi. what I can help next? small task :D12:52
xiangfuwpwrak, the release job(test plan) needs a little more time to finish. :) good news is build server back to work again.12:54
xiangfu"Update from files" . some lines of 'm1nor' will be easier if there is a jtag connect. :) I like the m1nor. :)12:56
wpwrak(small task) hmm ... how about not losing the static network configuration when you enable DHCP ?12:56
wpwrak(m1nor) yeah. low-level = reliable :)12:57
wpwrak(network config) e.g., if you click by accident on enable DHCP and then disable it again, your status network config is lost (except for the DNS)12:57
xiangfuis that DHCP server problem?  is you under different network mask etc.12:58
wpwrakit would be nice if it was merely hidden when you enable DHCP but if remembered came back when you disable it12:58
xiangfuoh. you mean if DHCP not success. then get back to static network.12:58
wpwraki suppose it's also not stored in the system configuration, so that would need looking into as well12:58
xiangfu( remembered came back when you disable it) ok. got it. understand now.12:58
wpwraka small detail, but surprisingly annoying when you hit it :)12:59
wpwrakanother nice to have feature would be a fullscreen mode for the video preview13:00
xiangfuwpwrak, oh. there is a patch for it.13:01
xiangfu'Lekernel - FullScreen Video-in Preview.fnp'13:01
xiangfumaybe when click the full screen mode. I just let it render this patch. yeah. :)13:01
wpwrakyeah, but that's awkward. exit video in dialog, select Start, click on Go, decide to change a parameter, so back to GUI, enter video in dialog, etc.13:02
wpwrakah yes, you could just run the patch directly. why not ;-)13:02
xiangfugot it. I will take a look the full screen mode. try to make it just 'one click' :)13:03
xiangfuwpwrak, have to go. see you.13:03
wolfspraulI'm wondering why Artuom would want 50 or even 80 pins on his expansion board, what kind of use case needs that many?13:17
wolfspraul(unfortunately he logged out already, but should come back at some point...)13:18
wolfspraulArtyom13:18
wpwrakhe wants trouble. picking up signals from all over the board should create an orgy of EMI issue :)13:20
lekernel+113:24
wolfspraulhis first thought was "I need *lots* of free ios" 50, or even 8013:32
wolfspraulsome devel boards have that, that's why they are devel boards ;-)13:32
wolfspraulI am just curious to understand what for?13:32
wolfspraulwhat do you need 80 pins for? which use case?13:32
wolfspraulI told him that most likely with all the existing peripherals and fully functioning system, we don't even have 50-80 free pins13:33
lekernel...to run a cypress high speed USB chip, which has 90% probability of never happening, and which is most likely a bad solution anyway (a better one would be to use the FPGA for DSP)13:33
wolfspraulfor sure not13:33
wolfspraulto which he said he doesn't need audio/video/midi, so one could share those with the expansion system13:33
lekernel...creating a mess of routing and SI/EMI for us13:34
wolfspraulunderstood13:34
wolfspraulwhy would a cypress high (or super) speed USB chip need 80 pins?13:35
wpwrakand while we're building the universal computer, can I have Token Ring and an EISA slot too, please ? :)13:36
lekernelwolfspraul: because very high bandwidth requires high I/O count or very high frequency13:36
wolfspraulI think the reasons why we decide against this or in favor of that should be well documented13:36
wolfspraulwhich this channel is helpful for since it's logged13:37
wolfsprauland then people can also build upon that later, add or remove reasons, branch off, etc.13:37
lekernelI'm not surprised about such an I/O count for a superspeed usb chip13:37
wolfspraulso I always welcome someone coming forward saying that they have this or that *idea*13:37
wolfspraulso for now we say - pins on the expansion headers are not shared, for routing and emi reasons13:38
wolfsprauland we don't have xxx (large number) of pins because m1 is not an ultra-flexible devel board, and we rather target specific smaller use cases, but actually make them happen, rather than preparing for the ultimate expansion that will not happen13:39
wolfspraulI mean pins on the expansion header13:39
lekernelyeah, there are already X&A devboards with e.g. FMC for the extremely few people who hack on modular FPGA systems13:40
lekerneland I've rarely seen one used btw13:41
wpwrakand good luck debugging signal integrity of super-speed usb :)13:41
lekernelexcept in private companies, academia and research facilities13:41
wpwrakexcept .. like everywhere ? :)13:42
lekernelyes, everywhere serious :-)13:42
wpwrakwolfspraul: yup. M1 tries to be flexible, but within reason.13:42
Action: larsc has such a board at work...13:56
kristianpaulfast ethernet yes ! ;)14:45
kristianpaulat least 100Mbit/s *g*14:46
kristianpaullike the usrpv114:46
lekernelkristianpaul: I think I already told you that ethernet on M1 _is_ 100Mbps. it's only the software which is slow.14:51
lekerneland which I have no plan on improving since it's fast enough for OSC and such14:52
kristianpaulreally, even with no DMA can we achieve such speed?14:52
lekernelso... feel free :)14:52
kristianpaul(plans) yeah, thats your slogan ;-)14:52
lekernelkristianpaul: you want DMA? then write some verilog and update the RTEMS driver. if it's technically good enough, there's no reason I'll refuse the patch. :)14:55
kristianpaulno plans for me14:55
kristianpauli moved all processing to FPGA since noticed this bottle neck ;) was easier fast choice14:55
kristianpauli dont want DMA, but as you said the current issues stop minimac2 achieved more speed is software14:56
kristianpauli wanted to confirm what kind of software you mean :)14:57
kristianpaulahh !!14:59
kristianpaulusrp uses a zpu,lol14:59
kristianpauli need to check this in depth later14:59
lekernelwhich zpu?15:02
lekernelah, the original vhdl one. could have been worse...15:03
wpwrak("_is_ 100Mbps") training for a job at marketing ? ;-)15:04
kristianpaulprobably ;)15:05
wpwrakreminds me of an ATM switch from cisco. they proudly stated it did 155 Mbps (one of the standard rates). and indeed, the PHY ran at that speed. unfortunately, if you actually sent data that fast, you got 100% packet loss.15:05
kristianpaulat least you get it lost..15:06
kristianpaullol15:06
kristianpaulsorry :)15:06
wpwrakluckily, linux had very good traffic shaping support (cisco didn't), so we could slow down things sufficiently that the cisco could keep up15:06
kristianpaulkeep up at what rate?15:07
lekernelcisco is building network hardware - the M1 isn't15:08
wpwrakof course, the problems didn't stop there. ATM also has signaling (basically to "dial" a call). at some point, i had to add an option to the linux signaling stack that enabled bug compatibility with cisco ...15:08
lekernelso I fully stand behind the current ethernet solution :)15:08
Action: kristianpaul too15:08
lekerneland if people with some special needs want more speed, they can just modify the FPGA design and software to implement it themselves. isn't that the point of OSHW?15:09
wpwrakkristianpaul: (rate) 155 Mbps wire speed15:10
wpwraklekernel: (cisco) yeah, we found that a little peculiar, too :)15:10
wpwrakbtw, how would you implement atan2() (e.g., for "ang"), taylor/maclaurin series ?15:14
lekernelfor "ang" I'd say pre-compute a table15:15
lekernelif we want the actual function... I don't really know. it's a tad complicated15:16
wpwrakyeah, lots of ifs15:16
lekernelyes15:17
lekernelhmm... and how convergent is that series?15:17
lekernelthough we can simply spew out +/- pi/2 beyond a certain interval15:19
wpwrak(convergence) hmm, so-so. at x^5, you can still see a difference at the edges15:20
lekernelhttp://www.wolframalpha.com/input/?i=x-x%5E3%2F3%2Bx%5E5%2F5-x%5E7%2F7%2Bx%5E9%2F9%2C+atan%28x%2915:20
wpwrakgnuplot: plot atan(x), x-x**3/3+x**5/5-x**7/7+x**9/915:20
wpwrakto ^9: |error| = 0.0515:24
wpwrakto ^7, 0.06; to ^5, 0.08, to ^3, 0.12, to ^1, 0.22 (all in the range x = [-1, 1])15:26
wpwrak0.8*x also has a peak error of about 0.06 ;-)15:27
lekernelwhat's the range we actually need for ang anyway?15:28
wpwrakthe arctan argument (y/x) would be pretty much from -\infty to +\infty, the full range15:29
wpwrakthe atan2 arguments would be better behaved. but i'm not sure if this helps much15:30
lekernelyes, but we're only interested about the values on the grid15:30
lekernelthough it doesn't make much of a difference, in fact15:30
wpwrakyes. how are the vertices iterated ?15:31
lekernels/about/in15:31
lekernelfor(x=0:xmax) { for(y=0:xmax) {...}}15:31
lekernelymax15:32
wpwrakwhere is that loop ?15:32
lekernelin the hardware15:32
wpwrakwhere ? :)15:32
lekernelhttps://github.com/milkymist/milkymist/blob/master/cores/pfpu/rtl/pfpu_addrgen.v15:33
lekerneland used here: https://github.com/milkymist/milkymist/blob/master/cores/pfpu/rtl/pfpu.v#L13415:34
wpwrakthanks ! hmm, needs some contemplation ...15:46
ArtyomHello once again. I've seen a little discusion of my proposal. And I want to say a "last word" about this topic. First of all I played a little with FX2 chip (it's high speed USB chip). It was rather simple to use it for streaming data to PC. Almost all simple GPS front-ends use it (NSL's PRIMO, GPS1ASampler, SiGe's GN3S). I also used it for the same task. The problem that I faced was a lack...18:30
Artyom...of transfer-control. There is simple interface between FX2 chip and FPGA. I used the simplest version without any control. But potentially FX2 can help to make reliable transfer. There are some flag-signals that can be used to determine time when transfer should be paused and when it should be continued. The problem is that during pauses data must be stored somewhere. The solution is to...18:30
Artyom...use a big SDRAM-based FIFO. And this is the field where I would like to use MM SoC (memory controller + FIFO). This task seems to me similar to VGA output + TMU-module. There is board that can be used for testing FX2 + MM SoC ( http://www.ztex.de/usb-fpga-1/usb-fpga-1.11.e.html ). But there are no boards that use FX3 (USB super speed chip) + FPGA. As FX3 is a very new chip. There was also...18:30
Artyom...discussion of high-count-pin connector. As I have mentioned for my tasks I need a 3 channels for high speed ADC. I roughly consider that each channel will require 16 bits/lines. 3*16=48 (in fact 30 would be fine). And half of them should be ground lines for EMI purposes (seems so to me after studing some forums but I'm not an expert in this field and any suggestions are welcomed). As I...18:30
Artyom...understand PC PATA interface works on frequencies up to 133 MHz - that can be considered top-solution. I need for my task less then a half speed (58 MHz). I think that on frequencies about 50 MHz EMI questions are not too difficult.18:30
kristianpaulfor the usb experts around, how hard will be to implement usb bulk transfers in the M1?18:41
lekernelkristianpaul: try it and tell us18:44
wpwrakthe hardest bit would probably be the CRC. for bulk sizes, you'll start to need it18:44
kristianpaulsure i can _try_ i just ask for a recomedation from who already tried usb world :)18:45
kristianpaulthanks wpwrak :)18:45
kristianpaulperhaps i still ASIC but recently i had seen projects like osmo-sdr using a SAM3U for getting sata sampled from adc18:53
kristianpaulwich is a bit refreshing since you can load custom firmware and have more control18:54
kristianpaulbut dunno if you can get upto 480MBit/s18:55
wolfspraulArtyom: ok now I understand how you come to those high pin counts - thanks!19:47
GitHub163[migen] sbourdeauducq created newnamer (+4 new commits): https://github.com/milkymist/migen/compare/ab8e08a^...a1043d120:31
GitHub163[migen/newnamer] fhdl: new naming system (broken) - Sebastien Bourdeauducq20:31
GitHub163[migen/newnamer] New naming system beginning to work - Sebastien Bourdeauducq20:31
GitHub163[migen/newnamer] corelogic/record: empty default name - Sebastien Bourdeauducq20:31
kristianpaulwolfspraul: how is your fedora 16 jtag bug hunting?21:49
kristianpaulujtag*21:49
wolfspraulnot working on it21:54
wolfspraulkristianpaul: do you think it's a difficult problem/21:55
wolfspraul?21:55
kristianpaulso how flashed the M1?21:55
kristianpaulor..21:55
wolfspraulused an old debian machine, and when i don't have that anymore I'll boot from a debian usb stick21:55
kristianpauldunno, but i have a bug open about it...21:55
kristianpaulhe :)21:55
kristianpauldear debian21:55
wolfspraulyeah, sometimes have to favor speed, cannot fix everything21:55
kristianpaulfix, yeah21:56
larscwpwrak: hard as in hard to implement or computational heavy?22:15
wpwraklarsc: hard to implement, from this rookie's point of view. LSRs (for CRCs) are rather efficient.22:41
--- Tue Jan 17 201200:00

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