freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined ##openfpga
unixb0y has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
freeemint has quit [Ping timeout: 250 seconds]
emeb has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
ironsteel has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Quit: Leaving.]
awordnot has quit [Read error: Connection reset by peer]
awordnot has joined ##openfpga
Jybz has joined ##openfpga
mwk has quit [Ping timeout: 240 seconds]
finsternis has quit [Excess Flood]
finsternis has joined ##openfpga
freeemint has joined ##openfpga
finsternis has quit [Read error: Connection reset by peer]
finsternis has joined ##openfpga
ironsteel has joined ##openfpga
ironsteel has quit [Ping timeout: 245 seconds]
ironsteel has joined ##openfpga
Asu has joined ##openfpga
freeemint has quit [Ping timeout: 265 seconds]
freeemint has joined ##openfpga
freeemint has quit [Remote host closed the connection]
freeemint has joined ##openfpga
ironsteel has quit [Ping timeout: 240 seconds]
freeemint has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 245 seconds]
Laksen has joined ##openfpga
ironsteel has joined ##openfpga
Bike has joined ##openfpga
kuldeep has joined ##openfpga
OmniMancer has joined ##openfpga
mwk has joined ##openfpga
_whitelogger has joined ##openfpga
ironsteel has quit [Ping timeout: 250 seconds]
rombik_su has joined ##openfpga
carl0s has joined ##openfpga
Zorix has quit [Quit: Leaving]
ironsteel has joined ##openfpga
ironsteel has quit [Ping timeout: 240 seconds]
freemint has joined ##openfpga
<balrog> might be worth a read
<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]
<rombik_su> Marex: there's a way to do synthesis with Yosis: and finish the rest in Quartus
<Marex> rombik_su: well, I was more interested in that assembler part :)
<rombik_su> For bitstream RE there's ZirconiumX's project
<ZirconiumX> Marex: So, rqou did a bunch of work on the Max V ("project chibi")
<ZirconiumX> I'm the Cyclone, not the Max :P
<Marex> ah cool, so there is something now
<ZirconiumX> I don't know if Chibi is enough to use nextpnr or whatever yet
<ZirconiumX> I suspect not :P
<Marex> that's fine
<Marex> ZirconiumX: which cyclone are you looking at ?
<ZirconiumX> V
<Marex> oh, the weird one
<ZirconiumX> They're all weird
<ZirconiumX> They're altera parts, what did you expect?
<cr1901_modern> marex: I haven't heard from rqou on here in months, but he's active on Twitter if you have an acct/want to reach out
<Marex> well, the others are pretty much similar
<Marex> V is the unusual one
<ZirconiumX> No, they're not :P
<ZirconiumX> The core part of the Cyclone V - the ALM - was used in the Cyclone III and Stratix II
<Marex> cr1901_modern: last I heard is he stopped on the cyclone stuff, but I figured I'll check and see what's going on
<Marex> ZirconiumX: right, and C-IV is a dieshring of CIII
<ZirconiumX> No, not quite.
<Marex> and CIII is some sort of evolution of CII, I think at some point they switched from 10 to 16 LEs per LAB, but it's still mostly similar ?
* ZirconiumX sighs
<ZirconiumX> "I think at some point they switched from 10 to 16 LEs per LAB"
<Marex> ZirconiumX: did they not ?
<ZirconiumX> This is ALM logic
<ZirconiumX> Altera have two different combinational logic architectures
<Marex> ZirconiumX: um, but ALM was only in CV , it wasn't in the older Cyclone FPGAs , was it ?
<ZirconiumX> The ALM-based LAB, which is 10xLUT6
<ZirconiumX> And the LE-based LAB, which is 16xLUT4
<Marex> ah, right
<ZirconiumX> The Cyclone IV is LE-based, as is the Cyclone 10LP
<Marex> right
<ZirconiumX> The Cyclone V is ALM-based, as is the Cyclone 10GX
<Marex> oh, I wasn't aware of 10GX, OK
<Marex> ZirconiumX: what I meant was that C-I had 10 LEs per LAB, I think since C-III they had 16 LEs per LAB
<Marex> and that's not taking into account any of the new ALM-based parts
<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
<adamgreig> and corresponding C code for linux on the soc
<marex-cloud> Although it's easy to add into DT with some syscon and simple gpio
<adamgreig> oh I just open("/dev/mem"), lol
<ZirconiumX> `cyclonev_hps_interface_mpu_general_purpose`
<ZirconiumX> Gesundheit
<adamgreig> quartus really makes you dig to find that out
<adamgreig> it wraps it in like 10 layers of bullshit autogenerated crud
<marex-cloud> :-)))
<ZirconiumX> I don't think nMigen actually has any way of instantiating a cell like that for I/O purposes
<ZirconiumX> wq: can you confirm?
<adamgreig> here's an example for axi3
<adamgreig> using "cyclonev_hps_interface_hps2fpga_light_weight"
<adamgreig> and corresponding C:
<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> aka atlas-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 ( 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
<whitequark> yeah
rombik_su_ has joined ##openfpga
rombik_su has quit [Ping timeout: 265 seconds]
rombik_su_ has quit [Quit: Leaving]
rombik_su has joined ##openfpga
Asu` has joined ##openfpga
Asu_ has joined ##openfpga
Asu has quit [Ping timeout: 265 seconds]
Asu` has quit [Ping timeout: 250 seconds]
Mimoja8 has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
fseidel has joined ##openfpga
emeb_mac has joined ##openfpga
Asu has joined ##openfpga
Asu_ has quit [Ping timeout: 268 seconds]
emeb_mac has quit [Quit: Leaving.]
Asu has quit [Quit: Konversation terminated!]
Jybz has quit [Ping timeout: 276 seconds]
rombik_su has quit [Quit: Leaving]