ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
dj_pi has joined ##openfpga
hackerfoo1 is now known as hackerfoo
emeb_mac has joined ##openfpga
azonenberg_work has joined ##openfpga
gnufan_home has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 245 seconds]
genii has quit [Remote host closed the connection]
Laksen has quit [Quit: Leaving]
unixb0y has quit [Ping timeout: 258 seconds]
dj_pi has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
azonenberg_work has joined ##openfpga
emeb has left ##openfpga [##openfpga]
tlwoerner has quit [Quit: Leaving]
dj_pi has joined ##openfpga
tlwoerner has joined ##openfpga
dj_pi has quit [Ping timeout: 246 seconds]
dj_pi has joined ##openfpga
jevinskie has joined ##openfpga
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 246 seconds]
dj_pi has quit [Ping timeout: 246 seconds]
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<mithro> whitequark: You were suggesting getting a T12 soldering iron... That is the "tip type" and it looks like there are lots of "kit soldering iron controllers" that pair with it? Like https://www.instructables.com/id/DIY-Hakko-T12-Compatible-Soldering-Station/ ?
<mithro> whitequark: They also seem to come in a portable variant?
<mithro> Looks like the Hakko FX-951 is the "original" design?
<hackerfoo> I have one of these, FWIW, because I wanted hot air too: https://hackaday.com/2009/02/20/tools-aoyue-968-3-in-1-soldering-and-rework-station/
<hackerfoo> I think the next thing I'd get is a microscope. I can do without a preheater by preheating the board with hot air.
<eddyb> does anyone have a demo of a "ring oscillator being sampled by the main clock" RNG example for iCE40? do the tools support that kind of circuit?
<eddyb> I've being told that it should work
<Sprite_tm> Ring oscillator works, at least on the ICE40. I;m using one as the main osc as I didn't realize the thing doesn't have an internal oscillator :/
<eddyb> ahahaha
<eddyb> lovely, thanks?
<eddyb> *thanks!
<eddyb> Sprite_tm: which iCE40 models is that? IIRC the stuff I was staring at a few days ago mentioned a main clock and 1 or 2 PLLs
<eddyb> (unless you mean that clock is external?)
<azonenberg> Sprite_tm: as long as you dont mind super wide drift in frequency, lol
<azonenberg> it does work
<futarisIRCcloud> mithro: TS100 is the portable USB soldering iron. A hakko FX-951 or 968 knock-off is fairly popular with hackers...
<Sprite_tm> azonenberg: Yeah, I found that out :P I use it for some audio stuff, the bleeps sound a bit different every time I turn the thing on.
<Sprite_tm> It's not random, it's just eclectic!
<Sprite_tm> eddyb: The standard ice40hx8k chips. THey do have PLLs, but no internal oscillator that you can get at.
<azonenberg> every time you turn it on, or every time you change the bitstream?
<azonenberg> the same bitstream should sound almost the same, modulo thermal/voltage drift which is likely small
<Sprite_tm> Erm.. well, during development those two events usually overlapped :P
<Sprite_tm> You're probably right in that it should be constant per bitstream, I just never paid enough attention to it.
<Sprite_tm> 1. get it working, 2. get out gremlins if they're bugging me :P
<azonenberg> On a different note, https://www.antikernel.net/temp/DSCF5209.JPG
<azonenberg> just gearing up to write the protocol decoder
<Sprite_tm> lol @ swilkscreen text
<azonenberg> yeah this was before oshpark made that a warning, it was a critical error at the time and DRC wouldnt let you submit the design
<azonenberg> i know one guy who just put a big ascii art middle finger
<azonenberg> side note, the Pico Tech probe holders are 1/4 the price of the ones with lecroy branding on them
<azonenberg> and they hold the probe just the same :p
<Sprite_tm> What's the protocol btw?
<azonenberg> USB
<azonenberg> you're seeing D+, D-, and FT232R TX data
<azonenberg> i wanted to start with a 12 Mbps device because the 480 Mbps PHY is almost the same
<Sprite_tm> Ah. Duh. Should've realised it was USB stream, I've been staring at them often enough.
<azonenberg> but i wanted to do a proper in-line probe with SMAs and such
<azonenberg> the 10M passive probes work just fine for 12 Mbps though
<Sprite_tm> Eh, pfff, dupont wires ftw :P
<azonenberg> lol
<azonenberg> i was going to build one of those
<azonenberg> usb 2.0 B on one side, 2.0 A on the other, then two SMAs connecting to the signals with integrated 20:1 probes
<eddyb> Sprite_tm: does timing analysis work w/ a ring oscillator as the main clock?
<Sprite_tm> Oooh, soo gold-plated
<azonenberg> I'm building one of these test fixtures for every protocol i write a decoder for that has standard connectors
<azonenberg> I won't be doing usb3 any time soon as my scope doesnt have the bandwidth
<azonenberg> but i'll be able to read usb 1.x / 2.0 off the wire
<Sprite_tm> eddyb: If you assume that the ring osc isn't all of a sudden going faster than whatever freq you set the main clock to be for the timing analysis, there's no issue.
<Sprite_tm> It won't figure out what that's going to be by itself, the ring osc more-or-less is an opaque black blox to the software.
<Sprite_tm> azonenberg: And here's me looking at the professional devboard which I use to validate the USB MAC and write the ROM-code for an upcoming chip... and the 2.54mm headers and the dupont wires to the LA...
<Sprite_tm> It's usb low/full-speed only, so it should be fine :P
<azonenberg> well i'm trying to make these test fixtures good enough to do compliance testing with
<azonenberg> not just signal recovery
<Sprite_tm> Ah, you do need something fancy'er for that indeed.
<Sprite_tm> I think we handed compliance testing of the phy off to an external lab; the devboard I have has an external phy instead so it doesn't need to be tested.
<azonenberg> this is the kind of stuff my software can do on SGMII / 1000base-X
<azonenberg> or (older build of the tool) 100base-TX Ethernet https://www.antikernel.net/temp/glscopeclient-25.png
<azonenberg> i plan to have at least this level of USB decoding integrated as well
<azonenberg> then the ability to export pcaps for more extensive analysis in wireshark
<Sprite_tm> Oooh, does that tool also support Rigol MSO5Ks?
<eddyb> Sprite_tm: aww. but you can use the same timing rules the software is using, to figure out the frequency?
<azonenberg> As of now there is a well developed lecroy VICP back end, an experimental lecroy/siglent raw SCPI back end, and that's it
<azonenberg> eddyb: you could find min/max
<azonenberg> Sprite_tm: Rigol scope support is planned, but i don't have a (working) rigol to test on
<Sprite_tm> I do :) but iirc it also talks SCPI, so it may be a quick adoptation.
<azonenberg> well SCPI commands for scopes arent super well standardized
<azonenberg> e.g. the waveform download binary format is totally vendor specific
<eddyb> would be neat to plug in a clock duration instead of a frequency, in the timimg analysis, to avoid computing a rounded 1/t
<Sprite_tm> Mmm, wanna build a LA pod for my scope first... kinda got set back because the LVDS comparators I ordered... well... most generous reading is that they accidentally forgot to put the silicon in them.
<azonenberg> You need to create a new driver class for each protocol, although you could certainly plug in bits and pieces
<eddyb> you can round up, I guess
<azonenberg> the lecroy driver is a good reference implementation for several kinds of instrument
<azonenberg> scopehal/Oscilloscope.h has all of the functions you have to override
<Sprite_tm> Mmm, sounds like something to look into, when I have time.
<azonenberg> If you are seriously interested in adding a rigol backend i'll gladly work with you to make it happen
<azonenberg> I just dont have the time or hardware to do it myself right now
<Sprite_tm> Heh, I have the hw, but the time bit is kinda a thing :)
<azonenberg> Lol
<azonenberg> I have... a not-short todo list
<tnt> azonenberg: is that using network to get samples btw ? Might be my code, but retrieving traces off my agilent 3000-x takes ages. (like ... a couple seconds).
<azonenberg> tnt: most scopes are very slow for waveform download in my experience
<azonenberg> I get ~10 FPS for short (50k point) waveforms off my waverunner 8104, down to 1-2 FPS for deep (1M point)
<azonenberg> the wavesurfer 3034 is significantly slower, 1-2 FPS for the shortest waveforms
<azonenberg> The lecroy backend is ethernet based, but you could totally support usb direct connections as well
<azonenberg> if a scope supports both i would prefer the driver to support both
<azonenberg> or at least separate the command/API layer from the transport layer
<azonenberg> like i did with the lecroy driver
<azonenberg> i doubt usb would be faster than lan though
<azonenberg> in general, my experience is that typical scopes are simply not optimized for remote operation
<tnt> yeah, I'm guess internally the gneeral purpose cpu only has a slow channel to go read the ASIC memory.
<azonenberg> Which is one of the reasons that a longer term plan is to build custom f/oss acquisition hardware intended to hit thousands of WFM/s over ethernet
<azonenberg> tnt: i cant speak to the low-end lecroys or other vendors
<azonenberg> but the high-end lecroys are a pcie acquisition card plugged into what's basically a bog-standard atx motherboard
<azonenberg> my waverunner runs windows 7 embedded edition and has an i5 with 8GB of RAM
<azonenberg> My planned high-end scope is going to be a completely different architecture
<azonenberg> The plan is a 3U Eurocard chassis with 1/10G serial links (TBD ethernet or custom protocol) on the backplane, plus a 10 MHz OCXO refclk distributed to each channel card
<azonenberg> then an I/O card with a 1G (for "legacy" baseT gear) and 10G or 40G SFP+/QSFP+ as the primary connection to the host
<azonenberg> then each channel card will have one or more SMA/BNC signal inputs
<tnt> 10 MHz only ?
<azonenberg> 10 MHz seems to be the standard refclk for test equipment
<azonenberg> every function generator i've seen uses it
<azonenberg> my waverunner has 10 MHz input and output
<azonenberg> so you can sync multiple scopes' PLLs to the same refclk and have phase aligned capture
<tnt> higher end one are moving to 100 MHz to improve the sync between them.
<azonenberg> i might support several frequencies then
<azonenberg> Internally, whatever refclk i have will go into a (tentatively) LMK04806
<azonenberg> on each line card
<azonenberg> then multiply up to drive the actual ADC acquisition clock
<azonenberg> The advantage of 10 is that you can feed it from a GPSDO
<azonenberg> But the PLL has a pretty wide input range so i can make it flexible
<azonenberg> The I/O card will have SMA refclk in/out as well as the ethernet ports on the front, and pretty much be the brain of the whole operation
<futarisIRCcloud> 10 MHz is the same input for most hacker SDRs too, e.g. HackRF.
<azonenberg> the backplane will be entirely passive
<azonenberg> Line cards can have one or more ADCs on them with arbitrary configuration, so you could for example have a card with two ADCs and two inputs and selectable interleaving
<azonenberg> you'll be able to mix them arbitrarily and they'll remain phase aligned
<azonenberg> so for example you could hypothetically have one card configured with interleaving, one 20 Gsps input
<azonenberg> another identical card non-interleaved as two 10 Gsps inputs
<azonenberg> and then another one be 500 Msps 12-bit
<azonenberg> With a switchable 18 GHz sample-and-hold in front of it
<azonenberg> (these are not arbitrary numbers, they're actual tentatively planned designs)
<azonenberg> This is one of the reasons glscopeclient shows the channel depth, sample rate, etc in the channel label and not in the status bar
<azonenberg> Because it doesn't assume channels have identical sample rates
<azonenberg> Some math functions are naive and assume the inputs are the same rate, but many of the more sophisticated protocol decodes are already multi-rate aware
<azonenberg> and will check timestamps of each sample and handle e.g. clock and data sampled at different rates
<azonenberg> Anyway, that hardware is a long ways out and i have several massive projects to do between now and then :)
sensille_ is now known as sensille
<Sprite_tm> Possibly already useful if you want to use e.g. a cheapie scope and a cheapie LA together tho'.
<Sprite_tm> Use two backends, mangle the data together in the frontend.
<Sprite_tm> Just sync up the trigger and you're gtg.
<azonenberg> Yes, in fact i have that working in tests already between my 10/20 and 2/4 Gsps lecroy scopes
<azonenberg> another planned use case is DSO + ILA
<azonenberg> It's multi-source capable from the start and will continue to be that way
<azonenberg> although the trigger handling in the UI still needs some work to make it usable
<whitequark> mithro: yes. T12 is a cartridge type. there are lots of controllers. I have one similar to your 1st link
<whitequark> I don't know anything about TS100, never held one in my hand
<whitequark> could be good, could be not
m4ssi has joined ##openfpga
emeb_mac has quit [Ping timeout: 255 seconds]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
rohitksingh_work has joined ##openfpga
Asu` has quit [Remote host closed the connection]
duck227 is now known as duck2
vup2_ has quit [Quit: vup2_]
vup2 has joined ##openfpga
gsi__ is now known as gsi_
<SolraBizna> I'm looking at I²C RTCs, and every datasheet I've looked at so far completely lacks information on registers, etc.
<SolraBizna> am I crazy?
<tnt> yeah, same ... I picked one at random 1307 and it was there.
<tnt> Table 2
<SolraBizna> well, there I go
<SolraBizna> but I need to find one that operates at 3.3V...
<whitequark> PCF85263A
<tnt> I'm curious which one you found where the DS doesn't have register set.
<SolraBizna> and then the next datasheet that I opened had register information
<SolraBizna> https://www.mouser.com/datasheet/2/3/AB-RTCMC-32.768kHz-IBO5-S3-780327.pdf ← this was the first one I looked at, and it actually does have a (brief) register map in it, I just missed it
<SolraBizna> (on page 10)
<SolraBizna> looking back, all of them have those
<SolraBizna> moral: don't do this sort of thing at 4AM
<daveshah> Pretty sure the actual RTC in that module is a https://ambiqmicro.com/static/rtc/files/AM18X5_Data_Sheet_DS0003V1p3.pdf
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ondrej3 has joined ##openfpga
m_t has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 244 seconds]
_whitelogger has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
X-Scale has quit [Ping timeout: 245 seconds]
genii has joined ##openfpga
Asu has joined ##openfpga
carl0s has joined ##openfpga
catplant has quit [Ping timeout: 252 seconds]
mumptai has joined ##openfpga
X-Scale has joined ##openfpga
Laksen has joined ##openfpga
emeb has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
mumptai has quit [Quit: Verlassend]
jevinskie has joined ##openfpga
jevinskie has quit [Client Quit]
<SolraBizna> how evil am I if I rely exclusively on CRESET as a way to reset my core?
<whitequark> CRESET?
<tnt> I'm assuming just the fpga POR.
<tnt> I'd advise against it ...
<whitequark> it's fine if you do something for BRAMs
<whitequark> on ice40 it does not win you much
<SolraBizna> resets the whole FPGA and makes it do configuration over again
<whitequark> since you have the global reset lines that can go everywhere
<tnt> but then for instance you can't use PLLs.
<SolraBizna> I can't?
<tnt> well no ... the clock wouldn't be stable ... your logic might get in weird state.
<tnt> all logic clocked by a PLL should be held in reset until such a time as the LOCKED is asserted.
<SolraBizna> oh, right... having a real reset line would actually be a really easy way to do that
<tnt> for the ice40 just make sure to use async reset.
<whitequark> async reset with sync release.
<tnt> yes
vup2 is now known as vup
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
vup has quit [Quit: vup]
vup has joined ##openfpga
<tnt> Huh, I managed to make a design that has nextpnr looping forever in the routing phase.
<tnt> (well for one particular seed at least
<daveshah> It's actually surprising this doesn't happen more often given how the router algorithm works
<tnt> daveshah: do you think there is timing improvement to be had in the router or is this placer only ?
<daveshah> There's definitely significant room for timing improvement in the router
<daveshah> Particularly in terms of how it chooses nets to rip up
<daveshah> Also looking at rerouting nets with negative slack at the end
<tnt> does it route them in order of "criticality" ?
<daveshah> Budget currently
<daveshah> Which should be the same ordering if there is a single clock domain
m_t has quit [Read error: Connection reset by peer]
<SolraBizna> last stupid question of the day involves MOSFETs as switches
<SolraBizna> I have an LED that I want to power when a control signal is at a logic low, so I want a p-type enhancement MOSFET, right?
<tnt> yes, that'd work.
<SolraBizna> (good, I was pretty confident about that half)
<whitequark> depletion mode MOSFETs aren't really used anymore
<SolraBizna> the other half is that I want to have a switch that "enables" one of two CS# lines
<SolraBizna> p-type enhancement MOSFET for one, n-type enhancement MOSFET for the other?
<SolraBizna> I saw a table that made me think I'd need an n-type depletion MOSFET, and my brain turned to Jell-O when I tried to look into it further myself
<tnt> nope
<tnt> you can't use a p-type to pull something to ground
<SolraBizna> can't I use it to "drain out" a line that is pulled high?
<tnt> a p-type depletion mode and a n-type enhancement mode might work.
<tnt> SolraBizna: no, because as you "drain it out", you reduce Vgs ...
<tnt> so you could only lower it down to Vth
<SolraBizna> ah
<SolraBizna> is there a simulator I can use to quadruple-check my circuit before blowing my one shot at getting it manufactured?
<whitequark> ltspice?
<SolraBizna> excellent, thank you
<adamgreig> you might also find http://circuitlab.com/ easier to get going with
<SolraBizna> ... aw, but Windows/macOS only
<adamgreig> try gnucap or ngspice on linux
<SolraBizna> CircuitLab looks like it should work
rohitksingh has quit [Ping timeout: 258 seconds]
zem has quit [Ping timeout: 268 seconds]
zem has joined ##openfpga
genii has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
gnufan_home has joined ##openfpga
gnufan_home has quit [Ping timeout: 245 seconds]
gnufan_home has joined ##openfpga
gnufan_home1 has joined ##openfpga
gnufan_home has quit [Ping timeout: 258 seconds]
jevinskie has joined ##openfpga
jevinskie has quit [Client Quit]
ZombieChicken has joined ##openfpga
futarisIRCcloud has joined ##openfpga
jevinskie has joined ##openfpga
Bike has joined ##openfpga
jevinskie has quit [Client Quit]
carl0s has quit [Quit: Page closed]
gnufan_home1 has quit [Quit: Leaving.]