<_whitenotifier>
[nmigen] jreyesr opened pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/Jtvhd
<_whitenotifier>
[nmigen-boards] jreyesr opened pull request #136: TinyFPGA AX2: Set internal oscillator as default - https://git.io/JtvjM
<_whitenotifier>
[nmigen] codecov[bot] commented on pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/JtvjD
<_whitenotifier>
[nmigen] jreyesr edited pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/Jtvhd
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/JtvjD
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/JtvjD
<_whitenotifier>
[nmigen] codecov[bot] edited a comment on pull request #575: Lattice: Add support for MachXO2/XO3L internal oscillator - https://git.io/JtvjD
emeb has quit [Quit: Leaving.]
mwk has quit [Ping timeout: 272 seconds]
mwk has joined #nmigen
electronic_eel has quit [Ping timeout: 264 seconds]
<kmc>
and the error is: ERROR: BEL 'X0/Y18/io1' has no global buffer connection available
<d1b2>
<TiltMeSenpai> I did the alchitry au so there's a tiny chance I might be able to help
<kmc>
when I try to run examples/board/01_blinky.py
<d1b2>
<TiltMeSenpai> could you toss the full error into a gist? it feels like the toolchain wants to use something as a global instance but can't (maybe the clock?)
<agg>
try removing GLOBAL=True
<kmc>
updated gist with full error
<d1b2>
<TiltMeSenpai> oh that's the full error? that's not super useful lol (tooling's fault, not yours)
<agg>
pin J3 on the CB132 package is not a GBIN pin
<d1b2>
<TiltMeSenpai> yeah try dropping the GLOBAL=True bit
<kmc>
oh the clock is probably somewhere else
<agg>
yea, just looking at schematic and j3 looks like any other IO
<agg>
it's P7
<agg>
which is GBIN5, so you can have GLOBAL=True
<kmc>
yeah I see now
<kmc>
okay, well it builds now! although the LED isn't blinking, so something else must be wrong
<d1b2>
<TiltMeSenpai> it's also a 100mhz clock, so whatever that ends up being in the clock notation
<kmc>
yeah
<agg>
yea, Clock(100e6)
<agg>
I guess check your LED pins are right too :p
<kmc>
double checked and they seem okay
<d1b2>
<TiltMeSenpai> hmm what does build/top.tim or build/top.rpt say your resource usage is
<d1b2>
<TiltMeSenpai> there might be another way to check if the toolchain decided to delete your design but I personally use those files to check
<kmc>
fwiw I changed it to try to blink all 8 LEDs
<d1b2>
<TiltMeSenpai> wait does the ice40 insert the reset delay only if you're using bram or does it do it regardless
<kmc>
Info: Annotating ports with timing budgets for target frequency 12.00 MHz
<kmc>
wonder where it's getting that
<kmc>
thought I changed the clock to 100 everywhere
<d1b2>
<TiltMeSenpai> should be getting that from your default clock frequency
<d1b2>
<TiltMeSenpai> line 18?
Raito_Bezarius has quit [Ping timeout: 260 seconds]
<kmc>
yeah i changed it to 100e6
<agg>
it gets the right 100M at the end when it's checking the frequency
<agg>
can't remember what the 12M thing is, but it's got 100m correctly there
<d1b2>
<TiltMeSenpai> everything else looks right, 50 LC's is somewhere in the neighborhood of what I would expect, so I don't think the toolchain is deleting your design
* kmc
-> afk for 15 min or so
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 272 seconds]
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 264 seconds]
<kmc>
would I need to populate the 'connectors' section to get the LEDs working?
<agg>
no
<agg>
could you post your current platform file and whatever blinky you're building?
<d1b2>
<TiltMeSenpai> LEDResources is actually a function that returns a list of Resources, prefixing with a * results in that list being flattened into the rest of the resource list
<kmc>
ahh
<kmc>
this is a python 3 feature I was unaware of
<kmc>
thanks!
<d1b2>
<TiltMeSenpai> is that only a python3 thing? it's been around for like forever as far as I'm aware, just a feature that isn't used too often
Raito_Bezarius has joined #nmigen
<kmc>
i just checked and in python 2, [1, *[2, 3], 4] is a syntax error, in python 3 it's the expected [1, 2, 3, 4]
<d1b2>
<TiltMeSenpai> huh, cool
Bertl is now known as Bertl_oO
<kmc>
as far as resources go, how would you suggest I handle the Alchitry add-on boards
<kmc>
they have one board which provides a bunch of switches and LEDs, and another which provides 0.1" headers for the FPGA pins
<kmc>
and you can stack them with each other and use them with either base FPGA board (Au or Cu)
<d1b2>
<TiltMeSenpai> yeah lol I kinda just decided that was a later problem
<agg>
probably the best option is to add the connectors to the platform, and then maybe add a new class or function in the platform file which can add the relevant resources using the given connector
<agg>
or a method on the platform perhaps, though it's a little unconventional perhaps
<agg>
still it would be neat enough
<agg>
the connectors object in the platform tells nmigen basically a new name for the given pins, so that you can in future call add_resource and pass it connector pin names instead of fpga pin names
<d1b2>
<TiltMeSenpai> I think the tricky bit here is the fact that these boards are designed to be shared between the au and cu
<agg>
even better really
<d1b2>
<TiltMeSenpai> the icebreaker board has additional resources for the break off pmods, but those are sort of designed to be unique to the icebreaker
<agg>
either a new class with those methods which is inherited from by both alacrity boards, or just a free function, either should work
<agg>
i think for breakoff pmods it's a bit different since they arrive physically connected
<agg>
mostly this is a question of style for nmigen-boards
<d1b2>
<TiltMeSenpai> how would people feel about an additional folder or package for common add-ons?
SpaceCoaster_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #nmigen
<agg>
there's a comment from 2019 in the ECP5 platform saying that nextpnr won't pack an FF (eg OFS1P3DX) into the PIO, does anyone know if that's still true? my nextpnr run reports some IOLOGIC cells where i'm using xdr=1, which I would have thought would be it packing that FF?