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?
* 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?
<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
<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.