<_whitenotifier-d>
[nmigen-boards] hansfbaier synchronize pull request #154: Add support for QMTech Boards EP4CE15, EP4CE55, 10CL006 and XC7A35 and their common daughterboard - https://git.io/JGvXe
Luke has quit [Quit: o/ 4w 6d 23h 59m 14s]
Luke has joined #nmigen
GenTooMan has quit [Ping timeout: 265 seconds]
GenTooMan has joined #nmigen
sm2n has quit [Ping timeout: 265 seconds]
sm2n has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
david-sawatzke[m has quit [*.net *.split]
Niklas[m] has quit [*.net *.split]
emilazy has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
Ekho has quit [*.net *.split]
key2_ has quit [*.net *.split]
key2_ has joined #nmigen
Raito_Bezarius has joined #nmigen
emilazy has joined #nmigen
Niklas[m] has joined #nmigen
david-sawatzke[m has joined #nmigen
Ekho has joined #nmigen
trabucayre has quit [*.net *.split]
duck2 has quit [*.net *.split]
pie_ has quit [*.net *.split]
awygle has quit [*.net *.split]
trabucay1e has joined #nmigen
awygle has joined #nmigen
pie_ has joined #nmigen
duck2 has joined #nmigen
trabucay1e is now known as trabucayre
emeb_mac has quit [Quit: Leaving.]
pftbest has joined #nmigen
nak has joined #nmigen
sorear has quit []
sorear has joined #nmigen
bvernoux has joined #nmigen
esden has quit []
esden has joined #nmigen
emeb_mac has joined #nmigen
emeb_mac has quit [Client Quit]
emeb has joined #nmigen
tannewt_ has quit []
tannewt_ has joined #nmigen
<lethalbit>
oh oh, so in fun news, dragonmux and i have been working on gettin the Xilinx PS7 and PS8 blockes worked into easy to consume and use elaboratables for nmigen based designed, cutting out the garbage that is the vivado block designer~
GenTooMan has quit [Ping timeout: 260 seconds]
<dragonmux>
(and it's working - first successfull PS7 synths last night.. though there's pleanty more work to do to make it good)
<lethalbit>
yeah! i've not got the PS8 sything yet, but soon :tm:
<dragonmux>
with all the groundwork you've laid for doing it right.. we don't doubt it
<vup>
also do you have a link to what you are doing? I would be very interested to see it :)
<dragonmux>
yes and no.. that doesn't give you access to the EMIOs, it doesn't handle (eventually) generating the FSBL code to set up the requested config on boot, and it doesn't support the DMA or IRQ bits
<dragonmux>
(though that entire repo is an entire thing to making it all work)
<dragonmux>
also, technically the PS7 talks AXI3 (we know this is wrong in our mappings, that's something we have to fix) and translating that to AXI4 to work with normal AXI stuff is not a simple connection.. there's translational mapping required to make it work
<vup>
yes this covers only the very small portion we needed so far
<dragonmux>
we're aiming to do a complete mapping (it's WIP atm) of the entire block
<vup>
do you actually plan to generate code using the vivado framework / sdk thing?
<dragonmux>
and have it generate the FSBL code required too
<vup>
I have thought many times about writing something a bit nicer myself
<vup>
especially something that can also change many of the settings at runtime
<dragonmux>
we were thinking using Jinja2 templates and (after the PS8 model) make the resources somewhat smart (or at least the PS7 class smarter) so we can generate fragments for each of the peripherals that then get put together into a bringup file
<dragonmux>
and specifically writing it all in C++ if we can get away with doing that
<dragonmux>
we do not, no
<dragonmux>
neat
<dragonmux>
but yeah, the plan was to build a high quality FOSS header that maps out all the regsiters the PS7 block has, and then generate a C++ source file that takes your specified configuration and bakes that into FSBL bringup code using that header
<dragonmux>
because honestly.. vivendor can go get shot to the moon esp with the really poor code quality their startup code exhibits
<dragonmux>
(we looked in the GPL FSBL code and just.. *shock horror stare*
<vup>
yeah, although you can get rid of most of it (besides the ps7_init_gpl.c file) by using u-boot spl
<dragonmux>
yes.. but consider wanting to not deal with u-boot and C and instead integrate the FSBL into an entirely embedded project that won't run an OS on the thing :3
<vup>
I see, yeah
<dragonmux>
we can make an FSBL in C++ that is correct by construction and that plays nice with our C++ ARM startup code (SPIFlashProgrammer has an example of this in repo)
<dragonmux>
think that's a far better place to be in
<vup>
yeah, for now I think we are stuck with linux for our usecase
<dragonmux>
understandable
<vup>
but maybe someway we will have one core running linux and one running some (hopefully rust :P) rtos
<vup>
How much of the register space do you want to map out in your FSBL generation thing? Only the bare stuff to make it boot, or basically the whole of the trm?
<lethalbit>
all of it eventually
<vup>
nice
<lethalbit>
but to start out with, just enough
<vup>
of course
<dragonmux>
in our case, we've done a lot with doing AXI peripheral dev and bringup and having to do tricks like running as root and mmap()'ing /dev/mem just to get to the point we can poke our gateware is just.. nah.. want to be able to build a nice minimalist firmware image we can throw at it that boots the PS7 properly and gets the bistream on and then pokes registers and gives you a pass/fail
<vup>
(oh also I assume you have found the xml files vivado ships that contains a lot of register definitions?, that could be handy to maybe atleast autogenerate some parts of what you need)
<dragonmux>
because then we can use our ArtyZ7 as a really nice dev platform
<dragonmux>
we need to poke that, but we know where the IP core for the PS7 is yes
<vup>
well we have been doing a lot of AXI peripherals aswell, but when you abstract away all of the lowlevel stuff you can (atleast try) and forget all of the ugly stuff in between
<dragonmux>
so.. it would be more accurate to say a lot of our stuff are peripherals with registers you can happen to map to an AXI bus.. but it could also just as well be a PLB or Wishbone or <insert bus here>
<vup>
oh yeah, we are doing the same
<dragonmux>
but debugging them on platforms with non-hard CPUs that we can trust are fine.. is really painful as we found out
<dragonmux>
because you can't always tell if the CPU even synth'd right if you screwed up in just the right way
<vup>
Oh yeah, but having a jtag "backend" for our register stuff has been very helpful for us there
<dragonmux>
hence wanting to turn it into a testbench
<agg>
The zync stuff looks cool, nice work dragonmux/lethalbit!
<dragonmux>
ah, thank you~
<agg>
I need to get some zync boards... it's a shame the altera soc stuff seems way less popular as I feel like their interconnection was way cleaner, but, so it goes
<agg>
Supporting it without Linux on the soc is nice
bvernoux has quit [Read error: Connection reset by peer]
emeb_mac has joined #nmigen
<jevinskie[m]>
Yeah it was a good choice by altera to let the logic get loaded without anything on the hard processor
mikolajw has joined #nmigen
<lethalbit>
i kinda wish lattice would bolt like, 4-8 small RISC-V cores to an ECP5
sm2n_ has joined #nmigen
sm2n has quit [Ping timeout: 260 seconds]
sm2n_ has quit [Remote host closed the connection]
sm2n_ has joined #nmigen
sm2n_ has quit [Remote host closed the connection]
sm2n_ has joined #nmigen
sm2n_ has quit [Remote host closed the connection]