pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
CoffeeFlux has quit [Ping timeout: 260 seconds]
CoffeeFlux has joined ##openfpga
CoffeeFlux has quit [Changing host]
CoffeeFlux has joined ##openfpga
f003brv has joined ##openfpga
<f003brv> Has anyone tried running ml algorithms on an FPGA?
<TD-Linux> whitequark, I noticed the glasgow device strings are null until you first run an applet. is that intentional?
<sorear> um, yes?
<whitequark> TD-Linux: run `glasgow flash`
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
LAK132 has joined ##openfpga
<TD-Linux> whitequark, ah I see. am I supposed to do that as part of the factory process?
<whitequark> TD-Linux: `glasgow factory` does the bare minimum required setup
<whitequark> it's like... minimal responsibility principle, i guess?
<whitequark> i'm not really committed to this design
<TD-Linux> I mean, would I expect a consumer to do that or should I do it before shipping?
<whitequark> there's no real difference
<whitequark> oh, wait
<whitequark> there is
<whitequark> if they are using windows and plug in for the first time a NON flashed glasgow
<whitequark> it will fuck up their registry in annoying ways
<whitequark> so, yeah, you need to run both of those
<TD-Linux> (apparently I've been running all mine "unflashed" so far...)
<whitequark> yeah i mean, they run just fine that way
<TD-Linux> yeah this just drops startup time and makes the vendor strings correct right away I suppose
<TD-Linux> thanks
<whitequark> it's more important on windows
<whitequark> on windows, if you plug the device in and it does not present a WinUSB descriptor
<whitequark> it is recorded as never having a WinUSB descriptor
<whitequark> and windows wont ask it for a descriptor again
<whitequark> which is ... kind of dumb but i also understand why they had to do it
<whitequark> then you have to go somewhere in the fuck ass end of registry and delete an opaquely named key
<whitequark> that i don't even remember offhand
<sorear> how does windows know it's the same device that survives flashing?
<whitequark> sorear: i thiiiiiink it matches by vid/pid/did?
<whitequark> so if a vendor adds a winusb descriptor they have to change at least one of those
<whitequark> fx2 lets you set vid/pid/did to expose while its missing firmware
<sorear> the vid/pid changes though, an unflashed fx2 does not have the glasgow openmoko ID
<whitequark> sorear: huh?
<whitequark> oh. "unflashed" here means "after $ glasgow factory"
<whitequark> which adds a c0 load command
<whitequark> and programs a serial
catplant has joined ##openfpga
<LAK132> So I'm kinda new to FPGA stuff, other than the little bit of work I did with a Mojo some years ago. I take it not many people care for the XC6SLX9's much anymore (if ever)?
<sorear> spartan-6 is not supported by the current xilinx toolchain
<q3k> and the old toolchain (ISE) is 100% artisanal handcrafted pain
<LAK132> That, I am fully aware of
<LAK132> hence why I'm looking for something better
<q3k> ECP5?
<sorear> s7/a7 would be what xilinx wants new designs to use?
<q3k> as a bonus, there's an open source toolchain in the making
<LAK132> I mean new software, I kinda can't afford new hardware
<q3k> you mean an open toolchain for s6?
<LAK132> anything that isn't ISE, yeah
<sorear> the smallest ecp5 chip is $5 and has more LUTs than XC6SLX9
<q3k> LAK132: nothing yet, although some people are working on that
<q3k> LAK132: i mean, there will probably never be vendor support for S6 in Vivado
<sorear> there are at least three projects to develop open tools for s6, which means none of them is likely to finish soon
<LAK132> I saw the fpgatools repo, what other projects are working on it? (I've been searching but couldn't even find that one myself)
<q3k> mwk is doing some work, but I don't think it's public yet
<LAK132> well if there's any ways I can help get S6 stuff working sooner, I'd very much like to
<mwk> S6 is cursed
<LAK132> cursed is my middle name
<sorear> you have hundreds of hours to work on toolchains but you don't have $40 for an ice40hx8k dev board?
<sorear> or do you just not value your time at all
zkms has left ##openfpga ["WeeChat 2.2"]
<LAK132> I'm just stubborn
<LAK132> I'd prefer to get the hardware I have working than throwing it away and buying something else
zkms has joined ##openfpga
<LAK132> I'll get something new when I get my money's worth out of this board
<mwk> LAK132: you might not live that long
<mwk> or the board, for that matter
<prpplague> hehe
<prpplague> that attitude always amazes me
* qu1j0t3 is sympathetic to it
<prpplague> "i have this really heavy screw driver, i know it's not the right tool to frame a house, and i really need a hammer, but hey... i have this screwdriver, might as well use it so i get my moneys worth out of it"
<pie___> well i mean if you are really resource starved you do hard mode for everything
<LAK132> I still daily an X220 sooo
<pie___> not sure if it applies here
<q3k> something about picking your battles
* mwk curses Xilinx and their inconsistent wire naming for a bit
<LAK132> pie___: X220 is older than the last ISE update
<pie___> but im just salty about being a teenager whos parents wouldnt help with anything so eh :P
<pie___> LAK132, "they dont make thinkpads like they used to"? :P
* pie___ runs off to bed
f003brv has quit [Ping timeout: 256 seconds]
<LAK132> It's true, but it's still old and slow
catplant has quit [Ping timeout: 268 seconds]
<prpplague> LAK132: grrrr, i am not old and slow, i am "experienced" and "thoughtful"!!!
* prpplague jokes with LAK132
LAKmobile has joined ##openfpga
catplant has joined ##openfpga
<LAKmobile> What is so "cursed" about S6 exactly?
<LAKmobile> The lights in front of my just flickered, I see now...
<LAK132> prpplague: those things aren't mutually exclusive ;P
<mwk> LAKmobile: it's an unholy irregular mess
<LAK132> the chip itself?
<mwk> yeah
LAKmobile has quit [Ping timeout: 256 seconds]
<LAK132> where would the best place to look for this kind of stuff (differences between S6 and other FPGAs) be? duckduckgo is failing me big time
<mwk> xilinx datasheets and user guides
<azonenberg_work> LAK132: yeah i dont think there is any serious work toward open s6 tools
<azonenberg_work> and i don't think there ever will be
<azonenberg_work> there's no point
<azonenberg_work> a7 does everything s6 can do, better
<azonenberg_work> the only exception i can think of is, on the very lowest end of the range
<azonenberg_work> s6 has lower static (but higher dynamic) power
<azonenberg_work> and comes in TQFP if you're uber cheap and want to make a 2-layer PCB (but seriously, just use a BGA - your assembly yields will be higher, your board will be smaller, and your layout won't be a nightmare)
<LAK132> I know even less about PCB design
<q3k> and 4layer is cheap enough these days
<LAK132> this is why I have a Mojo
<LAK132> I care more about this board than the specific chip on it
<azonenberg_work> Then use ISE and know that none of your designs will work on modern hardware
<azonenberg_work> and hate every painful minute of it
<LAK132> been there, done that
<azonenberg_work> Hope you're using linux or an old windows version because iirc ISE doesnt run on windows 10...
<LAK132> It runs in 32 bit mode just fine on Windows 8.1
<LAK132> Haven't tested 10 though
unixb0y has quit [Ping timeout: 272 seconds]
<q3k> azonenberg_work: xilinx performed some necromancy and release ISE 14.7.1 which is duct taped enough to run on win10
<q3k> it's not even 14.7
<azonenberg_work> yeah its s6 only right?
<q3k> it's literally 14.7 'for windows 10'
<q3k> yeah
<q3k> they dropped all series 7 support (which makes sense)
<q3k> although they should've kept older device support
<q3k> for the poor fucks stuck with s3
<LAK132> the Mojo IDE atleast means you don't need to use the ISE UI
<LAK132> pretty sure it just uses the synthesiser or something
<q3k> what the fuck is the mojo ide
<azonenberg_work> q3k: killing 7 series did *not* make sense
<azonenberg_work> there are times when you might want (say, lots of custom scripts) to use ise for 7 series
unixb0y has joined ##openfpga
<azonenberg_work> dropping *new* device support is awful
<q3k> LAK132: i can see that, but why
<q3k> azonenberg_work: right, but you should've ported your damn scripts to vivado anyway :P
<LAK132> q3k: they got annoyed with ISE so they wrote their own front end
<azonenberg_work> q3k: yes but the point is
<azonenberg_work> if i update software for a still-supported chip
<azonenberg_work> i should not lose functionality i rely on
<q3k> i don't think they market it as an update
<q3k> it's a bandaid
<azonenberg_work> for that matter, some of the RLOC etc functionality in ISE is simply missing in vivado
<q3k> explicitely for old_devices && win10
<azonenberg_work> upgrading your OS should not make your supported chips unable to compile
<azonenberg_work> if xilinx wanted to EOL s6 and ISE, they could do that
<azonenberg_work> But keeping it on life support, refusing to pull the plug, seems like the worst of all options
<q3k> LAK132: ... that seems like a waste of time
<q3k> LAK132: at least it could've been a plugin for a real IDE
<q3k> LAK132: i think they're desperately trying to market themselves as "arduino for fpgas'
<LAK132> I mean it's literally got a uno form factor
<azonenberg_work> q3k: i dont like projects that hide so much complexity while pretending to be something they're not
<q3k> azonenberg_work: hm?
<azonenberg_work> q3k: arduino and fpga seem pretty contradictory
<q3k> i have written many a rant about this
<LAK132> they shouldn't be
<q3k> any time someone on The Orange Site asks 'why isn't there something like arduino for fpga???'
<qu1j0t3> well. orange site.
<qu1j0t3> low expectations
<azonenberg_work> LAK132: arduino is a platform for people don't understand, or want to understand, what's going on under the hood
<azonenberg_work> FPGAs are inherently a low level platform
<qu1j0t3> azonenberg_work: yes and no
<azonenberg_work> that's like "arduino for assembly language"
<azonenberg_work> there's just no point
<qu1j0t3> azonenberg_work: you can easily switch from the standard lib to registers
<LAK132> azonenberg_work: my dad, who designs electronics for the university, uses Arduino regularly
<LAK132> Arduino to me, is meant to be *fast* to set up
<LAK132> the PnP of electronics
<q3k> i used to fuck around with arduino when I just wanted to run something on an AVR
<q3k> but these days with platformio it just doesn't make sense
<q3k> and the API, ugh
<qu1j0t3> the libraries are not.. great. but you can drop them any time
<q3k> any time you want to do any sort of concurrency you're screwed
<LAK132> with platformio or arduino?
<q3k> both
<LAK132> oh lmao
<q3k> i mean, if you use platformio for arduino
<q3k> (platformio offers multiple APIs, it's basically a packge manager for embedded toolchains)
<LAK132> ah
<LAK132> tbh I haven't use a genuine arduino board in forever
<q3k> genuine or not, it doesn't matter
<LAK132> I mainly use Teensys and WeMos board
m_w has joined ##openfpga
<q3k> i tried arduino for esp8266 development but just no
<LAK132> I got ImGui running on my ESP32 with Arduino just fine
<q3k> TLS is painful, and again, trying to do any sort of concurrency is just painful
<q3k> painful.
<LAK132> Pretty sure they added threading stuff recently
<q3k> right, but then nothing from the standard library is thread safe
<q3k> for instance, a lot of the std lib is just operating on singletons
<q3k> also i don't want classic threading, i want coroutines
<LAK132> fair
<azonenberg_work> q3k: is there a decent embedded ssh server library that you know of?
<azonenberg_work> one that's undergone independent security evaluations
<q3k> azonenberg_work: never needed one
<LAK132> does C++ even have coroutines yet?
<azonenberg_work> for bare-metal platforms without an OS
<azonenberg_work> or using a simple rtos like uc/os or something
<azonenberg_work> I'm considering implementing either ssh, ssp21, or both for my switch
<azonenberg_work> seriously considering making my own ssh-like "telnet over ssp21" client
<q3k> is SSP21 like gRPC but for centrifuges
<LAK132> back to the main point: I think there's a market for an FPGA board that is super easy to set up and program
<LAK132> the Mojo clearly isn't it, but eh
<q3k> but 'programming' FPGAs is generally not easy
<q3k> i mean, not for software engineers with no digital logic and RTL background
<q3k> sure, we need friendlier toolchains
<q3k> and possibly a better RTL language
<q3k> but I don't think it makes sense to target any of this to people who don't want to even read a book
<LAK132> it shouldn't matter
<LAK132> this is basically the same reason I hate building C++ projects. Yeah I know C++ and I know how to set up CMake for the most part, but I don't WANT to
<LAK132> I just want a compiler that knows what a bloody C++ project looks like and can handle that shit itself
<LAK132> I shouldn't need a goddamned IDE like ISE to tell a LUT what to do
<q3k> yosys -p 'synth_ice40 -json foo.json' foo.v
<q3k> nextpnr-ice40 --hx8k --json foo.json --asc foo.asc
<q3k> icepack foo.asc foo.bin
<q3k> iceprog foo.bin
<q3k> ¯\_(ツ)_/¯
<LAK132> none of that supports S6 though rip
<q3k> you can probably find only a 70% more cursed ISE based Tcl script
<LAK132> "ISE based" may as well just use Mojo IDE then
<LAK132> guess I'm just gonna have to figure out how fpgatools works then
<q3k> s6 patches for nextpnr are welcome :P
LAKmobile has joined ##openfpga
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
<LAK132> is it possible to build the important parts of nextpnr without CMake
<azonenberg_work> q3k: no it's an embedded-friendly replacement for TLS
<azonenberg_work> targeting SCADA environments
<LAK132> and without Qt
<azonenberg_work> basically removes all of the fluff, x509, etc
<azonenberg_work> intended to be used in a closed system where you control the single trusted root CA
<azonenberg_work> or with pre-shared keys
<q3k> LAK132: you can build it without Qt
<q3k> LAK132: and without Python
<q3k> LAK132: but you still need CMake as a build system
<LAK132> Python is fine
<LAK132> welp that's not happening then
<q3k> ... what's the problem with CMake?
<LAK132> Anything you can do with CMake can be done with a shell script
<q3k> lol no
<q3k> i'd like to see shell scripts being used to build nextpnr using visualstudio
<LAK132> batch can use JavaScript :)
<q3k> you have to be trolling right now
<q3k> i'd rather tear my eyes out than have to maintain this monstrosity
<LAK132> you're not meant to, its reads Makefile
<q3k> so this is a partial JS reimplementation of GNU make?
<LAK132> I was attempting to rewrite GNU Make in JScript
<prpplague> q3k: there is make, amake, bmake and cmake.... cmake is like 4th down in quality...
<LAK132> I have an issue with non-native Windows / not POSIX dependencies
<LAK132> compilers and shell scripts are all that is needed to build ANY project if they're set up correctly
<q3k> but makefiles are not shell scripts
<LAK132> GNU Make is fair game on Linux
<q3k> is pkg-config fair game?
<whitequark> what in the fresh hell am i looking at
<LAK132> is that a GNU/POSIX program?
<whitequark> pkg-config is a freedesktop program originally
<LAK132> whitequark: I think I'm slightly insane
<q3k> whitequark: the superior alternative to CMake, of course
<whitequark> but it's widely used for non-desktop things
* whitequark stabs q3k
<q3k> whitequark: don't you see how this is better than having to install cmake?
<LAK132> the idea behind make.bat is that you don't have to install it, you just put it in your repo and it just works
<whitequark> ...
<LAK132> I'm still working on it
<LAK132> I know it's helll but it genuinely works
<q3k> i honestly don't understand this
<LAK132> which part
<whitequark> "it works" is like, the least interesting part about software
<q3k> every single one
<LAK132> every one of what
<whitequark> "it works" was a good qualifier in like 1980s, which is also how we got unix
<whitequark> "oh hey it works"
<q3k> i mean, why the requirement that building software should only require 'compilers and shellscripts'
<whitequark> these days the bar is thankfully higher
<LAK132> it's better than installing dependencies
<q3k> it's not like end uses should be touching any of this shit
<whitequark> you need to install visual studio anyway.
<LAK132> that's a compiler
<q3k> end uses will get a .deb/.exe/... and that's it
<LAK132> I am ok with compilers
<whitequark> that's a dependency.
<whitequark> why not just write your entire software in batch javascript?
<q3k> LAK132: but that's like the most arbitrary choice ever
<whitequark> that eliminates a dependency
<LAK132> I mean I've done that for some stuff already
<whitequark> ok nevermind
<whitequark> i'm out
<q3k> i could say that i'm okay with dependencies whose SHA256(name) % 2 == 0
<LAK132> you certainly could
<q3k> it's about as sensible as saying you're only okay with compilers but not cmake
<LAK132> you can't do anything C++ without a compiler, but you can do EVERYTHING C++ without CMak
<q3k> alright, i'm out as well
<LAK132> :)
<LAK132> I'll just have to fork nextpnr and replace CMake with shell scripts to prove a point /s
<whitequark> you definitely can do everything C++ without a compiler
<whitequark> so first, you compile clang with emscripten to javascript
<whitequark> second, you embed it into your make.bat
<LAK132> yeah but then make.bat is a compiler
<whitequark> yeah but you don't have to install a compiler
<whitequark> one dependency less
<whitequark> isn't this great?
<LAK132> don't tempt me
<whitequark> never having to wait for visual studio to download again...
<LAK132> I hope you know I'm going to try this when I get home
<whitequark> yes
<whitequark> i would be very disappointed if you did not
<LAK132> actually I could probably just hook it up to godbolt.org
<LAK132> then it'll work for anything that supports
<LAK132> oh but then that makes the website a dependency :/
Finde has joined ##openfpga
<LAK132> whitequark: do you know what version of javascript "emscripten to javascript" uses?
<LAK132> windows only supports JScript
<sorear> just use gnu mes
<LAK132> that's not native to windows
<whitequark> LAK132: uh, it outputs fairly simple javascript
<whitequark> especially if you don't use array buffers
<whitequark> pretty sure you could polyfill everything jscript can't do
<LAK132> arrays are fair game
<LAK132> you just can't do classes
<whitequark> there are no classes in the output
<LAK132> nice
muvlon has joined ##openfpga
<LAK132> so compile LLVM with LLVM with the JavaScript backend, got it
<sorear> has anyone actually tested JScript on >300MB scripts
<LAK132> I have no fucking clue, but I'm gonna find out
<sorear> the last time I used that was back when <script language="text/vbscript"> was a thing
<LAK132> that's still a thing
<LAK132> I think I can use the batch script to hack multiple files together
<sorear> or you could just use Windows Installer like is actually intended, was good enough for me even in teenage years
<LAK132> or we can script everything
Bike has quit [Quit: Lost terminal]
Miyu has quit [Ping timeout: 272 seconds]
futarisIRCcloud has joined ##openfpga
<zkms> is "Info: promoting $PACKER_VCC_NET [cen] (fanout 34)" and "Info: promoting $PACKER_GND_NET (fanout 5)" supposed to happen when running nextpnr?
<whitequark> zkms: define supposed
<whitequark> there are certain constant signals that cannot be generated at point of use in certain parts of FPGA
<whitequark> mostly 1 but in some cases 0
<whitequark> this seems like you have a lot of DFFEs in your design
<whitequark> not sure what PACKER_GND_NET is about offhand
rohitksingh_work has joined ##openfpga
muvlon has quit [Ping timeout: 252 seconds]
LAKmobile has quit [Ping timeout: 256 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
m_w has quit [Ping timeout: 244 seconds]
LAK132 has quit [Ping timeout: 256 seconds]
lexano has quit [Ping timeout: 245 seconds]
lexano has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
LAK132 has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
<daveshah> Probably BRAM related, there are some places where explicit constants are needed
<daveshah> Might as well use the globals if nothing else is, as the extra delay doesn't cause any problem for constant nets
scrts has joined ##openfpga
m4ssi has joined ##openfpga
catplant has quit [Ping timeout: 252 seconds]
GuzTech has joined ##openfpga
<cpresser> i just got some PCBs from JLCPCB, and the inside of the NPTH are black. Is this some extra process? I would expect them to have the same color as the solder resist
kuldeep has joined ##openfpga
pie_ has joined ##openfpga
<pie_> does "TBT" in a TVS diode IC part number mean anything to anyone? im trying to figure out why different variations of the same part cost 2.5$ or 70 cents
<azonenberg_work> pie_: look up the datasheet?
<azonenberg_work> cpresser: i would expect it to be the same color as the fr4 substrate
<azonenberg_work> (not the soldermask)
<azonenberg_work> did they use black fr4?
<azonenberg_work> also possible that the drill was overheating and slightly carbonized the surface of the resin
<azonenberg_work> that wouldnt happen in a well-controlled process but who knows, jlc i dont think is the most high-end fab
<azonenberg_work> If you can get a photo under a microscope i could give a better assessment
<azonenberg_work> my experience is that normally NPTH's have the yellow-green color of bare FR4, tinted a bit by light coming through the soldermask
<pie_> azonenberg_work: in the data sheet it just seems to be part of the part number, otherwise the organization of the two datasheets seems to be rather different, but if thats what needs to be done ill try to compare them (or go the lazy route)
<azonenberg_work> well you say diff variations on the same part
<azonenberg_work> usually if they're actually "the same part" (changes in package or something) its only one datasheet
<azonenberg_work> multiple datasheets seem to imply there is indeed more of a difference
<pie_> yeah I guess that's why I was suspicious. Well, here's the link to at least concretize a bit https://eu.mouser.com/Circuit-Protection/ESD-Suppressors-TVS-Diodes/_/N-jy72?P=1yzvta6&Keyword=srda05&FS=True
<pie_> wait hold on...those are different manufacturers
<pie_> I think I pasted the wrong search
<pie_> I must be hallucinating *rolls eyes*, and I even had my coffee
<pie_> I *guess* I didn't notice the differing manufactuerers. I swear the datasheets were styled the same though.
LAK132 has quit [Ping timeout: 256 seconds]
<azonenberg_work> Lol
<azonenberg_work> So they have similar part numbers but are totally different?
<pie_> im not sure whats going on, they seem to be at least similar functionally but i havent checked closer yet
<pie_> i ...dont think this is some kind of standardized part numbering??? xD
<pie_> do packaging types have different names that mean the same thing sometimes? >_>
<pie_> right now im looking at some "SM8" footprint
<pie_> is there some guide thats good for choosing between footprints / shows them to scale or something or do you guys just have enough experience to decide what to use
rohitksingh_work has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
scrts has quit [Ping timeout: 250 seconds]
catplant has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 268 seconds]
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
kuldeep has quit [Read error: Connection reset by peer]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
m_w has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
scrts has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<cpresser> azonenberg_work: yep, it should be the same color as the substrate; that would make it yellowish-white.
<tnt> maybe they lasered off the holes ?
<cpresser> all holes have the same black color, regardless of drill size. routed holes are all nice yellowish, slightly green because the light enters through the solder resist
<cpresser> the fab did not cut the v-score line I included, so i have to contact them anyway. I'll ask about the black holes
<tnt> maybe their drill bit is doll and rubbing ...
<azonenberg_work> tnt: yeah thats what i was implying by overheating bits
<tnt> ah sorry, must have missed a couple lines when scanning through the backlog.
<azonenberg_work> (01:24:14) azonenberg_work: also possible that the drill was overheating and slightly carbonized the surface of the resin
<azonenberg_work> (01:24:33) azonenberg_work: that wouldnt happen in a well-controlled process but who knows, jlc i dont think is the most high-end fab
<azonenberg_work> That, i mean
<azonenberg_work> interesting that multiple sizes of bit are doing that though
<tnt> Mm,m I had not noticed by my pcb also have that.
<tnt> Doesn't look like rubbing or carbonization.
azonenberg_work has quit [Ping timeout: 268 seconds]
SpaceCoaster has quit [Ping timeout: 250 seconds]
m_w has quit [Quit: Leaving]
SpaceCoaster has joined ##openfpga
genii has joined ##openfpga
<cpresser> tnt: yep, mine look similar. I dont have good pics yet. will make some tomorrow
indy has quit [Read error: Connection reset by peer]
<swetland> I appear to have designed a PCB. Now to wait for OSH Park and then see if it actually works. Kicad seems reasonably survivable. https://pbs.twimg.com/media/DuEMLd7U4AEHsEz.jpg:large
indy has joined ##openfpga
<tnt> swetland: vcc is connected to some of the magjack pins ?
<swetland> yeah the center taps go to vcca
<tnt> huh.
<tnt> What phy is that ?
<swetland> LAN8720A
<tnt> interesting, I had nver see that before, always saw those being ac coupled to gnd or just left open
<swetland> I am (perhaps foolishly) using the recommendations from the datasheet
<swetland> https://pbs.twimg.com/media/DtkQ02BUcAA34cm.jpg:large (slightly stale, rearranged connector pinout since this)
<tnt> yeah, I saw it in the DS as well, so must be what the phy expects.
GuzTech has quit [Quit: Leaving]
<cpresser> swetland: nice schematic. it looks very clean
<cpresser> only your vcc-label is not on a net, so the net-name is not set with the label
<tnt> swetland: now you just need the MAC ;p
<cpresser> the labels next to J1 and J3 have the same 'issue'
<tnt> swetland: btw, for future version, you could consider to have a 1-wire to I2C + 1-wire to GPIO onboard to control the reset and MDIO from the single IO you have.
<qu1j0t3> swetland: indeed, nice schematic. What specific part do you use for the ferrite bead, just curious? And how do you physically arrange it?
<swetland> tnt: I don't anticipate needing to actually talk to the MDIO, but brought it out to a header so I could fly wire it over if necessary
<tnt> swetland: Oh, the phy boots in a sensible config, that's nice.
<swetland> cpresser: the net names being based on the label's physical contact with the wires is a bit weird
* qu1j0t3 never mind the 2nd part of my q is answered by the rendering
<swetland> still getting used to kicad
<qu1j0t3> looks great though
<swetland> I'm excited that oshpark's new faster service is way cheaper than the last iteration ($90 surcharge previously, now $10/in^2/3 vs $5/in^/3 2 layer). $16.10 for 3 boards that should ship out by friday is pretty awesome
<swetland> I lamed out and used a canned 25MHz oscillator rather than wrangle with getting all the caps, etc right with a crystal. For tiny quantities of boards, the maybe 50 cents of cost savings didn't seem worth the hassle
<tnt> new faster service ?
<tnt> Ah, for 2 layer only ?
<swetland> yah
<q3k> since ever jlcpcb became a thing i have no use for oshpark :/
<q3k> since shipping from the US is about as terribad as from china
<swetland> overseas shipping is indeed horrible
<q3k> and eurocircuits is still prohibitively expensive :/
<cpresser> aisler has a similar service to oshpark, but for europeans
<cpresser> resonable prices and lead times for small 2-layer boards.
<tnt> cpresser: I like the boards from aisler but their 4 layer delays are highly variable ... some board I got next week. Others I had to wait 3 weeks :/
<tnt> q3k: pretty much same here. jlc + express shipping gets me to the same price ~ as oshpark/aisler, but I get my PCB in 1 week.
<q3k> need to try out aisler
<cpresser> tnt: yep, I have the same experience. for medium sized PCBs, jlpcb just offers the better deal
* cpresser lives close to aisler-hq, i can pick up boards if required
<q3k> jesus the aisler site is annoying
<cpresser> I am not sure where aisler actually does the boards
<cpresser> q3k: its for 'makers', not professionals :)
<q3k> i just want to know what thickness the board is and whether it's HASL or ENIG
<q3k> okay, FR4, 1.6mm, ENIG
<q3k> pretty good price, actually cheaper than what I paid from jlcpcb
<q3k> although I ended up getting 10PCBs from jlcpcb, but I just needed 1 anyway
<q3k> but yeah, the UX is terrible
<cpresser> oshpark and aiser have the 'drill 3 boards at one' process, so you always get multiples of 3. getting 4 boards is stupid expensive
<tnt> mithro: 404 ?
<tnt> "It is no surprise that the VexRiscV won the first prize of the RISC-V Summit softCore contest." ...
scrts has quit [Ping timeout: 246 seconds]
<steve|m> just tried to build the glasgow fx2 firmware
<steve|m> "Internal error: validateLink failed in SPEC_EXTR((yyvsp[-2].lnk)) @ SDCC.y:576: expected SPECIFIER, got DECLARATOR"
<steve|m> meh
<tnt> swetland: I think I saw something like that when using an old sdd
<tnt> steve|m: ^^ that was for you :p
<tnt> Are you using 3.8.x ?
<steve|m> yeah, ubuntu ships 3.5.0, just upgrading
<steve|m> build works with 3.7.0
azonenberg_work has joined ##openfpga
<azonenberg_work> tnt: veeery interesting
<azonenberg_work> i note that it looks to be mostly deeper in the hole
<azonenberg_work> the very top edge looks like fr4
<azonenberg_work> what's the stackup? do you have super thin prepregs?
<azonenberg_work> that almost looks like green prepregs over a black core but i dont think thats the case
<tnt> azonenberg_work: yeah prepreg are 0.18 mm, core is 1.12
<azonenberg_work> got a pic of the pcb edge?
<tnt> But on the side (milled) you see no traces of the black
<azonenberg_work> yeah that is really strange
<azonenberg_work> if you had one of those boards you were willing to sacrifice to science, and willing to wait until i get my lab (somewhat) unpacked in another month or two
<azonenberg_work> i'd gladly do some microscope cross sections
<azonenberg_work> in the meantime i'd be interested if you scratched it a bit with a knife tip or something
<azonenberg_work> how deep is the black? is it just surface or what?
<azonenberg_work> it appears to only be affecting the resin, not the glass
<tnt> azonenberg_work: https://imgur.com/a/lJo0GRJ
<tnt> Didn't try scratching it yet. But I can mail you a board ... I have 5 extras :p
<azonenberg_work> i dont want one yet, the lab is not serviceable at this time
<azonenberg_work> just mentioning it for the future
m4ssi has quit [Remote host closed the connection]
<azonenberg_work> And it looks like both core and prepreg have the black on them
<azonenberg_work> but not the glass
<azonenberg_work> which is strongly suggestive of thermal decomposition of the resin (since the glass is unaffected, if it was contamination on the bit it would rub off on the glass too)
rohitksingh has quit [Ping timeout: 250 seconds]
pie_ has quit [Ping timeout: 256 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
catplant has quit [Quit: WeeChat 2.2]
catplant has joined ##openfpga
jevinskie has joined ##openfpga
jevinskie has quit [Client Quit]
jevinskie has joined ##openfpga
<daveshah> UI design study for Lattice sumarises FPGA development. "After spending time with them for 3 days, we discovered that most times, engineers work with computer eye strain for long hours, especially during the night" https://www.eugenemeng.com/latticediamond/
<fseidel> "increase our client's market chair"
<fseidel> is this an expression I've never heard of, a typo, or a request from lattice for more furniture to compete with Xilinx/Intel?
<cr1901_modern> Sounds like they need to go to The Dump (tm)
<tpw_rules> hey. i'm working on a cyclonev-SOC and i can't figure out how to change a kernel command line parameter. editing in the uboot script didn't work, editing it at the uboot console didn't work, and editing it in the device tree didn't work. the command line in /proc/cmdline didn't change and the effect didn't happen
scrts has joined ##openfpga
<RaYmAn> tpw_rules: not familiar with the device, but there's a generic kernel config to override commandline
catplant has quit [Ping timeout: 246 seconds]
catplant has joined ##openfpga
<adamgreig> ugh, my rmii mac is receiving valid packets and matching checksums, but nothing I transmit makes it beyond the switch
<adamgreig> switch interface says it's receiving loads of megabytes and no packet crc errors, but all my packets should have a broadcast destination mac :/
<adamgreig> suspect switch is lying about no crc errors
<adamgreig> I think my rmii timing is right? this is the end of transmission, crc32 was F66EF78B https://imgur.com/a/1HKTL2o
<tnt> azonenberg_work: what's your phy ?
<q3k> adamgreig: ... if you connect it directly to a linux box, does it receive the packets correcly?
<adamgreig> annoyingly the only convenient way to power it is poe, and all my poe injectors are passive, and it is only active
<adamgreig> so yea the next debugging step is wiring a non-poe supply to it and connecting it directly
<tnt> adamgreig: the phy question was for you obviously.
<adamgreig> oh sorry
<tnt> (my bad)
<adamgreig> it's a KSZ8081RNA
<azonenberg_work> tnt: ksz9031rnx is my default
<tnt> adamgreig: yeah your RMII timings look right to me.
<adamgreig> right, I can zero out a byte of checksum and the switch still says no crc errors on that port
<azonenberg_work> adamgreig: so the switch's performance counters are lying and your tx crc is bad
<azonenberg_work> :p
<adamgreig> bbbut the crc is right in simulation ;(
<azonenberg_work> Define "right"
<azonenberg_work> first guess: high/low nibble swap, endianness issue, forgetting to invert, any of a million possible things wrong
<azonenberg_work> here's a frame of 10baseT right off the wire with full traffic including preamble and crc
<azonenberg_work> If you want to sanity check that your crc generates the same results
<adamgreig> thanks
<adamgreig> the same crc module correctly validates incoming packets, and what it generates in sim matches what wireshark agrees is a valid crc, and the sim traces for txd0/txd1 match the scope traces
<adamgreig> I think I am chasing the wrong thing
<azonenberg_work> how fast is your scope? might be worth looking at the PHY side of the link and see what goes out on the wire
<adamgreig> I have just found a suspicious glitch as it goes from SFD to first data byte :p
<adamgreig> 200M bw
<adamgreig> but finding it hard to trigger on anything especially useful
<azonenberg_work> that should be fast enough to decode with some software support - and lol
<adamgreig> though I suppose I can trigger on txen and watch just TD+ or something
<azonenberg_work> i would have set the scope to trigger on txen then watch td+/td-
<azonenberg_work> however 100base-TX is a somewhat complex mdoulation
<adamgreig> only 2ch also
<azonenberg_work> you cant just read it off the wire, some postprocessing is needed
<adamgreig> mm
<adamgreig> going to fix this glitch first
<azonenberg_work> yeah fingers crossed that will work
<davidc__> adamgreig: also try transmitting the same frames with a regular PC. "smarter" switches sometimes try to get clever with anti-flooding measures
<davidc__> (so certain broadcast frames can sometimes be special-cased in terms of how they are forwarded)
<adamgreig> oh yay!!! got it
<adamgreig> I had two issues: transmitting 0x5D instead of 0xD5 for SFD
<adamgreig> and my exmaple packet did not have a padding field and was sub-64 bytes
<adamgreig> I am now flooding wireshark with gratuitous arp announcements
<adamgreig> hurray. I should add automatic padding to the mac though.
<adamgreig> davidc__: good idea.. my switch does have broadcast filtering, but it's turned off
<gruetzkopf> yeah many nics eat tiny packets
<gruetzkopf> (sub-standard tinies anyways)