phire has quit [Remote host closed the connection]
phire has joined #amaranth-lang
mindw0rk has quit [Read error: Connection reset by peer]
mindw0rk has joined #amaranth-lang
bl0x has joined #amaranth-lang
bl0x_ has quit [Ping timeout: 246 seconds]
whitequark_ has joined #amaranth-lang
<whitequark>
test
<whitequark>
okay, Matrix<>IRC bridge works again
whitequark_ has quit [Client Quit]
Degi has quit [Ping timeout: 248 seconds]
Degi has joined #amaranth-lang
indy- is now known as indy
nak has quit [Ping timeout: 252 seconds]
nak has joined #amaranth-lang
<d1b2>
<Olivier Galibert> @OmniTechnoMancer its spaces though, not \0, plus it's on linux which pretty much never goes utf-16. More like using a string as a vector, splitting the chars
<d1b2>
<Olivier Galibert> no idea what happened though, because afaict I didn't change anything and it went back correct. Well, iirc I reinstalled amaranth, guess something had been corrupted somehow
<d1b2>
<OmniTechnoMancer> yes spaces is weird
<Sarayan>
quartus takes something like half an hour for each compile, how can people stand that?
<d1b2>
<Darius> simulate a lot first
<d1b2>
<Darius> it is very tedious though, non trivial FPGA designs are so painful
<Sarayan>
it's not even a big design, it's just that quartus_map takes ages to synthesize rams
<Sarayan>
probably something quadratic in there
<whitequark>
hm
<whitequark>
that sounds odd, is it blasting them to flops?
<whitequark>
do you have BRAM primitives in the report?
<Sarayan>
I'll tell you once it has finished compiling
<d1b2>
<Darius> heh
<Sarayan>
it was long already, but now that I connected the framebuffer to the wishbone bus it just went insane
<Sarayan>
starting to think I should explicitely use m10ks
<Sarayan>
is the yosys-generated verilog supposed to create fpga-specific stuff like the m10ks?
<whitequark>
if you're using RAMs with synchronous read ports it should give you m10ks
<whitequark>
if it doesn't, report a bug against Amaranth
<whitequark>
hold on
<Sarayan>
reg [31:0] videoram [65535:0];
<Sarayan>
in top.v
<Sarayan>
wtf?
<Sarayan>
ah no, that's correct, but urgh
<Sarayan>
it's not explicitely m10ks though
<whitequark>
ok, so you're using 4.195 Mb of RAM, and it has 6.191 Mb total
<whitequark>
I think what you're likely bumping into is granularity=8
<FFY00>
happy to talk further if so, otherwise please just ignore :)
<whitequark>
so my concern about it is: most of the boards do not share the programmers (it is typically a custom one-off subcircuit), so why should the interface be shared?
<whitequark>
for something that is actually a separate device that is in and of itself a complete solution to programming and only needs a bitstream file, we can factor it out, since it would only need to be tested once, not per-board
<whitequark>
but as I see it, any change to the "common" code where the boards have no actual commonality means it needs to be re-tested on every board where it's used
<whitequark>
ideally there would be a test stand where every board is connected and that would get run on CI, but such a thing is very demanding on physical and compute resources
<whitequark>
I guess not really compute as the bitstreams can be cached, but it's a significant physical setup
<whitequark>
what it boils down to is, the only thing that 100% convinces me the programming code works, is positive confirmation of it loading a bitstream with that specific board. so when you change the common programming code, that positive confirmation is needed all over again for every board
<whitequark>
I hope this clarifies my position
<d1b2>
<Olivier Galibert> openFPGAloader is nice in the way that you just put -b <board> and it works, at least in my experience
<d1b2>
<Olivier Galibert> as soon as you go to quartus_pgm or others though....
<Sarayan>
ok, the interesting thing about playing with a fpga is that you get wrong results that are so facinating that you have zero idea how you managed to get them
<Sarayan>
they're just plain impossible, so of course they're happening
<Chips4MakersakaS>
Small blurp about typing; agree pytype looks interesting; am using pylance now and likely will switch in future. One of the reasons is [pylance #3591](https://github.com/microsoft/pylance-release/issues/3591). Both mypy and pytype do handle the case as I want it.
<Chips4MakersakaS>
Hope to find time to comment on minimal typing RFC before next IRC meeting.
<Sarayan>
is that testing all the bits or only the low bit?
<Sarayan>
ok, if you want something *really* fun to debug, make a memory range where write works but read tends to return the previous value you asked to read (because delays)
<Sarayan>
and then, since it's a b&w framebuffer, do all the drawing by vram[xxx] = vram[xxx] | yyy;
<Sarayan>
I promise you a day of fun
<d1b2>
<martian> isPrivateKeyWorkaroundEnabled
cr1901_ is now known as cr1901
<josuah>
<Sarayan> quartus takes something like half an hour for each compile, how can people stand that?
<josuah>
it might also do a lot of checks that Yosys does not yet
<josuah>
gurki in #fpga on libera.chat can have long discussion if you like
<josuah>
I have no idea myself :) only used yosys
<josuah>
@Olivier Galibert I learned that openocd also suports a few FPGAs!
<FFY00>
whitequark, thanks, I think I understand you position
<FFY00>
I just want to clarify something, to make sure we are on the same page. I am not envisioning writing tool abstractions and have them automagically work, because that, I agree, it's very difficult to test in hardware.
<FFY00>
instead, I would simply like to standardize the interfaces, so that they can be more consistent across boards, and better integrated with the CLI
<FFY00>
the idea would be to provide these standardized tool interfaces, and then have board authors support them in their definitions
<FFY00>
but overall the goal is really to just make it more consistent and integrated into amaranth
<FFY00>
anyway, thank you
skipwich has joined #amaranth-lang
skipwich has quit [Read error: Connection reset by peer]