<balrog>
"FPGAs and free software", writeup of a talk from the 2019 X.Org Developers Conference
<balrog>
ah I see, bwidawsk who his here gave the talk :)
<balrog>
who is*
<ZirconiumX>
With some assistance from others :P
<balrog>
nice. I haven't watched the talk yet
<ZirconiumX>
It won't tell you anything the writeup doesn't
<ZirconiumX>
It's mostly for people outside the ecosystem who don't know but are interesting in learning
OmniMancer has quit [Quit: Leaving.]
Zorix has joined ##openfpga
<Marex>
hey, just curious, did anyone make any progress on altera FPGAs ?
<Marex>
I am just looking at it again and it seems MAX V 5M40Z might be a good starting point, it's basically a cut-down cyclone I with 40 LEs (aka. a few), and anything newer is based on that architecture
<Marex>
(CII-IV,10 are basically the same thing, just more complex)
carl0s has quit [Remote host closed the connection]
<ZirconiumX>
"Each LAB consists of eight ALMs, carry chains, shared arithmetic chains, LAB control signals, local interconnect, and register chain connection lines."
<ZirconiumX>
It's not really all that "new" as such.
<Marex>
:)
<Marex>
ZirconiumX: anyway, good luck, the CV looks like a difficult task :)
<ZirconiumX>
Not *too* difficult, I think.
<ZirconiumX>
Routing is the main issue.
<Marex>
ZirconiumX: I recall seeing some altera patent for older cyclones which described the routing muxes and all that
<Marex>
maybe you saw that already
<ZirconiumX>
I mean, there's a patent for the bitstream compression, too
<Marex>
that's not surprising really
<ZirconiumX>
Sure. but when the chip *requires* bitstream compression, the legals get painful :P
<Marex>
I thought that's configurable with one of those BSEL pins
<Marex>
ZirconiumX: speaking of CV, did you also look into how the interaction with the ARM cores in SoC-FPGA works ? Presumably there is some bridge block ?
<ZirconiumX>
There's an AXI bridge you have to instantiate to talk to the SoC
<adamgreig>
and a 32-bit gpio if you're feeling lazy :P
<adamgreig>
quartus really overeggs instantiating the soc bridge
<ZirconiumX>
I didn't actually know about the GPIO
<ZirconiumX>
Which I should really add to nMigen >.>
<adamgreig>
i have an old migen project using it somewhere i think
<marex-cloud>
It's not really gpio, but a bank of GPIs and a bank of GPOs, no? It's a bit weird though
<adamgreig>
sorry, yes, 32 ins and 32 outs i think
<adamgreig>
and you can trigger ISRs on them.. or on some other ones. it's been a couple years since i touched it
<marex-cloud>
Same here, it's well hidden and I think Linux doesn't expose this either
<adamgreig>
here's a complete migen sample for a cyclonev-soc using gpi/spo http://dpaste.com/2VAKXQN
<marex-cloud>
ZirconiumX: is it really IO ? I somewhat suspect the GPIs/GPOs are wired into the fpga fabric, not to IO pins directly
rohitksingh has joined ##openfpga
<marex-cloud>
Pardon my ignorance , I might well be wrong
<adamgreig>
yea ^
<ZirconiumX>
I'd call intra-chip I/O I/O.
<adamgreig>
oh... you're saying you couldn't do it using the platform Pins stuff?
<adamgreig>
you could defo instantiate the instance in nmigen and wire its 32-bit gpi and gpo ports to Signals
<adamgreig>
but i don't think it would even make much sense to use Pins() for that
<adamgreig>
i wanted to get my head around building a minimal linux for that thing too, because the one it came with seems as overcomplicated as the quartus hps macros
<adamgreig>
what is it with altera/intel and just making this shit really complicated and hard to use
<adamgreig>
i haven't tried zync because this sort of scared me off
<ZirconiumX>
Altera is horrifically inconsistent :P
<adamgreig>
but i'd love to go back to using something with soc+fpga, it's a lovely principle
<adamgreig>
that said I'd miss nextpnr :P
* ZirconiumX
has a DE-10 Nano with that
<adamgreig>
i have the de-nano-soc board, which is cyclone v soc
<adamgreig>
once you work out that you just need one or two very simple instances to talk axi and gpi/gpo to the soc, it's all so much more tolerable
<adamgreig>
there's really not that many wires between the two
<marex-cloud>
adamgreig: compared to zynqmp, altera is consistent systematic and pure awesome greatness
<adamgreig>
oh christ, zync is that bad?
<marex-cloud>
No
<adamgreig>
well that's sad. maybe i'll just use discrete cpu and fpga.
<marex-cloud>
Bad doesn't even start to describe the hideous mess
<adamgreig>
eurgh :(
<adamgreig>
i take it ultrascale stuff is even worse than 7 series too? :P
<marex-cloud>
The greatness starts around PMUFW and ATF BL3 and the total CF ABI incompatibilities there
<adamgreig>
:(
<marex-cloud>
Also, generated DTs are awful
<marex-cloud>
Zynqmp is ultrascale
<adamgreig>
i'm tempted to try out 7 series just because of the prjxray stuff, being able to use yosys/nextpnr for ice40 and ecp5 is so much nicer
<adamgreig>
is zynq 7 any better?
<marex-cloud>
Well, the 7000 doesn't have the PMU I think, which helps, it's easier to bring up
Laksen has quit [Quit: Leaving]
<rombik_su>
PMU is working right from the box with default fw
<rombik_su>
(at least with baremetal Zynq projects)
<marex-cloud>
rombik_su: I think the newer versions added something to block reconfiguration of arbitrary PLLs, which Linux needed and then failed
<marex-cloud>
Also, Linux calls into the PMUFW through ATF BL3 (PSCI), and bizzare thing -- xilinx changes the ABI between these three things without actually updating the ABI version
<rombik_su>
And it was very helpfull to pinpoint UltraZed (http://zedboard.org/product/ultrazed) power issues as PMU exposing a lot of status registers
<marex-cloud>
If you don't have the correct matching versions of each, random mess happens
<marex-cloud>
These is no warning, the board either fails to boot or just misbehaves, sigh
<adamgreig>
Yea... Maybe discrete cpu and foga
<adamgreig>
Fpga* ugh
<marex-cloud>
adamgreig: don't get me wrong, socfpga is great because the CPU and FPGA can cooperate on large chunks of memory, e.g. for video applications :)
<rombik_su>
Messing with uboot was enough to stop me from trying to mess with Linux on Zynq
<adamgreig>
Yes it's very appealing, just a real shame it's so annoying and fiddly when that seems unnecessary
<rombik_su>
So I can only imagine how much struggle it is
<marex-cloud>
rombik_su: well, if you ever run into issues with that, ping me or monstr on #u-boot , maybe we can help ;)
<marex-cloud>
rombik_su: it's only convoluted because the tooling sucks ...
<rombik_su>
marex-cloud: Thanks :)
<marex-cloud>
Sure
<whitequark>
adamgreig: i never considered the case of on-chip comms in nmigen before
<adamgreig>
What model would you use beyond just instantiating it?
<whitequark>
it might actually make sense to expose it as Pins() or more like some new sort of constraint like Pins() and DiffPairs()... maybe InstancePorts()?
<whitequark>
say you want to "request" individual GPIOs in different parts of your design
<marex-cloud>
The real problem is updating the system, when there is some hidden ABI change , you update Linux and the system stops booting, that's just sad
<whitequark>
without actually wiring them to the single Instance()
<whitequark>
but it's not a huge hassle
<whitequark>
so this is less "you have to do it that way" and more just some thoughts on how that'd fit into existing model
<sorear>
this seems vaguely analogous to the glasgow port problem / having logical pins A0-B7 that don't correspond 1:1 with fpga pins