##openfpga on 2019-01-02 — irc logs at freenode.irclog.whitequark.org

00:10 Atlantic778 has joined ##openfpga

00:34 Atlantic778 has quit [Ping timeout: 268 seconds]

00:36 Flea86 has joined ##openfpga

01:24 oter has joined ##openfpga

01:24 oter has quit [Client Quit]

01:25 oter has joined ##openfpga

01:27 oter has quit [Client Quit]

01:35 emeb has quit [Quit: Leaving.]

01:41 <xobs> I am suspicious. Though I hope to understand more by the end of the day. But on my Fomu EVT (UP5K) board, I just rebuilt the bitstream and nextpnr reports: "Info: Max frequency for clock 'clk48': 107.97 MHz (PASS at 48.00 MHz)"

01:42 <whitequark> does the critical path look sensible?

01:43 <xobs> How would I check that?

01:44 <whitequark> nextpnr puts the critical path in the report

01:45 <xobs> Oh, that makes a lot of sense. Wow that's cool. Looks sensible to me.

01:49 GenTooMan has joined ##openfpga

01:52 jevinskie has quit [Ping timeout: 252 seconds]

02:05 unixb0y has quit [Ping timeout: 244 seconds]

02:07 unixb0y has joined ##openfpga

02:41 dj_pi has joined ##openfpga

02:44 pie_ has quit [Remote host closed the connection]

02:45 pie_ has joined ##openfpga

02:47 dj_pi has quit [Ping timeout: 240 seconds]

02:59 futarisIRCcloud has joined ##openfpga

03:16 jevinskie has joined ##openfpga

03:31 Miyu has quit [Ping timeout: 240 seconds]

03:53 soylentyellow__ has joined ##openfpga

04:00 GenTooMan has quit [Quit: Leaving]

04:14 dj_pi has joined ##openfpga

05:24 rofl__ has joined ##openfpga

05:25 Bike has joined ##openfpga

05:28 rofl_ has quit [Ping timeout: 252 seconds]

05:43 m_w has quit [Ping timeout: 250 seconds]

05:51 Bike has quit [Quit: Lost terminal]

06:05 dj_pi has quit [Ping timeout: 246 seconds]

06:41 _whitelogger____ has joined ##openfpga

06:43 _whitelogger has joined ##openfpga

06:43 _whitelogger_ has joined ##openfpga

06:43 _whitelogger__ has joined ##openfpga

06:43 _whitelogger___ has joined ##openfpga

06:57 pie_ has quit [Remote host closed the connection]

06:57 pie_ has joined ##openfpga

07:10 rohitksingh has joined ##openfpga

07:28 ym has quit [Ping timeout: 250 seconds]

07:37 _whitelogger has joined ##openfpga

07:56 rohitksingh has quit [Ping timeout: 245 seconds]

08:22 rohitksingh_work has joined ##openfpga

09:05 ayjay_t has quit [Read error: Connection reset by peer]

09:05 ayjay_t has joined ##openfpga

09:15 ayjay_t has quit [Read error: Connection reset by peer]

09:15 ayjay_t has joined ##openfpga

09:19 futarisIRCcloud has quit [Quit: Connection closed for inactivity]

09:27 Miyu has joined ##openfpga

09:32 Miyu has quit [Ping timeout: 246 seconds]

10:13 pie_ has quit [Ping timeout: 250 seconds]

11:24 m4ssi has joined ##openfpga

11:29 m_w has joined ##openfpga

11:35 m_w has quit [Ping timeout: 245 seconds]

11:47 _whitelogger has joined ##openfpga

11:48 Atlantic778 has joined ##openfpga

12:55 <whitequark> hmm

12:56 <tnt> indeed

12:56 <whitequark> daveshah: the more i look at LUT optimization and abc the more i question whether abc is good at this job more than incidentally

12:56 <whitequark> well, it's not very good

12:56 <whitequark> i'm looking at this paper http://cadlab.cs.ucla.edu/~cong/papers/iccad92.pdf

12:56 <whitequark> it's written somewhat incomprehensibly but i can see that i can represent *any* combinatorial logic with their algorithm *directly*

12:57 <whitequark> so, for example, i could literally take the combinatorial definition of SB_CARRY and include it in the flow graph

