<cr1901_modern>
The "cookies" setting works best for reflow.- azonenberg, 2017
<lain>
haha
<azonenberg_work>
Hey, the other options either dont have convection on or do weird things where only the top or bottom element runs
<azonenberg_work>
Also my garage is *freezing*
<azonenberg_work>
its 48F in here right now with the dehumidifier and reflow oven going
<azonenberg_work>
and all my servers
promach has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
<rqou>
azonenberg_work: you should bikeshed over my NAS build before I order it :P
ZipCPU|Laptop has joined ##openfpga
<azonenberg_work>
Send it again? to this nick
<azonenberg_work>
have some time to kill waiting for epoxy to curer
<lain>
azonenberg_work: did you try that epoxy we found a while back?
ZipCPU has joined ##openfpga
<azonenberg_work>
i'm using aa-bond something or other
<azonenberg_work>
i included th elabel in one of my tweets
<azonenberg_work>
and circuitmedic colors
<rqou>
just noticed on newegg: "Products with exposed solder may contain lead, a chemical known to the State of California to cause cancer, birth defects and other reproductive harm."
<rqou>
um... i hope devices no longer contain lead
<cr1901_modern>
I *wish* it would be 48F with servers running at my house
<lain>
Chinese Mystery Alloy™
* cr1901_modern
cherises his computers while they last before global warming forces countries to ration computer usage
<rqou>
my definitely-calibrated-and-not-from-china thermometer says it's 66F here
<rqou>
lain: my mechanical engineering friends liked to use the term "Chineseium"
<rqou>
this usually came up when discussing cheap shitty drill bits and screws
<lain>
:D
<rqou>
apparently shitty drill bits bend/break
<lain>
yeah, have heard that one a lot
<rqou>
and shitty screws cause galling
<rqou>
who would have thought? /s
<lain>
recently I saw some gallery of chinesium masterpieces
<lain>
I forget where though
<lain>
all manner of bent/twisted/mangled drill bits and other tooling, it was impressive
<rqou>
hmm apparently the ssd i was looking at went out of stock
<rqou>
must resist "bigger numbers!" temptation...
<lain>
I remember going monitor shopping
<lain>
I was thinking maybe a 19"
<rqou>
i was originally going for a 32gb ssd for $25 but it went out of stock
<lain>
but the 19" was next to a 22", and the 22" was noticeably larger, I liked that
<rqou>
now i'm looking at the 64gb one for $40
<lain>
but then standing at the 22", there was a 24" next to that, which, once I had gotten used to staring at the 22", looked better still
<lain>
then again with the 25.7" next to that
<rqou>
must resist getting the 128gb one for $60
<lain>
but the next one up was like a 40" tv and I was like nahhhh I'll just get the 25.7", got it home, unboxed it, "oh crap I don't even have enough desk for this. this is huge what have I done."
<rqou>
the price per gb keeps going down too
<rqou>
but i really don't need or want a huge os disk
<lain>
the sata signals go through those jumpers on the left
<rqou>
i am told that you can often get away with that
<lain>
you can
<lain>
but it's still crap
<lain>
a friend owns one of those, apparently it only works at the lowest speed
<rqou>
blargh pcie over sfp is actually a bit annoying
<lain>
it won't link above, like, 1.5 Gbps
<rqou>
because of refclk
<lain>
iirc refclk is optional?
<rqou>
idk, is it?
<lain>
hm, maybe it is required
<lain>
just disable spread spectrum and pick it up over RF
<lain>
"{
<lain>
:P
<lain>
ok
<lain>
it seems that it is not required to use the mobo-provided refclk, but only if the card provides its own 100 MHz reference that meets all the stability requirements over temperature and whatnot
<lain>
the refclk distributed by the mobo is mainly for cost saving, it seems
<rqou>
you can still do it though using one normal sfp and one BiDi sfp
<rqou>
for the most wtf?-inducing design ever
promach has quit [Ping timeout: 240 seconds]
<rqou>
offtopic: i was screwing around and discovered that the multimode fiber (LC connector) acceptance cone is huge
<rqou>
you can hit it with a laser pointer
<lain>
yep
<lain>
hm, I forget the reason, but there's good reasons for that :P
<rqou>
presumably cheaper?
<lain>
there's optical reasons iirc
* lain
digs out the texts
<rqou>
numerical aperture?
<lain>
ah here it is
<lain>
hrm, well, probably you have a 62.5 um core
<azonenberg_work>
50 is more common for modern stuff
<azonenberg_work>
OM2 and up
<azonenberg_work>
only OM1 is 62.5
<lain>
tl;dr LED sources produce divergent light, and come in surface emitting and edge emitting flavours. surface-emitting is cheaper and overfills 62.5um (calibrated to supply the correct power to 62.5um), when used with 50um a surface emitter will lose 2 dB to 5 dB due to intersecting a smaller area of the beam
<lain>
edge-emitting LEDs produce a beam spot that fits within either 62.5 or 50um core, coupling about the same power into each
<lain>
so most cheap stuff uses 62.5 because it's being used with surface-emitters
promach has joined ##openfpga
<rqou>
hmm my fiber is supposed to be 50um core om4
<rqou>
not 62.5um
<lain>
ah
<lain>
interesting :3
<rqou>
i can still hit the acceptance cone with a laser pointer
<rqou>
(which is pretty divergent and crappy overall)
<lain>
well, I'm sure the laser is overfilling it, so that's to be expected I think
<rqou>
it's one of those <$5 aliexpress ones
digshadow has quit [Quit: Leaving.]
<lain>
azonenberg_work: whatchu know 'bout CSFP?
<azonenberg_work>
Next to nothing
<azonenberg_work>
i only own SFP and QSFP+ optics
<azonenberg_work>
and have only actually interfaced with the SFPs
<lain>
the heck is QSFP+
<rqou>
qsfp28?
<rqou>
why do you have that?
<lain>
oic
<rqou>
supposedly csfp is a dual BiDi sfp
<rqou>
why would you do that?
<lain>
four simultaneous connections -- is this doing WDM or something?
<lain>
rqou: increase density
<rqou>
yeah, it's wdm
<lain>
rackspace is at a premium!
<rqou>
but there's no + sign
<rqou>
it's only 2gbit
<lain>
more jiggabits per U
<rqou>
huh it's actually reasonably clever
<rqou>
co-opting some ground and other "useless" pins for an extra tx/rx pair
<azonenberg_work>
lain: qsfp is a single module with four lanes in it
<azonenberg_work>
for 40gbe
<azonenberg_work>
eight fibers
<azonenberg_work>
four each way
<azonenberg_work>
four GTPs
<lain>
oh it actually uses 8 fibers?
<azonenberg_work>
Yes
<lain>
from the pics it looked like it used 2 fibers and WDM'd them
<rqou>
wait, that can become a successful product?
<lain>
wow rude :P
<lain>
;)
<rqou>
i've been meaning to do that and kept saying "eh, maybe later"
<rqou>
"i got this android thing that works most of the time"
<lain>
yeah, it sold pretty well, but sales are dying off
<lain>
yeah
<lain>
way back, I was going to do an android app, but it requires root, and everybody just pirates that stuff anyway >.>
<rqou>
it doesn't require root if you don't care about having all of the stupid bits correct
<rqou>
or wait
<rqou>
it does
<lain>
there's a competing device called i-odd, but rebranded by zalman, which uses a 2.5" hdd/ssd, but it has some wonky firmware limitations
<rqou>
it doesn't require a new kernel if you don't need all the bits correct
<lain>
but they do have a usb3 version now, which beats isostick :P
<rqou>
i don't care about usb3 personally
<rqou>
i just need "tricks apple's shitty efi until it boots my linux"
<lain>
eh, usb2 is annoying for loading tons of isos onto it
<lain>
especially with 128GB and larger cards now
<lain>
although isostick is doubly impaired in that regard
<lain>
the stupid mcu I used is limited to 12 MByte/s
<lain>
usb2 can go about 4x that
<lain>
mind you, back when I first created it this was as fast as microsd could go anyway
<lain>
and atmel promised a better mcu with higher speeds, but they fucked that all up
<lain>
then abandoned the product line
<rqou>
xmega?
<lain>
avr32
<rqou>
oh lol avr32
<rqou>
i never understood why that existed
<lain>
at the time, it had better features than most arm chips
<lain>
a year or two later arm stuff really beefed up
<lain>
and totally obsoleted it
<rqou>
ah i see
<lain>
also they had a really nice IDE
<rqou>
hrm, i need to re-evaluate what i consider to be a worthwhile product :P
<lain>
hehe
<rqou>
atmel's ide?
<lain>
it was visual studio based
<rqou>
yeah, i don't use semiconductor vendor ides
<lain>
but they didn't keep it up to date, and they never implemented the debugger or trace functionality for avr32
<rqou>
for arm at least, i don't even use vendor toolchains
<lain>
I have a $300 paper weight for avr32
<lain>
it's a lovely looking device, I think it's a rebranded lauterbach
<rqou>
for arm i use a really ugly hacked up version of devkitPro
<lain>
nowadays I use visual studio with visualgdb
<rqou>
which reminds me that i really should clean that up at some point
<rqou>
wait, you use windows?
<rqou>
heretic! :P
<lain>
lol
<rqou>
i got tired of messing with drivers on windows
<lain>
I've never had driver issues with windows
<rqou>
all the inifinity bajillion libusb kernel backend things
<rqou>
macos is the worst
<rqou>
because nobody in the world knows/cares about how to program iokit :P
<lain>
lol
<rqou>
the biggest problem on macos is that there's no implementation of libusb_detach_kernel_driver
<rqou>
idk if it can't be done or just nobody poked iokit enough
<rqou>
if a kernel driver hasn't claimed a device, libusb can talk to it
<rqou>
but libusb can't kick out a kernel driver that has claimed the device
<rqou>
hence the creation of "codeless kexts" which are imho the dumbest concept ever
<rqou>
basically a kext that has probe/match metadata that says "that device is mine" but doesn't actually load any kernel code to bind to it
<lain>
on windows I mostly use winusb
<lain>
it's quite nice :3
<rqou>
and these need to be signed :P
<rqou>
is winusb the microsoft user-mode-usb thing?
<rqou>
that libusb-<some bullshit fork version> can talk to?
<rqou>
in terms of overall suckiness to write code for though, win32 is still the worst
<rqou>
my personal two biggest issues: abi mess and unicode mess
<rqou>
abi mess: on win32 the crt is not* considered a part of the os
<rqou>
so every compiler gets to have its own
<rqou>
for "value add" or something? :P
<lain>
well
<rqou>
which means that you can't have e.g. a FILE* on an api boundary or you'll have lots of fun
<rqou>
you can't even malloc in one dll and free in another
<lain>
I program in .net so I dunno about most of that nonsense :P
<rqou>
* = the new universal crt fixes this
<rqou>
but nobody has e.g. adopted mingw to use it
<lain>
C#/.NET is now open and cross platform, so I just use that everywhere :3
<rqou>
C# is tremendously better
<rqou>
you still have to either deal with or ignore the unicode mess
<rqou>
(btw i used to be a heretic and a c# programmer in a past life)
<rqou>
(around the .net 2.0 era)
<rqou>
anyways, unicode mess:
<lain>
lol
<rqou>
first of all, windows allows unpaired surrogates in e.g. filenames
<rqou>
and, this is the worst part,
<rqou>
if you're interfacing with a C-like api that gives you a "char *"
<rqou>
wtf is the "char *"?
<rqou>
utf-8?
<rqou>
"ANSI"?
<rqou>
something else?
<rqou>
imho i want my higher-level-language FFI layer to have a concept of a "WrongStr"
<rqou>
you can concatenate wrongstr with either bytes or strings (using Python terminology)
<rqou>
doing so is automatically UB but won't cause an exception
<rqou>
and you can pass it back to the FFI layer
<rqou>
so you can cause some other layer of the stack to display mojibake or crash but it becomes "Not My Problem"
<rqou>
and chances are it just displays mojibake and doesn't crash
<lain>
or it creates a buffer overflow :3
<rqou>
and then i don't have to deal with this problem anymore :P
<rqou>
hopefully it doesn't create a buffer overflow because the string should probably contain at least one null in it
<rqou>
you can end up with fun results though
<rqou>
iirc there was once a screenshot on thedailywtf of some NSIS installer
<rqou>
that displayed the message "The file C" with options yes/no/yes to all/no to all/cancel or something
<lain>
lol
<rqou>
and afaik what happened was that the installer somehow managed to concatenate an ascii/"ANSI"/utf-8/whatever string and a UTF-16/UCS-2 string
<lain>
rqou: so you run linux as your primary OS?
<rqou>
at this point yes
<lain>
any particular reason you moved away from windows?
<rqou>
mostly not having to mess with compilers and usb drivers nearly as much
<rqou>
and configure scripts running orders of magnitude faster :P
<rqou>
a tiling window manager is a neat bonus
<lain>
hehe
<lain>
I use allsnap for window snappage, which works out nicely
<rqou>
in general i've found that messing with "lower-level" stuff is significantly less painful on linux
<lain>
(on windows)
<lain>
interesting
<rqou>
i also make use of linux containers now
<lain>
windows has containers too now
<rqou>
because i got tired of vendor eda tools shitting all over the system
<rqou>
wait it does?
<lain>
yeeeeup
<lain>
well they're basically docker containers though, which I think is separate from... LXC or whatever?
<lain>
I'm not sure what the linux story is
<lain>
but yes it has them, however I don't think you can run gui apps in them so it's kinda moot for eda tools
<lain>
that's supposedly going to change in the future
<rqou>
afaik the story is that linux grew over the years two super-powerful features: cgroups and namespaces
<rqou>
eventually this "cloud" thing happened
<rqou>
and people realized that cgroups+namespaces make lightweight vm-like things
<rqou>
lxc was one of the tools that could use these apis to make vm-like things
<lain>
I see
<rqou>
and then docker and all of its associated crap appeared as containers started to take off
<rqou>
also, windows containers not supporting gui doesn't surprise me at all considering how windows is architected
<rqou>
with random parts of "the win32 subsystem" smeared all over the kernel and random special userspace processes
<lain>
I think they've prettymuch worked all that out at this point
<lain>
there was a huge effort over the past N years to fix that
<rqou>
cygwin still can't call the undocumented nt kernel fork syscall
<rqou>
because forked processes still can't correctly register themselves with the "win32" or "gui" stuff
<lain>
it's interesting that you found low level stuff easier on linux - I found it harder, it's largely undocumented on linux :P
<rqou>
mostly because i'm not dealing with the lower-level linux desktop stuff
<lain>
yeah I'm not talking desktop
<lain>
like.. kernel apis and such
<rqou>
i mostly care about the layer below that e.g. talking to hardware
<lain>
there are some books, but mailing lists were mostly "just read the source, it's self-documenting"
<rqou>
i usually don't hack on the kernel directly
<rqou>
i just make use of its services and write usermode code
<lain>
and then if they caught wind that you were doing a commercial product or developing a non-GPL driver, wew lad.
<lain>
the flames were let loose
<lain>
so I moved to freebsd >_>
<lain>
where people don't care wtf you do they just think unix is pretty neat™
<rqou>
it's funny because (disclosure time!) i interned at national instruments
<rqou>
where they have a huge kernel blob probably on par with nvidia.ko
<rqou>
but nobody seems to hate NI, and NI does contribute back code afaik
<lain>
lol
<lain>
also in general I found the linux kernel stuff to be fairly abusive in general
<lain>
and the whole... Church of Linus thing
<lain>
it's like, I dunno, it just wasn't productive at all for me
<lain>
which is unfortunate since linux is ~everywhere~
<rqou>
hmm, i've never interacted with the community at all, so i can't comment on that
<rqou>
in general i'm not good at doing the people skills :P
<lain>
when I first got into freebsd, I was preparing to develop some kernel modules for something which was to run linux, but my modules were to be MIT licensed
<lain>
and yeah, I don't think I ever posted directly, but I was reading through mailing list logs and stuff, and I was really put off
<lain>
then someone suggested I check out freebsd, and people were super friendly and helpful and everything was really well-documented
<lain>
so I jumped ship :P
<lain>
at the end of the day they're all just useful tools
<rqou>
eh, i've read some of the famous flamewars and didn't find it that off-putting
<rqou>
i've found various technical explanations of OS concepts to be highly beneficial
<lain>
yeah it was just stuff like... if you're developing non-GPL, you shouldn't expect any help
<lain>
even if what yuo're doing is open (MIT/BSD/etc)
<lain>
if it's not GPL, you're not welcome basically
<cr1901_modern>
NetBSD community is nice. It's the only OS where I've actually gotten hardware to initialize properly using the APIs lol
<cr1901_modern>
(IIRC Free is similar/uses bus_space_map and friends)
<lain>
lol
<lain>
I couldn't figure out how to install netbsd
<rqou>
netbsd didn't seem to have documentation i could find on how to take their sh4 for dreamcast iso and make it into an "actually boots on a dreamcast" iso
<cr1901_modern>
Ask on the mailing list :P? I've only dealt w/ ARM and x86.
<cr1901_modern>
ARM is as simple as "write the image to an SD card and you're done"
<rqou>
i don't feel like burning a stack of coasters on "hmm, maybe try this?"
<rqou>
maybe some other time
<rqou>
too many projects :P
<cr1901_modern>
rqou: You could prob ask nbjoerg for help in #j-core depending on the mood he's in
<rqou>
well, i don't even have my dreamcast on hand right now :P
<rqou>
it's in the infinite-sized dumping ground of random junk known as my parents' house :P :P
<lain>
lol
<rqou>
alright, i'm going to try to clean my room again
<rqou>
we're on like week 2 now of this sprint :P
<lain>
whee
<rqou>
i should probably get rid of some of my junk
<rqou>
e.g. who wants a d945gsejt? (actually half serious)
<rqou>
at some point i might just make a huge inventory of crap i don't want anymore and see if anyone here wants it
<rqou>
and anything unclaimed will be sent to digshadow for decapping
<rqou>
whitequark: opinions about monoprice power cords?
<lain>
well, nvm, I guess the answer in my case is "simulate it and find out" heh
<rqou>
i know, that's not correct
<rqou>
maybe micron has a simulation model?
<rqou>
i've definitely seen their "ddr.v" "ddr2.v" "ddr3.v" basically everywhere
<lain>
yeah, in this case it's SI simulation but yes, the models for all components involved are at my disposal
<lain>
I'm just lazy
<rqou>
oh i never got a design with dram to the point where i had to do SI simulation
<rqou>
i don't even know of software to do so
<lain>
tl;dr micron and jedec appnote seem to suggest termination is optional on CA, depending on simulation results. intel seems to suggest it's mandatory.
<rqou>
supposedly openEMS can if you can figure out how to set it up
<lain>
I have hyperlynx for this
<rqou>
wow, very $$$
<lain>
it was not cheap :P
<lain>
but I don't have a "full" license either
<lain>
stupid thing has so many features
<rqou>
i asked my father how he used to do SI simulation and his answer was "we didn't" :P
<lain>
I think I have the 2.5D solver for hyperlynx, but without crosstalk and such
<lain>
lol
<rqou>
his designs just had so much timing margin that SI simulation wasn't needed
<lain>
yeah
<rqou>
my father also doesn't trust EDA tools that much (having seen them go from "nonexistent" to "we can (supposedly) do everything!"
<lain>
EDA tools are shit
<rqou>
"if the tool's answer is wrong and our board doesn't work, we're still SOL"
<lain>
haha
<rqou>
i also asked him how he did ERC
<lain>
I mean, I still use them to get pre-layout and post-layout info on tight margins
<lain>
but
<rqou>
the answer was "two engineers and an array of colored highlighters"
<lain>
haha
<lain>
yeah I performed that task at a job where nobody knew how to ERC
<lain>
eventually I taught them
<lain>
minds were blown
<lain>
:P
<rqou>
whee, just found another sd card with yet another ubuntu installer image on it
<rqou>
i swear half of my flash drives/sd cards have ubuntu installers on them
<rqou>
also holy f*** it's 5am
<rqou>
sleep time
<lain>
in theory, the intel soc's CA outputs should be the same impedance as the traces, so any reflection will just end there
<lain>
but intel is recommending I create a Vtt island and terminate all the CA signals to that through 80.6 ohms
<rqou>
yeah, I don't know anything about transmission line effects
<pie_>
hi guys' /Ü/
<pie_>
* ^_^
<pie_>
ugh keyboard layouts
<lain>
hihi
<pie_>
erc?
<lain>
electrical rule check
<pie_>
ah i remembered right then, just couldnt reverse the acronym xD
<pie_>
and was lazy to google :P
<pie_>
so if i ever get around to it, how do you guys figure i should learn the thing to go from "i need amassively paralel search on some specific matrix operations" to a working fpga implementation?
<pie_>
so, how do i learn teh logic design i guess?
<cr1901_modern>
fpga4fun website?
<pie_>
(books are fine too)
* pie_
checks out site
<lain>
okayyy I stopped being lazy and simulated it with an approximation of the final stackup
<nats`>
a recent one I hope old one didn't have 3D/2.5D solver
<lain>
I don't have all the fancy stuff, but yes it's recent, a couple years old now
<lain>
I have the 2.5D solver, but no coupled line (so no diffpair) simulation :(
<lain>
I don't know if I have full 3d, hm.
<lain>
I think so, but not sure
<nats`>
full 3D is not really interesting in pcb sig integrity
<nats`>
it becomes mandatory when you don't have reference plane anymore
<nats`>
like for antenna
<lain>
yeah
<lain>
RF stuff
<lain>
2.5D is fine for my needs :3
<nats`>
yep
<lain>
but I wish I had the coupled line sim, so I can do diffpair
<lain>
but it doesn't matter much
<lain>
I can get by with single-ended sim, crosstalk is handled by just obeying some simple calculations for spacing
<nats`>
I felt in love with SiWave but I don't talk about it anymore in ##fpga or rajkosto starts stalking me to give him a 5minute lesson on how to use it
<lain>
lol
<lain>
that guy.
<lain>
hm.. so lpddr3 spec says max overshoot amplitude is VddCA + 0.35 = 1.55, and max undershoot is -0.35
<lain>
lol, this signal gets very close to that
<lain>
and they state that the maximum area above VddCA is 0.10 V-ns, and max area below Vss is again 0.10 V-ns
<qu1j0t3>
pie_: I don't think it works that way, to be honest. You need to start small and work through increasingly more ambitious projects to get there?
<pie_>
qu1j0t3, well yeah i figure:P
<qu1j0t3>
pie_: Well i'm on the same path, maybe we can compare ntoes.
<qu1j0t3>
pie_: also i have a lot of books and such
<pie_>
still just doing exams righ tnow tho :(
<pie_>
i want to be doing clash already
* pie_
throws a tantrum
<pie_>
:P
<lain>
hmmm yeah I'm violating the over/undershoot specs
<pie_>
i wonder if you could use a down then up -converter
<pie_>
though from ghz -> mhz is probablyalot
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined ##openfpga
<pie_>
oops, things borked
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<pie__>
is there anything for simulating/synthesizing hdl to software targets?
<pie__>
idk how to describe this properly
<pie__>
like...so i can write some code and get a schematic and simulate it, but not actually target real hardware with it
<ZipCPU>
pie_: You can use a down then up converter. There are many advantages to be gained by it, and GHz -> MHz is one reason why you might.
<ZipCPU>
pie__: Not sure how to understand what you wish to accomplish.
<marcus_c_>
pie__: With Icarus you can run simulations of verilog code without any target hw if that's what you mean.
<pie__>
i guess i want to just synthesize to raw logic gates?
<pie__>
its probably ore effective to just simulate the hdl without synthesis but that sounds less fun :P
<ZipCPU>
You can simulate Verilog code in Verilator too ... but that's not the same as simulating transistors, resistors, capacitors, diodes, etc.
<pie__>
and less insight
<pie__>
*more
<qu1j0t3>
pie__: yes, see what marcus_c_ said. And in other environments you can too, e.g. Chisel compiles to C++ for simulation.
<pie__>
ok ok but i do want to actually synthesize to something :P
<pie__>
well, logic
<pie__>
this is for learning not production
<qu1j0t3>
pie__: not sure what you meant by "software targets"
<pie__>
yeah that was not a good way t express it, i want to simulate logic components
<pie__>
so like if i want to play around with stuf while looking at a digital logic book or something
<qu1j0t3>
just start?
pie__ has quit [Quit: Leaving]
<qu1j0t3>
i used Altera Quartus, but I couldn't get ModelSim to work, so i moved to icarus and gtkwave
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
<ZipCPU>
pie__: If you just want to play around with digital components while reading a digital logic book, use Verilator. It won't cost you a dime, and it's sufficiently powerful to synthesize and run even a full blown CPU (.... the ZipCPU)
<digshadow>
rqou: fwiw I have a bunch of relatively high quality junk I'm getting rid of soon
<digshadow>
like a co2 laser engraver
<digshadow>
and some dev boards
<qu1j0t3>
pie_: ooh look dev boards
<pie_>
ooh
<azonenberg>
digshadow: define engraver
<azonenberg>
can it cut thin acrylic sheet?
<azonenberg>
What host software does it use? Is it functional?
<pie_>
no its imperative :(
<pie_>
:P
<digshadow>
azonenberg: its designed for part marking
<pie_>
qu1j0t3, guy mentions pdp11
<digshadow>
someone gave it to me
<digshadow>
never got a chance to use it
<digshadow>
so not how complete it is
<azonenberg>
ah, ok
<azonenberg>
well it would likely not be cost-effective to ship, but i do want one eventually :p
<digshadow>
I was hoping to use it to mark Signetics 25120 chips
<Spida>
azonenberg: wat is starshipraider actually supposed to do?
digshadow has quit [Quit: Leaving.]
Bike has joined ##openfpga
<pie_>
ok i think what i want is synthesis to gate-level netlist and apparently yosys does that
<qu1j0t3>
pie_: Yeah but if you're starting out, any high level simualtion is fine. Like ZipCPU said.
<azonenberg>
Spida: logic analyzer, bus pirate on steroids, etc
<pie_>
qu1j0t3, i guess
<pie_>
qu1j0t3, for that i can just use clash's own internal tool probably
<azonenberg>
rqou: btw my new input protection circuit is clamping properly but i'm worried about capacitance still
<azonenberg>
its higher than i want
<qu1j0t3>
pie_: Just start. A text that I really liked was Wirth's "Digital Logic Circuits for CS undergrads"
<pie_>
though i guess it cant hurt to sim the generated verilog too
<pie_>
qu1j0t3, yeah i thik i have that
<pie_>
qu1j0t3, i actually need to study for my mechanics exam on monday :/
<qu1j0t3>
procrastination ftw!
<pie_>
yeh...
<ZipCPU>
pie_: Using Verilator, I've simulated some very complex FPGA dev-boards---with flash, SDRAM, SD cards, UARTs, and more.
<pie_>
ZipCPU, yeah i will probably use that
<ZipCPU>
Verilator is good/complete enough to allow you to plug in C++ simulations of hardware, that then your logic must interact with.
<azonenberg>
ZipCPU: it can be hard to find sim models for more complex stuff
<azonenberg>
like an ethernet PHY or something
<ZipCPU>
I've even used a simulation of a VGA.
<ZipCPU>
I built the ethernet PHY--wasn't too hard.
<azonenberg>
now thats interesting... rendering to an onscreen frame buffer?
<ZipCPU>
It just turned the whole thing into an echo chamber and such.
<ZipCPU>
"echo chamber" ... sheesh ... turned the network port into a local echo port. That which went out, came back in.
<ZipCPU>
As for the VGA ... pretty much. I built a window using GTK++, verified the sync protocol, and updated pixels on the image as the device wrote them.
<ZipCPU>
It was pretty slow, but worked well.
<ZipCPU>
I recently rebuilt it for an OLEDrgb too.
<pie_>
though i guess code is actually orthogonal at the moment though still something i will want
<pie_>
i want some "hands on" experience with hooking up digital logic blocks and stuff and simulating them
<pie_>
i guess most EDA tools do that? it there something perhaps more educationally directed?
<ZipCPU>
The really cool thing from my standpoint, is that when I actually got my board ... I had everything working within a weekend, and was then scratching my head wondering what to do next.