ZombieChicken has joined ##openfpga
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 246 seconds]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 264 seconds]
flea86 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 248 seconds]
azonenberg has quit [Ping timeout: 248 seconds]
futarisIRCcloud has joined ##openfpga
azonenberg has joined ##openfpga
azonenberg_work has joined ##openfpga
biostar has joined ##openfpga
<MicroHex> I'd say MOST SMT stuff is done via paste
<MicroHex> but... there is another way
<MicroHex> (though it does restrict what sorts of packages you can use)
<flea86> MicroHex: Drag soldering? :)
<MicroHex> naw that would count under hand assembly
<MicroHex> uh, wrong video there
<flea86> MicroHex: Sure. That's what I get for joining mid-conversation heh.
<MicroHex> right, I have no choice, can't find a decent video otherwise to explain wave soldering... so here's wave soldering https://www.youtube.com/watch?v=ntxIdJTygIE
<flea86> MicroHex: Isn't wave soldering normally used for thru-hole? Oh wait no that's not true.
<flea86> it's also used for SMD I think
<MicroHex> you can use the same equipment for both typically
<flea86> Aye
<MicroHex> these days, wave soldering for SMT is probably pretty rare. unless you only have a handful of SMT parts and are mostly doing PTH anyways
<flea86> I like how you put a 'dam' on your board to prevent SMD parts from washing away (if thru hole soldering) :D
<flea86> At one company I worked, we had two SMT lines, with IR and wave soldering
<flea86> Nice to see your own creation go through it though
biostar has quit [Quit: Page closed]
ZombieChicken has quit [Quit: WeeChat 2.5]
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Client Quit]
vonnieda has joined ##openfpga
Jybz has joined ##openfpga
genii has joined ##openfpga
genii has quit [Remote host closed the connection]
genii has joined ##openfpga
genii has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
wpwrak has quit [Ping timeout: 258 seconds]
rohitksingh_work has joined ##openfpga
rombik_su has joined ##openfpga
OmniMancer has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
jcreus has joined ##openfpga
m4ssi has joined ##openfpga
emeb_mac has quit [Ping timeout: 272 seconds]
jcreus has quit [Ping timeout: 272 seconds]
wpwrak has joined ##openfpga
_whitelogger has joined ##openfpga
eightdot has quit [Ping timeout: 272 seconds]
Asu has joined ##openfpga
<zignig> I have been messing about with the new nmigen-boards code, has anyone else taken if for a spin ?
<mithro> How do you get "3.95 Coremark/MHz" with a 2 stage pipeline processor?
<mithro> zignig: I have not, but I hope to sometime soonish
ZipCPU has quit [Ping timeout: 248 seconds]
<tnt> mithro: I'm not familiar with CoreMark, but why would it be an issue ?
<mithro> tnt: My understanding is that 1-2 Coremark/MHz for a 2 stage pipeline is normal and you need to go to more stages and OO to get higher
<tnt> I don't see why the # of pipeline stage would have any influence ... I mean it's per MHz, so it's independent of the fmax.
<tnt> And about OO, a compiler optimized for your particular arch could just issue the instruction in the best order for your particular CPU variant or am I missing something.
<zignig> mithro: afk , dinner and small people..
<zignig> mithro: i have only done a very small amount of omigen , bit nmigen feels easier to write.
<zignig> much more pythonic , I have mangaged to make gizmos that auto memory map themselves.
ZipCPU has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
ZipCPU|Alt has quit [Client Quit]
<mithro> tnt: zignig From reading it, it definitely looks nicer. Haven't gotten around to writing it yet...
rohitksingh_work has quit [Read error: Connection reset by peer]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 248 seconds]
X-Scale` is now known as X-Scale
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
vonnieda has joined ##openfpga
emeb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
m4ssi has quit [Remote host closed the connection]
gsi__ is now known as gsi_
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vonnieda has joined ##openfpga
jcreus has joined ##openfpga
emeb_mac has joined ##openfpga
rombik_su has quit [Ping timeout: 248 seconds]
mumptai has joined ##openfpga
mnr has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 272 seconds]
<TD-Linux> zignig, I've been using it barely, with my own platform file
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Ping timeout: 248 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 245 seconds]
SpaceCoaster has joined ##openfpga
gnufan_home has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
ZombieChicken has joined ##openfpga
wpwrak has quit [Ping timeout: 246 seconds]
wpwrak has joined ##openfpga
Asu has quit [Quit: Konversation terminated!]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 245 seconds]
mumptai has quit [Remote host closed the connection]
gnufan_home has quit [Quit: Leaving.]
Bike has joined ##openfpga
m4ssi has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 258 seconds]
<adamgreig> TD-Linux: i've just ported from using my own platform to using the built-in platforms
<adamgreig> pretty painless
<adamgreig> (it helps that my own platforms were written to what i guessed the real ones would look like, so very little needed to change :P)
<adamgreig> also wrt that usb-c connector, i've only been hand soldering it, but if it did work with paste that would be great, lmk if you ever try it
ZombieChicken has quit [Ping timeout: 245 seconds]
<adamgreig> not sure if you could get enough solder in or what though
<adamgreig> incidentally i've just finished the computer-side software for the ffp programmer, in rust, it's a bit nicer than the python script (though not really much in it)
eightdot has joined ##openfpga
<tnt> So this will not allow an iCE40 to boot because CDONE will never rise above 0.6V. Anyone ever see that documented anywhere ?!? (that the ice40 actually samples CDONE as an input before releasing its internal reset ?)
<adamgreig> jeez what
<adamgreig> i always just drive the led from cdone directly :P
<tnt> Well I guess the Vf of your led was high enough :p
<adamgreig> cdone has an internal pullup and i sink the led current into it, so it gets to 3v3 when fpga high-z's it
<adamgreig> hmm
<whitequark> tnt: i recall that being documented somewhere
<adamgreig> i can't find any mention of it in the programming app note which has the most detail on cdone, but it would typically be somewhere weird
<adamgreig> aha found it
<adamgreig> hmm
<adamgreig> no, I misread
<whitequark> yeah no, it's not in that appnote
<whitequark> i might be misremembering? i think xilinx does something like that
<tnt> The closest I found so far is "Number of configuration clock cycles after CDONE goes HIGH before the PIO pins are activated"
<tnt> but ... that's a bit of a stretch.
<adamgreig> everything I can find says very specifically that it's just an output
<tnt> but they go to great detail specifying the max pull up value you must use ... now I know why.
<adamgreig> i always figured that was just so your application processor reads it correctly
<adamgreig> but it did seem weird that it depends on SCLK freq
<adamgreig> I guess cdone has to pull high enough inside the 49 clocks or whatever, which is time dependent on the sclk freq
<whitequark> it's not actually 49 clocks at least on UP
<whitequark> more like 22 or something
<whitequark> i'm not even sure where 49 comes from
<adamgreig> 22.. times two.. add a few for good measure...
<adamgreig> the ice40 documentation is not exactly thorough
<adamgreig> whitequark: is -relut still recommended for synth_ice40 and if so should it be in the nmigen ice40 platform?
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark> adamgreig: hmm, i think it'd be better to turn it on upstream
<whitequark> but in general, yes, recommended
<adamgreig> It'd be nice if there was a way to set platform overrides from within python, like a method on the class, so you could set defaults in your board specific platform without having to set environment variables
<adamgreig> But I guess you can set os.setenv...
<whitequark> adamgreig: you can do it
<whitequark> moment
<adamgreig> Oh cool, thanks
<adamgreig> All I could see was via env
<whitequark> platform.build(synth_opts=["-relut"])
<adamgreig> huh, no kidding
<adamgreig> aha, I see it, nice
<adamgreig> thanks
m4ssi has quit [Remote host closed the connection]
<adamgreig> interesting, with relut on, nextpnr promotes a reset to a global then fails to place the SB_GB and quits out
<adamgreig> if I turn off promoting entirely it builds ok, and without relut it also builds ok. what have i done...
<adamgreig> if I make my sync cd not reset_less it's also ok
<tnt> adamgreig: :/ nextpnr shouldn't promote something it can't do.
<adamgreig> heap placer also fine, so only reset_less=True and relut on and default promotion on and sa placer causes the problem
<tnt> what's the log ?
<adamgreig> https://pastebin.com/fKcj1XH0 is nextpnr
<adamgreig> yosys is 1.2M of log
<adamgreig> L45 and L69 are the trouble
<adamgreig> sticking --no-promote-globals fixes it, or swapping to heap placer also fixes it