12:58 <whitequark> so that if it happens to be efficient to pack carries into LUTs for some reason (see one of my new PRs), it's done

12:58 <whitequark> similarly, i wouldn't even have definitions for nodes like $_AND_ or $_OAI3_ or whatever

12:58 <whitequark> it's sufficient to use yosys consteval to interrogate them during packing

12:58 <daveshah> ABC can do optimisation of carry and similar primitives too

12:59 <whitequark> right but what internal representation does abc use for them?

12:59 <daveshah> It's all an AIG

12:59 <whitequark> don't you have to break them into an aig or something?

12:59 <whitequark> yeah

12:59 <whitequark> fuck aig

12:59 <whitequark> i don't want an aig

13:00 <whitequark> this just messes up my logic for no good reason and makes it harder to see where it went

13:00 <whitequark> why can't it directly represent multiple input primitives? this is dumb

13:01 <whitequark> i want an optimization pass that works directly on luts

13:01 <whitequark> its been thirty fucking years and we still have no tools that do this? what bullshit

13:02 <daveshah> ABC can definitely do something more like that

13:02 <daveshah> It's still AIG based but with partitions for LUTs and hard functions

13:03 <whitequark> is there more than one person on this planet who knows how to actually make it work with abc?

13:03 <daveshah> Yes

13:03 <daveshah> Clifford knows now

13:04 <daveshah> I think him and Eddie will work on a new pass in Yosys using the extended AIGER interface rather than BLIF

13:04 <daveshah> This will also enable timing aware synthesis

13:05 Atlantic778 has quit [Ping timeout: 268 seconds]

13:07 <whitequark> hrm

13:07 <whitequark> do you think i should write opt_flowmap, or defer to that?

13:08 <daveshah> I'm pretty sure you'll have opt_flowmap done much sooner than the new ABC pass :)

13:08 <whitequark> okay

13:08 <whitequark> gonna write it then

13:08 <daveshah> Might be worth talking to clifford though

13:09 <whitequark> I think there is definitely some, uh, potential synergy available with opt_flowmap, because of the reuse of Yosys IR

13:09 <whitequark> but at some point the benefit over abc_aiger may be marginal

13:09 <whitequark> it's hard to say offhand

13:10 <daveshah> The new ABC interface will also get us much better retiming

13:10 rohitksingh_work has quit [Read error: Connection reset by peer]

13:12 <daveshah> If it helps, I managed to redraw the ECP5 carry logic into a way that is much easier to work with, also much closer to Xilinx carry logic. This form does lose an input that would occasionally be useful, but brings the significant benefit of making the two LUT halves independent.

13:12 <daveshah> https://usercontent.irccloud-cdn.com/file/3puwAlb1/ecp5%20carry%20split.png

13:13 <daveshah> I'll need to write a small packer pass, probably in Yosys, to recombine the subcomponents to a CCU2

13:13 <whitequark> daveshah: interesting

13:13 <whitequark> daveshah: that looks like it still can't implement an add/sub?

13:13 <whitequark> since it now only has 3 inputs

13:13 <daveshah> It can

13:13 <whitequark> oh, wait

13:14 <daveshah> Diamond manages it

13:14 <whitequark> the carry logic is *after* the LUTs not before

13:14 <daveshah> yes

13:14 <whitequark> that's why it can

13:14 <daveshah> Xilinx has the same MUX&XOR arrangement

13:14 <daveshah> but of course bigger LUTs on the 7-series

13:14 <whitequark> what is S?

13:14 <daveshah> sum output

13:14 <daveshah> ie what would be the LUT output in non-carry mode routing wise

13:15 <whitequark> oh i see

13:15 <whitequark> interesting

13:15 <daveshah> it's also worth thinking about the LUT expansion muxes in Xilinx & Lattice devices

13:15 <sorear> PFUMUX&L6MUX?

13:15 <daveshah> yeah

13:15 <daveshah> F7MUX/F8MUX in Xilinx land

13:16 <daveshah> they should also make building large multiplexers much easier

13:16 <daveshah> s/large/wide/

13:18 <daveshah> probably the best option for these is to have a Yosys techmap that maps multiplexers with >N (N to be decided on an arch-specific basis) inputs to them

