09:59 <pepijndevos> What are named_pc?

09:59 <pepijndevos> Seems all build targets just yeet them at the end of the constraints

12:06 <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

12:06 <pepijndevos> that's simple.py

12:12 <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...

12:15 <pepijndevos> wait no... confusion...

12:21 <zyp> 0x2000 is 8kB or 64 kbits

12:23 <pepijndevos> yea so 468K is like 10 times more right... if i'm not completely mad

12:23 <zyp> sounds right, yes

12:24 <pepijndevos> Maybe it's using a whole BRAM for every tiny array in there... but hard to tell

12:24 <pepijndevos> I also can't find out what I may do with RAM_STYLE

12:25 <pepijndevos> I get that may cause some things to synth to lutram which sounds great... but how

13:11 <pepijndevos> hurray, I made a bunch of random brams in vexrisc distributed and we'll see... it's veeeery tight

13:14 <pepijndevos> Like, it uses 26 out of 26 brams and if i use one more lutram it runs out of those haha

14:04 <lkcl> _florent_, daveshah: https://libre-soc.org/180nm_Oct2020/2020-09-28_15-02.png

14:05 <lkcl> litex to define the IO pads :)

14:33 <_florent_> lkcl: nice

14:35 <_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

14:35 <tpb> Title: litex-boards/icebreaker.py at master · litex-hub/litex-boards · GitHub (at github.com)

14:36 <_florent_> pepijndevos: but it's easier to start with the ROM in the FPGA when possible

14:36 <pepijndevos> oooh okay :)

14:44 <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?

14:47 <pepijndevos> CHASER!!

14:48 <pepijndevos> also with openfpgaloader... but still gives fail

14:49 <pepijndevos> I'm just stuck at [LXTERM] Starting.... now

14:54 <_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

14:54 <tpb> Title: litex/simple.py at master · enjoy-digital/litex · GitHub (at github.com)

14:55 <pepijndevos> ah ok thanks

14:55 <_florent_> you can use something like: CRG(platform.request(platform.default_clk_name), platform.request("rst))

14:56 <pepijndevos> getting so cloooose to working soc...

14:57 <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.

14:58 <pepijndevos> oops, rst is inverted...

15:02 <pepijndevos> works!!! now some hello world...

15:08 <pepijndevos> bleg... the fpga_101 expects a common makefile which does not seem to be there

15:20 <pepijndevos> okay I got a binary from icerbreaker examples... but, still no cigar.

15:22 <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"

15:22 <pepijndevos> Then nothing.

15:22 <pepijndevos> I've passed the binary with --kernel

15:27 <_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?

15:28 <pepijndevos> _florent_, I now have it in bram with a few things moved to lutram

15:29 <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

15:30 <_florent_> it's not fully working if you are not able to get the prompt

15:31 <pepijndevos> alright, so just "lxterm /dev/ttyUSB0" should get me a prompt right?

15:31 <_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)

15:31 <_florent_> yes

15:31 <pepijndevos> Yea, I was about to try a different CPU.

15:31 <pepijndevos> Maybe VexRisc doesn't like some of its bits moved to lutram hehe

15:35 <_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)

15:35 <pepijndevos> haha yea i had exactly this problem again

15:36 <pepijndevos> heyyyy! now the bios works

15:38 <pepijndevos> but my blinky does not... :((((

15:45 <lkcl> _florent_: one thing that's missing is the SDRAM dqm 0/1 bits

15:48 <lkcl> from GenSDRPHY

15:48 <lkcl> https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/gensdrphy.py#L76

15:48 <tpb> Title: litedram/gensdrphy.py at master · enjoy-digital/litedram · GitHub (at github.com)

15:48 <pepijndevos> well duh because the blinky has the memory regions all wrong for the icebreaker... okay back to linker land I guess...

15:50 <pepijndevos> I'll see if I can get my Rust HAL to work on it tomorrow or something

15:50 <pepijndevos> And then write a proper platform/target. Should I add those to litex or litex-boards?

15:50 <lkcl> _florent_: can those be wired to dfi.p0.wrdata_mask?

15:51 <_florent_> lkcl: i'll have a look

15:52 <_florent_> pepijndevos: are you still using VexRiscv? you can do a PR to litex-boards

15:54 <lkcl> i'm guessing this:

15:54 <lkcl> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=cd8119ebba7ce080cf17a6c147db92edbedd27f5;hb=5b4254bea20b8562872cc94b889fd0e18e0a41e1#l228

15:54 <tpb> Title: git.libre-soc.org Git - soc.git/blob - src/soc/litex/florent/ls180soc.py (at git.libre-soc.org)

15:55 <pepijndevos> _florent_, no I'm using PicoRV for now. I'll try VexRiscv again once I moved the rom to SPI.

16:45 <yosys-questions> Is there a way to leverage the use of Xilinx's URAM (UltraRAM) for Ultrascale+ devices?

17:51 <daveshah> A large enough RAM should map automatically

17:52 <daveshah> I've seen this happen with LiteX designs in the past, anyway

18:32 <yosys-questions> daveshah .. Interesting, thanks!

22:50 <somlo> https://github.com/litex-hub/linux/tree/litex-rocket-rebase now has a more-or-less working litesdcard driver

22:50 <tpb> Title: GitHub - litex-hub/linux at litex-rocket-rebase (at github.com)

22:51 <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

22:52 <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

22:53 <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)

22:56 <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" :)