Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak> and here we are with the front side: http://downloads.qi-hardware.com/people/werner/tmp/collage-front.jpg
<wpwrak> i didn't add any red LED around the buttons because the green LEDs make it hard to see. best case, it would just be a sea of yellow light
<wolfspraul> can the leds increase radiation emissions?
<wpwrak> you mean EMI ? if you run the PWM very fast ....
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<wpwrak> i switched them at 1 kHz. not sure how fast the edges would be.
<wpwrak> worst case, we could add some caps to the matrix, e.g., after the current-limiting Rs
<wolfspraul> looking at collage-front - ok
<wolfspraul> no comment other than I don't like more than 1 color
<wolfspraul> looks like a cheap xmas tree
<wpwrak> at least one green LED will relocate anyway :)
<wolfspraul> do you want multiple colors?
<wpwrak> oh, it can become red. no problem with that.
<wpwrak> ah, interesting. they replaced the laser pointer in the rii keyboard with an universal IR remote. smart move, though cat lovers may be disappointed.
<wpwrak> URL update: all the LED-related stuff is now in http://downloads.qi-hardware.com/people/werner/m1/leds/ (a and not my general dumping ground, .../werner/tmp/)
<wolfspraul> I think there are many variants of this idea
<wolfspraul> many vendors
<wolfspraul> I am working on this and will zoom in after cny
<wolfspraul> will take a few weeks though, contacting vendors, getting samples, etc.
<wolfspraul> there are most likely more
<wolfspraul> so that's good, I think we will zoom in on a vendor that is willing to work with a tiny customer like us, and sell us keyboards at a good price and with the specs we want (though it is in our own interest to pick an existing high-volume model)
<wolfspraul> do we need infrared as well?
<wolfspraul> I though if we have keyboard + mouse that's perfect (with USB dongle)
<wolfspraul> also backlight, I think very important
<wpwrak> the thing just seems to come with an extra. either laser pointer (old) or new IR remote.
<wpwrak> well, perhaps not all of them. this looks a little different: http://www.antertom.com/english/ShowProducts.asp?id=113
<wpwrak> and no, i don't think we need IR or laser :)
<wolfspraul> with those factories, you can get exactly what you want
<wolfspraul> they can change *everything*
<wolfspraul> the problem is volume, cost, etc.
<wolfspraul> on such an accessory, I want to go with the flow
<wolfspraul> I don't even want them to print "milkymist" on the thing, though it's tempting
<wolfspraul> so the website only serves as an indicator or what they have or might have
<wolfspraul> "something like that"
<wolfspraul> :-)
<wolfspraul> rest needs to be found out talking to their sales staff
<wpwrak> kewl. maybe we should define a special unique milkymist color and have it with a milkymist-colored laser pointer ;-)))
<wolfspraul> I am quite serious in switching to this
<wolfspraul> remove silicone keyboard and remote control, and switch to this
<wolfspraul> we should have done it in the first place, but didn't register with me somehow
<wpwrak> it looks good to me. unlike the keyboard, it's more than just an alibi accessory
<wolfspraul> but whatever, then we do it now and improve and done
<wolfspraul> it's all work
<wolfspraul> I can only do so much each day
<wolfspraul> now this is on
<wolfspraul> it's a lot of work still
<wolfspraul> big difference between idea, and actually having them in the box, and working well...
<wolfspraul> so we see
<wolfspraul> it's early now, I couldn't do anything on this before cny, it starts after cny
<wolfspraul> though xiangfu does have a similar keyboard now, sourced randomly from taobao (like ebay)
<wpwrak> you may be able to find it in .de, too
<wpwrak> (easily)
<wpwrak> but of course, there's no rush
<wolfspraul> oh of course I can buy them everywhere
<wolfspraul> but that's not a connection we can use for sourcing into the box
<wolfspraul> first of all the price
<wolfspraul> it's going to be twice as much at least
<wpwrak> sure. i mean to get a feeling for how it works
<wolfspraul> ah yes
<wolfspraul> but I am so loaded, I wait until i'm back in china in a few days
<wpwrak> ;-))
<wolfspraul> how do you like those upright types with a notebook-like touchpad above the keyboard?
<wpwrak> picture ?
<wolfspraul> (on the unisen site)
<wolfspraul> here are some http://www.ipazzport.com/wireless.html
<wolfspraul> (those seem to be unisen products because linked from there)
<wpwrak> that could also be interesting. maybe less likely to tap by accident
<wolfspraul> yeah ok, I will find out more after cny. common models, prices, etc.
<wpwrak> you'll have fun :)
<wolfspraul> then testing, bugfixing, moving hotkeys so they are easy and make sense on the chosen kbd, ship to Taipei, include in box
<wolfspraul> easy 15 steps
<wolfspraul> calling it a day, n8
<wpwrak> ah yes, the hotkeys. right now, pretty much all of them are where i can't reach them.
<wolfspraul> sure
<wolfspraul> it will be quite some work, but when we are done, the m1 experience will be so much better
<wpwrak> sweet dreams of gazillions of keybaord designs !:)
<wolfspraul> yeah
<wpwrak> yeah :)
<wolfspraul> you bet
<wolfspraul> I visited a large keyboard maker once, very impressive visit
<wolfspraul> I had no idea...
<wolfspraul> that factory I visited makes 4-5 million keyboards / month
<wolfspraul> only large ones (notebook/desktop)
<wolfspraul> smaller keyboards are made in even crazier volumes
<wpwrak> phew
<wolfspraul> yeah. 6000 workers.
<wolfspraul> they even have clean rooms up to class 1000
<wolfspraul> they have giant machines in sizes that made me think they are preparing for a moon landing or so
<wpwrak> maybe the keyboards are just a front ? :)
<wolfspraul> :-)
<wolfspraul> keyboards are very work intensive
<wolfspraul> and there are a huge number of varieties and details
<wolfspraul> you would never believe me unless you visited one of those monster factories
<wolfspraul> anyway
<wolfspraul> we just want to source some tiny amount, nothing really
<wolfspraul> a rounding error
<wpwrak> indeed :)
<wpwrak> part of a flyspeck
cwoodall [cwoodall!~cwoodall@comm575-0301-dhcp011.bu.edu] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
cwoodall [cwoodall!~cwoodall@comm575-0301-dhcp011.bu.edu] has joined #milkymist
<cwoodall> Hello, I was told to come around these parts to talk about an MMU
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
Technicus [Technicus!~Technicus@adsl-99-156-210-28.dsl.applwi.sbcglobal.net] has joined #milkymist
<wolfspraul> chris again :-)
<wpwrak> unfortunately, a bit too quick
<wpwrak> ah, another advantage of having those LEDs: improving their control would make a nice HDL beginner's project
<wpwrak> quite a bit less intimidating than an MMU :)
<wpwrak> and there are countless ways how you can tweak LEDs in more interesting ways
<wolfspraul> ah yes I wanted to ask that - how much control do we have over them?
<wolfspraul> if they are really all at the bottom of the pcb, can someone make something like a wave going around the board?
kill_me2 [kill_me2!~km2@99-7-110-97.lightspeed.lsanca.sbcglobal.net] has joined #milkymist
<wolfspraul> or something like Knight Rider's KITT car? http://www.youtube.com/watch?v=Mo8Qls0HnWo
<wolfspraul> (the lights at the front of the car)
<wpwrak> (knight rider) remember ben-blinkenlights ? ;-)
<wpwrak> you could do pretty much anything you want ... but the density of LEDs will be a bit low for many effects
<wolfspraul> I hope nobody tries to wave the m1 that explosively...
<wolfspraul> yes sure [density]
<wolfspraul> but the control would allow us to drive them all independently and at the same time?
<wpwrak> there should be a bit of SoC that implements a controller that takes care of the low-level details, yes
<wpwrak> such as: walking the matrix, varying the duty cycle, etc.
<wpwrak> for a proof of concept, we'd just need to walk the matrix. so that's one bit of control per LED
<wpwrak> for fancy effects, you'd have more controls. whatever you can dream up :)
<wpwrak> e.g., maybe per-LED duty cycle, LED mode (off, on, pulse on when kicked, pulse off when kicked, ramp on/off, etc.)
<wpwrak> kick = some register/signal that indicates activity
lekernel [lekernel!~lekernel@f052070192.adsl.alicedsl.de] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0af487.pool.mediaWays.net] has joined #milkymist
<GitHub114> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/L0cVpg
<GitHub114> [milkymist-ng/master] Use meaningful class names - Sebastien Bourdeauducq
<lekernel> most signal names are autogenerated with the new python introspection hacks
<wpwrak> looks nice and tidy :) some constructs are non-intuitive, though. e.g., the structure of things in wishbone.InterconnectShared, or what verilog.convert does.
<wpwrak> but i guess alot of that stuff is ultimately a documentation issue
<wpwrak> and maybe some of the procedural stuff for code generation can be hidden later
wolfspra1l [wolfspra1l!~wolfsprau@p5B0ABF11.dip.t-dialin.net] has joined #milkymist
<kristianpaul> cheap xmas tree indeed ;)
<lekernel> kristianpaul: you should start using migen for your gps stuff. no more manual modifications of wb_conbus ...
<kristianpaul> lekernel: yeah sure, i'll update your migen repo and look for a example
<kristianpaul> milkymist-ng**
<lekernel> atm it runs the beginning of libhpdmc
<lekernel> ie you get a banner
<lekernel> then there's no UART RX (maybe you could help? simply port the existing code to migen...) and no sdram
<kristianpaul> yeah i noticed that, why you dont use the old uart anyway?
<lekernel> because we have a new generic system for generating CSR banks and interrupt/event controllers, rather than hand-code it in the UART and every other core
<kristianpaul> hmm yup
<lekernel> but yes, the lazy-lazy approach is to use instance encapsulation (like I did for lm32)
<wpwrak> aka backward-compatibility ? :)
<kristianpaul> yay ;)
<wpwrak> i'd consider that a feature. allows for incremental deployment, etc.
<lekernel> it'll make sense for more complex code, but uart is 100 lines
<wpwrak> ok :)
<lekernel> and by the way, there's no backward compatibility for the -ng soc, except for the lm32 instruction set
<kristianpaul> avoiding to write/fork a new cpu? ;)
<lekernel> why? lm32 is fine
<kristianpaul> sure ;)
<kristianpaul> so you plan rewrite sdram controller too, tmu?
<lekernel> and everyone's writing (often shitty) softcore CPUs anyway ...
<lekernel> yes, sdram controller and TMU will be fundamentally redesigned
<kristianpaul> btw fast memory link will too i guess?
<lekernel> yes, new OOO bus
* kristianpaul looks for its python book
<kristianpaul> btw is icarus happy with the verilog code generated by migen?
<lekernel> yes
<kristianpaul> phew
<lekernel> why shouldn't it?
<wpwrak> (no compatibility) so yet another round of register address, interrupts, etc., reassignments ?
<lekernel> yes
<wpwrak> phew
<lekernel> the CSR address space is saturated anyway
<kristianpaul> oh yes :)
<wpwrak> so you extended it ?
<lekernel> yes
<kristianpaul> finally 1 bit? was it?
<wpwrak> good then. we'll need room for all the LED controls ;-)))
<kristianpaul> shouldn dunno, well lm32 still not last time i tried..
<lekernel> and we'll have level-sensitive interrupts everywhere (you asked for it for linux, now you'll get it)
<wpwrak> i don't mind having level-sensitive interrupts :)
<kristianpaul> how a mmu could fir in -ng, it will be just another core? or migen could provide some aid to write it?
<lekernel> the MMU needs to be integrated into the LM32 pipeline, which is pretty much independent of migen
<kristianpaul> ah so this fork lm32 anyway, interesting
<kristianpaul> i guess you discussed this before, but put stuff inside that pipeline is not make things slower?
<wpwrak> i don't think an MMU would have to "fork" lm32. but it's surely an invasive internal change (mainly to the cache, of course)
<kristianpaul> invasive indeed
<kristianpaul> ah ok
<kristianpaul> but cache is part of pipeline? now i'm cofused :)
<lekernel> yes, the cache is part of the pipeline
* wpwrak wonders if there's a good primer on physically tagged virtual caches. i have a boot that explains caches rather nicely but that's not really suitable as a reference here
<wpwrak> s/boot/book/ # grmbl
<kristianpaul> boot the book !
<wpwrak> "unix systems for modern architectures" by curt schimmel. from 1994. YMMV. (your "modern" may vary)
<lekernel> now there's the interesting possibility of using dataflow to build a CPU, but that would need support for speculation
<wpwrak> of course, there probably haven't been too many changes to the state of the art since then
<GitHub30> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/b15eae3081558c2c8332f796e45b18b2b4f531de
<GitHub30> [migen/master] Logo - Sebastien Bourdeauducq
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
cjdavis1 [cjdavis1!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
lekernel_ [lekernel_!~lekernel@g225044059.adsl.alicedsl.de] has joined #milkymist
<sh4rm4> !addquote * kristianpaul looks for its python book
<lekernel> !quote
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<larsc> hm, he always quits when i'm about to ask something
lekernel [lekernel!~lekernel@g225044059.adsl.alicedsl.de] has joined #milkymist
<larsc> lekernel: i'm curently trying to understand the migen flow stuf
<larsc> so an actor does something. it has 0 to many inputs and zero to many outputs. an input has a data-in and a data-accept signal and and output has an data-out and a data-ready signal
<larsc> the data-output signal is a normaly a register
<lekernel> no, the data-out can have combinatorial logic too
<lekernel> it just depends how the control signals are driven by the actor
<larsc> but you have to have a register somewhere in the actor
<lekernel> btw - the control signaling is the same as the TMU which is explained in my thesis, except that stb-to-ack combinatorial feedback at an actor input is allowed
<lekernel> no, you don't
<lekernel> in a very simple case you can simply pass through the control signal and have some combinatorial logic in the token path
<lekernel> the adder actor (and the other basic logic functions) do this, for example
<larsc> so it only acks the input once the output has been successfully delivered?
<lekernel> of course, if you stack too many of those actors in series, you can have timing closure problems later
<lekernel> that's why there's a generic "buffer" actor which simply inserts a register
<larsc> and you have to insert the buffer manually?
<lekernel> at the moment yes
<lekernel> but it shouldn't be too hard to implement some algorithm that examines the graph and inserts buffer actors based on some heuristics
<lekernel> (btw, the buffer actor adapts to any data type automatically)
<larsc> is there any plan that an actor can adapt it's number of stages depending on the graph
<larsc> e.g. if you have a multiplier in paralell with some other stuff
<lekernel> you mean, for pipeline compensation?
<larsc> and the other stuff takes a fixed number of cycles
<larsc> i don't know what pipeline compenstation is
<lekernel> having the same number of registers in all data paths so all associated data elements come out at the same time
<larsc> ok. no i meant if we know from the graph that there is an actor in paralel to our actor which needs a fixed number of cycles and our actor can be implemented with different cycle times, that the cycle time would be choosen, so that the resources usage is minimized
<lekernel> ha
<lekernel> yes, but I'm rather thinking about implementing it in a more heuristic way
<lekernel> i.e. you run a simulation of your whole system on some datasets
<lekernel> and it tries to find which actors are uselessly fast/resource intensive, and tries to switch them to more sequential implementations
<larsc> hm
<lekernel> in the same vein there can be actor sharing, too (i.e. if the same actor appears twice in the graph, it can be only implemented once, and some glue logic multiplexes the tokens in and out)
<lekernel> supporting this sort of stuff only in the "fixed number of cycles" case is too limiting to be really useful imo
<lekernel> in real world, you have DMA's to system memory and algorithms with a processing time depending on the data
<lekernel> this whole thing would only appear way later though
<lekernel> I want a migen version with great "manual" dataflow to start with :)
<larsc> hm
<lekernel> another "blue skies research" area is speculative execution. then you could imagine to build efficient pipelined CPUs quite easily using dataflow if done right
<lekernel> but I'm not really thinking about this yet... too much to do already
<larsc> ah, ok. the combinatorial scheduling model is just not mentioned in the README
<larsc> so that's basically a passthrough of the control signals and some combinatorial logic applied to the data
<lekernel> yes, but it can be a bit more complicated than a passthrough
<lekernel> ie if you have a combinatorial actor with two inputs and one output
<larsc> hm
<lekernel> it must only ack those two inputs at the same time, and when both have a token to send that can be accepted downstream
<lekernel> this needs a few AND gates
<lekernel> passthrough is only in the simple 1 input 1 output case
<larsc> yes
<larsc> hm, i guess two outputs, one input is even more complicated
<larsc> hm, copy & paste error in ala.py for And()?
<lekernel> yes
<GitHub83> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1966117e17174141a4c2794be43d53a7804b87bb
<GitHub83> [migen/master] flow/ala: fix typo for And (thanks Lars) - Sebastien Bourdeauducq
<larsc> somehow the distinction between different scheduling models reminds me of 'reg' and 'wire'
<wpwrak> ;-)
<lekernel> the point of scheduling models is (1) to have generic control logic in the base Actor class (2) to be able to implement algorithms that do things like remove the control logic and signals when a static schedule is found, insert buffer actors, equalize pipelines, etc.
<lekernel> so I think you have spoken too fast *g*
<larsc> yes, but for example combinatorial is just a special case of pipelined, with the length of the pipeline being zero
<larsc> also it is a special case of sequential with the ratio being one
<larsc> also which scheduling model has a actor which is combined actor out of an pipelined and sequential actor?
<wpwrak> so the scheduling model is basically a hint to the code generator ? i.e., in theory, a perfect code generator could figure it out on its own. but it may be hard to implement.
<larsc> imo a better model is to let an actor have both properties
<larsc> the number of pipeline steps and the number of sequential steps
lekernel [lekernel!~lekernel@g225034075.adsl.alicedsl.de] has joined #milkymist
<larsc> imo a better model is to let an actor have both properties
<larsc> the number of pipeline steps and the number of sequential steps