13:18 <daveshah> then use abc_xaig/flowmap/etc to optimise them

13:18 <sorear> does "flowmap" have a specific meaning?

13:19 <sorear> *reads whitequark's paper* oh.

13:19 <whitequark> it's lut techmapping using flow maximization algorithm

13:19 <whitequark> actually the use of flow there is pretty boneless

13:19 <whitequark> all capacities are 0 or 1

13:21 <whitequark> it's really an iterative pathfinding problem stated in terms of flow maximization for some weird reason

13:21 <whitequark> probably because there were facts proven about that or something

13:21 <whitequark> they really have to go out of their way to make it about flow

13:22 <daveshah> > Sun SPARC IPC workstation (14.8 MIPS)

13:22 <daveshah> it's weird to think that people were doing FPGA synthesis on machines beaten by the fancier Arduinos

13:23 <whitequark> 32 MB of RAM tho

13:23 <daveshah> yeah, realistically that's the limit

13:23 <daveshah> we do need to do something self-hosting one day

13:24 <daveshah> probably makes more sense for Xilinx or something that can self-partial-reconfigure

13:24 <whitequark> daveshah: how do you feel about this paper btw?

13:25 <whitequark> in the sense of

13:25 <whitequark> can i ask you to read it and assist me in understanding some of the finer points

13:25 <whitequark> i grasp the overall idea but i resent the style in which it's written because it's like the opposite of what i want to know to implement it

13:26 <daveshah> So I must remind that my techmapping experience is probably less than yours (I've only ever done a very naive implementation a few years ago)

13:26 <daveshah> but I'll see what I can make of it

13:26 <whitequark> i got the impression that you're better with, well, badly written academic prose

13:27 <whitequark> well i guess it's not very badly written

13:27 <whitequark> mediocre academic prose :D

13:27 <daveshah> yes, I somehow managed to get that vaguely described BFS-based timing optimiser to work

13:27 <whitequark> the reason i went with flowmap is

13:27 <whitequark> the same people released several very closely related algorithms

13:28 <whitequark> http://cadlab.cs.ucla.edu/~cong/papers/iccad93.pdf is slower but better at depth minimization

13:28 <whitequark> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.7335&rep=rep1&type=pdf

13:28 <whitequark> this one does depth and area minimization at the same time

13:28 <whitequark> ie it determines critical path, optimizes it for depth and optimizes the area

13:28 <daveshah> Speed is no concern imo, synthesis CPU time right now is basically free

13:28 <whitequark> that's actually the one i'm most interested in

13:29 <daveshah> given that PnR is often well over an order of magnitude slower

13:29 <whitequark> because it's exactly what you want

13:29 <whitequark> you can also combine cutmap (the last one) with a variation on flowmap to do depth relaxation

13:29 <whitequark> so, it looked to me like it's reasonable to invest some time into figuring out how flowmap works

13:30 <whitequark> especially given that it's very straightforward conceptually

13:44 _whitelogger has joined ##openfpga

13:44 <Flea86> "<daveshah> probably makes more sense for Xilinx or something that can self-partial-reconfigure" Or two ECP5 chips in master-slave mode :D

13:44 <daveshah> :D

13:45 <daveshah> how about an ECP5 reconfiguring an iCE40

13:45 <Flea86> That would be neat as well

13:46 <Flea86> All I have right now, is an ECP5 that can be reconfigured by a dumb micro heh

13:46 <whitequark> daveshah: or an iCE40 that reconfigures the ECP5

13:46 <whitequark> using an intermediate PSRAM or something

13:46 <daveshah> unfortunately I realised the PSRAM idea doesn't work

13:46 <whitequark> oh?

13:47 <daveshah> all the SPI PSRAMs I find have a maximum CSn low time of 8us because of the DRAM refresh

13:47 <Flea86> Also, man VME files are largely full of nothing... :(

13:47 <daveshah> I am pretty sure the ECP5 has CSn low during the entire bitstream read like the ICE40

13:47 <whitequark> daveshah: that's why I said an intermediate iCE40

13:47 <whitequark> with additional logic to arbiter the PSRAM

13:47 <daveshah> yeah, you could do that with slave serial

13:48 <daveshah> there's prior art, the icoboard had a machxo2 to do misc config management

13:49 <Flea86> Nice, I should give ice40 a spin sometime

13:49 <whitequark> ice40 is really nice.

13:50 <whitequark> nice40.

13:50 <daveshah> Buy an icebreaker :D

13:50 <daveshah> https://www.crowdsupply.com/1bitsquared/icebreaker-fpga

13:50 <Flea86> heh

13:50 <whitequark> it's not very powerful but it's so tiny, you can understand every single thing it offers you in no time

13:50 <daveshah> that's why clifford picked it in the first place

13:50 <zkms> qt smol ice40 :3

13:50 jcreus has joined ##openfpga

13:50 <whitequark> well, it's certainly powerful enough for glasgow

13:50 <Flea86> daveshah: Cool board!

13:53 <Flea86> daveshah: Not sure if you've seen my Ohm board offering.. rpi zero form factor isn't everyone's cup of tea I'd imagine.

13:53 <daveshah> It suits the iCE40 well imo

13:53 <daveshah> because you can run the tools on the Pi zero too

13:54 <daveshah> I think mithro is interested in doing this for a very low cost complete dev environment, no install needed

13:54 <Flea86> Cool.

13:55 <daveshah> The other neat thing about the iCE40 is its static power. 2 orders of magnitude lower static power per LC than Artix-7

13:56 <Flea86> Reminds me of the MachXO2.. that was easy on the juice too

13:56 <daveshah> <100µW static power for the UltraPlus

13:56 <Flea86> Not bad

13:56 <Flea86> Not bad at all

13:57 <Flea86> One of the things I miss about the MachXO2 that isn't on the ECP5: The uber-flexible PLL block :(

13:57 <daveshah> ditto

13:57 <daveshah> it's a real shame

13:58 <daveshah> particularly for video mode switching, etc

13:58 <Flea86> Why they gimped it like that I'll never understand lol

13:58 <Flea86> I could, for example, generate an accurate NTSC colorburst signal from a 50MHz input :D

13:59 <Flea86> That is nice

13:59 <noopwafel> are there ECP5 dev boards I can actually just go buy atm, other than the lattice ones?

14:00 <Flea86> noopwafel: I made some previously.. working on an Ohm2 currently :)

14:00 <daveshah> nice

14:00 <daveshah> noopwafel: there is some kind of availability of the ULX3S, but it's more a case of emailing them

14:00 <daveshah> http://radiona.org/new-fpga-board-ulx3s/

14:00 <Flea86> noopwafel: I understand tinyfpga is also making some too :D

14:01 <daveshah> right now the Lattice boards are definitely the easiest to buy

14:01 <noopwafel> Flea86: yeah, looking forward.. :)

