Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak> grmbl. most of github is down :-(
<whitequark> they're under DDoS
<whitequark> what kind of person would DoS a site like github?!
<whitequark> I've heard that someone hosts their static pages on github and their site is under attack, through
<whitequark> ah
<whitequark> not ddos anymore
<wpwrak> "unicorns" :)
<whitequark> erm
<whitequark> you know what preforked Apache is, right?
<whitequark> this is called "unicorn" in Ruby/Rails world by some reason (mainly the weird sense of humor of the author)
<whitequark> somehow rubyists often think that stupid names like "libpng" are too boring
<whitequark> and they call libxml "Nokogiri"
<whitequark> (that's a libxml binding, not a clone of course.)
<whitequark> actually, nokogiri means "saw" in Japanese (the metal thingy, that is), but good luck determining the function of the package from its name.
<whitequark> personally, I prefer these kinds of names by two reasons: 1) easier to google 2) similar things don't get called by similar names, and hence there is less confusion.
antgreen has joined #milkymist
<whitequark> a preforked server for slow clients is called "Rainbows!". yes, exactly like that, with the bang symbol at the end.
cladamw has joined #milkymist
wolfspraul has joined #milkymist
cladamwa has joined #milkymist
xiangfu has joined #milkymist
xiangfu has joined #milkymist
xiangfu has joined #milkymist
qwebirc47389 has joined #milkymist
rejon has joined #milkymist
rejon_ has joined #milkymist
<kristianpaul> xiangfu: thanks i'll try out
<xiangfu> kristianpaul, nope :)
rejon_ has joined #milkymist
<cladamwa> seems using tiny voltages changed between ground contact and cable shield is worth paying attention to capture action of insertion/removal but probably not in M1 case. With this tech, it should be more applied in measurement industries.
wolfspraul has joined #milkymist
cladamw has joined #milkymist
sh4rm4 has joined #milkymist
Martoni has joined #milkymist
rejon_ has joined #milkymist
<Fallenou> http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/MILKYMISTONE.pdf < red cross means "not connected" pin ? shouldn't we ground them instead of nc ?
rejon has joined #milkymist
elldekaa has joined #milkymist
xiangfu has joined #milkymist
azonenberg has joined #milkymist
wpwrak has joined #milkymist
elldekaa has joined #milkymist
<wpwrak> CONNECTED AGAIN !!! ;-))
<GitHub64> [flickernoise] wpwrak pushed 1 new commit to imaginarium: http://git.io/mZARug
<GitHub64> [flickernoise/imaginarium] images: make images array variable - Werner Almesberger
<wolfspraul> wpwrak: what happened?
<wpwrak> seems that one of the building's infrastructure power lines failed. elevators were down, too.
xiangfu has joined #milkymist
<wolfspraul> oh
<wolfspraul> so you had to climb 13 floors?
<wpwrak> naw. i didn't run out of any urgent supplies :)
<wolfspraul> ah good :-)
<wolfspraul> you were worried that my pcb core idea would fail over expensive copper, so I checked
<wpwrak> i just checked the elevators to know the general status of the infrastructure. to ask the janitor, i would have had to climb those 14 floors ...
<wpwrak> and ?
<wolfspraul> price of a 50x60cm core is 5-11 USD depending on thickness
<wolfspraul> roughly
<wolfspraul> say 5 USD for a 0.3mm core, then 11 USD for 3mm
<wpwrak> and the same in 3 mm acrylic ?
<wolfspraul> copper makes no big difference at all, so the range is still 5-11 USD
<wpwrak> ah, interesting
<wolfspraul> one by one. pcb makers don't know much about acrylic :-)
<wpwrak> so they throw in all the chemistry "for free"
<wolfspraul> there must be a difference, of course. but I would only be able to find it out if I negotiated hard prices for larger volumes, which is too tiring just for the heck of it.
<wolfspraul> say for 1000 50x60 panels - I'm sure there will be a difference whether I want copper or not, and how thick the copper is, etc.
<wolfspraul> but if I just buy 1, it's the same 10-11 USD for 2.5mm or 3mm, with or without copper
<wolfspraul> just fyi
<wolfspraul> my feeling is that the copper part must be < 1 USD (of those 11)
<wpwrak> not a bad price. at one of the local shops, the same amount of acrylic (unprocessed) would be around USD 18
VJTachyon has joined #milkymist
<lekernel> BUFIO2 #(
<lekernel> .DIVIDE (1), // The DIVCLK divider divide-by value; default 1
<lekernel> .DIVIDE_BYPASS ("FALSE"),
<lekernel> .I_INVERT ("FALSE")) // I_INVERT attribute to be added in last week of jan 2009
<lekernel> ...
<lekernel> the DDR PHY clocking is such a mess
<wpwrak> it's like a christmas present. it brings bad luck if you open it before the 24th ;-)
<lekernel> this thing requires no fewer than 10 different clock signals
<lekernel> with various phase/frequency relationships and FPGA routing restrictions
rejon has joined #milkymist
<wpwrak> complexity keeps your job safe :-)
<wpwrak> lekernel: i'm looking for a place to put things like the pacman, the heavily midified tornado, etc. these are code examples that illustrate how things work but they may not be readily usable like the rest of the patches
<wpwrak> lekernel: i'd still like to keep them in flickernoise.git, to keep them synchronized with the rest.
<wpwrak> lekernel: what i wouldn't want to happen is that they end up in a web update by accident
<wpwrak> lekernel: would (a) subdirector(y|ies) in patches/ be safe ?
<lekernel> yeah, the webupdate patches are handpicked atm anyway
<wpwrak> oh, perfect :) thanks !
<wpwrak> it seems to be surprisingly difficult to get the frame number wrap around the maximum. somewhere, there's something very weird going on ...
<wpwrak> (and no, i'm not using % ;-)
antgreen has joined #milkymist
LmAt has joined #milkymist
wpwrak has joined #milkymist
sh4rm4 has joined #milkymist
<lekernel> whoa! it synthesized!
<lekernel> and without complaining dozens of times about unroutable clocks after 20 minutes of runtime at each attempt
cwoodall has joined #milkymist
kilae has joined #milkymist
<lekernel> it even works (or at least, the 1x clock does and all the PLLs lock). great!
<GitHub14> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/c08687b9c6032c4236c413ec32c52c4a481901a1
<GitHub14> [migen/master] bus/dfi: filter signals by direction - Sebastien Bourdeauducq
<GitHub53> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/nY3Jfg
<GitHub53> [milkymist-ng/master] Generate all clocks for the DDR PHY - Sebastien Bourdeauducq
<kristianpaul> good !, free IP cores seems to be usefull after all ;)
<Hodapp> I hadn't realized Milkymist was semi-compatible with MilkDrop... maybe if I'd ever have used the latter or read the thesis paper it would have helped
<GitHub187> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/ca7056b07fb90b9424fa33918b5d701577e23be9
<GitHub187> [migen/master] fhdl: support forwarding of bidirectional signals from instance ports - Sebastien Bourdeauducq
<GitHub141> [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/4FS_wg
<GitHub141> [milkymist-ng/master] lm32: compatibility with the new instance API - Sebastien Bourdeauducq
<GitHub141> [milkymist-ng/master] m1crg: make clock feedback pin bidirectional - Sebastien Bourdeauducq
<wpwrak> Hodapp: we have a the option of using a nicer syntax, though
<wpwrak> Hodapp: milkdrop syntax is kinda evil :)
<lekernel> hmm... if I make all accesses to a single page of DRAM and keep that page open, I should not need to refresh, right?
<lekernel> (of course, this will destroy the data in the other pages)
<lekernel> I'm thinking about the simplest way to do the startup calibration of I/Os ...
<lekernel> driving the DRAM pins directly from a software routine (like the initialization sequence is done) sounds interesting, but refreshes might complicate things a bit
<Fallenou> (mmu) if someone has an idea on this problem : http://pastebin.com/frQR9FWj
<Fallenou> it seems incoherent, what I see in simulation, with the verilog code
<Fallenou> this is the source of my problems, leading to d_dat_o and d_adr_o of lm32 being XXX when doing a memory store
<lekernel> Fallenou: is that your modified source? did you get the original to work 100% correctly?
<Fallenou> yes it's the modified one, but here I'm in kernel mode
<Fallenou> so in theory nothing is modified
<Fallenou> I should try with totallyunmodified lm32
<Fallenou> I honestly never tried memory stores with unmodified lm32, only memory loads
<Fallenou> but modified or not, it's strange that the value is incoherent, or I missed something ...
<lekernel> it's probably going to be easier to track if you have a working version
<larsc> no other drivers for operand_w?
<Fallenou> research in vim only gives me those "two" drivers
<Fallenou> which is one actually because of the `ifdef
<larsc> and to be sure that the simulator is not stumbling upon the ifdef I'd remove the second
<Fallenou> and the 3rd for reset condition
<Fallenou> oh yes good idea
<Fallenou> still the same thing
<Fallenou> I commented ifdef, else and the unused driver
<Fallenou> and endif
<GitHub168> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/TejZeg
<GitHub168> [milkymist-ng/master] clkfx: remove - Sebastien Bourdeauducq
<Fallenou> I get the same thing with almost unmodified lm32
<Fallenou> only this is modified
<Fallenou> it's necessary to get simulation "compile"
<Fallenou> otherwise it does not even "compile"
<lekernel> ha, and how do you initialize r0?
<lekernel> be careful, in verilog X ^ X = X (not 0)
<lekernel> though X ^ X = 0 on the hardware, assuming it's the same signal
<lekernel> one of many discrepancies ...
<Fallenou> I do xor r0, r0, r0
<lekernel> yes, so it won't work
<Fallenou> well I hoped that my ram[0] = 0 would at least initialize r0 to 0
<Fallenou> in lm32_dp_ram.v
<lekernel> don't do such hacks... get the original code to work
<Fallenou> is there a way to 0 a register ? other than xor rn, rn, rn ?
<lekernel> just reset the register file with an initial statement in simulation
<lekernel> what's the problem with the code you commented out?
<Fallenou> ERROR:HDLCompiler:69 - "lm32_cpu.v" Line 2781: <reg_0.mem[0]> is not declared.
<Fallenou> ERROR:HDLCompiler:69 - "lm32_cpu.v" Line 2782: <reg_1.mem[0]> is not declared.
<Fallenou> ERROR:Simulator:778 - Static elaboration of top level Verilog design unit(s) in library work failed
<whitequark> lekernel: err what. X ^ X = X ? why?
<Fallenou> maybe I should put .ram instead of .mem
<lekernel> whitequark: because verilog is crap
<whitequark> lekernel: not an answer
<lekernel> there's even worse, 0*X=X
<Fallenou> X means "undefined" in verilog
<Fallenou> so they just say undefined xor undefined = undefined
<Fallenou> it ends up stupid with for example a ^ a != 0 if a == X
<whitequark> ahhh, I got it. you don't mean X as a variable
<Fallenou> nop
<Fallenou> X is the value
<Fallenou> 0,1,X,Z
<whitequark> yeah, then it's logical
<Fallenou> lekernel: registers seems to be reseted to 0 be the reset condition
<lekernel> what would have been logical is to remove X from the language - it causes more problems than it solves
<Fallenou> see line 2668 of lm32_cpu.v
<lekernel> but do you have LM32_EBR_REGISTER_FILE ?
<lekernel> it seems so, since it executes reg_0.mem[0] ... statements?
<Fallenou> yes I think we don't use at all the reg "registers"
<Fallenou> we use the lm32_dp_ram instead
<Fallenou> now it compiles, with .ram[0] instead of .mem[0]
<Fallenou> but it still bugs
<Fallenou> same problem
<Fallenou> oh, but I only initialize r0
<Fallenou> I should initialize all registers I guess
elldekaa has joined #milkymist
<Fallenou> lekernel larsc < OK, perfect, thanks
<Fallenou> http://pastebin.com/CJuHgcNd < I added this to lm32_dp_ram.v
<Fallenou> works nicely now :)
<lekernel> cool
<lekernel> yeah, X is nasty. there are even complete papers and presentations written on this mundane and annoying topic
<lekernel> for example ...
<lekernel> I guess it gives Verilog coders more job security
<Fallenou> ahah
<Fallenou> it made all the red signals of my simulation disappear
<Fallenou> magic initialization
<Fallenou> \o/
<Fallenou> and mmu stores seem to work as well (at least in simulation)
lekernel_ has joined #milkymist
<larsc> Fallenou: nice :)
<lekernel_> are there any DDR1 memories with differential DQS?
<lekernel_> that supposedly DDR1-compatible PHY has hardcoded differential buffers for DQS, but afaik all DDR1 memories have single ended DQS
<lekernel_> [{#~#{! that crap won't also generate the correct number of serdes I/O buffers
<lekernel_> I guess it is safe to assume it has never been tested with DDR1 and with a data width different from what is installed on NWL's devboard ...
<lekernel_> ha! now, of course, those 'unroutable clock' errors that I mentioned earlier and friends are coming in