_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
tpb has quit [Remote host closed the connection]
tpb has joined #litex
jaseg has joined #litex
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #litex
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #litex
acathla has joined #litex
acathla has quit [Changing host]
acathla has joined #litex
jaseg has quit [Ping timeout: 240 seconds]
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 240 seconds]
<pepijndevos> What are named_pc?
<pepijndevos> Seems all build targets just yeet them at the end of the constraints
scientes has joined #litex
scientes has quit [Changing host]
<pepijndevos> uhoh ERROR (RP0002) : The number(31) of BSRAM in the design exceeds the resource limit(26) of current device. And RAM_STYLE maybe the useful user assignment to change the inference result
<pepijndevos> that's simple.py
<pepijndevos> It apparently has 468K bits of bram, while SoCCore has 0x2000 bytes? So 65536 bits? Yea I can see how that wouldn't fit...
<pepijndevos> wait no... confusion...
<zyp> 0x2000 is 8kB or 64 kbits
<pepijndevos> yea so 468K is like 10 times more right... if i'm not completely mad
<zyp> sounds right, yes
<pepijndevos> Maybe it's using a whole BRAM for every tiny array in there... but hard to tell
<pepijndevos> I also can't find out what I may do with RAM_STYLE
<pepijndevos> I get that may cause some things to synth to lutram which sounds great... but how
<pepijndevos> hurray, I made a bunch of random brams in vexrisc distributed and we'll see... it's veeeery tight
<pepijndevos> Like, it uses 26 out of 26 brams and if i use one more lutram it runs out of those haha
<lkcl> litex to define the IO pads :)
<_florent_> lkcl: nice
<_florent_> pepijndevos: in case you are short on BRAMs, it's possible to remove the ROM and execute directly code from SPI Flash, as it's done for example on the iCEBreaker target (for the same reasons): https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/icebreaker.py
<tpb> Title: litex-boards/icebreaker.py at master · litex-hub/litex-boards · GitHub (at github.com)
<_florent_> pepijndevos: but it's easier to start with the ROM in the FPGA when possible
<pepijndevos> oooh okay :)
<pepijndevos> and uh... on the ULX3S I have to press the reset button before it goes into lxterm, but on simple.py I don't see anything like a reset button configured, which bits take care of that?
<pepijndevos> CHASER!!
<pepijndevos> also with openfpgaloader... but still gives fail
<pepijndevos> I'm just stuck at [LXTERM] Starting.... now
<_florent_> pepijndevos: the second parameter (optional) parameter here should be the reset signal: https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/simple.py#L36
<tpb> Title: litex/simple.py at master · enjoy-digital/litex · GitHub (at github.com)
<pepijndevos> ah ok thanks
<_florent_> you can use something like: CRG(platform.request(platform.default_clk_name), platform.request("rst))
<pepijndevos> getting so cloooose to working soc...
<pepijndevos> I should probably try the spi flash trick... how do you get the rom into the spi though... I assume that requires some trickery with the programmer.
<pepijndevos> oops, rst is inverted...
<pepijndevos> works!!! now some hello world...
<pepijndevos> bleg... the fpga_101 expects a common makefile which does not seem to be there
<pepijndevos> okay I got a binary from icerbreaker examples... but, still no cigar.
<pepijndevos> When I press reset it does the LiteX header, of which the last line is "BIOS built on Sep 28 2020 17:00:16"
<pepijndevos> Then nothing.
<pepijndevos> I've passed the binary with --kernel
<_florent_> pepijndevos: sorry i'm not sure to understand, do you have the ROM on BRAM? are you able to get the LiteX BIOS working?
<pepijndevos> _florent_, I now have it in bram with a few things moved to lutram
<pepijndevos> I'm not sure when the bios is considered "working", it displays an ascii art and some copyright and version info, but does not download the kernel or offer a prompt
<_florent_> it's not fully working if you are not able to get the prompt
<pepijndevos> alright, so just "lxterm /dev/ttyUSB0" should get me a prompt right?
<_florent_> which CPU are you using? VexRiscv? if so could you try with SERV (this will reduce resource usage and use polling mode for UART)
<_florent_> yes
<pepijndevos> Yea, I was about to try a different CPU.
<pepijndevos> Maybe VexRisc doesn't like some of its bits moved to lutram hehe
<_florent_> ah also, if you change the CPU, be sure to remove your build directory first :) (IIRC you already had this issue when playing with the ULX3S & Rust)
<pepijndevos> haha yea i had exactly this problem again
<pepijndevos> heyyyy! now the bios works
<pepijndevos> but my blinky does not... :((((
<lkcl> _florent_: one thing that's missing is the SDRAM dqm 0/1 bits
<lkcl> from GenSDRPHY
<tpb> Title: litedram/gensdrphy.py at master · enjoy-digital/litedram · GitHub (at github.com)
<pepijndevos> well duh because the blinky has the memory regions all wrong for the icebreaker... okay back to linker land I guess...
<pepijndevos> I'll see if I can get my Rust HAL to work on it tomorrow or something
<pepijndevos> And then write a proper platform/target. Should I add those to litex or litex-boards?
<lkcl> _florent_: can those be wired to dfi.p0.wrdata_mask?
<_florent_> lkcl: i'll have a look
<_florent_> pepijndevos: are you still using VexRiscv? you can do a PR to litex-boards
<lkcl> i'm guessing this:
<lkcl> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=cd8119ebba7ce080cf17a6c147db92edbedd27f5;hb=5b4254bea20b8562872cc94b889fd0e18e0a41e1#l228
<tpb> Title: git.libre-soc.org Git - soc.git/blob - src/soc/litex/florent/ls180soc.py (at git.libre-soc.org)
<pepijndevos> _florent_, no I'm using PicoRV for now. I'll try VexRiscv again once I moved the rom to SPI.
yosys-questions has joined #litex
<yosys-questions> Is there a way to leverage the use of Xilinx's URAM (UltraRAM) for Ultrascale+ devices?
<daveshah> A large enough RAM should map automatically
<daveshah> I've seen this happen with LiteX designs in the past, anyway
CarlFK has quit [Read error: No route to host]
CarlFK has joined #litex
<yosys-questions> daveshah .. Interesting, thanks!
yosys-questions has quit [Remote host closed the connection]
_whitelogger has joined #litex
<somlo> https://github.com/litex-hub/linux/tree/litex-rocket-rebase now has a more-or-less working litesdcard driver
<tpb> Title: GitHub - litex-hub/linux at litex-rocket-rebase (at github.com)
<somlo> started with the Antmicro driver, made it portable for 32-bit csr-data-width, fixed sdcard clocking, am generally able to mount and read/write a sdcard
<somlo> major remaining wart is that the sdcard must be plugged in during kernel boot, and ejecting and re-inserting it is not currently handled
<somlo> (although I can see the gateware CD register holding the correct value in the bios, so most likely additional scrubbing of the linux driver is needed)
<somlo> right now the litex_mmc commits are "raw" (reflecting my haphazard hacking of the antmicro starting point). Once I get to the bottom of the card-detect problem, I'll do a clean-up rebase to "hide the sausage-making process" :)
lf has quit [Ping timeout: 240 seconds]
lf has joined #litex