14:01 <Flea86> daveshah: Yes, forgot about ulx3s, I have one here :D

14:01 <noopwafel> and yes I regret having not found the ulx3s people at 35c3 :(

14:01 <noopwafel> will mail them, thanks

14:01 <daveshah> I think there will be some 85k ULX3Ss available soon

14:02 <Flea86> daveshah: They've put a lot of effort into their board, it uses a jtag solution that is borrowed from my Ohm xD

14:03 <Flea86> Which borrowed from my earlier work with the XO2

14:03 <daveshah> heh

14:04 <swetland> I strongly suspect that if the foss fpga toolchain stuff keeps pushing ahead, eventually we're going to see performance/quality exceeding the vendor tools

14:05 <swetland> just thinking... there are only a few vendors... they have a relatively small pool of folks working on this stuff... some of them are probably quite good... but the open source projects have the potential of getting contributions from amazing people who'd never consider going to work for an fpga vendor

14:07 <swetland> but based on the overall software quality I see from fpga vendors, I suspect they suffer from similar issues to the silicon vendors in software development -- not enough value placed on and compensation directed toward software teams, difficulty in hiring really excellent people, etc.

14:07 <daveshah> I'm not super comfortable disclosing exact benchmarks. But my testing of Yosys with all the latest optimisations (tnt's CE stuff and whitequark's relut) and nextpnr with opt-timing and we were less than 10% behind Radiant Fmax-wise on the designs I tested - with overlapping error bars in some cases

14:07 <daveshah> So the inversion point will be next year for sure

14:08 <daveshah> *this year

14:08 <daveshah> derp

14:09 <whitequark> lol

14:09 * swetland nods.

14:09 * swetland needs to see if he can trick his employer into paying him to work on this stuff fulltime ^^

14:13 <sorear> Fmax per MB of download

14:13 <whitequark> lol

14:14 * swetland dies

14:14 <daveshah> whitequark: So these papers seem reasonable enough I think

14:14 <daveshah> I still need to spend a bit more time thinking over them

14:14 <whitequark> okay, thanks

14:15 <whitequark> the specific issue i have is representation for the flow graph

14:15 <whitequark> what htey have on fig3c clearly doesn't have to actually exist

14:15 <whitequark> it's just a conceptual representation of a graph on fig3b

14:15 <whitequark> but i think i have to actually build the graph on fig3b in memory

14:16 <whitequark> and if i have to do this from scratch for every node it'll get slow pretty quickly

14:16 <whitequark> i think there are reuse opportunities, but i do not see them

14:16 <whitequark> well not offhand anyway

14:17 <swetland> I really want to dig in and play with tracking net/etc names across synthesys and placement and see if we can't improve the ability to understand what part of your design ended up where and better relate the final bitstream with the original design

14:17 <whitequark> swetland: do you want any specific suggestions?

14:18 <whitequark> the verilog frontend currently gives cells really dumb names

14:18 <whitequark> that would be a nice easy fix

14:18 <swetland> yeah that was something I was wondering about

14:18 <whitequark> i've looked at it

14:18 <daveshah> another thought - the JSON file can have multiple names for a signal

14:18 <whitequark> just never got around to fixing

14:18 <daveshah> at the moment nextpnr picks one according to a heuristic

14:18 <swetland> definitely would be up for some suggestions of things to poke at while I start learning how the codebase works

14:18 <daveshah> but it would be cool for nextpnr to have some kind of aliases

14:18 <daveshah> so any name works for timing constraints, etc

14:19 <daveshah> one day I'd love a cross-probing IDE

14:19 <swetland> I was wondering if clocks shouldn't be distinct entities (named when declared in constraints and attached to a pin/net/etc) and then they "stick" to that net

14:20 <daveshah> click a wire or bel in the device view; editor goes to a line in the source code

14:20 <daveshah> swetland: seems reasonable

14:21 <swetland> which also provides a nice hint for promote-to-global

14:22 <swetland> similarly interesting would be a mechanism for generating derived clocks -- give SB_PLL* and its parameters and a clock definition of the input, we should be able to make a pretty solid guess about downstream clocks

14:22 <whitequark> ooh

14:23 <swetland> I seem to recall the xilinx tools being able to do that, I don't think the lattice tools do

14:23 <tnt> swetland: they do

14:23 <tnt> and I think dave has derived clock in his todo list.

14:23 <swetland> I must be holding them wrong then

14:23 <daveshah> it's on the todo list for my master's thesis

14:24 <daveshah> effectively we already do it in nextpnr for the trivial case of global buffers

14:26 tmeissner has joined ##openfpga

14:30 <swetland> re: hw issues from last week: got to the bottom of the non-functional PLL on my second icebreaker -- either the resistor in front of vpll was busted or solder joint was not happy (lost the resistor swapping it... frakkin 0402s are too tiny) but replacing it made the world happy again.

14:30 <daveshah> good to know

14:31 <daveshah> guess esden needs a PLL test now

14:31 X-Scale has joined ##openfpga

14:34 <s_frit> is there currently any path to getting an icebreaker before mid-year? (for people who missed the early bird)

14:34 Laksen has joined ##openfpga

14:35 <daveshah> find someone who bought one at CCC and make them an offer they can't refuse /s

14:35 <swetland> board files are on github, no? the truly adventurous could have their own fabbed I suppose!

14:36 <daveshah> swetland: https://twitter.com/GregDavill/status/1073517114449747968

14:36 <tnt> Yeah, it's not that adventurous, it's not that complex.

14:36 <tnt> Making a glasgow rev.C, that's adventurous :p

14:37 <daveshah> or a tinyfpga ex

14:37 <whitequark> daveshah: so, for the example circuit in paper, opt_lut produces 10 LUTs of depth 4

14:37 <whitequark> this... really sucks

14:37 <whitequark> it's no wonder Fmax is shit

14:37 <s_frit> yeah, if i did it, it would be my first 0402 hand solder job

14:38 Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]

