dh73 has quit [Ping timeout: 260 seconds]
azonenberg has quit [Ping timeout: 264 seconds]
<emily> is project trellis' python usage performance-intensive in the way icestorm's is? i.e. should I bother trying to get it working with pypy?
azonenberg has joined ##openfpga
Bike has quit [Quit: Lost terminal]
Flea86 has joined ##openfpga
emeb has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
emeb_mac has quit [Quit: Leaving.]
<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
<sorear> you can use a lfsr for pc generation
<sorear> 1-bit microprocessors historically existed
<Flea86> MC14500 :)
<Flea86> Admittedly that only had an LU, not ALU
<Flea86> @sorear
<sorear> over a 1-bit ring + - ^ are degenerate as are * &
<sorear> so you do have the 3 functions
<Flea86> That sounds rather masochistic to do with a 14500 heh
<Flea86> It'd work tho
<emily> ZirconiumX: I should get around to (watch|read)ing Spice and Wolf. the source of mine is https://danbooru.donmai.us/posts/1621140
<emily> 1-bit CPUs are cute
<emily> there should be more of them
<tnt> Someone here was making a 4 bit one.
<tnt> Used in HP calculators.
<tnt> yup, that's probably it.
<Flea86> emily: I'm not sure the last chapter has been written on those yet.
<ZirconiumX> emily: the anime is really good IMO, but it's incomplete
<whitequark> spice and wolf is really good
<ZirconiumX> It's surprising how good a story about medieval economics can work
<ZirconiumX> But I think it works due to being based on intrigue, plus how the main characters play off each other
Asu` has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
rombik_su has joined ##openfpga
rohitksingh has joined ##openfpga
wpwrak has quit [Ping timeout: 272 seconds]
<zignig> whitequark: I am maping all the free IO on my tinybx to be tristate, a set of registers for direction and two for value (r/w)
<zignig> what I would like to do is make a big crossbar that can map a series of resident Elaboratable(s) over any of those pins.
<zignig> where should I start ? a bin fan out fan in mux ? incant some cursed logic ?
<tnt> Funny, I've been looking at that very recently :)
<zignig> tnt: I almost have a serial bootloader for boneless_v3 running , but I getting distracted from the main event.....
<tnt> https://en.wikipedia.org/wiki/Clos_network#Bene%C5%A1_network_(m_=_n_=_2)
<zignig> interesting thanks , zipcpu has a speil aswell, http://zipcpu.com/blog/2019/07/17/crossbar.html
* zignig mmm FAT trees
<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]
Asu` has joined ##openfpga
Asu` has quit [Ping timeout: 246 seconds]
Bike has joined ##openfpga
freemint has joined ##openfpga
MarcelineVQ has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
wpwrak has quit [Ping timeout: 244 seconds]
emeb has quit [Ping timeout: 246 seconds]