<_florent_>
tnt, swetland: In fact I think we all agree regarding Linux on FPGA, it's clearly overkill, but can also be so convenient compared to other solutions that it's sometimes the preferred solution (at least for developments/experiments before switching to a lighter OS). So that's still useful to have it in our toolbox :)
FabM has joined #litex
FabM has joined #litex
davebee has joined #litex
<davebee>
I'm trying to use uartbone to debug a vexriscv. It only partly works. I can breakpoint, but not continue or step. Is there any way to diagnose the problem? I could looks at the UART traffic in a logic analyser, but I don't know what I'm looking for. Sometimes the uart traffic stops and I have to restart litex_server and openocd.
<davebee>
I can manually step over software breakpoints using "(gdb) set $pc = $pc + 4"
lexano has quit [Ping timeout: 250 seconds]
lexano has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
leons has joined #litex
<leons>
Ah, finally getting back to some LiteX work :)
<leons>
I've been wanting to update the LiteX package definitions for Nix, but noticed that the video core downloads a file while building the SoC (soc/cores/video.py downloads ter-u16b.txt)
<leons>
Because these builds are executed in a Sandbox they don't have internet access
<leons>
_florent_: I can hack around this and hot-patch my packaged LiteX version to use a pre-downloaded file, or can we perhaps just include this in the repo given it's not too big and plain ASCII?
<tpw_rules>
leons: hi
FabM has quit [Quit: Leaving]
lexano has quit [Ping timeout: 246 seconds]
lexano has joined #litex
<leons>
tpw_rules: hi!
lexano has quit [Ping timeout: 276 seconds]
davebee has quit [Quit: Leaving]
lexano has joined #litex
NotHet has joined #litex
<tpw_rules>
let me know when you get your updates done, i'll fix up the scala stuff
<swetland>
Crazy question: has there been thought to providing ways to help keep registers, etc, from shifting around as litex evolves?
<swetland>
For things built entirely within the Litex framework and build system or using that as source of truth it might not matter much that registers, CSR bases, etc, can easily move around -- just use generated headers.
<swetland>
Integration with larger systems, upstream emulators (Qemu, etc) is trickier though.
<tnt>
yeah, you can fix the 'base' of each top level block, but anything under those can't be manually controller AFAIK.
<tnt>
(which I also find annoying for exactly those reasons ... )
<NotHet>
Is it a correct statement that the LiteSPIMMAP handles reads, and that writes supposed to be issued through the LiteSPIMaster CSRs?
<NotHet>
ie reads are memory backed but writes are more of a programmed io
NotHet has quit [Remote host closed the connection]
<_florent_>
swetland: As tnt said, it's possible to fix the mapping of each module, but not yet the mapping of CSRs inside a module. I also want to add this since often have to workaround it...
<_florent_>
mithro: I not necessarily agree with what you said on twitter (ie only have automatic mapping generation), this is clearly un-wanted for some systems.
<_florent_>
on some systems that are built with LiteX and using fixed mapping, this enables compatibility between different boards and also software compatibility (and the LiteX has quite evolved since the project are > 8 years old and have regular updates)
<_florent_>
so I think we need both: good fully automated support + config export and fixed mapping
<mithro>
_florent_: I think there are is a bunch of compelling reasons that my approach isn't always the best
<mithro>
_florent_: As I mentioned, I would say that most people disagree with my idea that we should make the register layout *more* random which is why I haven't logged an issue and sent a pull request to do that.
<_florent_>
mithro: I think we just need both, it really depends of the usecase
lexano has quit [Ping timeout: 256 seconds]
<_florent_>
mithro: If you have a small team and the team creates the gateware + software and the software can accept a config file, fully automatic generation can be useful
<_florent_>
as we are doing for the Linux system or Zephyr for example, where this gives some flexibility
<mithro>
_florent_: Yeah, I can understand that -- My only concern is that static layout of stuff is so dangerously seductive that people who shouldn't be using it will end up doing so.
<_florent_>
but for deployed systems, were you need retro-compatibility and want fine control on your register map, this can be problematic
<_florent_>
mithro: we should probably document things better and describes the pros & cons of each approach
<_florent_>
as we can see with swetland/tnt's feedbacks, not being able to have fully static layout is annoying for developers used to more traditional approaches
<swetland>
as I said on twitter (sorry about the permissions on that thread, locked things down for some political chatter and forgot to open them back up again), I'm a bit less concerned about base addresses moving around than the idea that there's no way to keep your registers from renumbering if you rearrange your source HDL
<swetland>
I think it depends on your project and goals. for things that are entirely self-contained driving everything from the HDL as a source of truth makes sense
<_florent_>
swetland: sure, I understand, I want to also fix this (see #548)
<swetland>
but if you're going to be building a product where others may supply the software, where you may support it across multiple generations and want to provide backward compatibility so you don't have to rebuild the world on a bugfix, etc, having a way to keep things consistent from version to version is valuable
<mithro>
swetland / _florent_: I would love us to figure out an efficiently way to make the system more self describing but understand that is still a rather unsolved problem
<swetland>
I think that's hard to do reliably when you get down to the individual register level -- at some point you're building an interface and it'd be nice to (if one desires) have tooling to support maintaining that interface
<tnt>
Also while I'm at it, a way to specify a name different than the auto generated one would be nice.
<_florent_>
swetland: I could spend more time looking at this, I generally have a tendency to accommodate myself to limitations until someone else also complains :)
<tnt>
Like, sometimes the HDL needs to be structured a certain way and that yields insane #define names for the CSRs ...
<swetland>
because building software that has to go through an elaborate abstraction to figure out where the bits are is not very efficient or sustainable
<_florent_>
swetland/tnt: If you have ideas on this, can you eventually fill them in #548?
<swetland>
florent: I don't have an urgent need for this, so no worries, but yes, will think on it and provide some feedback
<_florent_>
swetland: great thanks, I don't think this require that much efforts to implement
<_florent_>
tnt: we could also try to add fixed name support yes
<swetland>
it really depends how elaborate you want to go. also, I'm not super-familiar with all the migen/litex internals so I might not have a good idea what's easy or hard
<mithro>
tnt / swetland: I think there was a proposal a while ago about separating the layout of CSRs from the definition of them.
<swetland>
one simple thing might just be tooling where you can checkin a representation (json or something?) of the register layout of a peripheral and have the build warn if it changes
lexano has joined #litex
<swetland>
mithro: yeah that would be my inclination, assuming it wasn't too painful: some kind of simple register interface language to define the names/offsets/subfields of registers which could then plug into the HDL and be the source of truth for headers, etc
<mithro>
swetland: I think that we added functionality to LiteX which should issue a warning if you are running on gateware which is not the same as the gateware which the headers where generated for
<mithro>
swetland: Like there is a register which has a hash stamped into it which should be the a hash of configuration information
<mithro>
_florent_: Didn't we implement something like that -- or am I dreaming?
<swetland>
just fyi, my short term goals here are that I agreed to do a sort of ongoing os-internals/how-to-write-an-os workshop and decided RISCV was a nice modern "real" architecture but then wanted a RV32IMA U/S/M MMU based platform with some reasonable peripherals and existing both as an emulator target (qemu) and fpga soc (ulx3s / icsesugarpro)
<swetland>
and I'm just about there. I've got a VEXRISC-INTC, LITEX-UART, LITEX-TIMER (need to verify), and flat framebuffer plumbed into qemu that line up with the bitstream for the fpga boards and software happily runs on both
<_florent_>
mithro: if this is implement, this is probably external to LiteX, I'm not aware of it
<swetland>
this is similar to my setup notes for my project (but bigger and linuxier)
lexano has quit [Ping timeout: 260 seconds]
<swetland>
I'm not asking anyone to deal with the gateware side of things (these are folks already kinda intimidated by bare metal osdev, so one thing ata a time ^^)
<swetland>
I want to find some time to play with renode more but at the moment it seems their litex peripherals and what litex generates have drifted apart, and for its warts I can work on qemu's byzantine source base more easily than renode (or at least more quickly)
<mithro>
swetland: The goal with that tutorial was eventually to get people to implement a fake "RustyLove3000" device and talk to it from Linux
<tpb>
Title: Love Rusty 3K - LCA2018 FPGA Project Miniconf - Google Präsentationen (at docs.google.com)
<swetland>
neat! I'm doing more a sort of mini os course --- RV32 architecture, registers/csrs/processor modes, boot, mode switching, syscalls, context switching, mmu, drivers, etc
<tpb>
Title: Love Rusty 3000 - Techsheet - Google Docs (at docs.google.com)
<swetland>
going to see if I can get a bunch of people who are plenty smart but have always worked much further up the stack building some toy kernels
<mithro>
swetland: The Fomu workshop also tries to ge software people excited about doing embedded hardware - https://workshop.fomu.im/
<tpb>
Title: FPGA Tomu Workshop — FPGA Tomu (Fomu) Workshop 0.1-481-g505a715 documentation (at workshop.fomu.im)
<mithro>
I have fond memories of Rusty's tutorial about writing a Linux PCI device driver -- was the first time I ever did Linux kernel development
<swetland>
for all my griping about python (not a python fan), I'm pretty impressed with litex and how easy it's been to do some slight mods and assemble a useful little soft soc platform
<mithro>
swetland: You have seen the Fomu workshop, right?
<swetland>
I'm a firm believer you can't really do osdev without a hardware target and the actual available RISCV SoCs are sort of poor pickings right now (either way too tiny MCUs without enough memory, MMU, or 64bit and spendy, or from china with no docs but an "sdk" or pile of linux patches)
<swetland>
mithro: I have not!
<swetland>
been away from the foss fpga stuff and hw hacking for too long. spent the last year or so writing radio firmware for NRF52832 MCUs
<swetland>
mithro: it'd be interesting, I think to do something kinda like ARM's CORESIGHT ROMs
<swetland>
generate a table of device ID, revision, base addr, irq, etc in a "rom"
<mithro>
_florent_: I think maybe what I'm thinking of was only doing in something with Fomu/xobs[m]/BeTrusted stuff or the TimVideos LiteX-BuildEnv
<mithro>
swetland: That is kind of what compiled DeviceTree is?
<swetland>
which then could be expanded into fdt or whatever vehicle your sw platform wants to know where the peripherals are
<swetland>
kinda, but simpler and without all the miserable error prone string parsing
<swetland>
I'm still pissed about devicetree. linus got grumpy about people causing a lot of churn and this war against board files was born and we got saddled with this godawful description format from the rotting corpse of openfirmware
<swetland>
I feel it's a "the cure is worse than the disease" situation. But obviously opinions vary.
<mithro>
swetland: I would rather use an existing solution rather than investing yet another one
<mithro>
swetland: Actually, I believe LiteX can also generated SVD files which are compatible with a lot of ARM tooling
<_florent_>
swetland: This would also be really useful to connect SoC together, when you do a bridge to another SoC, first thing you do is read this ROM
lexano has joined #litex
<mithro>
swetland: A long while back I was trying to make it possible to download prebuilt gateware from the TimVideos CI system and just iterate on the firmware / C side without having to have installed Vivado / Xilinx tooling
<mithro>
swetland: Then I decided it was going to be less work to just make the open source tooling better and then somehow I ended up doing paperwork full time so that this stuff gets funding
lexano has quit [Ping timeout: 248 seconds]
<_florent_>
leons: Hi, I'll try to see what we can do to avoid downloading the font for the VideoTerminal
lexano has joined #litex
lexano has quit [Ping timeout: 256 seconds]
lexano has joined #litex
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
cr1901_ has joined #litex
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
zjason` has quit [Read error: Connection reset by peer]
zjason`` has joined #litex
<_florent_>
mithro: BTW, I'm currently working on a SoC generator for LiteX, the idea is to have a equivalent of a mini Nios SOPC Builder/Microblaze subsystem generator: CPU + ROM + SRAM + base peripherals + MMAPs / DMAs interfaces, that you can uses without targeting a specific board.
<_florent_>
yes, using the same configuration parameters than the ones used on the targets (--cpu-type, --bus-standard, etc...)
lexano has quit [Ping timeout: 246 seconds]
<_florent_>
mithro: I had a quick look yes but find the code a bit difficult to read
<_florent_>
mithro: is it also possible to simulate caravel on an FPGA or are they only doing simulation?
<mithro>
_florent_: It would be great to help provide them with suggestions/advice so it is easier to read
<_florent_>
mithro: if they are not running it on FPGA, I think it could make sense to do it. It would make contributions a lot easier (and I think most of the code should be generic enough for it).
<mithro>
_florent_: Unclear to me about that
<mithro>
_florent_: I agree that would be great to have working
<mithro>
_florent_: Always infinite more work to do :-P
lexano has joined #litex
<_florent_>
mithro: I'll try to have a closer look/play with it and will try to contribute of do suggestions.
<_florent_>
mithro: is it what is now used on MPW?
<mithro>
_florent_: No pressure, there is always lots of different things happening
<mithro>
_florent_: Yes
<mithro>
_florent_: I wanted more collaboration / overlap between the ASIC and FPGA work I was funding, so requested they stop designing their own SoC system and just use the already popular LiteX ecosystem
<_florent_>
ok good, thanks :)
<_florent_>
in fact, I think being able to running caravel on an FPGA could be 1) interesting for the development of caravel 2) but also for users having to interface their design with caravel (if user core can fit in an FPGA)
<mithro>
I 100% agree
<mithro>
_florent_: Trying to convince people to work together seems like 50% of my job -- It is really great to see the LiteX + SpinalHDL collaboration and LiteX + mor1kx
<mithro>
_florent_: I have a goal of getting LiteDRAM taped out on SKY130
<tpb>
Title: Michael Taylor on LinkedIn: I am excited to announce another tapeout from the Bespoke Silicon (at www.linkedin.com)
<mithro>
> We implemented the world’s first open source SSTL DDR3 I/O.
<_florent_>
nice, for LiteDRAM are you planning to directly go with DDR3? or do a first test with SDRAM?
<_florent_>
Collaborations with Dolu are very pleasants and both projects are complementary, we don't speak the same HDL language but are still able to understand each others on concepts (and in french) :)
<mithro>
_florent_: While he currently lives in Japan, Johan / proppy on my team is also french. It does seem like france really punches above its weight in the field of FPGA / ASIC world
<mithro>
_florent_: Did you see the LiteX inside Juypter notebooks that proppy did?
<mithro>
_florent_: When combined with Google's Colab Notebooks (basically free Google Cloud hosted Juypter notebooks) you can do FPGA SoC development without needing to install anything.
<_florent_>
mithro: ah interesting, do you have a link?
<CarlFK>
that is just an ssh client, so people are free to use whatever ssh client they want
<mithro>
_florent_: Two plans -- (a) CI for things like LiteX / F4PGA / etc (b) Access by anyone to play with and test things and don't have local hardware
<_florent_>
mithro: Good
<mithro>
_florent_: They are suppose to be as identical as possible and are remotely power cyclable as well
<_florent_>
Sorry that the end of the day here, thanks for the discussion
<mithro>
_florent_: No worries! I always assume that IRC is a lossy communication mechanism and people might need to walk away at any time