14:38 <whitequark> oh, if i tell it to do it with 3-LUTs like in the paper, still 10 LUTs, but depth 5

14:38 <whitequark> so over 2x of what's necessary

14:39 <daveshah> I almost wonder if the first step is just to look for better heuristics for opt_lut

14:40 <whitequark> I think opt_lut should be relegated to a cleanup role, tbh

14:40 <daveshah> I was thinking about that.

14:40 <daveshah> opt_lut would be very nice to do "LTO" in a hierarchical flow

14:40 <whitequark> yep

14:41 <daveshah> where you techmap modules individually with ABC/whatever, but might as well do some basic optimisations on the flattened netlist

14:41 rohitksingh has joined ##openfpga

14:42 <whitequark> ok, so what I'm thinking is

14:42 <whitequark> in the paper the nodes are cells

14:43 <whitequark> but this doesn't work all that well for rtlil

14:43 <whitequark> first, PI and PO aren't cells, they can well be module ports

14:43 <whitequark> second, cells can have multiple outputs

14:43 <whitequark> so I'm thinking about making *signals* the nodes

14:44 <whitequark> actually

14:44 <whitequark> i think if i make signals the nodes

14:44 <whitequark> i can do techmapping *directly* from coarse cells

14:45 <whitequark> or rather

14:45 <whitequark> we don't need to call simplemap at all on coarse cells with <=k inputs

