_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
rohitksingh has joined #litex
<awygle> _florent_: is there documentation of how litex streams are intended to work, other than the source file? (i'm continuing to investigate a design for nmigen streams)
palmer has quit []
palmer_ has joined #litex
palmer has joined #litex
palmer has quit [Quit: authenticating]
palmer has joined #litex
palmer is now known as Guest75209
Guest75209 has quit [Client Quit]
Guest75209 has joined #litex
Guest75209 has quit [Quit: authenticating]
Guest752091 has joined #litex
Dolu has quit [Ping timeout: 260 seconds]
Dolu has joined #litex
Guest752091 is now known as palmer
<somlo> _florent_: so, tomorrow when I'm back in the office I'll try specifying ClockSignal("clk100") explicitly, since I just realized I can do that :)
rohitksingh has quit [Ping timeout: 245 seconds]
simeonm has joined #litex
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #litex
CarlFK has joined #litex
<_florent_> awygle: sorry, there are not that much information, the basis is what i described in https://github.com/nmigen/nmigen/issues/317#issuecomment-583277029, so a Record of signal very similar to a simplified AXI that forms an Endpoint
<tpb> Title: Stream Abstraction for nmigen.lib · Issue #317 · nmigen/nmigen · GitHub (at github.com)
<_florent_> each module then has sink(s) and source(s) that you connect together with self.comb += module0.source.connect(module1.sink)
esden has quit [Ping timeout: 248 seconds]
futarisIRCcloud has quit [Ping timeout: 248 seconds]
daveshah has quit [Ping timeout: 248 seconds]
_florent_ has quit [Ping timeout: 248 seconds]
esden has joined #litex
daveshah has joined #litex
futarisIRCcloud has joined #litex
_florent_ has joined #litex
m4ssi has joined #litex
<acathla> I just found the right board definition file in... migen : migen/build/platforms/ice40_up5k_b_evn.py, but not in litex nor litex-boards
<_florent_> acathla: if you look for a board in addition to litex-boards you can look at https://github.com/m-labs/migen/tree/master/migen/build/platforms and https://github.com/timvideos/litex-buildenv/tree/master/platforms, you should be able to reuse it almost directly. The ones in litex-boards are the ones that have been contributed by LiteX developers that are tested with LiteX.
<tpb> Title: migen/migen/build/platforms at master · m-labs/migen · GitHub (at github.com)
sajattack[m] has quit [*.net *.split]
sajattack[m] has joined #litex
<acathla> Info: ICESTORM_LC: 76070/ 7680 990%
<acathla> when I try to add LiteEthMAC to my design (when adding the self.add_wb_slave() about that ethmac)
<acathla> What could cause that?
<_florent_> hmm, this is probably the SRAMs of the MAC that are implemented as logic, what's the resource usage without LiteEthMAC?
<acathla> _florent_, ICESTORM_LC: 1020/ 7680 13%
<acathla> _florent_, I just see some FIFOs I can reduce a bit
<acathla> and ICESTORM_RAM: 1/ 32 3% without LiteEthMAC
<acathla> ICESTORM_RAM: 9/ 32 28% with it
<pdp7> _florent_: thanks for the response about JTAG on the arty. I'm trying it out now. This is the first time I've used this Arty. Only other experience was mithro walked me through litex-buildenv on an Arty at FOSDEM
<pdp7> I'm following "Installing OpenOCD (only needed for hardware test)" now from linux-on-litex-vexriscv
ambro718 has joined #litex
m4ssi has quit [Ping timeout: 248 seconds]
m4ssi has joined #litex
m4ssi has quit [Ping timeout: 255 seconds]
m4ssi has joined #litex
<_florent_> acathla: i could look if you are able to share your design
<_florent_> acathla: or you can create an issue with the files to reproduce on LiteX or LiteEth
m4ssi has quit [Remote host closed the connection]
<pdp7> _florent_: i'm trying to get my system to build arty
<pdp7> ./make.py --board=arty --build
<pdp7> ends in this error
pdp7 has quit [Excess Flood]
pdp7 has joined #litex
<pdp7> oops bad pasting
<pdp7> I think the issue is:
<pdp7> /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/rdiArgs.sh: line 179: 29301 Segmentation fault (core dumped) "$RDI_PROG" "$@"
<pdp7> but I am not sure what RDI is
<_florent_> pdp7: that's strange, have you already been able to build a design with your installed version of Vivado?
<pdp7> I was able to do it with litex-buildenv
<tpb> Title: litex/arty.py at master · enjoy-digital/litex · GitHub (at github.com)
<tpb> Title: HowTo LCA2018 FPGA Miniconf VexRiscv Renode · timvideos/litex-buildenv Wiki · GitHub (at github.com)
<pdp7> I'm doing:
<pdp7> pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ ./make.py --board=arty --build
<pdp7> I created symlink
<pdp7> /opt/Xilinx -> /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx
<_florent_> are you using litex-buildenv or litex directly?
<_florent_> before building, can you just do "source /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/VIvado2017.3/settings64.sh"?
<_florent_> sorry "source /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/VIvado/2017.3/settings64.sh"
<pdp7> ah, let try
<pdp7> ok,
<pdp7> pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ source /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/settings64.sh
<pdp7> pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ ./make.py --board=arty --build
<pdp7> but bit different error this time
<pdp7> source top.tcl
<pdp7> ERROR: [Common 17-685] Unable to load Tcl app xilinx::xsim
<pdp7> # create_project -force -name top -part xc7a35ticsg324-1L
<pdp7> ERROR: [Common 17-69] Command failed: ERROR: [Common 17-685] Unable to load Tcl app xilinx::xsim
<pdp7> INFO: [Common 17-206] Exiting Vivado at Wed Feb 19 19:00:55 2020...
<pdp7> running again
<pdp7> i now get:
<pdp7> /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/rdiArgs.sh: line 179: 30863 Segmentation fault (core dumped) "$RDI_PROG" "$@"
<CarlFK> pdp7: what distro/release ?
<pdp7> that line is:
<pdp7> "$RDI_PROG" "$@"
<pdp7> which turns out to be:
<pdp7> /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/unwrapped/lnx64.o/vivado
<pdp7> let me chec
<pdp7> pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ ldd /home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/unwrapped/lnx64.o/vivado
<pdp7> libtcmalloc.so.4 => not found
<pdp7> libboost_signals.so => not found
<pdp7> linux-vdso.so.1 (0x00007ffef2525000)
<pdp7> librdi_common.so => not found
<pdp7> libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7edd7ff000)
<pdp7> librdi_commonmain.so => not found
<pdp7> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7edd7e5000)
<pdp7> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7edd5f2000)
<pdp7> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7edd4a3000)
<pdp7> /lib64/ld-linux-x86-64.so.2 (0x00007f7edda0e000)
<pdp7> could be problem
<pdp7> @CarlFK Ubuntu 19.10
<pdp7> with Vivado 2017.3
<pdp7> _florent_: are there instructions with regard to linux-on-litex-vexriscv and vivado ?
<_florent_> the issue seems to be related to the Vivado version/Ubuntu version
<CarlFK> pdp7: your vivado seems to be 'broken' (or crashing...) give me 20 min and I'll try to set up the same thing here
<pdp7> yeah, installing some packages
<pdp7> also
<pdp7> export LD_LIBRARY_PATH=/opt/Xilinx/Vivado/2017.3/lib/lnx64.o:$LD_LIBRARY_PATH
<pdp7> hmmm
<pdp7> ldd is happy now
<pdp7> but
<pdp7> $ /opt/Xilinx/Vivado/2017.3/bin/unwrapped/lnx64.o/vivado
<pdp7> Error: The file is corrupt. Please re-install this software from the original media.
<pdp7> Aborted (core dumped)
m4ssi has joined #litex
<pdp7> pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ /opt/Xilinx/Vivado/2017.3/bin/vivado
<pdp7> DEBUG:RDI_PROG:/opt/Xilinx/Vivado/2017.3/bin/unwrapped/lnx64.o/vivado
<pdp7> **** SW Build 2018833 on Wed Oct 4 19:58:07 MDT 2017
<pdp7> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
<pdp7> ****** Vivado v2017.3 (64-bit)
<pdp7> **** IP Build 2016188 on Wed Oct 4 21:52:56 MDT 2017
<pdp7> start_gui
<pdp7> ERROR: [Common 17-267] Couldn't open 'libjvm.so': 'libjvm.so: cannot open shared object file: No such file or directory'
<pdp7> Make sure you are using a supported OS of RHEL5.x or greater.
<pdp7> ERROR: [Common 17-211] Error loading jvm.
<pdp7> Vivado%
<_florent_> if you have space (and time...) you should probably update your Vivado version to 2019.2
<pdp7> ok
<pdp7> Xilinx Unified Installer Update 1 - 2019.2 (TAR/GZIP - 9.03 GB)
<pdp7> sound right?
m4ssi has quit [Client Quit]
<pdp7> time to clean my hard drive
<pdp7> mithro: is symbiflow ready yet? :)
<CarlFK> pdp7: 22964656463 Xilinx_Vivado_SDK_2019.1_0524_1430.tar.gz
<pdp7> thanks
<CarlFK> hmm, 2019.2... looks more current than what I have...
<pdp7> i'm downloading Xilinx_Vivado_Vitis_Update_2019.2.1_1205_0436.tar.gz
<CarlFK> yeah, now I am too :p
<pdp7> 13 minutes left
<mithro> pdp7: Had the first success with DDR on the Arty yesterday
<pdp7> awesome!
<_florent_> mithro: great!
<pdp7> CarlFK: trying to install Xilinx_Vivado_Vitis_Update_2019.2.1_1205_0436 now
<CarlFK> pdp7: im confused... https://www.xilinx.com/support/download.html says "Vivado Design Suite 2019.2.1 is now available..."
<tpb> Title: Downloads (at www.xilinx.com)
<CarlFK> but I don't see 2019.2.1... where did you find it?
<pdp7> Xilinx Unified Installer Update 1 - 2019.2 (TAR/GZIP - 9.03 GB)
<pdp7> under Vivado Design Suite - HLx Editions Update 1 - 2019.2
<CarlFK> got it. thanks.
<pdp7> ugh... "there is no valid Xilinx installation that this update can be applied to"
<pdp7> CarlFK: ok, now I downloaded Xilinx_Unified_2019.2_1106_2127_Lin64.bin
<pdp7> ugh, it's a java program install wizard
<pdp7> hmm I have to choose between Vitis and Vivado
<pdp7> in radio button dialog
<pdp7> oh god, requires 46 GB
<somlo> _florent_: Thanks again for the litesdcard clocker fix, now https://hastebin.com/uleyeyilow.rb works with Rocket at 60MHz (and also with vexriscv at 100MHz and below)
<CarlFK> pdp7: yeah, yuck. you can install to a thumb drive and then make a sym link
<CarlFK> im trying to clear out space for the download before my disk fills up...
<CarlFK> rm ubuntu-19.10-desktop-amd64.iso 4G feed up.. not eneough...
<pdp7> wow, this is crazy... now i know why yosys and nextpnr is so nice
<CarlFK> geeze.. 3 hours of dl left.. 3.5 of 26 gig!!!
<pdp7> yikes
<pdp7> i'm going back trying to fix /opt/Xilinx/Vivado/2017.3/
<pdp7> stuck on
<pdp7> pdp7@x1:/opt/Xilinx/Vivado/2017.3$ vivado
<pdp7> DEBUG:RDI_PROG:/home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/unwrapped/lnx64.o/vivado
<pdp7> ****** Vivado v2017.3 (64-bit)
<pdp7> **** SW Build 2018833 on Wed Oct 4 19:58:07 MDT 2017
<pdp7> **** IP Build 2016188 on Wed Oct 4 21:52:56 MDT 2017
<pdp7> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
<pdp7> start_gui
<pdp7> ERROR: [Common 17-70] Application Exception: JVM classPath has not yet been set
<pdp7> ERROR: [Common 17-211] Error loading jvm.
<pdp7> Vivado% exit
<somlo> daveshah: random data point on trellisboard -- I noticed that generally correct and working Litex+Rocket bitstreams will pass memtest almost 100% of the time after the board has been plugged in and powered for "a while" (hours); however, after it's been unplugged for a while, it tends to fail memtest using the same exact bitstream
<somlo> so once it "warms up" it seems the DRAM circuitry tends to work better (and I literally mean I think temperature has something to do with it :) )
<daveshah> Seems quite plausible
<daveshah> I think 55-60MHz is the low end of what the internal delay loop thingy supports
<daveshah> stuff tends to get slower as it warms up
<somlo> I run it at 60MHz because I tend to be intimidated a bit by nextpnr "failing" to guarantee the requested fmax :)
<somlo> I could probably try 65MHz, but then if I start seeing random glitches while in linux I fear I'll have trouble blaming the appropriate layer...
<daveshah> Yeah, there's no way around it with rocket, unless you somehow ran litedram at a higher clock
<somlo> but anyway, I'm happy to hear the temperature thing makes sense -- thanks!
<sorear> might be interesting to experiment with a controlled temperature? maybe have it off for a while, but in an 80C oven
<pdp7> python3 -m litex.soc.software.mkmscimg bios.bin --little
<pdp7> **** SW Build 2018833 on Wed Oct 4 19:58:07 MDT 2017
<pdp7> ****** Vivado v2017.3 (64-bit)
<pdp7> **** IP Build 2016188 on Wed Oct 4 21:52:56 MDT 2017
<pdp7> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
<pdp7> source top.tcl
<pdp7> # create_project -force -name top -part xc7a35ticsg324-1L
<pdp7> ERROR: [Common 17-69] Command failed: ERROR: [Common 17-685] Unable to load Tcl app xilinx::xsim
<pdp7> ERROR: [Common 17-685] Unable to load Tcl app xilinx::xsim
<pdp7> INFO: [Common 17-206] Exiting Vivado at Wed Feb 19 21:03:40 2020...
<somlo> sorear: that'd be interesting indeed, but I'm not set up to do that test (I'm really just a software guy trying to fake it :D )
<pdp7> ugh, tcl and big binaries...
<pdp7> daveshah: can I use nextpnr for arty (artix7)? :)
<daveshah> You can but it's pretty finnicky at the moment
<pdp7> seems better than finding 40GB of space :)
<tpb> Title: GitHub - daveshah1/nextpnr-xilinx: Experimental flows using nextpnr for Xilinx devices (at github.com)
<pdp7> nice, there is Arty example in the readme. thanks
<daveshah> You can disable devices in Vivado to reduce the space it needs btw
<pdp7> looks like the smallest I can acheive is 40GB
rohitksingh has quit [Ping timeout: 260 seconds]
Dolu has quit [Ping timeout: 272 seconds]
davidc__ has quit [Quit: leaving]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined #litex
Dolu has joined #litex
<pdp7> mithro: any idea why this is failing?
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<tpb> Title: HowTo LCA2018 FPGA Miniconf VexRiscv Renode · timvideos/litex-buildenv Wiki · GitHub (at github.com)
rohitksingh has quit [Ping timeout: 258 seconds]
ambro718 has quit [Ping timeout: 258 seconds]
tpb has quit [Remote host closed the connection]
tpb has joined #litex