<eddyb>
I'm curious what FPGA families they're talking about and whatnot but I'd rather not waste their time with a long twitter thread lol
<ZirconiumX>
emily: as far as I can tell Python is mostly used to call Diamond in Trellis, so pypy probably would not help.
<emily>
ZirconiumX: *nod* I was just going by nextpnr's build involving an awful lot of CPU time in trellis-related python3, but I guess that's hopefully mostly in the C++ extension
<emily>
(pypy does help generate the ice40 stuff faster)
<ZirconiumX>
Apparently building the Trellis chipdb is really intensive
<ZirconiumX>
Unfortunately I don't know too much about the build process
<ZirconiumX>
I mean, I'm writing my fuzzing scripts in bash ^^;
<sorear>
the "build system" doesn't call fuzzers
<sorear>
at least not unconditionally
<sorear>
you can build nextpnr from the repo without diamond
<ZirconiumX>
So it's working on the output files of fuzzing?
<sorear>
not sure
<sorear>
haven't tried
<sorear>
past conversations have suggested there is a lot of low-hanging algorithmic fruit in the build system
<ZirconiumX>
Is this the part where we summon daveshah?
<sorear>
no, it's the part where I apologize for having intended to look over the build system and make it faster but never got around to it
<emily>
I'm guessing it's probably doing things that don't actually need to take 4 gigabytes of RAM and all of (one, because Python) CPU for half an hour but that are more convenient that way
<tnt>
The generate bba , then generate .c file from the bba, then build the cfiles sequential process is definitely not optimal.
<ZirconiumX>
Eeyup
<tnt>
I'm not sure if it's possible to directly write binary files (instead of bba) and then use objdump to directly convert to object files, that would already be a start.
<daveshah>
The slow part is generating the deduplicated chip databases (which then make nextpnr much smaller and faster)
<daveshah>
Most of this is already in C++ and bound by Boost so PyPy probably isn't what you want
<daveshah>
To avoid using too much memory CMake is set to build them one by one
<daveshah>
To run faster at the expense of memory you can do -DSERIALIZE_CHIPDB=no
<daveshah>
This builds all three devices at once
<ZirconiumX>
I think it got serialised after the build brought WQ's computer to its knees
<tnt>
The CI systems builds them right ? And they don't change all that often IIRC. So maybe just having then downloadable and skip that part of the build process for most people would be doable ?
<daveshah>
Yes, that would be the best option
<daveshah>
It's just a case of actually getting round to setting up the infrastructure for that
<daveshah>
When compressed they aren't too big
<emily>
I'm already turning off SERIALIZE_CHIPDB, yeah.
<emily>
I'm updating stuff for nixpkgs/NixOS so just downloading someone else's build unfortunately doesn't quite work :)
<daveshah>
Well, it's not really building stuff from scratch anyway as it's using the database in Trellis (that would be ~30 hours to rebuild)
<daveshah>
So using prebuilt bbas would just add one more preprocessing step to that
<ZirconiumX>
Yeah, there's a line that should probably be drawn on reinventing the wheel :P
<sorear>
by "30 hours to rebuild" you mean running the fuzzers against a copy of diamond?
Asu has joined ##openfpga
<emily>
ZirconiumX: your twitter avatar is cute btw ^^
<ZirconiumX>
emily: it's a custom commission of Holo from Spice and Wolf
<ZirconiumX>
Your own avatar is cute, too
<Flea86>
ZirconiumX: o/ Just saw your inventory list for your 32bit TTL computer... that's quite a list!
<ZirconiumX>
Indeed, which was how I became one of the two idiots who got Yosys to synthesise Verilog into 7400-series TTL ICs
<daveshah>
sorear: yeah
<daveshah>
In theory at least that should work to rebuild an identical db
Asu has quit [Ping timeout: 245 seconds]
Asu` has joined ##openfpga
<tnt>
ZirconiumX: did you buy the parts yet ? :)
<ZirconiumX>
Sadly not, tnt; even though I've got a bunch of schematics, ADD really sucks
<ZirconiumX>
Also, I need to figure out a way to simulate a KiCad schematic
<tnt>
Are you using some ALU chips ? What makes the addition such an issue ?
<Flea86>
ZirconiumX: Or find some way to export Kicad sch to ISE sch capture :D
<tnt>
oh wait, nm, ... got that completely wrong.
<sorear>
ha
<ZirconiumX>
tnt: '181 and '182 chips don't come in anything more modern than TTL; so I have to get creative with '153s and '283s
<sorear>
psychologists need to step up their game and work out what SUB, DIV, and MUL ar
<ZirconiumX>
Which makes it essentially LUT2(a, b) + LUT2(a, b)
<sorear>
look if Z/(2^16)Z is too hard you can just do GF(2^16)
<ZirconiumX>
tnt: another issue is the carry chain
<Flea86>
ZirconiumX: I thought there was an 'F181? No?
<ZirconiumX>
When you're working in 'AC/'AHC, TTL is a bit inconvenient, Flea86
<Flea86>
Well OK, that's still TTL
<Flea86>
Yeah Okay
<Flea86>
You can always use HCT to talk to it :)
<tnt>
ZirconiumX: is is a bit serial ? or do you do a 32 bit adder ? (then yeah, doing a manual carry chain is a pain ...)
<ZirconiumX>
Sure, Flea86, but that incurs a latency penalty over native CMOS
<sorear>
don't have an adder, do addition with a sw routine
<ZirconiumX>
tnt: at the time I designed this I didn't know what bit-serial was
<zignig>
tnt: my aim is to have a boneless construct that can be run on _any_ nmigen board.
<tnt>
I don't really understand what you mean.
<zignig>
tnt: given a 9600 8n1 serial port I want to be able to generate an image for any defined nmigen-board that will drop into a usable console
<zignig>
a FORTH console seem the easiest be , but that remains to be seen.
<zignig>
her-quarkyness has written a fresh processor, I'm trying to get it running.
<tnt>
ok. But I don't see the connection with your earlier request. I mean, at some point you'll need the user to define (1) which clock pin to use (2) which pins to use for that uart before building. Looking at a couple of boards, naming isn't specified and varies per board.
<whitequark>
nmigen has a "default clock" thing now
<whitequark>
as for the UART, naming is actually specified: platform.request("uart") will give you the 1st uart if any
<tnt>
"if any" ... lots of board just have a bunch of gpio with no meaning assigned.
<whitequark>
indeed
<whitequark>
but you said "naming isn't specified and varies per board"
<whitequark>
except in all nmigen boards it is the same...
<whitequark>
anyway it doesn't sound like you need a crossbar here
<tnt>
right, my bad. On the clock, I saw different names, I didn't know nmigen would just "pick a default one" among those. And for the uart I meant that there is no universal names you can use with _any_ board as stated in the original problem. It nice at least that for those with defined uart there is a specified name.
<whitequark>
tnt: there is a "default_clk" parameter that says which clock is the default
<whitequark>
there's no magic in that
<whitequark>
as the board designer you can pick one or omit it
<tnt>
But as you said, crossbar seems a tad overkill, some of those boards have _lots_ of IOs.
<whitequark>
indeed
<whitequark>
it's not realistic to handle 200 IOs or something
<ZipCPU>
An I/O crossbar would be much simpler than the bus crossbars I discussed in my article
<ZipCPU>
Arbitration would be easier ... at issue might be the clock delays required to go through an IO arbiter ...
<sorear>
the fpga fabric itself is a crossbar, why make a soft one?
<zignig>
sorear: so I can fill up an fpga with gizmos and map them to any pin with software.
<zignig>
if I need a new gizmo , compile and deploy.
* zignig
managed to get 2 bonelessii runinng tonight.
<ZipCPU>
sorear: Most SOCs that you can buy have some form of I/O crossbar. Therefore, there's a valid discussion to be had there. The limitation with the FPGA crossbar, as zignig noted, is that it's fixed at PNR time.
<zignig>
ZipCPU: thanks for all the (rather lengthy) blog posts, you have go the brain juice flowing.
<zignig>
*got
rohitksingh has quit [Remote host closed the connection]
genii has joined ##openfpga
keesj has quit [Ping timeout: 248 seconds]
keesj has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
genii has joined ##openfpga
lexano__ has quit [Ping timeout: 272 seconds]
lexano__ has joined ##openfpga
emeb has joined ##openfpga
dh73 has joined ##openfpga
wpwrak has joined ##openfpga
Flea86 has quit [Quit: Leaving]
azonenberg_work has joined ##openfpga
rombik_su has quit [Read error: Connection reset by peer]
rombik_su has joined ##openfpga
rombik_su has quit [Read error: Connection reset by peer]
rombik_su has joined ##openfpga
rombik_su has quit [Ping timeout: 248 seconds]
rombik_su has joined ##openfpga
rombik_su has quit [Ping timeout: 245 seconds]
dh73 has quit [Ping timeout: 260 seconds]
Jybz has joined ##openfpga
Jybz has quit [Remote host closed the connection]
Jybz has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 272 seconds]
stefanct has quit [Quit: quit]
Asu has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
lexano__ is now known as lexano
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Jybz has quit [Quit: Konversation terminated!]
genii has quit [Remote host closed the connection]
Asu` has quit [Read error: Connection reset by peer]