Ideas

[enjoy-digital]

You have an idea about possible improvement(s) to the project but this is difficult to know if this is realistic or how much work it could be involved, please use this issue to share your idea and discuss it with us.

(We are trying to only keep realistic issues opened to allow us to use Github issues as a useful tool and so try to avoid too much opened issues for non-realistic short/mid-term tasks)

[enjoy-digital]

From @hansfbaier (https://github.com/enjoy-digital/litex/issues/765):

Modularize generated verilog: Separate modules into files and put wiring in top.v: Currently, litex generateds some monolithic 20k loc verilog file, which is humanly next to incomprehensible. It would help greatly to factor out all hardware modules into separate files each and put the wiring only in the top.v module.

From @hansfbaier (https://github.com/enjoy-digital/litex/issues/766):

produce colorful wiring diagrams to visualize the generated SoC: Qsys on altera produces a nice graphical representation of the SoC that is being built. It would be great to have a generator that produces a nice wiring block diagram (eg in SVG) which makes it possible to understand how all the modules are wired together.

[hansfbaier]

produce colorful wiring diagrams to visualize the generated SoC: Qsys on altera produces a nice graphical representation of the SoC that is being built. It would be great to have a generator that produces a nice wiring block diagram (eg in SVG) which makes it possible to understand how all the modules are wired together. I just found a project which generates pretty wiring diagrams from Yosys output: netlistsvg

[enjoy-digital]

Hi @hansfbaier,

thanks for the ideas, improving the verilog generation is indeed something we'd like to improve in the long term. Sadly removing this limitation requires non-trivial changes to Migen or a switch for LiteX to another HDL DSL. So we are considering evaluating nMigen or have our own HDL DSL for that: https://github.com/enjoy-digital/litex/wiki/Migen-nMigen. This is difficult for now to provides a timeline for this. Any help to go in this direction as a proof of concept or tests with an existing project is welcome.

For the diagram creation, this is also a good idea and something we could try to add while reworking the HDL generation.

[tcal-x]

Modifications for litex_bare_metal_demo to run on Fomu and Icebreaker.

I've been able to get the demo to run on both the Fomu and Icebreaker boards. It required modification of linker.ld to put the sections into sram instead of main_ram, and also adding a reserved section at the beginning of the sram region so that the binary being loaded doesn't overwrite the BIOS working memory. And also, adding a --kernel-adr option to the lxterm command is required.

I was writing this up as a blog post about how to hack stuff to get it to work, but then it occurred to me that it wouldn't be that much work (?) to get the demo itself to use an alternative linker.ld for Fomu and Icebreaker, based on information from the BUILD_DIR that is specified.

But maybe there's a better, less hacky way to do this.

[mithro]

@tcal-x We should most certainly figure out how to make this work without needing the hacks.

[enjoy-digital]

@tcal-x: would you mind sharing you changes as a diff? I could have a look at this.

[tcal-x]

diff linker.ld-orig linker.ld-icebreaker

9a10,14
>         .dummy :
>         {
>                 . += 0x3000;
>         } > sram
> 
15c20
<       } > main_ram
---
>       } > sram
24c29
<       } > main_ram
---
>       } > sram
35c40
<       } > main_ram
---
>       } > sram

Then in demo/, rebuild:

make BUILD_DIR=../build/icebreaker clean
make BUILD_DIR=../build/icebreaker

Then run it:

lxterm --kernel=demo.bin --kernel-adr=0x3000  /dev/ttyUSBX

It is exactly the same for Fomu, except of course change BUILD_DIR, and the device is /dev/ttyACMX.

[mithro]

You might want to do a diff -u for an easier to understand diff.

[tcal-x]

Sure,

--- linker.ld-orig      2020-12-22 23:11:21.000000000 -0800
+++ linker.ld   2021-02-16 10:33:43.115360051 -0800
@@ -7,12 +7,17 @@

 SECTIONS
 {
+        .dummy :
+        {
+                . += 0x3000;
+        } > sram
+
        .text :
        {
                _ftext = .;
                *(.text .stub .text.* .gnu.linkonce.t.*)
                _etext = .;
-       } > main_ram
+       } > sram

        .rodata :
        {
@@ -21,7 +26,7 @@
                *(.rodata .rodata.* .gnu.linkonce.r.*)
                *(.rodata1)
                _erodata = .;
-       } > main_ram
+       } > sram

        .data :
        {
@@ -32,7 +37,7 @@
                _gp = ALIGN(16);
                *(.sdata .sdata.* .gnu.linkonce.s.*)
                _edata = .;
-       } > main_ram
+       } > sram

        .bss :
        {

[mithro]

It seems like there are two pieces;

• If main_ram doesn't exist, then sram should be used.
• The sram block should also had padding to the size needed by the bios.

[tcal-x]

Yep, although there's other ways of doing it, for example, you could modify regions.ld to split the sram into two regions, and call the upper region main_ram. Then (I think) you don't need to modify linker.ld. But you'd still need to adjust the --kernel-adr option to lxterm. I didn't like that approach since it meant modifying stuff under the LiteX build/ (build/icebreaker/software/include/generated/regions.ld). But just now I realized that you could make a local copy of regions.ld in the demo/ directory and use that...it should work but I haven't tested it. Edit: but then you'd need to edit linker.ld to refer to the local regions.ld

I may be missing an even simpler approach, so I'm glad other people are taking a look.

[mithro]

@tcal-x -- Maybe LiteX could understand that the main_ram region is just the unused region of the sram region if the main_ram is not otherwise added?

[enjoy-digital]

Closing, this is probably too generic and drifted quiclky to specific discussions. Let's switch back to issues for discussing ideas.