pie_ has quit [Ping timeout: 268 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
wbraun has quit [Quit: wbraun]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
azonenberg_work has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
unixb0y has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 272 seconds]
Miyu has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 246 seconds]
<SolraBizna> in which I spend two days running into every possible wrong combination of UART polarities
rohitksingh_work has joined ##openfpga
eightdot has quit [Ping timeout: 240 seconds]
eightdot has joined ##openfpga
Bike has quit [Quit: Lost terminal]
grantsmith has quit [Ping timeout: 250 seconds]
grantsmith has joined ##openfpga
<marshallh> i know that feel
<marshallh> tx > tx? not on this device, it's tx > rx
<Lord_Nightmare> better than the votrax type n talk where the db25 connector on the back has a wiring error that swaps RTS and CTS; they shipped a special cable with it to swap them back, but these are almost universally missing from units on ebay
<Lord_Nightmare> since they look like a plain db25 to db25 cable
<Lord_Nightmare> fortunately its 2 traces to cut and a tiny X of patch wires to fix
wbraun has joined ##openfpga
azonenberg_work has joined ##openfpga
wbraun has quit [Quit: wbraun]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 244 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
<gruetzkopf> have i mentioned the 1200bd partyline modems that use RTS for PTT?
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
Ultrasauce has quit [Remote host closed the connection]
WilhelmVonWeiner has quit [Ping timeout: 260 seconds]
Ultrasauce has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner is now known as Guest3080
jcreedon has joined ##openfpga
jevinskie has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
<SolraBizna> nextpnr is now taking several minutes per *iteration* routing my project
<SolraBizna> if ever there was a sign that I'm close to device capacity, this is it
<azonenberg_work> SolraBizna: what chip?
<azonenberg_work> (you need a bigger one lol)
<SolraBizna> iCE40 UP5k
<SolraBizna> in the end I'm going to be on an HX8k, but I'm taking this detour to attempt the contest
<SolraBizna> I've been iterating slowly on the pieces, and I haven't really had time to optimize any for size (since I don't even have them all working on a basic level yet)
maciejjo has quit [Ping timeout: 252 seconds]
Patater_ has quit [Quit: Explodes into a thousand pieces]
Patater_ has joined ##openfpga
<SolraBizna> but it's backfiring now, since it takes me over an hour to iterate on even the smallest change
oeuf has joined ##openfpga
maciejjo has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
<SolraBizna> ugh, is there a good libre Verilog UART out there?
<rqou> azonenberg_work has one
<rqou> it's optimized for the fabric to use though, not a cpu
<rqou> e.g. it will assert done signals for only a single cycle (not latched)
<SolraBizna> sounds like I can wrap a couple FIFOs around it and interface it to my CPU pretty easily
<azonenberg_work> SolraBizna: yeah you could
<rqou> i've used a hacked up version of the opencores one before
<rqou> it's not great though
<azonenberg_work> it's in azonenberg/antikernel-ipcores on github
<azonenberg_work> (3-clause BSD license)
<azonenberg_work> should be easy to find
<SolraBizna> sweet
<azonenberg_work> i think under /interface/uart/
<SolraBizna> yup
<SolraBizna> this looks perfect, thanks
<azonenberg_work> SolraBizna: good catch, i guess the extra bit of padding never got used for anything so i never fixed it?
<azonenberg_work> feel free to send a PR :p
<SolraBizna> I just might do that, it'll make a nice break from a whole three days of debugging my own attempt at a UART without an oscilloscope
<azonenberg_work> this code is pretty well tested
<SolraBizna> It looks pretty solid
<azonenberg_work> i do want to do a few tweaks to clean it up a bit at some point, in particular if you have oversampling turned off there's no metastability hardening on the input ff
<SolraBizna> hm... it looks like it will have issues if the clock divider is very close to zero
<SolraBizna> not that that will actually matter in practice
GuzTech has joined ##openfpga
<azonenberg_work> SolraBizna: yeah it assumes a decently fast clock
<azonenberg_work> i didnt optimize it for bizarre situations like 10 Mbps uart on a 20 MHz clock
<SolraBizna> makes perfect sense
<SolraBizna> getting a reliable UART link >1Mbps is gonna be insane no matter what... and even my braindead giant-spaghetti-tangle-of-logic RV32I core still managed to reach 8MHz
<whitequark> SolraBizna: huh?
<whitequark> UART works just fine on 3 Mbps
<SolraBizna> I'll take your word for it
<whitequark> SolraBizna: do you need a proven UART?
<whitequark> mine is not oversampled so it's smaller and simpler
<SolraBizna> neither is azonenberg_work's by default
<whitequark> ah ok
<whitequark> nvm then
<azonenberg_work> whitequark: the issue is that my uart right now divides the clock down (even with oversampling off) so you can sample in the middle of the data eye
<whitequark> since mine is in migen azonenberg's probably easier to integrate
<azonenberg_work> so you cant use a divider of like 1-2 very well
<whitequark> azonenberg_work: i sample in the middle of data eye too
<azonenberg_work> But realistically, nobody wants to run a uart that fast
<azonenberg_work> so its a non-issue
<SolraBizna> the one I was building required a 16x line rate clock, so this is definitely an improvement on that :P
<whitequark> that too
<azonenberg_work> if yo need a 3 Mbps uart you'll have a 10+ MHz clock
<whitequark> yeah
<azonenberg_work> I think right now mine realistically wants a 4x rate clock at minimum
<azonenberg_work> But i havent touched the code in a little bit
<azonenberg_work> obviously if your clock isn't an exact multiple of the line rate, you get problems with small dividers causing big errors
<azonenberg_work> vs if you have say a 50 MHz clock doing 9600 baud, you dont need an exact multiple becuase the error is tiny
<azonenberg_work> whitequark: oh, $BOSS wants me to learn python this coming week
<azonenberg_work> lol
<azonenberg_work> I have a project in mind that i think might actually be useful (as well as educational)
<whitequark> azonenberg_work: my UART has a function that calculates clock error :p
<whitequark> it used to be in verilog, actually
<whitequark> oh
<whitequark> I still have that one
<azonenberg_work> anyway... I want to make a low level, roughly timing accurate model of FREESAMPLE
<azonenberg_work> the trigger and acquisition subsystem
<whitequark> you could find this useful, perhaps
<azonenberg_work> whitequark: start with a raw data capture somebody in ##fpga sent me (5M samples of USB3 @ 12.5 Gsps, as a float[])
<azonenberg_work> Sinc upsample to 125 Gsps
<whitequark> azonenberg_work: use numpy
<whitequark> definitely use numpy
<azonenberg_work> then iterate through that dataset
<azonenberg_work> find rising edges, model the propagation delay of the comparator as i do so
<azonenberg_work> Do a timing-accurate model of my trigger circuit (just an AND gate and four flipflops)
<azonenberg_work> and delay line
<azonenberg_work> Then feed into a second comparator to actually latch the signal compared against my DAC'd reference voltage
<SolraBizna> "It’s somewhat too complicated and inflexible due to my desire to have 50% duty cycle on something that’s marked as “clock” going out of a reusable module." ← lol
<azonenberg_work> whitequark: then repeat a few million iterations and see what the data looks like
<whitequark> SolraBizna: mostly linking it to you because of the clock freq deviation functions
<azonenberg_work> before i build hardware i want to sim it
<whitequark> SolraBizna: also, are you running simulation?
<SolraBizna> I am
<SolraBizna> but my tools are... lacking
<SolraBizna> in particular, they are very very poorly suited for testing ... signals
<whitequark> huh?
<azonenberg_work> whitequark: anyway, in theory if i evaluate this circuit on my signal with a few thousand points at each (time offset within UI, voltage) tuple
<whitequark> so does your UART work in sim?
<azonenberg_work> then normalize the resulting array so that each element is a real number in [0,1] indicating the percentage of the time the signal at time T was > V volts
<azonenberg_work> I should have a 2D array which is the partial integral of an eye pattern with respect to dV
<azonenberg_work> then if i take the partial derivative in the Y axis, i should get the actual eye
<whitequark> yep
<SolraBizna> It's hard to tell; the closest thing to an oscilloscope I have is `$monitor("%t tx=%d", $time, tx)`
<whitequark> why can't you use gtkwave?
<whitequark> plus iverilog
<SolraBizna> I probably could, if I knew what I was doing :P
<SolraBizna> It's one of those cases where it surely would have saved me a lot of grief, but I never sat down and thought "time to actually learn how to use gtkwave"
<whitequark> you should do that now
<whitequark> or you'll have even more pain later
<SolraBizna> that's almost certainly true
<whitequark> no, it is definitely true :p
<tnt> +1. Trying to write verilog (or vhdl) without sim tools is a bad idea. Especially if you're trying to write a whole risc-v core ...
<GuzTech> tnt: Which is why I'm writing my risc-v core in Clash so I can easily evaluate parts of my implementation without even starting QuestaSim, ModelSim, etc.
<GuzTech> And that already helps significantly.
<tnt> SolraBizna: If you're already using monitor, just stick a $dumpfile("blah_tb.vcd"); $dumpvars(0,blah_tb); in a initial block and then, done, you can just load the vcd in gtkwave.
<GuzTech> SolraBizna: Simulation is essential. If it doesn't work in simulation, it will definitely not work in hardware. If it does work in simulation, it *could* work on hardware.
<tnt> I sure hope that contest will yield a <= 500 LCs risc-v core ...
<whitequark> GuzTech: same but migen...
<GuzTech> tnt: picorv32 is already very small, but yeah, it will be interesting to see what people come up with.
<tnt> GuzTech: really ? I thought picorv32 had trouble fitting on a up5k at all.
<daveshah> no, in its smallest config picosoc is less than half a up5k
<GuzTech> whitequark: I used SpinalHDL before, and it quite liked it, but after getting used to runtime evaluation... it's pretty difficult to use anything else.
<tnt> daveshah: ok, good to know. Any idea of fmax ?
<GuzTech> tnt: On the 7-series Xilinx FPGAs, the smallest configuration uses like ~800 LUTs.
<tnt> GuzTech: yeah, I'm talking ice40 here.
<daveshah> tnt: probably around 15-20MHz with nextpnr
<SolraBizna> one version of my core actually worked on real hardware but hanged iverilog
<GuzTech> It easily fits on the HX8K with a bunch of peripherals. But I don't know *which* configuration of picorv32 is used by default by picosoc.
<SolraBizna> (it was getting stuck evaluating a combinatorial loop that was semantically straightforward but in a way it couldn't detect)
<GuzTech> Why do you have a combinatorial loop in your code?
<whitequark> do not use combinatorial loops
<whitequark> FPGA LUTs are not glitchless
<whitequark> they do not have a guaranteed behavior
<SolraBizna> the loop was a logic error on my part
<SolraBizna> or rather, it arose from unintended inferred latches
<SolraBizna> it was supposed to be a straightforward "A depends on B depends on C", but something about the latches made it seem (to iverilog) that C also depended on A, and it sat there grinding on logic that wasn't actually changing
<SolraBizna> that core was a silly idea anyway; it was just me trying to explore the consequences of trying to cram too much logic into not enough clock
<SolraBizna> (the consequences were, unsurprisingly: the logic became hard to understand and had a crummy Fmax)
<tnt> daveshah: \o/ (wrt to clock domains :P)
<daveshah> thanks tnt!
<tnt> I'm trying to have a look at issue #69 ( https://github.com/YosysHQ/nextpnr/issues/69 )
<tnt> Is all that's needed to set the .extra_bit ?
<daveshah> yes
<daveshah> and make sure you don't also place a global buffer that conflicts with it
<tnt> How does nextpnr know which global buffer that pll output is connected to ?
<daveshah> I am not sure if this is in the database yet, actually
<daveshah> it is the same global buffer as the `padin` at that location
<tnt> I'm looking at http://www.clifford.at/icestorm/io_tile.html ATM. So if I understand correctly, setting that extra bit, if the PLL is active/configured, this will route the pll output to the global buffer. And if the PLL is not there/active, then this will be like a SB_GB_IO ?
<daveshah> yes, exactly
<daveshah> the PLL is effectively between the IO pad and the IO input to the FPGA
<daveshah> this is also why you can't use those IOs as inputs at all when the PLL is used
<tnt> Right. I wish there was a map of those fpga with all tiles marked with location and what's in there :p (I know that's what chipdb is, but not vere visual).
<tnt> Speaking of which, maybe I'm too dumb to see it ... but is there a way to pan left/right/up/down in next pnr gui ???
<daveshah> right or middle click
<tnt> Oh, ok. Right that's why I missed it. Doing that with a touch-to-clock trackpad is tricky.
rohitksingh has joined ##openfpga
cr1901_modern1 has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
cr1901_modern has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Guest3080 is now known as wilhelmvonweiner
wilhelmvonweiner is now known as WilhelmVonWeiner
<tnt> daveshah: what do you think the best approach is to avoid global net conflict ? Would creating SB_GB locked to the right site with some attribue marking them as 'used by pll' be a good approach ?
rohitksingh has quit [Ping timeout: 272 seconds]
genii has joined ##openfpga
Miyu has joined ##openfpga
<daveshah> tnt: yes, that seems reasonable
<daveshah> You could also use that attribute to set the extra bit
<daveshah> That should then scale nicely to SB_GB_IOs too
<tnt> daveshah: small details, promote_globals() is done before pack_special() [which is where I'd have created the SB_GB].
<daveshah> tnt: I can't see any problems in changing that, if it would make things easier
<daveshah> promote_globals does need to know how many globals are available
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
jevinskie has joined ##openfpga
jevinsk__ has joined ##openfpga
jevinski_ has quit [Ping timeout: 250 seconds]
jevinskie has quit [Ping timeout: 264 seconds]
jevinskie has joined ##openfpga
jevinsk__ has quit [Ping timeout: 260 seconds]
<tnt> Apparently by changing the output routing, I manage to make the PLL not lock. Awesome ... :p How did I even manage that.
<whitequark> tnt: what board?
<tnt> icebreaker
<tnt> yeah, it's not an upduino if that's what you were thinking :)
<tnt> I'm sure it's something in my bistream that must screw it up somehow. I guess I don't quite understand how it all fits together.
<GuzTech> I've just had a bunch of students that found it a bit weird that I brought 10 different FPGA boards that I own to uni to show to prospective master students...
<GuzTech> I'm not weird, you're weird!
<GuzTech> :P
<tnt> huh why would that be weird ?
<tnt> ok, maybe because you _only_ brought 10 ?
<GuzTech> Yeah ok, but I couldn't fit every board I own into my bag...
<GuzTech> Most of them don't even *know* what an FPGA is :P
<tnt> Ah yeah :). Speaking of which, I got my ECP5 5G board (the 100$ one) Damn, the packaging for that boardis huge :p box inside box inside box with little card inside.
<GuzTech> Instead of collecting stamps, I collect FPGA devboards.
<GuzTech> Cool!
<GuzTech> I want to try the ECP5 series too one day.
<tnt> And I also got all the parts for the glasgow :D Now just waiting for the PCB.
<GuzTech> whitequark said that work is being done on rev. C (?)
<GuzTech> If it's ready and I can buy it somewhere, then I'll get it for sure.
<GuzTech> I'm not the best at assembling stuff (mainly because I don't do it too often).
<tnt> Yeah, I'm assembling a rev B. rev C is not complete, has a lot of changes and also will use BGA, so not so trivial to make it myself.
<tnt> I'll definitely buy a rev C once they're available, but I've been fed up trying to use bus pirate / bus XXXx and being disappointed every time and so I could use a homemade rev B in the mean time.
<GuzTech> Have fun assembling it :)
television has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
television has joined ##openfpga
television has quit [Changing host]
television has joined ##openfpga
<G33KatWork> -win 15
<G33KatWork> grrrr
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 264 seconds]
<rvense> have any of you used that ice40 board that plugs into a beagleboard?
<tnt> Mmm, I think my issue is that nextpnr thinks the IO tile is not used because none of the pllout_{a,b} is wired anymore and so it disables stuff ...
<tnt> rvense: do you have a link ? (I haven't but interested in having a quick look)
kem_ has joined ##openfpga
<shapr> rvense: yes, BeagleWire
<shapr> rvense: I love it
<shapr> I'm teaching a Monday lunchtime class at work using the BeagleWire
m4ssi has quit [Remote host closed the connection]
Patater_ has quit [Quit: Explodes into a thousand pieces]
<whitequark> tnt: sweet :D
<tnt> daveshah: is by anychance the numbering of global network different in nextpnr than in the official lattice doc ?
<daveshah> tnt: eh, the usual trap
<daveshah> The SB_GB and SB_GB_IO in a tile drive a different global
<daveshah> Despite being in the same tile
<tnt> whitequark: hehe, well thank you for making it :)
<daveshah> I think the Lattice docs only show the SB_GB_IO global numbers
Patater_ has joined ##openfpga
<tnt> daveshah: oh ... so in fact the "fake" SB_GB I need to make is not the one right next to the PLL but the one that actually drives the global net that correspond to that PLL.
<daveshah> tnt: yup
<tnt> daveshah: so you can actually have the SB_GB that's next to the PLL used by a completely different signal then ? even when the pll is output to global ?
cr1901_modern has quit [Read error: Connection reset by peer]
<daveshah> tnt: yes
cr1901_modern has joined ##openfpga
<tnt> daveshah: \o/ My LED blinks :)
<qu1j0t3> tnt: o/
<qu1j0t3> o _ o _ o _ o
<tnt> 7h to make a led blink. Productive day :p
<daveshah> tnt: awesome
<tnt> Still need to figure out how to extract all that information from the DB though. ATM I just hardcoded it all ... hum ...
<rvense> shapr: it's nearly perfect for a silly project i have.. have you used the ram on it?
GuzTech has quit [Quit: Leaving]
<shapr> rvense: nope, not yet. I'm teaching myself fpga/verilog in the process of teaching this class
<tnt> Mmm, chipdb.py doesn't seem to process .gbufin or .gbufpin at all. How does nextpnr even know which SB_GB correspond to which global net ?!?
<daveshah> I think it is done in chipdb.py when the SB_GB Bels are added
<daveshah> Effectively hardcoded in chipdb.py
<tnt> Oh yeah, you're right. I see that now.
wbraun has joined ##openfpga
<tnt> Mm, yeah, I think that nextpnr's db just doesn't have the required info in it.
WilhelmVonWeiner has quit [Quit: Lost terminal]
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner has quit [Client Quit]
<shapr> rvense: I know I can write C code to tell the beaglebone's gpmc to move data between main memory and the BeagleWire ram, but I don't know how!
<daveshah> tnt: I am fine with you hardcoding it
<daveshah> The set of support devices hardly changes quickly
<rvense> shapr: i looked for an example but couldn't find it
<tnt> daveshah: Yeah, I was hoping I could find the 'padin' wires somewhere (which in the chipdb.txt link back to the global network and tile x/y), but they don't seem to be there either.
<tnt> I'm still a bit curious how this whole bba / db thing even works.
<daveshah> Basically it's about building up a C structure describing the architecture at build time in a generic yet efficient way
<daveshah> This avoids the startup time cost of parsing a database file
<daveshah> Because of some performance issues doing this entirely in Python, we generate a text bba file in Python and "assemble" it to a C string
<kc8apf> wait...what?!?
Bike_ has joined ##openfpga
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
Bike_ is now known as Bike
<tnt> kc8apf: yeah that's why nextpnr build repo is 2G :p
<kc8apf> if parsing the database takes too long, the database has a poor layout
<whitequark> what the fuck
<whitequark> so THAT's where my SSD space went
<daveshah> The good news is that nextpnr doesn't mandate a database architecture
<daveshah> So if you want to add a new arch then you can store the database however you want
<shapr> rvense: there's verilog to handle that C code: https://github.com/pmezydlo/BeagleWire/blob/master/examples/arm_blink_leds/top.v
<shapr> Thus I suspect someone has written C code to move data between main memory and ram on the beaglewire, but I don't know how to do it.
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined ##openfpga
qu1j0t3 has joined ##openfpga
<SolraBizna> yeah, I really should have been using gtkwave this whole time
pie_ has joined ##openfpga
<pie_> hey folky. so i ended up needing to do some simple electronics stuff for work to automate testing some software, i need to hook up this relay and im not sure how to read it off the datasheet https://omronfs.omron.com/en_US/ecb/products/pdf/en-g5v_1.pdf
<pie_> *folks.
<pie_> i found the part that shows some sort of internal diagram "bottom view"
<pie_> at the bottom of page 4
<pie_> im guessing 2 and 9 are the solenoid (no polarity)
<pie_> and it switches between (5,6)->1 and (5,6)->10?
<kc8apf> pie_: that part seems to come in many coil voltages. What voltage is yours rated for?
<pie_> with (5,6)->1 being the default state?
<pie_> kc8apf: oh. uhhhhh
<pie_> i dont know. im pretty sure the only model number on my part (dont have it with me) was g5v-1
<pie_> it did have some strangely high voltages written on it, like 30, 60, and 125 iirc (at various amperages also listed)? i think that was just for the maximum voltage the circuit it switches should use?
<pie_> kc8apf: youre looking at the table on the left?
<kc8apf> pg 1, left table
wbraun has quit [Quit: wbraun]
<kc8apf> contacts are rated 0.5A@125Vac or 1A@24Vdc
<kc8apf> coil seems to come in 3, 5, 6, 9, 12, or 24Vdc
<pie_> i think thats multiple voltages listed for the same model?
<kc8apf> but that's not part of the model # (!)
<qu1j0t3> pie_: no
<pie_> i mean...idk why they would do that but i think that means multiple voltages are ok?
<qu1j0t3> pie_: it will have a specific coil voltage
<qu1j0t3> pie_: i just spec'd an omron relay
<pie_> oh. huh. ok i have no clue then
<kc8apf> yeah, the coil resistance sets the voltage
<pie_> wat do
<kc8apf> look at the case
<kc8apf> should be written on it
<pie_> ok. i will check tomorro
<pie_> assuming thats ok, then what?
<kc8apf> as for pin-out, yes 2 and 9 are the coil
<kc8apf> 5 and 6 are tied together and are the common
<kc8apf> 1 and 10 are the two throws with 1 being connected when the coil is denergized
<pie_> im actually wanting to use this as a simulated switch, so i think i would just leave 1 hanging
<pie_> *floating
<kc8apf> yup, when the coil is energized, 5/6 will be connected to 10
<pie_> yay \o/
<pie_> whats the shaded rectangle on that diagram supposed to be?
<kc8apf> as for the coil itself, you need to figure out the voltage, make sure whatever you are using to drive it can source enough current, _and_ put in some sort of flyback snubber
<pie_> oh its right under it "indicate the products directional marks"
<pie_> kc8apf: oh, good thing i asked then. flyback snubber?
<qu1j0t3> diode should be ok?
<kc8apf> when you turn off power to the coil, the magnetic field in the coil causes a voltage spike
<kc8apf> diode usually fixes it
<pie_> kc8apf: well /apparently/ im going to be prototyping it from an arduino micro, but i need to scale up to 10 relays later
<kc8apf> if I'm building a board, I prefer to use purpose-built relay drivers
<qu1j0t3> kc8apf: made a very important point about the diode
<pie_> kc8apf: that explains why the last circuit had a diode
<qu1j0t3> ya
<pie_> kc8apf: by last i mean there was some stuff on the breadboard but i just started over because i couldnt RE it
<pie_> thanks, ill keep that around for the scaling up
<kc8apf> those take care of all the wonky bits. Just feed it a logic-level on/off signal
<pie_> i also plan to add safety features for stuck-closed and stuck-open, well the latter doesnt really need safety? but i want to signal error condition with a LED or somethng
<pie_> well none of this is safety critical in any sense in actuality
<pie_> ok thanks, ill have sometihng to work off of now \o/
<kc8apf> buy an off-the-shelf SSR for industrial control?
<pie_> whats an ssr
<qu1j0t3> pie_: looks like with coil voltage 5V, draws 30mA, which i think is ok for Arduino (40mA? but check Arduino doc)
<pie_> qu1j0t3: yeah i was going to but might have forgotten if you didnt remind me
<qu1j0t3> pie_: but ofc you first have to confirm coil voltage :-)
<pie_> kc8apf: ah. probably overkill
<pie_> i just need to short someting, not actually deliver power
<kc8apf> ah
<pie_> should have probably specified that in the beginning
<qu1j0t3> then you might not need a relay at all? /me doesn't quite get it
<pie_> qu1j0t3: apparently we want a relat for galvanic isolation?
<qu1j0t3> oh, ok.
<kc8apf> relays are usually a pain to deal with
<pie_> though i was thining maybe just use an optocoupler or an ssr
<pie_> but i dont know much about tihs stuff
<pie_> i meant transistor instead of optocoupler
<qu1j0t3> transistor isn't isolated
<pie_> i wanted to say maybe an optocoupler makes sense
<pie_> qu1j0t3: right, thats what i was told
<kc8apf> optoisolator
<qu1j0t3> so maybe use the relay for now
<pie_> kc8apf: if an optoisolator works how i think it does, i wouldnt have to worry about power delivery?
<pie_> for the coil i mean, or anything like that
<pie_> just a simple isolated switch
<kc8apf> optoisolators are an LED and a photodiode in a single package
<kc8apf> when you turn on the LED, the photodiode turns on
<pie_> kc8apf: thats what it seems like, but idk if a photodiode is basically like an optically triggered transistor, and even if it is, i dont really know how transistors work /in practice/
<kc8apf> that device will pass up to 50mA and up to 80V
<pie_> (i know how they work on a physical level)
<pie_> also, thanks
<pie_> qu1j0t3: what was your breadboarding safety setup again? just a fuse on the power lines?
<qu1j0t3> i use a fuse, but it's not that useful
<kc8apf> when the LED is off, a max of 100nA will flow from collector to emitter. When the LED is on, up to 50mA will flow.
<qu1j0t3> i mean it won't save any semiconductors
<qu1j0t3> but at least it will not allow a short circuit to do too much harm
<pie_> kc8apf: im not sure what counts as "shorted"
<pie_> i mean, "not shorted", for the circuit im automating
<qu1j0t3> pie_: i have only 12v and 5v and my small bipolar supply (< 20v) on to the breadboard
<pie_> the button in question is a reset button
<pie_> but i can just ask one of the guys tomorrow
<kc8apf> the two wires are probably +5V and an IC's input pin or an input pin pulled high and GND
<kc8apf> really doubt 100nA would trigger the input
<pie_> kc8apf: sounds reasonable
<pie_> also bbiab, just got home, really need a shower
<whitequark> pie_: transistors are charge controlled devices
<whitequark> to a first approximation
<whitequark> all transistors, bjts and fets and all others
azonenberg_work has quit [Ping timeout: 268 seconds]
<pie_> whitequark: what do you mean by charge controlled
<pie_> the voltage applied?
<whitequark> no
<whitequark> the charge accumulated on the control electrode is what provides the power gain
<whitequark> like, in FETs, the charge is isolated on the gate
<whitequark> so it appears voltage-controlled
<whitequark> in BJTs the charge is drained away via the pn transition, so it appears current-controlled
<whitequark> but in both cases it's actually charge-controlled and those are separate effects
<pie_> im kind of embarrassed because either i dont know how they work well enough, or im totally missing what you mean.
* pie_ goes to look at transistor internal diagram and think for a bit
<adamgreig> i found it helpful to think of the gate as a capacitor
<adamgreig> when you apply a voltage you charge it up
<whitequark> yep
<adamgreig> and the charge on the capacitor sets the e-field strength which is what sets the channel size
<whitequark> that's how most FET models actually work, too
<pie_> adamgreig: well yeah, pretty sure i got that for FETs :I
<pie_> iirc fets seem really simple tbh
<whitequark> bjts are basically the same as fets
<whitequark> fundamentally
<pie_> i think i never thoroughly understood bjts
<qu1j0t3> i've been studying them for months, not sure i do either yet :)
<qu1j0t3> pie_: i can recommend some books
<pie_> though it /was/ kind of a crash course in physics class
<qu1j0t3> pie_: Kuphaldt is a good start imho
<qu1j0t3> free book
<qu1j0t3> open source, even
<pie_> from the FET wiki page, this is still super cool IMO https://en.wikipedia.org/wiki/File:Threshold_formation_nowatermark.gif
<pie_> ah, thats a simulation though :p
<pie_> whitequark: i havent had time to think yet but im guessing its something like: applying voltage increases the amount of charge carriers in the intermediate area
<pie_> oh wait i just described all (most?) semiconductor junctions ever
<pie_> junction is the wrong word, the middle are
<pie_> area
<pie_> p-n junction
azonenberg_work has joined ##openfpga
<gruetzkopf> i like relays
<gruetzkopf> i like relays so much, i have about 12000 of them.
amclain has joined ##openfpga
<Bob_Dole> I wanted to buy a bunch of the clear ones once, the ones you can see the state the contacts are in, and try to use that for a bit of hands on learning logic.
cr1901_modern has quit [Ping timeout: 245 seconds]
<pie_> gruetzkopf: wowo
<pie_> gruetzkopf: today, on hoarders :P
<pie_> jk tho, that just makes you a neerd ;p
<gruetzkopf> yeah
<gruetzkopf> so?
f003brv has joined ##openfpga
<f003brv> Hi
<f003brv> Is #openfpga compatible with Mac?
<f003brv> OS X?
<f003brv> also what OS do you folks use for FPGA dev, Linux or Windows?
amclain has quit [Quit: Leaving]
amclain has joined ##openfpga
amclain has quit [Client Quit]
<etrig> plan9
<whitequark> f003brv: it should be compatible with macOS, yes
<whitequark> I use Linux personally
<SolraBizna> same
<Bob_Dole> same
cr1901_modern has joined ##openfpga
<f003brv> cool thanks
<f003brv> very helpful
<f003brv> I'll have my Linux set up in a week or two
<f003brv> I was worried I was going to need Windows as well.
<f003brv> but I'm glad I can do FPGA work on Linux and Mac too
<f003brv> goodbye for now
<f003brv> :wq
<f003brv> q
<f003brv> quit
f003brv has quit []
feuerrot has quit [Ping timeout: 264 seconds]
feuerrot has joined ##openfpga
<cr1901_modern> protip- do not try running ninja -j3 when building nextpnr on Windoze w/ 8GB of RAM. You will crash your system when it inevitably goes to swap building those damn binary blobs