lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jevin has joined #milkymist
playthatbeat has quit [*.net *.split]
zumbi has joined #milkymist
zumbi is now known as Guest37274
playthatbeat has joined #milkymist
Guest40180 has quit [Ping timeout: 245 seconds]
bkero has quit [Ping timeout: 245 seconds]
sh4rm4 has joined #milkymist
bkero has joined #milkymist
ChanServ has quit [*.net *.split]
larsc_ has joined #milkymist
larsc has quit [*.net *.split]
ChanServ has joined #milkymist
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
azonenberg has quit [Read error: Operation timed out]
kyak_ is now known as kyak
lekernel has joined #milkymist
kilae has joined #milkymist
bhamilton has joined #milkymist
lekernel has quit [Ping timeout: 256 seconds]
lekernel has joined #milkymist
kyak has quit []
<lekernel> so next MM board will likely have the JTAG/serial builtin. wpwrak will be happy ;)
<lekernel> and less slow -3 speed grade FPGA
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
larsc_ is now known as larsc
bhamilton has quit [Quit: Leaving.]
<Fallenou> lekernel: Do you know how do they manage to do different speed grades?
<Fallenou> they use different cell tecnologies?
<Fallenou> +h
mumptai has joined #milkymist
bhamilton has joined #milkymist
<Fallenou> 12:15 < lekernel> and less slow -3 speed grade FPGA < you mean with a kintex-7 ? or a Spartan-6 with a better speed grade? ( is -1 better than -3 for S6?)
<Fallenou> http://forums.xilinx.com/t5/CPLDs/Speed-Grade/td-p/3052 <= here, "barriet" says that for "modern FPGAs" (post Virtex) the higher the speed grade is, the faster the fpga is
bhamilton has quit [Ping timeout: 256 seconds]
<lekernel> speed binning I guess
<lekernel> everything using modern semiconductor processes has wide process/voltage/temperature variation
<Fallenou> oh, ok, so they design with the "fastest" goal in mind
<Fallenou> and then they attribute "lower" speed grades to the one not capable of reaching that goal after testing
<Fallenou> because of manufacture problems
<lekernel> the slowtan6 philosophy is generally to dump this mess on the user, e.g. the programmable IO input delays have a "maximum" delay, and then "the minumum delay is typically 1/3 the maximum delay" - deal with that
<Fallenou> ahah :)
<lekernel> or the high speed IO terminations are specified between ~10 ohm and ~50 ohm - I wonder if anyone can actually use that...
<Fallenou> wow
<lekernel> let me get the actual number...
<Fallenou> how can anyone use that for driving something efficiently without too much noise
<lekernel> ah, it's 22/55. a bit less bad, but still bad
<Fallenou> is there a trick to detect dynamically the impedance of the I/O and then adapt to it?
<lekernel> for the input, and 11/52 for the output :-)
<lekernel> serious chips have an external calibration resistor
<Fallenou> I know that for instance for our bluetooth modules, we put low quality capa/resistance in the RF stage
<lekernel> eg. DDR3 memories have a RZQ pin for that
<Fallenou> and then we have a "production calibration bench"
<lekernel> and xilinx doesn't have the cost excuse, DDR3 is cheap
<Fallenou> which calibrates the bluetooth chip writting into registers
<Fallenou> and then save the best values to the flash nand
<Fallenou> so each bluetooth module we sell basically have different C/R values for RF stage but it's compensated inside the BT chip
<Fallenou> by uniq calibration values
<lekernel> that works against the process variation... but temperature and voltage can also cause changes
<Fallenou> well, if you have automotives chips, that should not be a problem
<Fallenou> chips should handle temperature issues in a big range
<Fallenou> and then if you have regulators .. (automotive ones) then it should be ok
<Fallenou> it may not be perfect but you should have very less surprises than when using "non automotive AEC-Q100" parts
<lekernel> DDR3 can even change its terminations in a couple nanoseconds :) http://www.micron.com/~/media/Documents/Products/Technical%20Note/DRAM/TN4104.pdf
<Fallenou> nice :)
<lekernel> xilinx? 15 minutes with the ISE software. hahaha
<Fallenou> lol
<Fallenou> you can pre-generate several bitstreams and put them to nand and re-configure on-the-fly when needed :)
<Fallenou> then you can maybe switch in 1 sec
<lekernel> yes, you can just retransmit the IO frame. but xilinx does not tell you that, and there also might be glitches.
aeris has quit [Read error: Operation timed out]
aeris has joined #milkymist
<lekernel> yay, got both channels to work at the same time by inserting 24 ohm resistors
<lekernel> got mixing to work now
<lekernel> after two days of constant ISE breakage
<Fallenou> awesome!
<Fallenou> \\o//
* lekernel cleans his desk a bit for the photo
<Fallenou> :)
<Fallenou> maybe you can take a video while you change the mix ratio between two sources
<lekernel> haven't connected the controls yet... shouldn't be a problem, though I know anything can happen now
<lekernel> I also suspect crosstalk between SDRAM and the extension board traces (causes some noise on the picture)... will investigate
<lekernel> it seems the more I read from the DRAM, the more noise
<lekernel> I was thinking about the usual horde of gateware and/or ISE bugs, but this seems to be a consistent pattern among several bitstream tests
<Fallenou> it seems reasonable to think so
<Fallenou> do the dram traces follow the extension port traces a bit?
<lekernel> and the first TFTP tests, which only wrote to the DRAM while the picture was being captured, did not have any noise
<Fallenou> oh, so only read whould generate noise ... funny
<lekernel> it could be that the DRAM chips have a faster slew rate than the FPGA IOs
<lekernel> you can program that by reloading the DDR mode register, will have a look at it
<lekernel> this whole project is really in deep bugland, lol
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 256 seconds]
aeris has quit [Ping timeout: 256 seconds]
<Fallenou> looks good :)
aeris has joined #milkymist
<lekernel> Fallenou, you should send git-formatted patches instead of github pull requests
<lekernel> they are easier (no need to open browser and then pull again on the command line) and cleaner (no tons of merge commits) to appöy
<lekernel> apply
<Fallenou> ok, I thought just clicking the button on github was easier
<lekernel> not when you have unpushed local changes, and you need to git-pull again to update your copy
<Fallenou> hum ok
<Fallenou> I guess if you don't have any makefile related changes you can git stash && git pull --rebase && git stash pop
<Fallenou> but I don't mind sending patches :)
<Fallenou> will do that
<lekernel> yeah well I'm sure there are solutions ;) but git am <email> is easier
<Fallenou> ok no problem
<lekernel> it's ok for this one, don't resend
<lekernel> and thanks for the patch :)
<Fallenou> ok will know for the next one
<Fallenou> hehe you're welcome it's just very small things
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 256 seconds]
<GitHub195> [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/XohDkQ
<GitHub195> milkymist-ng/master 534dec6 Sebastien Bourdeauducq: First video mixing working (hacky)
<GitHub195> milkymist-ng/master e35315b Sebastien Bourdeauducq: cleanup
<GitHub105> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/qN00IQ
<GitHub105> migen/master 792b8fe Sebastien Bourdeauducq: bus/asmi: port sharing support
<lekernel> ah, 800x600 starts to work now ...
<lekernel> still lots of problems but it's not 100% noise
<lekernel> the 24 ohm resistors seem to help a lot
<lekernel> reducing drive strength through the SDRAM extended mode register doesn't
<lekernel> let's try some captures with the framebuffer off ...
<Fallenou> increasing drive strength adds more harmonics and then reduces energy pics?
<Fallenou> it shares the energy between more harmonics?
<lekernel> the DRAM signals looked clean on the scope, but you never know ...
<lekernel> 6. Controlling Drive Strength
<Fallenou> ok
<Fallenou> so less "overshoots" , or kinf od
<Fallenou> kind of*
<lekernel> and mostly, less high frequency components that have a more marked tendency to splatter on nearby traces
<Fallenou> ok
<Fallenou> nice link!
<lekernel> there is definitely a SDRAM READ -> DVI crosstalk problem
<lekernel> SDRAM is DMA-written by the DVI core at all times
<lekernel> framebuffer is only scanning (and reading the DRAM) when the software says it's on
<lekernel> and the resolution counter is implemented in gateware and is independent of any potential DRAM write problem
<lekernel> hmm, or it could be the VGA DAC too
<Fallenou> yes maybe stop driving the DAC :/
<Fallenou> to see if there are still SI issues
<lekernel> let's try the magical S6 OUT_TERM
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 264 seconds]
lekernel has quit [Quit: Leaving]
lekernel has joined #milkymist
<wpwrak> (jtag/serial built-in) yay ! ;-)
Alarm has joined #milkymist
Fallenou_ has joined #milkymist
Fallenou has quit [*.net *.split]
zumbi has joined #milkymist
larsc_ has joined #milkymist
zumbi is now known as Guest64795
21WAAKUO3 has joined #milkymist
Hawk777` has joined #milkymist
juliusb has quit [Write error: Broken pipe]
mumptai has quit [Excess Flood]
mumptai_ has joined #milkymist
Guest37274 has quit [Remote host closed the connection]
larsc has quit [Remote host closed the connection]
Hawk777 has quit [Remote host closed the connection]
larsc_ is now known as larsc
Alarm has quit [Ping timeout: 252 seconds]
<Fallenou_> larsc: why in switch_to_kernel_mode you do mv r9, r0 before restoring r0 to 0x0 ?
<Fallenou_> it seems to be doing r9 = r9_set_by_user_space | &lm32_state
<Fallenou_> why keeping value set by user space (or other kernel code)?
<Fallenou_> oh no ok got it
<Fallenou_> it does r0 | r0
<Fallenou_> sorry
<larsc> r0 contains the address of the state struct at that point and we need that later in the function as well
<Fallenou_> I just misunderstood the mv r9, r0 syntax, I thought it was doing r9 = r9 | r0 when it was doing r9 = r0 | r0
<Fallenou_> just to save &lm32_state in r9 to use it later but be able to restore r0 to 0x0
<Fallenou_> thanks ^^
Alarm has joined #milkymist
21WAAKUO3 is now known as juliusb
<wpwrak> (git pull) i think the "clean" approach is to pull the latest upstream, create a new branch on top of that, dump all your changes into the branch, check that it still builds, then run git request-pull on it
<Fallenou_> I only missed the "git request-pull" part of it :)
Fallenou_ is now known as Fallenou
<wpwrak> heh :)
balrog has quit [Ping timeout: 264 seconds]
balrog has joined #milkymist
bhamilton has joined #milkymist
<mumptai_> haha .. "The code quality standard for inclusion of HDL modules is higher than what you may be used to." (milkymist hdl guidelines)
<mumptai_> :)
bhamilton has quit [Client Quit]
<Fallenou> where is it?
<lekernel> fact. raspberry pi model B cannot play 640x360 video with mplayer software decoding and fbdev output (it's even worse with the X overhead)
<Fallenou> aouch
<Fallenou> which video codec?
<lekernel> that oh-so-cool 700MHz ARM is too slow :)
<Fallenou> if it's some H.264 like codec that can be understood
<lekernel> or maybe the framebuffer/SDRAM writes are - I'd expect the CPU core itself to be fast enough
<lekernel> mpeg4
<lekernel> you need to pay for those license keys to have hardware decoding, lol
<Fallenou> I guess mpeg-2 would be decoded fine
<lekernel> another good demonstration that popular != good
azonenberg has joined #milkymist
<lekernel> it can talk to the M1 through the HDMI board, at least that is good :)
<Fallenou> at least raspberry is not racist against open source hardware :)
<wpwrak> (popular != good) if you need something to sink the argument for good: hitler was kinda popular ... ;-)
<lekernel> hm, so the crosstalk is coming from the SDRAM reads. problems are still there when not driving the VGA DAC (and still disappear when stopping the framebuffer scan)
Alarm has quit [Ping timeout: 246 seconds]
Alarm has joined #milkymist
Alarm has quit [Client Quit]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 245 seconds]
<Fallenou> you can cut it from your screen :)
<wpwrak> kewl ! :)
<GitHub162> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/RypiLA
<GitHub162> milkymist-ng/master bb73558 Sebastien Bourdeauducq: software/videomixer: framebuffer enable/disable
Alarm has joined #milkymist
<lekernel> Other operating systems include the cost of the various codecs within the price of the operating system. In the case of Linux distributions, free versions of media encoders and decoders are used instead. But hang on – the Raspberry Pi runs a Linux distribution, so why isn’t the MPEG-2 codec free?
<lekernel> The answer is simple. The Raspberry Pi is designed to be used for education, and while there are many who enjoy its multimedia capabilities, the developers decided to remove MPEG-2 in order to keep costs down. If you want to use MPEG-2, it is there for you to unlock for a small fee
<lekernel> this is so hilarious
<lekernel> oh, it gets even better:
<lekernel> Could I Try a Hacked Codec? [...] The sale of the codec raises money so that the non-profit Raspberry Pi Foundation can work towards its altruistic aims. So don’t go ripping off a codec that costs less than a bottle of beer – pay for it, and help change the world!
<lekernel> ok, so what else can I use that has a good framerate on the rpi? otherwise I'm sure some people would assume it's the M1 that is slow =]
<Fallenou> you want to mix output of 2 rpi using the M1 ? :)
<wpwrak> use a pc ? they come without anyone trying to send you on a guilt trip
<lekernel> right now I have a eee pc and desktop pc
<lekernel> and I bought a rpi to replace the desktop for mobile demos, but ...
<Fallenou> are you sure there is no binary blob somewhere that you can use with your rpi?
<larsc> well the binary blob is the thing you can buy
<lekernel> you need license keys that depend on a unique ID written in the chip
<lekernel> I'm sure most of the license fees go to MPEG LA and payment companies
<lekernel> what complete BS :)
<Fallenou> :/
<wpwrak> you should ask about the split in one of the rpi fanboy forums :)
<Fallenou> isn't 700 MHz enough to do software decoding of MPEG-2 at , say , 1024x768 ?
<lekernel> and maybe a bit to broadcom or whoever else wrote those proprietary GPU codecs
<lekernel> depends how fast your framebuffer is... even moving windows or scrolling text in X is sluggish
<Fallenou> :/
<Fallenou> maybe you will eventually have to pay the few $ :/
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
Alarm has joined #milkymist
bhamilton has joined #milkymist
lekernel has quit [Quit: Leaving]
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
bhamilton has quit [Ping timeout: 264 seconds]
froggyto2d is now known as froggyto1d
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 260 seconds]
azonenberg has quit [Remote host closed the connection]
azonenberg has joined #milkymist
playthatbeat has quit [Remote host closed the connection]
playthatbeat has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 245 seconds]
mumptai_ has quit [Quit: Verlassend]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 264 seconds]