#timvideos

hi

mithro: I tried a "VexRiscv-Lite" I created on tinyfpgab... as is par for the course, I don't get any activity, even w/ _florent_'s minimal soc

Time to simulate I guess...

cr1901_modern: what's your "VexRiscv-Lite"? is it a specific vexrsicv verilog you generated to reduce resource usage? If you share it, i'll do some tests

_florent_: It can be found here on this branch: https://github.com/cr1901/VexRiscv-verilog/tree...

Title: GitHub - cr1901/VexRiscv-verilog at lite (at github.com)

And yes, it's a variant explicitly to reduce resource usage

I'm not ready to share the SoC it's part of though; you'll need to reduce the integrated_rom_size of your tinyfpga-soc to 0x1800 for all the block RAM to fit

cr1901_modern: thanks, have you been able to test it on another board (a Xilinx one?)

_florent_: No, not yet

cr1901_modern: if you want an easy way to test configurations, you can use the simulation: in litex/boards/targets, run ./sim.py --cpu-type=vexriscv

cr1901_modern: and you replace the VexRiscv.v in litex/soc/cores/cpu/vexriscv/verilog with your generated file

cr1901_modern: the VexRiscv-Lite.v is working in simulation

cr1901_modern: i'm going to test in arty

cr1901_modern: it's working on arty.

mithro: Appears we can upgrade FuPy to modern micropython:

Executing booted program at 0x40000000

MicroPython v1.9.4-509-gf4e8a40-dirty on 2018-08-27; litex with lm32

>>>

mithro: or if we just pull forward rather than rebase

Executing booted program at 0x40000000

MicroPython v1.9.4-513-gc6fb8fc-dirty on 2018-08-27; litex with lm32

FTR, key trick to getting v1.9.4-... version numbers is that we must grab the v1.9.4 tag from the upstream and push it up to our repo.

(otherwise git describe will report v1.8.7-NNNN-.... with a huge number of commits, which is rather misleading.)

mithro: pull forward is probably better, which is currently only at https://github.com/ewenmcneill/fupy-micropython...

Title: GitHub - ewenmcneill/fupy-micropython at ports-fupy (at github.com)

In case anyone is following along at home, I managed to port Coriolis to run on Ubuntu 18.04, including porting it to Python3. I still can't /do/ anything with it yet, since I'm trying to figure out how to get yosys to synthesize something it'll accept. https://github.com/xobs/coriolis

Title: GitHub - xobs/coriolis: An alternative PnR system, or at least an attempt to modernize it. (at github.com)

I have the LM32 booting on TinyFPGA-BX with _florent_'s tinySOC

mithro: third_party/edid-decode is causing me pain trying to push to my own repo, even after cherry-picking the URL change from your branch, "git submodule sync", "git submodule update --recursive".

The following submodule paths contain changes that can

not be found on any remote:

third_party/edid-decode

mithro: is there some step I'm missing in how to make it happy again?

mithro: Finally fixed my thirdparty/edid-decode issue by (a) cherry-picking your submodules update (as well as the edid-decode git repo location change) *and* (b) rm -rf .git/modules/third_party/edid-decode third_party/edid-decode && git s

ubmodule sync && git submodule update --init --recursive

(all one command: ie ... && git submodule sync && git submodule update --init --recursive)

It appears edid-decode managed to diverge the git trees after moving locations, just to make it extra specially difficult.

FTR, https://github.com/timvideos/litex-buildenv/pul... has a cherry-pick of the two submodule updates from #34, in case we can merge them separately from everything else.

Title: WIP: Update third party submodules (including edid-decode) by ewenmcneill · Pull Request #36 · timvideos/litex-buildenv · GitHub (at github.com)

Plus a note of what needs to be done when merging/pulling that to get thirdparty/edid-decode back to a sane state.

ewen: poke _florent_ about that error with the MimasV2

ewen: it looks like an issue in LiteDRAM - https://github.com/timvideos/litex-buildenv/pul...

Title: WIP: Update third party submodules (including edid-decode) by ewenmcneill · Pull Request #36 · timvideos/litex-buildenv · GitHub (at github.com)

_florent_: After updating litex modules in litex-buildenv (with the updates mithro had), building litex-buildenv on Mimas V2 breaks, very early in the build, in make.py.

_florent_: Output of build attempt is in https://github.com/timvideos/litex-buildenv/pul...

Title: WIP: Update third party submodules (including edid-decode) by ewenmcneill · Pull Request #36 · timvideos/litex-buildenv · GitHub (at github.com)

_florent_: Do you have any ideas of root cause (appears something is not defined, but I'm unclear why). Builds okay on the Arty platform.

mithro, ewen: i'm looking at that

_florent_: At this point, I'm wondering if icetime is lying about all the cores (lm32, vexriscv) passing timing

It will do that if they have any negative edge clocks

daveshah: what version did you flash opsis? you just did this, right?

Nope

Never used an opsis in my life

ah different D.

deeprave: what firmware version did you flash?

Title: LiteX Build Environment - FuPy - Relationship - Google Drawings (at docs.google.com)

What is Zephyr?

cr1901_modern: The IoT platform you use when you really wanted Linux but couldn't make it small enough

Well I never wanted to use Linux on IoT, so...

I guess maybe Zephyr is for me?

cr1901_modern: Zephyr is backed by the Linux Foundation

mithro: can you look into why there aren't any hdmi2usb builds in so long?

also, I have a PR against download-prebuilt-firmware.py - was just banging on it in the last day or so.

reloacint to PS1 for nerp night with pdp11 - see ya