really2 has quit [Remote host closed the connection]
<pepijndevos>
trabucayre, no I don't know it. Looks kinda boring.
<pepijndevos>
secretly hoping you'll figure out the JTAG/ARM part of disasm[m]'s board haha
<pepijndevos>
But before I even get to looking at that I want to find this stuuuupid bug that's breaking attosoc.
<pepijndevos>
After that I can hopefully move on to the fun stuff like bram and the arm board and stuff like that
<trabucayre>
Bugs are always boring :)
<trabucayre>
disasm[m]'s board is already supported :)
<trabucayre>
I plan to try spi slave
<trabucayre>
mainly to write corresponding driver
* trabucayre
need to buy a binocular before
<trabucayre>
but before (again) I need to finish to write an article (in french) about the quickfeather and to learn a bit about ghidra.
<pepijndevos>
oh! nice
<pepijndevos>
So how does it work with uploading code to the ARM part? Is it part of the bistream, or you just use normal ARM MCU things?
<trabucayre>
it's the opposite :)
<trabucayre>
an header is produces
<trabucayre>
with a static char array
<trabucayre>
and the MCU program FPGA with this content
<trabucayre>
one way to program MCU is to use the bootloader with tinyfpga protocol
<trabucayre>
or using SWD and openocd
<pepijndevos>
So what does it mean that the board is supported?
<pepijndevos>
Wait, tell me moooooore about the bootloader thing. This is what I want.
<disasm[m]>
(I think that was about QuickLogic FPGA)
<disasm[m]>
It starts MCU and then the firmware loads the bitstream. IIRC.
<disasm[m]>
Gowin is different: MCU is "part of the" bitstream.
<pepijndevos>
IIRC the way they set up the flash for the MCU you can't do a bootloader really, but I'd loooove to be wrong
<disasm[m]>
In the default setup, MCU loads its firmware from one of the internal flash memories
<disasm[m]>
I think you can make a bootloader to overwrite the internal flash, but maybe you can't reset the FPGA from the inside
<disasm[m]>
Also Gowin FEA mentioned that in the default SoC the flash is read-only, but I don't think it's impossible to make it read-write
<pepijndevos>
IIRC it talks to the peripherals THROUGH the FPGA fabric. So either it uses its own flash but then it's read-only, or it uses the FPGA flash/bram but then it needs a bitstream to access it I think
<disasm[m]>
Yes, it talks to the flash through the fabric. Actually this is what was in the encrypted IP.
<trabucayre>
to be able to program FPGA through USB maybe something like done for orangeCrab or FOMU.
<pepijndevos>
Yea that's what I was hoping, but since the CPU talks to the USB peripheral through the FPGA, you can't really run a bootloader on the MCU and talk to the USB without loading a bitstream first. But then yea maybe the MCU can bootstrap the FPGA.
<pepijndevos>
gatecat, I just pulled nextpnr and am getting cmake errors that /home/pepijn/code/nextpnr/3rdparty/abseil-cpp doesn't contain a cmakelist
<gatecat>
I think you need a submodule init and update
<pepijndevos>
ah ok that's a new one, thanks :)
<trabucayre>
pepijndevos: You need to have a first bitstream with the bootloader, and a second for the targeted design
<pepijndevos>
Yea. Problem is just finding a writable location from the MCU so that it can reprogram itself.
<trabucayre>
for gowin it's maybe more complex since you need to fully erase flash...
<trabucayre>
orangeCrab, tinyfpga or fomu has access to the SPI flash, erase/write dedicated area
<disasm[m]>
Maybe one can erase the internal flash in smaller blocks on Gowin, I don't know
<trabucayre>
It's maybe possible but instructions provided in AN talk about full erase :-/
<pepijndevos>
disasm[m], the problem is how do you verify that it actually works
<disasm[m]>
Agree
<pepijndevos>
I'm actually thinking of building a Raspberry Pi CI setup that just has a HAT with a Gowin FPGA and runs integration tests
<pepijndevos>
TODO: everything
<disasm[m]>
You can just hook an STM32 board to an FPGA board and use something like avatar-rs for GPIO
<disasm[m]>
Other options include FTDI chips and i2c GPIO expanders
<pepijndevos>
I want it to be independent from my laptop and ethernet connected
<pepijndevos>
So it's just git push and it runs tests on a pi in a closet somewhere
<disasm[m]>
Ah, I see
really2 has joined #apicula
really2 has quit [Ping timeout: 256 seconds]
<pepijndevos>
Debugging so far: AttoSoC works perfectly with -nodffe, but a single dffe works fine. WUT?
<pepijndevos>
Any random ideas welcome
<disasm[m]>
DFFE-based counter
<pepijndevos>
Also, the shift example works with 5 LEDs, is a bit wrong with 6 LEDs and completely dead with 7 or 8 LEDs
<pepijndevos>
That's basically what the shift example is, a DFFE counter + a shift register. So it depends on the size of the register if it works or not.
<disasm[m]>
Can you pin them to specific locations to see if it's related to a location?
<pepijndevos>
The failure mode of the 6 LED case is really fascinating. In that case it appears as if the counter reset doesn't trigger.
<pepijndevos>
Yes and no. I don't really have constraints implemented for anything other than IOB at the moment.
<pepijndevos>
iiiiiinteresting
<pepijndevos>
I changed the beta parameter in nextpnr that controls how closely everything is spaced, and now 8 LED works
<disasm[m]>
Hmm, so maybe it's routing, not DFFs
<pepijndevos>
Could it be my first timing issue ever? Seems weird on such a small and slow design.
<gatecat>
Or an issue with clock enable packing?
<gatecat>
something like mixing FFs with and without clock enables can hit edge cases
<gatecat>
lower beta would result in less packing together of FFs
<pepijndevos>
What's the default beta?
<pepijndevos>
I had it set to 0.5 and now I just commented it out
<pepijndevos>
So I think it's *tighter* now
<pepijndevos>
I made it 0.5 because the AttoSoC would not route with the default
<gatecat>
default is around 0.9 iirc
<gatecat>
so yeah, commenting out 0.5 would pack tighter
<gatecat>
still, I think its defo worth looking at packing
<pepijndevos>
As far as I can tell in the buggy case it wasn't packing anything at all. Every DFF in the source resulted in 2 DFF in unpacking, so nothing shared a slice. That could be a bug in itself, or just nextpnr spacing things out for this very tiny design.
<pepijndevos>
So with the tighter packing, it works *slowly* at 8 and correctly at 6 LEDs. So the working regions kinda shifted up.
<pepijndevos>
So it feels like there is a fixed *area* within it works. So I'm kinda starting to think timing. Hmmm, lemme see what kind of routing the vendor tools use for CE
<pepijndevos>
Hypothesis: the vendor tool drives CE with global routing, and nextpnr currently drives it with generic routing, and if the design gets too big the clock skew breaks it
<disasm[m]>
It should be driven by global routing
<disasm[m]>
At least different vendors do so
<pepijndevos>
Actually the vendor doesn't use global routing for the CE either.
<pepijndevos>
buuuut my unpacking of the vendor bitstream is wonky. So that's something to go by!
<disasm[m]>
You have a bitstream unpacker?
<pepijndevos>
yea that's actually the first thing I had before I had a packer: you need to make sure your understanding of the vendor bitstream is correct
<pepijndevos>
So the fact that my unpacker gives me different stats than the stats of the vendor netlist is concerning and something to look into
<trabucayre>
pfff... I must be able to understand and contribute to this!!