lekernel changed the topic of #milkymist to: Mixxeo, Migen, MiSoC & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
mumptai has quit [Ping timeout: 252 seconds]
xiangfu_ has joined #milkymist
xiangfu has quit [Ping timeout: 240 seconds]
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has joined #milkymist
xiangfu has quit [Quit: leaving]
rjo has joined #milkymist
<rjo> funny. lekernel got ~11GB/s DDR memory bandwidth on the m1. I am getting ~9GB/s on this puny LX9 microboard where the DDR data is only 16 bit wide (compared to 32 on the M1)...
<rjo> read: 4800Mbps write: 4288Mbps all: 9088Mbps
mumptai has joined #milkymist
azonenberg has quit [Read error: Operation timed out]
Alarm has joined #milkymist
azonenberg has joined #milkymist
xiangfu has joined #milkymist
lekernel has joined #milkymist
<larsc> and it is running at the same clock rate?
<larsc> I think the b is bits not bytes
<lekernel> rjo, hi
<lekernel> rjo, the gateware only reports the number of transactions, and the bus width is hardcoded in the memtest software
<lekernel> so if you didn't fix it, you actually have only half the reported bandwidth
<lekernel> and yes, it's bits, not bytes
kilae has joined #milkymist
<lekernel> the bus width could be added to a memtest core CSR
<GitHub20> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/4bW7bg
<GitHub20> misoc/master 4fc301c Robert Jordens: common.mak: -Os instead of -O3, smaller bios (<32k)
<GitHub20> misoc/master 05944cf Robert Jordens: cpuif.py: add _ADDR and _SIZE defines for each register...
qi-bot has quit [Ping timeout: 240 seconds]
<GitHub54> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/94D5wQ
<GitHub54> misoc/master c1e5683 Robert Jordens: s6ddrphy: drop unused outputs, shortens verilog and produces more readable warnings...
<GitHub120> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/KWv3iw
<GitHub120> misoc/master e4db7d1 Sebastien Bourdeauducq: common.mak: specify python3
xiangfu has quit [Ping timeout: 248 seconds]
xiangfu has joined #milkymist
qi-bot has joined #milkymist
xiangfu has quit [Ping timeout: 248 seconds]
<rjo> lekernel: i see. the remaining difference is then probably 83.7/75 MHz clock.
<rjo> larsc: i was assuming bits
xiangfu has joined #milkymist
<lekernel> how much of the lx9 are you using?
xiangfu has quit [Ping timeout: 240 seconds]
<rjo> lekernel: ~75% for the m1-soc -dvi -fb +memtest
<rjo> lekernel: do you prefer me sending patches or would you like to cherry-pick/pull from a repository?
<lekernel> patches are great
<lekernel> do you intend to merge lx9 support directly into misoc?
xiangfu has joined #milkymist
<lekernel> i.e. is that a platform you're serious enough about it that it's worth the extra bit of maintainance hassle
<rjo> lekernel: it gets ugly distinguishing the two in top.py.
<lekernel> yeh
<rjo> lekernel: there is really not much extra stuff.
<lekernel> your build.py patch has a test for lx9_microboard
<rjo> lekernel: yes. and that part in build.py
<rjo> lekernel: in the end, the lx9 specific stuff is very small: https://github.com/jordens/milkymist-ng/commit/886291532774d50b0f35b5aa5e9b869b8b97bdd1
<lekernel> I wonder if it would make sense to revamp the misoc build/integration system so it's easier to add extra platforms, possibly in external repositories
<rjo> lekernel: yes.
<rjo> lekernel: split misoclib from top.py/make.py
<lekernel> does your SPI flash core memory-map the flash data?
<rjo> lekernel: yes. like norflash
<lekernel> you should be able to XIP the BIOS then
<lekernel> it shouldn't be ridiculously slow thanks to the lm32 caches
<rjo> lekernel: thats the plan.
<rjo> in terms of cycles it is actually not much slower than the parallel norflash.
xiangfu has quit [Ping timeout: 248 seconds]
<rjo> something like ~24 cycles for a random read if the clocks are matched.
<rjo> ... but the onboard jtag is the most inconvenient thing on that board.
<lekernel> you can already use misoclib without make.py/top.py
<lekernel> the problem is, you'll have to duplicate a bunch of code from make/top and the BIOS
<lekernel> another portability issue is the lm32_include.v file. a radical solution would be to rewrite the whole lm32 core in migen :)
<lekernel> (jtag) have you tried urjtag?
<lekernel> it works nicely for writing the nor flash. afaik there's no support for SPI though.
xiangfu has joined #milkymist
<rjo> lekernel: re code splitting: exactly
<rjo> lekernel: seen it, yes.
<GitHub24> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/0ChNtw
<GitHub24> misoc/master 31ec33d Robert Jordens: s6ddrphy: use shorter Instance argument notation...
<lekernel> thanks for the patch
<rjo> lekernel: it would be great if the digilent bozos would just open up their atmel based jtag thingy...
<lekernel> atmel based? yet another one? lol
<lekernel> I thought they used ez-usb
<lekernel> well, you can always reflash that atmel thing... but yes, it wastes everyone's time.
<rjo> that would be overkill ;)
<rjo> lekernel: i could imaging they even burned the fuses so that i can't reflash it.
<lekernel> otoh... I'm not a big fan of ftdi chips since I looked at some code, and would prefer an AVR-based solution
<lekernel> (for future FPGA boards)
<lekernel> how fast is that JTAG?
<rjo> lekernel: sure.
<rjo> lekernel: dunno. it claims to do the fpga programming at 4MHz.
<rjo> lekernel: but writing the flash is ~10 minutes.
<lekernel> SPI flash writing (and particularly erasing) isn't fast
<lekernel> it also could be that they simply assume the worst-case erasure time from the datasheet, instead of monitoring the flash status during an erase
<lekernel> you can easily get a 5x slowdown with that technique :)
<rjo> lekernel: the etherbone slave looks like it should work base on the simulation but i never tested it with hardware. would you accept it now or would you rather wait until something uses it?
<lekernel> I'd rather commit only code that is actually used. every bit I add, I have to maintain.
<rjo> lekernel: oh yes. and they invented another flash loading technique (sfutil.exe) which goes some other route but uses the same hardware...
<lekernel> but it'd be very nice to have etherbone :)
<lekernel> should be much faster for quick debugging hacks than using adhoc LM32 C software and TFTP
<rjo> yep.
xiangfu has quit [Read error: Connection reset by peer]
<rjo> lekernel: i'll send etherbone anyway. you can ignore it if you like ;)
<lekernel> what are the obstacles to testing it on the lx9?
<rjo> not much. need to write some wrapper that passes the etherbone packets over wire.
<rjo> the "ether" in that etherbone is not there yet. etherbone actually only specifies the serialized protocol.
<rjo> but you could run it over serial
<lekernel> it'd be nice to combine it with an Ethernet MAC that the CPU can use at the same time
<rjo> yes. i have only seen that FX2 implementation.
<GitHub25> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/f_3RRw
<GitHub25> misoc/master de87149 Robert Jordens: common.mak: drop the echo from the version tag finding, did not work here, use python -c...
<rjo> weird. github tells me i wrote those patches two days ago. back then i did not have any patches yet...
<rjo> aight. i'm off. thanks for commiting!
<lekernel> you're welcome
<lekernel> bye
xiangfu has joined #milkymist
aeris has quit [Quit: en a pas]
xiangfu has quit [Remote host closed the connection]
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]]
aeris has joined #milkymist
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
Alarm has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]]
antgreen has quit [Ping timeout: 272 seconds]
lekernel has quit [Read error: Operation timed out]
lekernel has joined #milkymist
<GitHub24> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/Bg0jXA
<GitHub24> misoc/master f5211af Sebastien Bourdeauducq: videomixer: add EDID manipulation routines
<GitHub24> misoc/master 75d25af Sebastien Bourdeauducq: cosmetic changes
lekernel has quit [Quit: Leaving]
<larsc> ah, right what I need :)