14:46 <whitequark> because those can be flowmapped directly

14:46 <whitequark> and in fact the papers have some indication that this is preferable

14:47 <daveshah> Yes, that seems very reasonable

14:48 <daveshah> Might have to be a bit careful dealing with multibit signals for coarse cells

14:48 <whitequark> oh I'll sigmap everything to wires

14:49 <daveshah> Yeap

15:04 Miyu has joined ##openfpga

15:23 jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]

15:26 <whitequark> okay, i can extract what looks like a viable graph

15:27 <whitequark> time to look at dot again :S

15:38 jevinskie has joined ##openfpga

15:39 Atlantic778 has joined ##openfpga

15:41 <whitequark> https://gist.github.com/whitequark/1c1f4d12fcaf6142fa3c080b7424bc19

15:41 <whitequark> looks similar to the paper?

15:49 rohitksingh has quit [Remote host closed the connection]

15:50 jcreus has quit [Read error: Connection reset by peer]

15:51 jcreus has joined ##openfpga

15:51 rohitksingh has joined ##openfpga

15:56 Atlantic778 has quit [Ping timeout: 252 seconds]

16:06 Atlantic778 has joined ##openfpga

16:21 <daveshah> yep, looks good

16:26 <tnt> whitequark: in glasgow, is there a way to get back the subtarget that was built in the Applet.build() method from a test setup routine ? Like in SPIMasterAppletTestCase.setup_loopback() you get self.applet.mux_interface but what I'd like is the SPIMasterSubtarget ?

16:34 <whitequark> tnt: mmm, you could assign it as a property

16:36 <tnt> ok tx, I was just wondering if there was some built-in way I wasn't seeing.

16:38 <whitequark> nope. glasgow doesn't really do a lot of magic

16:38 <whitequark> it does a bit but i try to make it plain python as much as i can

16:44 m_w has joined ##openfpga

16:47 X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]

16:52 ironsteel has joined ##openfpga

16:56 m4ssi has quit [Remote host closed the connection]

16:57 mumptai has joined ##openfpga

17:04 rohitksingh has quit [Ping timeout: 272 seconds]

17:15 tmeissner has quit [Quit: Textual IRC Client: www.textualapp.com]

17:18 rohitksingh has joined ##openfpga

17:21 ironsteel has quit [Ping timeout: 250 seconds]

17:25 Atlantic778 has quit [Ping timeout: 250 seconds]

17:26 emeb has joined ##openfpga

17:34 <whitequark> lmao

17:34 <whitequark> i segfaulted dot

17:52 <cpresser> from graphviz?

17:54 <whitequark> yeah

17:54 <jn__> somehow i first read that as "i segfaulted qDot"

