<GitHub75>
[milkymist/master] pfpuasm: auto-NOP, pass all regs, and some syntax corrections - Werner Almesberger
<GitHub75>
[milkymist/master] asm/pfpu: new option -v; cleanup - Werner Almesberger
<GitHub75>
[milkymist/master] asm/fpvm: fpvm-like execution engine - Werner Almesberger
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<azonenberg>
want to build an osre lbuejust codingc0dking dev/breakout boardsBut when i write code i d
<GitHub54>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/lC4njA
<GitHub54>
[scripts/master] compile-milkymist-firmware.sh: copy the rtems patches when there is a build - Xiangfu Liu
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0ae114.pool.mediaWays.net] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<cladamw>
( internal usb connection headers for usb ports) hi is there any done idea about this? seems I saw backlogs discussed.
<wolfspra1l>
yes, the latest is 2*5 100mil male header, no usb power switch needed, but usb transceivers needed as on current external ports
<cladamw>
related 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.
<wolfspra1l>
yes
<cladamw>
so I'm now going to keep edit sch for not edited parts of those features. then post here to review it.
<wolfspra1l>
yes
<cladamw>
I hope i can finish tomorrow then we maybe just fine re-arrange pins on J21 or else then.
<wolfspra1l>
yes
<wolfspra1l>
I doubt we can finish the entire schematics before your holiday next week, but we should try to get a draft out for review
<wolfspra1l>
but no rush please, when time is up it's up
<wolfspra1l>
a mistake now will cost us dearly later
<cladamw>
wpwrak, 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.
<cladamw>
yes, i hope a draft out firstly, that's the plan. ;-)
Artyom [Artyom!~chatzilla@h6.net58.bmstu.ru] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw_ [cladamw_!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<Artyom>
Hello 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...
<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.
<Artyom>
I used Digilent s3e500 board for my experiments because I bought this board couple of years ago and I could find working ports for it.
<Artyom>
After 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...
<Artyom>
...write documentation myself.
<Artyom>
Now 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=
<Artyom>
3521&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://www.adlinktech.com/PD/web/PD_
<Artyom>
detail.php?cKind=&pid=22&seq=&id=&sid= ) or even this one ( http://www.adlinktech.com/PD/web/PD_detail.php?cKind=&pid=838&seq=&id=&sid= ) . I don't know how popular their are, but the price of the last is 1700$ and milkymist board would seem a good alternative. I understand that there is number of pitfalls in making such a thing. So as I said now I'm faced with a choise: wheather to start...
<Artyom>
...developing such a project myself (and take as a base Milkymist board). Or may be I could help you to improve milkymist. I understand very wellthat making such an improvement is very difficult but I would start anyway.
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
lekernel [lekernel!~lekernel@g225038120.adsl.alicedsl.de] has joined #milkymist
<xiangfu>
Artyom, wow. this is an Email. :D
<Artyom>
Sorry... I just wanted to express all thoughts at one time ;)
<lekernel>
Artyom: ethernet is not fast enough?
<Artyom>
well, I have two projects in my mind: first one needs 16Mhz * 8bit transfer rate. Second 3channels * 56 MHz * 8bit.
<lekernel>
compress the data?
<Artyom>
And one more remark: I don't know easy way of guaranting reliable transfer through Ethernet. Of course we can neglect potential data losts, but USB 2.0 (and I think 3.0 also) guaranties it on the low level (not with the help of software).
<Artyom>
Compressing... That a good question. But I think that noise-like signals (like in GNSS) is difficult to compress with high rate
<lekernel>
USB doesn't guarantee anything except headaches
<lekernel>
if you have a short enough ethernet cable directly connected to a PC, the error rate is fairly low/negligible (and there's a CRC32 too)
<Artyom>
I've seen some discussions about compressing data from ADC but I don't remember any notes that it was realised.
<lekernel>
maybe move some of the processing into the FPGA?
<Artyom>
Well, I can agree that ethernet can be considered good alternative
<lekernel>
this will also reduce the CPU load on the PC
<Artyom>
But USB 3.0 seems a bit faster...
<Artyom>
then Gigabit ethernet
<lekernel>
ADC -> FPGA processing -> ethernet seems a lot better to me than ADC -> USB
<Artyom>
My task is to analyze signal. And any processing that can reduce transfer rate will "corrupt" the signal
<lekernel>
no, analyse the signal on the FPGA
<lekernel>
that's what those FPGAs are made for, not just act as a dumb ADC/USB bridge
<lekernel>
analyzing realtime at 1.3Gbps will likely put quite a load on your PC anyway
<lekernel>
what sort of signal do you analyze?
<lekernel>
and what for?
<Artyom>
Well, you are right when you know from the beggining "What to look for". But when you don't know exactly what to expect - then it's better to have all possible data. I'm interest in analyzing GNSS (GPS/COMPASS/GALILEO/COMPASS) signals.
<lekernel>
you have all possible data, only you process it on the FPGA not on the PC
<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)
<lekernel>
scilab won't process data realtime at 1.3Gbps
<Artyom>
I don't need real time ;) Just an ability to check different processing algorithms on a data snapshot
<lekernel>
then you can buffer data into the SDRAM and transfer it to the PC over 100MBps ethernet
<wolfspra1l>
Artyom: thanks a lot for writing this up above, always good to have fresh thoughts...
<Artyom>
Oh yes, this is the plan for the nearest future :)
<wolfspra1l>
the idea of sharing some existing midi/dmx/audio pins on the (future) expansion headers is new to me
<wolfspra1l>
not sure what the pros and cons are
Artyom [Artyom!~chatzilla@195.19.58.6] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak>
my 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.
<wpwrak>
regarding 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.
<wpwrak>
ah, he left already
<wpwrak>
wolfspra1l: 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 ;-)
<wolfspra1l>
I haven't gone back to it yet. no it's not a lot of trouble, but I'm multitasking
<wolfspra1l>
I would think that pressing the 'update' button still won't get me the latest stuff though...
<wpwrak>
i think our official updates don't happen very often
<wolfspra1l>
yes but that has to change, it's not just for me
<wpwrak>
it's not a very flexible mechanism anyway. e.g., if you run into a problem, how do you downgrade ?
<wolfspra1l>
updates need regression testing, and then 'downgrade' should be something that is rarely if ever needed
<wpwrak>
famous last words ;-)
<wpwrak>
particularly if you want to extend this for more experimental and more frequent releases
<wpwrak>
e.g., xiangfu's daily builds probably have all the goodies you want ... but the update system doesn't know about them
<wpwrak>
and there's of course no serious testing. so you'll run into regressions every now and then
<wpwrak>
also, we have known regressions with respect to the july release. so by a "zero regressions" logic, you couldn't have a proper release this month
<wpwrak>
either way, you end up with manual upgrades. which aren't that bad once you have jtag working
<wpwrak>
a 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.
<wpwrak>
e.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.
<wpwrak>
but of course, someone would have to implement such a flexible upgrade mechanism :)
<wolfspra1l>
yes yes. all agree. so the bottom line is we need more upgrade mechanisms, more flexible ones for different cases, better documented, etc.
<wolfspra1l>
to 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...
<wolfspra1l>
or I spend time fixing the Fedora issues
<wpwrak>
hmm, fixing urjtag sounds like a good idea in general ...
<wpwrak>
do we have a useful alternative manual upgrade mode, e.g., something via the bios ?
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wolfspra1l>
ftp :-)
<wolfspra1l>
I guess
<wpwrak>
well, there's "netboot" (in the BIOS). but that doesn't change FPGA
<lekernel>
wpwrak: yes, FTP - you can transfer the files, then select them in the GUI
<lekernel>
and it will flash like the web update
<xiangfu>
wpwrak, reflash_m1.sh support --daily-build. checkout the --help :)
<xiangfu>
it's --snapshot
<xiangfu>
also support --local-folder
<xiangfu>
just FYI.
<xiangfu>
it still not easy for end user
<xiangfu>
FTP and reflash_m1.sh can do the downgrade :D
<xiangfu>
wpwrak, after about 50 days. the build server success build milkymist firmware again. :) also I take your advice. revert the rtems back to 12-01. :)
<xiangfu>
wpwrak, I will try to create a wiki page about Milkymist One release test plan.
<wpwrak>
ah, via "Update from files". i see.
<xiangfu>
yes.
<wpwrak>
(rtems) heh ;-)
<xiangfu>
have to revert back to 12-01. make it compile fine.
<xiangfu>
maybe I try to revert the 'static' commit next time.
<xiangfu>
wpwrak, Hi. what I can help next? small task :D
<xiangfu>
wpwrak, the release job(test plan) needs a little more time to finish. :) good news is build server back to work again.
<xiangfu>
"Update from files" . some lines of 'm1nor' will be easier if there is a jtag connect. :) I like the m1nor. :)
<wpwrak>
(small task) hmm ... how about not losing the static network configuration when you enable DHCP ?
wolfspraul [wolfspraul!~wolfsprau@p5B0AD425.dip.t-dialin.net] has joined #milkymist
<wpwrak>
(m1nor) yeah. low-level = reliable :)
<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)
<xiangfu>
is that DHCP server problem? is you under different network mask etc.
<wpwrak>
it would be nice if it was merely hidden when you enable DHCP but if remembered came back when you disable it
<xiangfu>
oh. you mean if DHCP not success. then get back to static network.
<wpwrak>
i suppose it's also not stored in the system configuration, so that would need looking into as well
<xiangfu>
( remembered came back when you disable it) ok. got it. understand now.
<wpwrak>
a small detail, but surprisingly annoying when you hit it :)
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
<wpwrak>
another nice to have feature would be a fullscreen mode for the video preview
<xiangfu>
maybe when click the full screen mode. I just let it render this patch. yeah. :)
<wpwrak>
yeah, 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.
<wpwrak>
ah yes, you could just run the patch directly. why not ;-)
<xiangfu>
got it. I will take a look the full screen mode. try to make it just 'one click' :)
<xiangfu>
wpwrak, have to go. see you.
<wolfspraul>
I'm wondering why Artuom would want 50 or even 80 pins on his expansion board, what kind of use case needs that many?
<wolfspraul>
(unfortunately he logged out already, but should come back at some point...)
<wolfspraul>
Artyom
<wpwrak>
he wants trouble. picking up signals from all over the board should create an orgy of EMI issue :)
<lekernel>
+1
<wolfspraul>
his first thought was "I need *lots* of free ios" 50, or even 80
<wolfspraul>
some devel boards have that, that's why they are devel boards ;-)
<wolfspraul>
I am just curious to understand what for?
<wolfspraul>
what do you need 80 pins for? which use case?
<wolfspraul>
I told him that most likely with all the existing peripherals and fully functioning system, we don't even have 50-80 free pins
<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)
<wolfspraul>
for sure not
<wolfspraul>
to which he said he doesn't need audio/video/midi, so one could share those with the expansion system
<lekernel>
...creating a mess of routing and SI/EMI for us
<wolfspraul>
understood
<wolfspraul>
why would a cypress high (or super) speed USB chip need 80 pins?
<wpwrak>
and while we're building the universal computer, can I have Token Ring and an EISA slot too, please ? :)
<lekernel>
wolfspraul: because very high bandwidth requires high I/O count or very high frequency
<wolfspraul>
I think the reasons why we decide against this or in favor of that should be well documented
<wolfspraul>
which this channel is helpful for since it's logged
<wolfspraul>
and then people can also build upon that later, add or remove reasons, branch off, etc.
<lekernel>
I'm not surprised about such an I/O count for a superspeed usb chip
<wolfspraul>
so I always welcome someone coming forward saying that they have this or that *idea*
<wolfspraul>
so for now we say - pins on the expansion headers are not shared, for routing and emi reasons
<wolfspraul>
and 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 happen
<wolfspraul>
I mean pins on the expansion header
<lekernel>
yeah, there are already X&A devboards with e.g. FMC for the extremely few people who hack on modular FPGA systems
<lekernel>
and I've rarely seen one used btw
<wpwrak>
and good luck debugging signal integrity of super-speed usb :)
<lekernel>
except in private companies, academia and research facilities
<wpwrak>
except .. like everywhere ? :)
<lekernel>
yes, everywhere serious :-)
<wpwrak>
wolfspraul: yup. M1 tries to be flexible, but within reason.
* larsc
has such a board at work...
<kristianpaul>
fast ethernet yes ! ;)
<kristianpaul>
at least 100Mbit/s *g*
<kristianpaul>
like the usrpv1
<lekernel>
kristianpaul: I think I already told you that ethernet on M1 _is_ 100Mbps. it's only the software which is slow.
<lekernel>
and which I have no plan on improving since it's fast enough for OSC and such
<kristianpaul>
really, even with no DMA can we achieve such speed?
<lekernel>
so... feel free :)
<kristianpaul>
(plans) yeah, thats your slogan ;-)
<lekernel>
kristianpaul: 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. :)
<kristianpaul>
no plans for me
<kristianpaul>
i moved all processing to FPGA since noticed this bottle neck ;) was easier fast choice
<kristianpaul>
i dont want DMA, but as you said the current issues stop minimac2 achieved more speed is software
<kristianpaul>
i wanted to confirm what kind of software you mean :)
<kristianpaul>
ahh !!
<kristianpaul>
usrp uses a zpu,lol
<kristianpaul>
i need to check this in depth later
<lekernel>
which zpu?
<lekernel>
ah, the original vhdl one. could have been worse...
<wpwrak>
("_is_ 100Mbps") training for a job at marketing ? ;-)
<kristianpaul>
probably ;)
<wpwrak>
reminds 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.
<kristianpaul>
at least you get it lost..
<kristianpaul>
lol
<kristianpaul>
sorry :)
<wpwrak>
luckily, linux had very good traffic shaping support (cisco didn't), so we could slow down things sufficiently that the cisco could keep up
<kristianpaul>
keep up at what rate?
<lekernel>
cisco is building network hardware - the M1 isn't
<wpwrak>
of 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 ...
<lekernel>
so I fully stand behind the current ethernet solution :)
* kristianpaul
too
<lekernel>
and 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?
<wpwrak>
kristianpaul: (rate) 155 Mbps wire speed
<wpwrak>
lekernel: (cisco) yeah, we found that a little peculiar, too :)
<wpwrak>
btw, how would you implement atan2() (e.g., for "ang"), taylor/maclaurin series ?
<lekernel>
for "ang" I'd say pre-compute a table
<lekernel>
if we want the actual function... I don't really know. it's a tad complicated
<wpwrak>
yeah, lots of ifs
<lekernel>
yes
<lekernel>
hmm... and how convergent is that series?
<lekernel>
though we can simply spew out +/- pi/2 beyond a certain interval
<wpwrak>
(convergence) hmm, so-so. at x^5, you can still see a difference at the edges
<wpwrak>
thanks ! hmm, needs some contemplation ...
wolfspraul [wolfspraul!~wolfsprau@p5B0AD425.dip.t-dialin.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AD425.dip.t-dialin.net] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-hcaxhwuxpwffazab] has joined #milkymist
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
Artyom [Artyom!~chatzilla@84.23.62.191] has joined #milkymist
<Artyom>
Hello 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...
<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...
<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...
<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...
<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.
<kristianpaul>
for the usb experts around, how hard will be to implement usb bulk transfers in the M1?
<lekernel>
kristianpaul: try it and tell us
<wpwrak>
the hardest bit would probably be the CRC. for bulk sizes, you'll start to need it
<kristianpaul>
sure i can _try_ i just ask for a recomedation from who already tried usb world :)
<kristianpaul>
thanks wpwrak :)
<kristianpaul>
perhaps i still ASIC but recently i had seen projects like osmo-sdr using a SAM3U for getting sata sampled from adc
<kristianpaul>
wich is a bit refreshing since you can load custom firmware and have more control
<kristianpaul>
but dunno if you can get upto 480MBit/s
proppy [proppy!u1692@gateway/web/irccloud.com/x-ekqvmsudfgzvvhlb] has joined #milkymist
Artyom [Artyom!~chatzilla@84.23.62.191] has joined #milkymist
DJTachyon [DJTachyon!~Tachyon@ool-182eff46.dyn.optonline.net] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0ae114.pool.mediaWays.net] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<wolfspraul>
Artyom: ok now I understand how you come to those high pin counts - thanks!
roh [roh!~roh@yamato.hyte.de] has joined #milkymist