sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sh4rm4 has joined #m-labs
antgreen has quit [Ping timeout: 250 seconds]
<mithro> Kind of a random question, does anyone have a good primer on understanding the "rule of thumb" performance of DDR2/DDR3 style memory. Things like "should I be reading bytes sequentially for better performance?"
<mithro> I'm trying to understand how I should structure writing and reading buffers into / from DDR3 and don't have a good feel for how different reading/writing styles affect performance
<mithro> _florent_ / rjo: Do you guys have CI for MiSoC stuff?
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #m-labs
<sb0> mithro, if you read sequentially and submit precharge/activate to other banks in the background, you should reach ~99% of the peak IO bandwidth
<sb0> random accesses can be a lot slower, especially if you are following pointers
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 265 seconds]
<GitHub133> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/veSzG
<GitHub133> migen/master a69741b Sebastien Bourdeauducq: forgot other cordic files
<mithro> sb0: how much is "a lot" - are we talking 25% or like 75%? I assume there is some kind of "stall" that happens when you do a jump in read locations
<sb0> you can do the math: you wait for the data to get the pointer value, that pointer address misses the page, and you need to do another precharge + activate + read
<sb0> another inefficiency with pathological cases of pointer following is that you read using bursts while you only need a smaller data chunk for the pointer
<sb0> rjo, maybe we should rename misoc. any good idea for a name?
<sb0> also we should setuptoolize it and turn make.py into a "frontend tool" like in artiq
<mithro> sb0: do you know of a good place which explains that stuff?
<rjo> sb0: ack. mimod, micores, milib? ;) but misoc is really all that wrong. a system on a chip does not imply a cpu, isn't it just-a-bunch-of-modules?
<rjo> but not with hardware-in-the-loop yet.
<rjo> s/misoc is really all that wrong/misoc is _not_ really all that wrong/
<rjo> sb0: "jabom" optionally with a "mi-" in front ;)
<mithro> rjo: are you "http://www.phys.ethz.ch/~robertjo"?
<mithro> rjo: looks like you have a working cutback Xilinx toolchain?
<sb0> mithro, I did some explaining in my msc thesis http://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A370883&dswid=-9648
<sb0> the micron datasheet are also pretty decent
<sb0> especially by datasheet standards
<mithro> sb0: thanks!
fengling has quit [Quit: WeeChat 1.0]
<whitequark> (by datasheet standards) bitter much? :)
<sb0> rjo, why jabom?
* sb0 just received an invitation to a "ceremony cum networking session" (sic) to "drive the collaboration among industries, universities and research institutions in HK" and "help startups to know more about the needs of angel investors"
* sb0 is answering with a talk proposal about not giving a damn about venture capitalists
<whitequark> hah
<ccube> can I somehow add a second serial port to my design to have two uart interfaces for communication? want to have one for a serial terminal (status messages) and another one for transmitting binary data
<sb0> yes
<sb0> just use a different name for the 2nd one
<sb0> you may need to modify the driver a little bit so you can create multiple instances of it
<ccube> sb0, okay, but does the device create another /dev/ttyUSBx device when connecting to computer then?
<ccube> or how can I connect to either of them when having 2 seria;l ports?
<mithro> rjo: you should run the xilinx output through https://raw.githubusercontent.com/xobs/novena-ws2812b-fpga/master/synth/colormake.pl - it makes the output slightly nicer
<sb0> ccube, obviously you need a second usb/serial converter connected to the fpgs
<sb0> fpga
<sb0> though if you don't have it already, it's probably better to multiplex stuff on the same serial device
<whitequark> GSM 07.10 *ducks*
fengling has joined #m-labs
<larsc> there is even kernel support for that
<sb0> ysionneau, can you update artiq_flash.sh so it supports the kc705?
<ysionneau> sb0 : I've never flashed kc705, which tool is needed?
<sb0> xc3sprog -c jtaghs1_fast
<sb0> and a different flash proxy bitstream
<sb0> otherwise same as papilio
<ysionneau> ok cool
<ysionneau> thx for the quick review on flash_storage, btw I know it still misses a lot of stuff, for instance erasing and rewriting when the sector is full, to get rid of the duplicated keys
<sb0> ah and different fbi address
<ysionneau> btw, how do I know which sector will I use for storage?
<ysionneau> do we reserve some high address? or a very low address (right after bitstream?) and then we move bios+runtime higher in memory?
<ysionneau> I guess to be safe from runtime/bios getting bigger, we should put that right after the bitstream
<sb0> right after fbi
<sb0> right after bitstream needs changing a bunch of addresses
<ysionneau> yes
<sb0> and getting them wrong results in frustrating debugging
<sb0> just reserve some 256KB for fbi
<ysionneau> but what happens if you use the core device, you store some piece of information on it, then you update the runtime which gets a bit bigger and then overwrites the storage sector?
<ysionneau> ah
<sb0> then you need to reconfigure the device, which isn't something exceptional after a major runtime update
<ysionneau> alright then
<sb0> you could even make it 128K since we are loading the kernels 128K after the runtime start in the sdram
bhamilton has joined #m-labs
bhamilton has quit [Remote host closed the connection]
bhamilton has joined #m-labs
bhamilton has quit [Remote host closed the connection]
ccube has quit [Remote host closed the connection]
ccube has joined #m-labs
ccube has quit [Remote host closed the connection]
ccube has joined #m-labs
ccube has quit [Remote host closed the connection]
ccube has joined #m-labs
T4b__ has joined #m-labs
<ccube> relocation truncated to fit: R_LM32_CALL against undefined symbol `fwrite'? its prototype is in include/stdio.h, but what to link?
<ccube> seems not available on libbase, implemented my own
antgreen has joined #m-labs
<kristianpaul> a cpu smaller than j1?
<ccube> can I do more than 115200 baud with misoc uart interface on papilio pro?
<ysionneau> yes
<ccube> cool
<ccube> 1M?
<ysionneau> if I remember correctly I had up to 3 Mbps
<ccube> uuh, nice
<ysionneau> 1M was definetely working
<ccube> can I change the baud setting from my derived SoC class?
<ccube> or what is the best to configure it?
<ysionneau> if you derive from SoC then you can just pass uart_baudrate=something when instanciating
<ysionneau> you can also change the baudrate at runtime, without resynthesizing
<ccube> oh, thats even better
<ysionneau> you just need to write to the "frequency tuning word" CSR register
<ccube> static inline void uart_phy_tuning_word_write(unsigned int value)
<ccube> ?
<ysionneau> if the device receives some RPC request to switch baudrate, it writes to the CSR calling uart_phy_tuning_word_write()
<ysionneau> yes
<ysionneau> for how to compute the ftw : ftw = ((long long)the_new_baudrate << 32LL)/(long long)identifier_frequency_read();
<ccube> yep
<ysionneau> (same file but line 197)
sh[4]rm4 has quit [Remote host closed the connection]
sh[4]rm4 has joined #m-labs
<ccube> ysionneau, thx
<ccube> seems like 115200*10 is kind of my limit
<ysionneau> you don't get it to work faster?
<ccube> no :(
<ysionneau> it can depend on which software you use on the host side also
<ccube> 96kb/s seems to work
<ccube> yeah, I have to use RXTX :/
<ccube> dont know if there ar elimits in java library
<ccube> rxtx source says max 4M
<ccube> or maybe not... dont know. but ~100kb/s is pretty cool
<ccube> thx mate
<ysionneau> you're welcome :)
sh[4]rm4 has quit [Remote host closed the connection]
rofl__ has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
<sb0> rjo, should we use _logger in modules, instead of logger?
<sb0> so there's no namespace clash when doing import *
<GitHub39> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/ve7Fv
<GitHub39> artiq/master cb2596b Sebastien Bourdeauducq: coredevice/comm: split protocol to allow reuse for Ethernet
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#102 (master - cb2596b : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<GitHub73> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/ve5vF
<GitHub73> artiq/master f427041 Sebastien Bourdeauducq: coredevice/comm_serial: minor cleanup
<GitHub73> artiq/master 88e0aae Sebastien Bourdeauducq: coredevice: add comm_tcp
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#103 (master - 88e0aae : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<rjo> sb0: jabom: just a bunch of modules.
<rjo> mithro: dunno. then, if someone wants to download the build logs and process them, the control codes are tedious.
<rjo> sb0: i would manage the namespaces using one of two different methods which both tends to require fewer "_": 1) use __all__ 2) populate the namespaces in __init__.py
<rjo> since IME you tend to want to import * only from higher level things, i.e. directories or __init__.py the later one is really easy to manage.
sh[4]rm4 has joined #m-labs
rofl__ has quit [Ping timeout: 265 seconds]
<rjo> ysionneau: let me see whether i can fix that vivado-flex thing.
<rjo> amp_amp_amp_amp_bus_....
<rjo> didn't we want ise because of a problem with vivado 2014.2 and mor1kx?
<rjo> nah. that vivado thing doesnt like being trimmed.