17:54 <jn__> plz, brain

18:12 <tnt> ... fuck that FXMA ...

18:13 <tnt> trying to flash a spi flash ... but of course there are 10k pull ups on the line :/

18:13 <whitequark> tnt: i know right.

18:14 Atlantic778 has joined ##openfpga

18:14 Atlantic778 has quit [Client Quit]

18:29 X-Scale has joined ##openfpga

18:36 <whitequark> daveshah: i wrote exactly half of the pass.

18:37 <daveshah> awesome

18:38 <kc8apf> I applied for a job at Lattice to see what would happen. Rejected right away.

18:39 <daveshah> :(

18:39 <whitequark> what did they reject you for?

18:39 <kc8apf> just got a generic rejection letter

18:39 ironsteel has joined ##openfpga

18:40 <whitequark> huh.

18:41 ironsteel has quit [Remote host closed the connection]

18:41 octycs has joined ##openfpga

18:42 <kc8apf> guess I don't have enough experience in writing FPGA tools *eyeroll*

18:43 <daveshah> s/don't have enough/have too much/

18:43 <sorear> or maybe the reason has very little to do with anything about you

18:44 <kc8apf> sure. they could have had a candidate already lined up but the paperwork wasn't finished

18:50 <sorear> a thing Rocket relies on synthesis tools doing: recognizing long chains of multiplexers and converting them into logarithmic priority encoders

18:58 <whitequark> i think yosys can do that?

19:15 rohitksingh has quit [Ping timeout: 246 seconds]

19:24 <whitequark> daveshah: ... and now that i managed to write a DFS correctly, it even works

19:46 <whitequark> aaaand we have cuts!

19:50 <plaes> o_O

19:50 <plaes> cuts?

19:50 <whitequark> graph cut

19:51 <plaes> and DFS is depth first search? ;)

19:51 <whitequark> yes

19:51 <plaes> \o/

19:58 ayjay_t has quit [Read error: Connection reset by peer]

19:58 ayjay_t has joined ##openfpga

19:59 <m_w> https://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm

19:59 pie__ has joined ##openfpga

20:01 <whitequark> yes

20:01 <whitequark> i'm using that one

20:02 <m_w> I used this for circuit partitioning in the past

20:02 <m_w> max flow min cut

20:03 <whitequark> yes

20:04 <m_w> wonder if I still have that code somewhere

20:04 <jcreus> it can also be formulated as an LP

20:04 <jcreus> not sure how the complexity compares in practice tbh

20:05 pie___ has joined ##openfpga

20:08 pie__ has quit [Ping timeout: 252 seconds]

20:27 tlwoerner has joined ##openfpga

20:45 GuzTech has quit [Remote host closed the connection]

20:49 GuzTech has joined ##openfpga

20:57 <tnt> I removed the FXMA and just connected it through and now at least I can talk to the flash ... rework is ugly though, will have to redo it. Maybe a 0ohm resistor pack would work to cross that gap.

21:14 inquisitiv3 has joined ##openfpga

21:21 kristianpaul has quit [Quit: leaving]

21:21 kristianpaul has joined ##openfpga

21:24 octycs has quit [Remote host closed the connection]

21:41 Flea86 has joined ##openfpga

21:48 jcreus has quit [Ping timeout: 250 seconds]

21:55 genii has joined ##openfpga

22:35 mumptai has quit [Quit: Verlassend]

22:36 Laksen has quit [Quit: Leaving]

23:12 <tnt> whitequark: did you actually use the 25c spi flash applet with a real device ?

23:13 <tnt> This looks highly suspicious to me: https://pastebin.com/15nbsP5R especially all the incoming 0xff ... since there was no read commands at all requesting that much data.

23:31 pie___ has quit [Ping timeout: 260 seconds]

23:36 futarisIRCcloud has joined ##openfpga

23:43 genii has quit [Remote host closed the connection]

23:46 pie___ has joined ##openfpga

23:57 Bike has joined ##openfpga

23:58 pie___ has quit [Remote host closed the connection]

23:58 <tnt> looks like it doesn't like the write of > 256 bytes for the page write command. splitting that into 2 CMD_WRITE commands (using SS_HOLD for the first) solves the issue.

23:59 pie__ has joined ##openfpga