05:33 <sf-slack4> <timo.callahan> General *Renode* question about monitor commands: Let's say I've set `foo` to a numeric value. How can I do "echo Foo is $foo" and get an output e.g. "Foo is 256"? Renode doesn't like it directly without quotes (`echo Foo is $foo`), and if I try `echo "Foo is $foo"`, I get `Foo is $foo`. I've tried playing with the `string` command but haven't found a way that it helps. My fallback is this: `echo -n

05:33 <sf-slack4> "Foo is "` `echo $foo`

05:53 <tcal> Hmm, that last bit didn't come across the bridge very well. Let me retype it without the code markdown:

05:53 <tcal> echo -n "Foo is "

05:53 <tcal> echo $foo

08:05 <sf-slack4> <mkurc> @olof.kindgren Hi. So to recap: You are trying to get a design with pre-initialized RAM content into EOS S3 and then read it back, right? Are you doing that with a pure HDL design or with QORC SDK? I'm trying to narrow down where the issue may be.

08:32 <sf-slack4> <olof.kindgren> Well, it's something in between. Since I can't load a bitstream directly to the device I need to embed it into a C program

08:33 <sf-slack4> <olof.kindgren> But in the later stages I started hacking the _bit.h file directly and just rebuilding the ELF from there

08:35 <sf-slack4> <olof.kindgren> But yes, in the end I'm trying to get a design with pre-initialized RAM content into EOS S3 and then read it back

08:36 <sf-slack4> <olof.kindgren> My observations is that the 32-bit word I specify in the $readmemh hex file gets split into two 16-bit words by yosys or vpr and get padded with a parity bit

08:37 <sf-slack4> <olof.kindgren> And when it's written to memory, first all the lower 16 bits are written and then the upper 16 bits. But it seems like I can only read back the lower 16 bits correctly

08:37 <sf-slack4> <mkurc> Ok, I see

08:38 <sf-slack4> <olof.kindgren> And since I don't have any good debugging solution, all I can do is to guess the value of a memory address and turn on a LED if it's correct

08:38 <sf-slack4> <olof.kindgren> So the process is a bit slow

08:39 <sf-slack4> <mkurc> Mhm. I'm thinking about a test that would not require the SoC. Just to narrow down the issue.

08:40 <sf-slack4> <olof.kindgren> Wait, there's one more clue

08:41 <sf-slack4> <olof.kindgren> The memory contents in both ram.mem and the _bit.h file consist of 1024 32-bit words (of which 18 bits in each words are actually used)

08:41 <sf-slack4> <olof.kindgren> So as I said, the lower 16 bits of address 0 correspond to the first word in the memory array

08:42 <sf-slack4> <olof.kindgren> But it looks like the upper 16 bits of address 0 is related to word 1023 in the array

08:42 <sf-slack4> <olof.kindgren> i.e. the last word

08:43 <sf-slack4> <olof.kindgren> It would be very interesting to see if we can find which word that corresponds to the upper 16 bits of address 1 in the RAM

08:43 <sf-slack4> <olof.kindgren> I had a theory that the upper half was reversed for some reason so I tried to hack the mem init function to write the top half backwards but that didn't seem to change anything

08:46 <sf-slack4> <mkurc> But you are programming both the eFPGA and RAM using the ARM core (i.e. the ARM writes the data) You are not using JTAG to do that?

08:47 <sf-slack4> <olof.kindgren> Correct

08:47 <sf-slack4> <mkurc> (I'm asking as there is a separate script for initializing RAM via JTAG)

08:47 <sf-slack4> <mkurc> ok

08:48 <sf-slack4> <olof.kindgren> But that script is for extracting data from ram.mem, right?

08:51 <sf-slack4> <mkurc> Not exactly. When you have an initialized RAM instanced in Verilog, the content is set as parameters of the RAM cell. Then it goes through VPR and gets written to the output FASM file as a number of "virtual" bitstream features. It is then extracted from there and converted into a series of system bus writes that get executed via JTAG.

08:51 <sf-slack4> <mkurc> But that happens only when you program the FPGA via JTAG

08:52 <sf-slack4> <olof.kindgren> aha

08:53 <sf-slack4> <olof.kindgren> Is that kind of the same thing that happens in the `init_fpga_mem` function in `fpga_loader.c` in qorc-sdk?

08:53 <sf-slack4> <mkurc> Indeed, but the data source is different.

08:53 <sf-slack4> <olof.kindgren> Ah ok. That's interesting

08:54 <sf-slack4> <mkurc> The code that runs on ARM core programs the eFPGA and RAM in the same way

08:54 <sf-slack4> <mkurc> but it gets the data from the program memory (like any other constants)

08:54 <sf-slack4> <olof.kindgren> By writing to 0x40020000 or something like that?

08:55 <sf-slack4> <mkurc> I'd need to double check the address, but yes

08:55 <sf-slack4> <olof.kindgren> Yeah, I'm not sure that was the exact address either, but something like that

08:55 <sf-slack4> <olof.kindgren> Think RAMFIFO3 was at 0x4001B000

08:57 <sf-slack4> <mkurc> mhm

08:57 <sf-slack4> <olof.kindgren> Btw, there's a typo (I guess) for the RAMFIFO2 base address in EOSS3-Registers.xlsx

09:34 <sf-slack4> <mkurc> @olof.kindgren In your HDL design is the RAM inferred by Yosys or instanced explicitly?

09:42 <sf-slack4> <olof.kindgren> Inferred

09:45 <sf-slack4> <olof.kindgren> I haven't made a minimal test case out of this. I'm using my regular servant design with a small hack to turn on a LED depending on memory contents of a certain address

09:49 <sf-slack4> <mkurc> Ok, I see. I'll do some checks to verify that the SymbiFlow part of RAM initialization works as expected.

15:30 <_whitenotifier-f> [symbiflow-arch-defs] acomodi opened issue #1776: Instability due to small changes to memory initialization - https://git.io/JkcwM

19:05 <_whitenotifier-f> [symbiflow-examples] mithro opened issue #63: Add Nexys Video examples into the repository - https://git.io/JkcpN

19:09 <mithro> litghost: https://github.com/SymbiFlow/symbiflow-examples/issues/63

20:15 <mithro> https://skywater-openfpga.readthedocs.io/en/latest/

20:15 <tpb> Title: Welcome to SKywater-OpenFPGA documentation! Skywater-OpenFPGA Chips 1.0 documentation (at skywater-openfpga.readthedocs.io)

22:19 <_whitenotifier-f> [xc-fasm] HackerFoo opened issue #5: Implement parsing to a bit vector in C++ - https://git.io/JkCZr

22:22 <HackerFoo> litghost mithro: https://github.com/SymbiFlow/xc-fasm/issues/5

22:22 <HackerFoo> ctypes is pretty easy to use, for what I need.

22:22 <HackerFoo> https://github.com/HackerFoo/cpyo

22:31 <mithro> @HackerFoo This really needs to be a Google Doc

22:31 <mithro> @HackerFoo You also haven't enumerated the requirements

22:33 <HackerFoo> Okay. I'll write some more in a doc.

23:56 <cjearls> I'd like to attempt to compile a design to an ECP5 with a soft core, but I'm not sure if the design will even fit on the ECP5. What's the fastest way to see if a design will fit that requires the least initial configuration?