Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
elldekaa has joined #milkymist
<wolfspraul> wpwrak: very cool wheel video! :-)
<hypermodern> Thank you lekernel
azonenberg has joined #milkymist
hypermodern has joined #milkymist
wolfspraul has joined #milkymist
azonenberg has joined #milkymist
sh4rm4 has joined #milkymist
wolfspraul has joined #milkymist
LimitedAtonement has joined #milkymist
LmtdAt has joined #milkymist
Hodapp has joined #milkymist
rejon has joined #milkymist
xiangfu has joined #milkymist
elldekaa has joined #milkymist
fpgaminer has joined #milkymist
wolfspraul has joined #milkymist
* fpgaminer is wondering how useful a ring oscillator based temperature sensor would be in preventing chip damage on a Spartan-6...
<Fallenou> hi
* fpgaminer waves
azonenberg has joined #milkymist
bkero has joined #milkymist
wolfspraul has joined #milkymist
<lekernel> fpgaminer: it would work - but do you really make the chips so hot?
<lekernel> (of course, assuming you compensate for process and voltage effects too)
sh4rm4 has joined #milkymist
<fpgaminer> lekernel: You bet. Without a heatsink the mining firmware will easily cook the FPGA.
<fpgaminer> Which is great for BBQs but ... not so great for making Bitcoins :P
xiangfu has joined #milkymist
<lekernel> meh
<lekernel> what do you have in there which uses so much power?
<lekernel> have you tried using XPA?
<fpgaminer> lekernel: 200MHz, >75% slices occupied on an LX150, and a high toggle rate.
xiangfu has joined #milkymist
lekernel_ has joined #milkymist
<lekernel> Fallenou: iirc mvhi sets the 16 LSBs of the register to 0
<Fallenou> oh really ?
* Fallenou checks
<Fallenou> oh yes
<Fallenou> you're right
<Fallenou> it means I don't have to xor the register
kilae has joined #milkymist
<larsc> mvhi is just orhi with r0
<lekernel> "Additionally, the use of local routes within the CMT provides an improved clock path because the route is handled locally, reducing chances for noise coupling."
<lekernel> noise coupling inside the fpga... sounds nice
<Fallenou> what is CMT ?
<lekernel> the tiles in S6 FPGAs which contain DCMs and PLLs
<Fallenou> ok
<Fallenou> are they only located on the edges ? or inside too ?
<lekernel> http://www.xilinx.com/support/answers/46141.htm <= I really wonder if NWL really got their PHY to work, since it uses CLKOUT3 with a 90 degree shift
<larsc> well, if it only happens in 13.4
<lekernel> no, no, read it well... 13.4 _and earlier software_
<lekernel> which means it never worked
<Fallenou> but since it's software it means they will be able to correct it for 13.5 :)
<larsc> ok, missed the "and earlier"
<Fallenou> maybe it can be corrected with planahead post processing on the bitstream ?
<lekernel> maybe, but it doesn't explain how NWL released that PHY oh, one year ago?
<lekernel> with that bug and no one noticed
<Fallenou> maybe they just don't need the phase shifting
<lekernel> they do need the phase shifting
<Fallenou> ok ^^
<lekernel> it's necessary for generating critical DRAM control signals
<Fallenou> well on the xilinx support page they say "may/can" so maybe in this precise case it does not happen (the bug)
<Fallenou> it does not seem to happen 100% of the time
<lekernel> that, the DQS problem with DDR1, and the calibration FSM not working (I haven't fully investigated this last bug)... ahem
<Fallenou> do you know someone using it ?
<lekernel> the PHY was also tickling a MAP bug that made the placement of the BUFPLL fail, but I don't know if it was a ISE regression or just another thing that NWL didn't test
<lekernel> as usual, DRAM + FPGA = complete mess ...
<lekernel> no matter how much "IP" they throw at it, they seem to always get it wrong somehow
<lekernel> DDR4 will be fantastic
<Fallenou> don't they have "hard" ddr ip controller inside fpga ?
rejon has joined #milkymist
<Fallenou> which could work
<lekernel> they do, but it has a bunch of problems too
<lekernel> they even removed it from the -7 series
<lekernel> "naaaah, no more hard DRAM controller PLEAAASE!"
<Fallenou> =(
<Fallenou> too bad SRAM is that expensive
<Fallenou> 'cause DRAM seems to be a real mess
<lekernel> oh, I'm sure that fast SRAM (QDR etc.) and this kind of high-quality timing generation can lead to funny things too
<lekernel> but yes, the control algorithm is much simpler. it's a different problem though.
<Fallenou> does "ddr controller chip" exist ?
<lekernel> on PCs, it's usually part of the motherboard "northbridge" chip... but it also tends to be integrated with the CPU those days
<Fallenou> yep with sandy bridge stuff
<lekernel> also, multiplying the number of chips in the memory path increases latency
<Fallenou> yes sure
<Fallenou> they have a DDR2 demo on digilentinc Atlys board
<Fallenou> I wonder which ddr controller they use
DJTachyon has joined #milkymist
<Fallenou> Lattice also released a SDRAM controller (both vhdl/verilog code) with testbench and documentation
<Fallenou> but their license is not clear
<lekernel> SDR and FSM with auto-precharge... that's a very simple one :) we already have a faster one...
<lekernel> what I'm trying to do atm is (1) run the SDRAM command bus at twice the system clock frequency (and the data four times faster the system clock) (2) process two requests at once (3) reorder requests
<lekernel> #1 is causing problems atm due to PHY and toolchain bugs
lekernel_ has joined #milkymist
* kristianpaul tought new PHY was fore getting faster memory
<kristianpaul> Fallenou: seems license stick its use to lattice products
<Hodapp> w00t. I had Staples print out the thesis paper for the Milkymist, should be ready soon...
<Hodapp> been very intrigued but my tablet is a little small to read a 100-page paper on
<GitHub32> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1b8cb5b46ce7228eab43141ff8810afab7bd4322
<GitHub32> [migen/master] bus/dfi: fix multiphase naming - Sebastien Bourdeauducq
<lekernel> kristianpaul: all the new PHY is supposed to do is sort out timing issues to get the SDRAM base clock at 2x the system clock
<lekernel> this would only get a 2x increase in memory bandwidth, but I'm also planning a more powerful controller
<kristianpaul> the PHY also deal with crossing clock domain issues?
<lekernel> yes
<kristianpaul> cool
<kristianpaul> :)
<kristianpaul> lekernel: what about for FML, it will be use same clock domain fro the PHY or?
<lekernel> there won't be FML anymore
<kristianpaul> oh
<kristianpaul> why?
<kristianpaul> no need?
<lekernel> FML doesn't support transaction reordering
<kristianpaul> ergh, so the TMU will share bus with others cores?
* kristianpaul click
<kristianpaul> btw any plans to support a wishbone switch-like bus with migen? :-)
<lekernel> it's already there
<lekernel> and it works
<kristianpaul> oh
<kristianpaul> i need check that
<lekernel> that's all. migen automatically builds the interconnect based on this.
<kristianpaul> so it decides wich logic is better shared bus or a mix switch-like wishbone implementations?
<kristianpaul> I dont disgree with sofyware generaring software but i need understand this better before give it a bite
<kristianpaul> but i havent forget i want namuru be happy with migen/milkymist-ng ;-)
<lekernel> no you define this manually
<lekernel> InterconnectShared is just a shortcut for arbiter -> shared bus -> decoder
<kristianpaul> yeah, that is messy by hand
<kristianpaul> of course best looking code ;)
<kristianpaul> i dont see a class for a Cross Bar Switch Internconnect..
<kristianpaul> may be i missudertand you at first
<lekernel> there isn't any, but you can build it easily from the arbiter and decoder classes
<kristianpaul> ahh ;-)
<lekernel> it doesn't make sense to have a xbar on MM, most transfers are with the memory
<kristianpaul> but you implemented it some time ago it was with NOR
<lekernel> and I have already enough to do with the things that make sense *g*
<kristianpaul> yeah memory
<lekernel> no, it wasn't really xbar
<kristianpaul> what was it then?
<lekernel> well, it was a partial xbar
<lekernel> and it's no longer needed, it was to try to fix some issues with ethernet DMA from the BIOS
<lekernel> but we no longer have DMA for ethernet
<kristianpaul> :(
<kristianpaul> what i like most of migen is this top.py for milkymist-ng
<kristianpaul> looks prerry simple :)
<kristianpaul> s/prerry/pretty
<lekernel> he, if you want DMA, you know what to do right? :-)
<kristianpaul> ask you first? ;-)
<kristianpaul> may be you reconsider, lol
<kristianpaul> :-D
<kristianpaul> but no i dont need, i prefer do the heavy memory stuff on the core, and dont disturb the rest of the SoC
<kristianpaul> i guess that was the buggy part with minimac at first..
<kristianpaul> not saying i was memory corruption somehow.. ;)
<lekernel> there were multiple bugs, but the most annoying of them was that the FIFOs were becoming very large in attempt to prevent under/overflows
<lekernel> so now it's storing whole packets in block RAM, which is much simpler, and does not waste my time
<kristianpaul> indeed :)
<kristianpaul> and since block RAM seems to me more abudant in xilinx-7 devices well :)
<lekernel> but if you want to implement DMA, I can recommend you to keep storing the whole packets in BRAM instead of fighting with overflow issues
<lekernel> with the block RAM, it should be pretty simple to do, in fact
<lekernel> just a small FSM
<kristianpaul> yes i do follow that recomendation
<GitHub62> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/usww_Q
<GitHub62> [milkymist-ng/master] Prepare for new DDR PHY - Sebastien Bourdeauducq
<kristianpaul> lekernel: what you think of a phisical connector that wires to milkymist wishbone bus, with some aid from bios and a control logic (tree state stuff) it could allow to plug wishbone compatible boards, dont yout think?
<kristianpaul> mwalle: where i write system frequency? is flash or hardcoded to bistream?
<kristianpaul> s/bitstream/HDL..
<kristianpaul> anyway, this means bios adapt it self to system clock freq?
<bkero> win 27
<kristianpaul> ah yes sysctl
<lekernel> wishbone is just too many wires
<kristianpaul> ah, yes i forgot there is bidireccional buses..
<kristianpaul> dam
<kristianpaul> n
hypermodern has joined #milkymist
<kristianpaul> argh, xst dont matters this kkjj| .sys_clk(sys_clk)
<kristianpaul> i wonder that it think it was..
<kristianpaul> "kkjj| .sys_clk(sys_clk)" <-- this
<Fallenou> kristianpaul: why bios would need to know system frequency ?
<kristianpaul> Fallenou: it does ! it reads from a CSR register
<kristianpaul> commit b9605012ac9554645386e192db5f6cc4b67aefe1
<kristianpaul> it seems adjust timers
<kristianpaul> so uart can work correctly?
<Fallenou> oh for timers ok
<Fallenou> uart does not need to know freq at bios level iirc
<Fallenou> freq is in hard in the hdl
<kristianpaul> ah yes
DJTachyon has joined #milkymist
<kristianpaul> that it is right !
<kristianpaul> so what are timers for? :)
<Fallenou> dunno ! for whatever you want :p
<kristianpaul> lol
<kristianpaul> Fallenou: https://gist.github.com/1865260
<kristianpaul> seems gdb uarts was the excuse CSR_UART_DIVISOR :-)
<kristianpaul> isnt mwalle ?
<lekernel> [{#«#{(!! I managed to make a design that fails timing in PAR but the timing analyzer reports no problem
<kristianpaul> good you alredy know to to cheap xilinx tools ;-)
<kristianpaul> s/to to /how to
<kristianpaul> s/cheap/cheat
<GitHub15> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/DYYWVQ
<GitHub15> [milkymist-ng/master] s6ddrphy: clock, address and command - Sebastien Bourdeauducq
cjdavis has quit ["PART #linuxcnc :PART #drupal-support :PART #drupal :ISON Paul_hive13 Hodapp bangpound"]
azonenberg has joined #milkymist