<ranzbak>
I'm struggeling with Litevideo code, and I can't really find documentation using Google, is there documentation available how to build a RGB -> video pipeline -> DDR3 ram -> VGA out?
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #litex
<acathla>
How do I know which part of a litex design is taking which amount of LC, BRAM, etc?
<zyp>
compare the numbers with a given part disabled or enabled?
<acathla>
zyp, that's a solution but a bit limited as some blocks can't be enabled alone
<zyp>
the problem is that the whole hierarchy of migen modules reduces into a single verilog module
<zyp>
external cores like the cpus and so on will still be their own modules, so they'll show up in the statistics
<acathla>
If I can output a verilog for a module, like an uart+phy, how can I synthetise it to know the LC usage?
<zyp>
I guess you could pull out part of the design, turn it into a standalone verilog module and then put it back in as an external module
<acathla>
Is that normal that a simple UART+UARTPhy takes 564 LC?
<daveshah>
I think high UART resource usage has previously been caused by the FIFOs not mapping to BRAM
<daveshah>
You could reduce the FIFO depth from 16 to 1/2 and see if that reduces resource usage
<lkcl>
hmmm, when generating the ls180 ASIC verilog i'm getting GPIO tristates being declared as inputs, SDRAM address as output reg and many other oddities
<lkcl>
output reg [12:0] sdram_a
<lkcl>
SDRAM address pins are not outputs!
<daveshah>
> SDRAM address pins are not outputs
<daveshah>
really?
<lkcl>
err...
<lkcl>
outputs from a _chip_ i wouldn't have expected them to be
<lkcl>
outputs from the *peripheral* i would expect them to be
<daveshah>
huh?
<daveshah>
they are outputs from the SoC and inputs to the SDRAM
<lkcl>
outputs from the SoC... *smack* yes of course
<lkcl>
doh
<lkcl>
this still leaves GPIOTristate as being declared as input
<daveshah>
yeah, not sure about that one
<lkcl>
input wire [11:0] gpio_io,
<lkcl>
things that are "inout" that work successfully are SDRAM and SDMMC
<daveshah>
ime, unexpected inputs with litex are usually when the pin is accidentally unused
<daveshah>
Has the tristate logic been generated correctly?
<lkcl>
and TSTriple has get_tristate which returns Tristate
<lkcl>
so i'm not seeing anything obvious that would cause gpio pins to be declared input where sdcard_cmd is correctly inout
<lkcl>
_florent_, any ideas?
<lkcl>
ahh i have a clue
<lkcl>
SDRTristate
<lkcl>
def iter_expressions(self):
<lkcl>
yield self, "io", SPECIAL_INOUT
<lkcl>
ngggh that's likely it.
<lkcl>
migen Specials detects that back in Special.list_io
<lkcl>
urrr i have a horrible-hack idea, but it would make a mess of the CSRs...
<lkcl>
use SDRTristate for GPIO :)
<lkcl>
arg arg i'm going to have to hack something together, a hybrid combination of GPIOTristate and SDCard CMD
<acathla>
daveshah, from 8 to 16 bytes fifo, it's an increase of 33 LC
<acathla>
and 2 ICESTORM_RAM to 3
<somlo>
so here's something a bit weird: 64-bit rocketchip based LiteX SoC running a stock linux kernel (with drivers for litex gateware as the only modification)
<somlo>
I went with some silly low number for "timebase-frequency" in the DTS: e.g., 1000000
<somlo>
recently, I decided to make that number reflect the *real* clock speed I'm using on the nexys4ddr: 75000000
<somlo>
and as a result, I can barely type on the tty, and running `date` will advance by a second about every minute or so...
<somlo>
so I am wondering if I need to tell linux about some custom HZ related configuration -- this ring any bells to anyone?
<sorear>
the timebase-frequency in the DTS needs to match the rate at which mtime/mtimecmp are incremented
jaseg has quit [Ping timeout: 240 seconds]
jaseg has joined #litex
<somlo>
sorear: thanks -- that makes me think there should probably be another DT variable besides timebase-frequency that indicates the main sys_clock, and/or some sort of relationship between it and timebase-frequency
<somlo>
at least now I know the basic idea of what I'm looking for (back-story is that the current litesdcard driver proposed by antmicro uses timebase-frequency in lieu of the overall system clock when computing the divider for clocking the sdcard)
<somlo>
and now I suspect that timebase-frequency should *not* be assumed to be the same thing as the overall SoC clock generator, but something *based* on that that's internal to the CPU
<somlo>
_florent_: what do you think, the "75MHz" of a litex SoC on nexys4ddr, should that go under the CPU node as `clock-frequency`, under the soc node as `bus-frequency`, or more likely *both* ?
<somlo>
it should definitely *not* be the cpu node's `timebase-frequency`, as my experience shows :)
<somlo>
_florent_: we're talking about the `CONFIG_CLOCK_FREQUENCY` in generated/soc.h, to be precise
<Finde>
CPU0 has clock-frequency and cpus has timebase-frequency
<Finde>
and uart has its own clock-frequency
<somlo>
Finde: thanks! At this point, the remaining question is whether the LiteX `CONFIG_CLOCK_FREQUENCY` value should become clock-frequency on (each of the) CPU(s) or bus-frequency on the SoC node, or both
<somlo>
and once that's decided, I can modify the litesdcard driver proposed here [*] to grab it from the appropriate location in DT (because we've established that using timebase-frequency is wrong)
<st-gourichon-fid>
Finde, mmh, SERV's github does mention "irq" though not a lot.
alanvgreen has quit [Ping timeout: 244 seconds]
Claude has joined #litex
futarisIRCcloud has quit [Ping timeout: 260 seconds]
alanvgreen has joined #litex
tannewt has quit [Ping timeout: 244 seconds]
tucanae47 has quit [Ping timeout: 244 seconds]
bubble_buster has quit [Ping timeout: 260 seconds]
key2 has quit [Ping timeout: 240 seconds]
<st-gourichon-fid>
We tried to just remove mentions in C code, but crt0 does mention interrupts. I guess it's because few people actually use SERV so the path has to be somehow cleared up... ?
tucanae47 has joined #litex
key2 has joined #litex
flammit has joined #litex
tannewt has joined #litex
futarisIRCcloud has joined #litex
bubble_buster has joined #litex
<Finde>
"SERV only implement the bits required for ecall, ebreak, misalignment and timer interrupts"