Friday, 2019-05-17

*** tpb has joined #litex00:00
*** femto has joined #litex00:43
femtomithro: fwiw, tinyprog writes, but the final read to compare the data is always cut off00:45
mithrofemto: Are you using a vm?00:53
*** femto has quit IRC01:08
*** femto has joined #litex01:18
*** femto has quit IRC01:29
*** femto has joined #litex04:24
*** futarisIRCcloud has joined #litex08:42
tpbTitle: Google fosters the open source hardware community | Google Open Source Blog (at
keesjHow, nice.. I was literaly writing notes down on the why of open silicon! thanks09:04
keesj(linked from the other atricle)09:05
keesjGoogle is planning to contribute a Universal Verification Methodology (UVM)-based instruction stream generator environment for RISC-V cores.09:05
keesjsounds .. cool/ scarry / AI??09:05
femtoAnyone else run into the gateware flash size issue on the TinyFPGA BX board?
tpbTitle: make gateware-flash "FAILED!" on TinyFPGA BX · Issue #137 · timvideos/litex-buildenv · GitHub (at
*** femto has left #litex10:57
*** futarisIRCcloud has quit IRC11:01
keesjI am wondering why I see 2 times python -m -f firmware.bin -o firmware.fbi11:35
keesja.. gone11:35
somlo_florent__: with the LiteDRAM generator, assuming one specifies an AXI user port, at what physical address is the DRAM actually mapped (e.g., on nexys4ddr)?13:43
_florent__somlo: in this case there is no mapping, you are just accessing the DRAM14:24
somloso the DRAM essentially starts at AXI address 0x0000_000014:28
somloif the AXI master wanted to write/read to/from it, that is, via the AXI user port14:29
somlowhich would mean that a simple offset inserted into the master/slave AXI link *should* take care of translating that to whatever region the CPU thinks its RAM is mapped to, internally14:30
somlofeel free to kick me if I'm spouting nonsense :)14:30
_florent__yes that's it14:43

Generated by 2.13.1 by Marius Gedminas - find it at!