moho1 has quit [Ping timeout: 252 seconds]
moho1 has joined ##openfpga
moho1 has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 240 seconds]
moho1 has joined ##openfpga
unixb0y has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
jcarpenter2 has joined ##openfpga
<jcarpenter2> hi, i'm looking forward to use an FPGA to design a processor. Just wondering if you humans have any suggestions on some software to use to simulate and program them.
<azonenberg_work> jcarpenter2: So first off, hope you're not a VHDL fan
<azonenberg_work> Free tooling for vhdl is practically nonexistent
<jcarpenter2> no, i'm very open to the different options
<azonenberg_work> Most of the free tools are verilog with a little bit of systemverilog support (far from complete)
<azonenberg_work> As far as silicon goes, lattice ice40 and ecp5 (?)
<azonenberg_work> are the best supported decently sized parts
<jcarpenter2> cool
<azonenberg_work> there are several tiny parts with good free tools but a cpu would be hard on them
<azonenberg_work> There is active work on the far larger xilinx 7 series parts but it's months from usability at best
<azonenberg_work> maybe closer to a year? i'm not super involved
<azonenberg_work> What kind of stuff did you want to do on it? "a cpu" can mean anything from an attiny to an x86 lol
<azonenberg_work> aka, a $2 fpga or a $20M rack of them :p
<jcarpenter2> not sure tbh, my starting price range is probably up to $2000, but i've only recently come into enough money to start thinking about buying things like these
<azonenberg_work> i've personally worked with FPGAs that cost $0.50 up to $50,000
<azonenberg_work> If you want free tooling, nothing will cost more than a few hundred bucks and probably mid to high tens
<azonenberg_work> None of the large parts have useable free tooling yet
<azonenberg_work> just because they're so much more complex the reverse engineering is very nontrivial
<jcarpenter2> mainly i want a processor that (don't laugh) lets my application memory-map cache lines
<jcarpenter2> very dumb idea
<Bike> cmon mate, have some possibly misplaced confidence.
<Bike> some drive!
<jcarpenter2> ty
<azonenberg_work> jcarpenter2: So, to start, i'd suggest you get a cheap ice40 dev board like the icestick
<jcarpenter2> cool
<azonenberg_work> Play around with yosys for synthesis and icestorm for place-and-route
<azonenberg_work> Don't make a cpu yet
<azonenberg_work> start with an led blinky, then maybe a uart or something
<azonenberg_work> also play around with simulation, there's lots of options
<azonenberg_work> verilator seems popular
<azonenberg_work> Once you have a good grasp of how the tools work, start designing your cpu in simulation
<azonenberg_work> you can do most of the architecture work without touching hardware
<prpplague> "making CPUs is fun!" (TM)(C)
<Bike> the trademark is why nobody actually says that
<azonenberg_work> Then when you have something semi-finished, try synthesizing with yosys for ice40
<azonenberg_work> and get an estimate of how much space it takes up
<azonenberg_work> At which point you can either build it force the icestick, get a larger board
<azonenberg_work> maybe switch to ecp5
<azonenberg_work> for*
<azonenberg_work> But until you have a good feel for how many fpga resources your designs will use, buying complex hardware is a bit of a waste
<jcarpenter2> right
<azonenberg_work> be warned, depending on how complex your designs are you may eventually reach the point (like i have) that your designs don't fit in any chip that has a free toolchain :)
<azonenberg_work> At that point you need to either split it into multiple chips, optimize your code better, or just give up and use the closed-source tools
<azonenberg_work> (and then become a developer of the open tools as a penance :D)
<jcarpenter2> :D
<azonenberg_work> But now that we have some ecp5 support outgrowing the universe of f/oss friendly fpgas is a lot harder
<azonenberg_work> My projects are probably still a bit too big though, the big one on the horizon for me is a 24x 1G + 4x 10G port rack-mount ethernet switch
<azonenberg_work> If you're significantly smaller than that an ecp5 is probably going to be ok
<jcarpenter2> that's a lot of ethernet ports
<azonenberg_work> jcarpenter2: Yes, and a lot of fpga in the switch fabric
<azonenberg_work> Most critically, there is no fpga with 10G transceivers that has a free toolchain right now
<azonenberg_work> The ecp5 can go up to i think 3G or 6G however i don't think anyone has reverse engineered the transceivers yet
<azonenberg_work> so the free tools don't support them
<awygle> 5G
<awygle> it's in the name
<zkms> what's the status of the ECP5 toolchain work
<azonenberg_work> zkms: i think logic fabric is working but not much else
<azonenberg_work> in nextpnr
<azonenberg_work> not even sure if they got to block ram yet
<awygle> logic and basic I/O, no BRAM
<awygle> last i checked
<awygle> so runnable but not complete
<azonenberg_work> jcarpenter2: there you go
<azonenberg_work> thats the state of ecp5 support
<awygle> the infrastructure is in place though, i think adding BRAM support wouldn't be too-too much work
<azonenberg_work> ice40 is basically 100% complete though, as long as you are using one of the supported chips
<awygle> which are the HX, LP, UP, and (mostly) LM families. but not the Ultra or UL.
<azonenberg_work> jcarpenter2: Additionally, we have support for some silego greenpak4 and xilinx coolrunner-2 devices, but not the full line of either
* jcarpenter2 logs this chat
<awygle> those are definitely too small for a cpu though
<azonenberg_work> correct
<azonenberg_work> rqou is doing work on some small altera parts as well, i think he was mostly focusing on bitstream reversing
<azonenberg_work> not sure if he has a useable toolchain for that
<azonenberg_work> then Project X-Ray is the big effort to do the xilinx artix7/kintex7 family
<awygle> about which i have heard zero news in >6 months
<azonenberg_work> Right now they have the logic fabric pretty well understood as well as i think block ram and the basic io features, but none of the fancy ip
<azonenberg_work> awygle: my understanding is that they basically halted bitstream RE work to focus on PAR
<awygle> mine as well
<azonenberg_work> But i dont know how that's going
<azonenberg_work> AIUI the ecp5 support in nextpnr was kind of a PoC
<awygle> i mean, nextpnr exists :p
<azonenberg_work> and they wanted to do 7 series part after that
<azonenberg_work> par*
<azonenberg_work> but i dont know how far along the 7 series nextpnr library is
<awygle> you'd think it'd be as simple as checking the commit log but i guess that group likes to deliver larger chunks of work
<awygle> jcarpenter2: anyway, sort of parallel to yosys, there's Icarus Verilog and Verilator for simulation (also ghdl for vhdl but as stated that's not a good path to OSS support)
<awygle> and gtkwave is what i see used to look at vcd files from the simulators
<azonenberg_work> awygle: you remind me i wanted to add vcd import support and maybe interactive simulator pipe support to my scope client app
<azonenberg_work> So i can view simulator output in it
<rqou> you probably should use lxt2 if possible
<awygle> there's also a bunch of non-verilog non-vhdl HDL projects, of which the only one i know anything about is Migen
<azonenberg_work> jcarpenter2: Additionally, Yosys has decent formal verification support which is a bit advanced for a full newbie but is very helpful when you are trying to make very reliable code
<awygle> it's also lots of fun :p
<azonenberg_work> Basically you can write boolean expressions that should always be true and it tries to prove you wrong
<awygle> rqou: does anything but icarus/gtkwave use lxt2?
<rqou> idk, I've only been using it for icarus/gtkwave
<jcarpenter2> nice, formal verification is helpful if you understand its limitations
<azonenberg_work> jcarpenter2: at which point you get one of three results... search space covered and your proof holds
<rqou> there were some features that vcd didn't have
<azonenberg_work> a counterexample showing your proof is invalid
<azonenberg_work> Or "inconclusive, you didn't want to wait any longer" :p
<rqou> and the docs basically said "use lxt2"
<awygle> jcarpenter2: my recommendation is to get started with Icarus and/or Verilator, then synthesize with Yosys and get something working in hardware, then play with formal. but that's just me.
<azonenberg_work> Yeah agreed
<azonenberg_work> Dont start with formal
<azonenberg_work> But its a good tool to have in the toolbox
<awygle> rqou: yeah there are several much-better-than-vcd formats but they don't seem to be broadly supported so i'm hesitant to use them
<azonenberg_work> As a more experienced designer, i have actually done projects with a formal-first methodology
<azonenberg_work> write the assertions then code until the proof holds
<azonenberg_work> Great way to get really solid code for small IP blocks, but not for a beginner trying to learn everything at once
<awygle> rqou: there's vcd, lxt, lxt2, and fst, of which fst is supposed to be the bestest
<rqou> insert xkcd "standards" here
<awygle> yup
<awygle> but incremental formats (lxt2 and fst) definitely add value
<awygle> i'd probably use one of them if i was writing a new tool. wonder how separable the file format code is in gtkwave and/or iverilog.
<azonenberg_work> awygle: i definitely want the ability to get live updates as the sim runs
<jcarpenter2> awesome
<jcarpenter2> it'll take me years to get to the point where i'm really productive
<jcarpenter2> you never know what you're gonna get on freenode or in any industry, but you guys seem really active and helpful
<awygle> we try :)
<awygle> azonenberg_work: yeah i think you need lxt2 or fst
<awygle> also somebody please give me a single-step button in a simulator
<rqou> awygle: thoughts on labview's "slow down" mode? :P
<awygle> rqou: a better idea than most things in labview
<rqou> heh
* azonenberg_work wonders if he dislikes labview or simulink more
<rqou> hmm, i wonder if i can trigger a whitequark aneurysm by designing/theming a gui toolkit to look like labview? :P
<awygle> tbh labview isn't actually that bad if it stays in its lane
<awygle> except for the "bring all windows to front" behavior
<awygle> which is a war crime
<rqou> imho it's way way too skeuomorphic but still better than current flat design
<rqou> wait what behavior?
<TD-Linux> gotta love that timeless win16 drawing code (especially for the block diagram)
<awygle> rqou: labview has a "front panel" and a backend where you do the actual work, right?
<rqou> yeah?
<awygle> whenever you click either of them, both of them come to the front
<rqou> huh
<rqou> i never noticed that
<awygle> making it _hugely frustrating_ to reference documentation or whatever
<rqou> i wonder if it's a holdover from when it was a (classic) mac program
<awygle> this is true of _all_ labview windows too
<awygle> so if you have more than one instance open or more than one of the backend canvases (the name of which i can't recall)
<awygle> all of _those_ also come to the front
<rqou> hmm yeah, sounds like a holdover from the classic mac days
<awygle> it's *infuriating*. i'm still mad about it and i haven't used labview since 2013
<awygle> maybe even 2012
<TD-Linux> I'm pretty sure labview was always windows and not mac
<rqou> blame apple and their absolute clustefuck of an OS :P
<rqou> it was _definitely_ a mac app at one point
<TD-Linux> wow I'm totally wrong
<TD-Linux> started on macintosh
<rqou> yeah
digshadow has joined ##openfpga
<jcarpenter2> i used labview for FIRST robotics in high school
<rqou> heh another FRC alum
<TD-Linux> so did I, they switched the last year
<jcarpenter2> surprise
<rqou> (i'm actually never did FRC but i knew a lot of people who did)
<TD-Linux> vxworks and labview on a ppc potato
<TD-Linux> with a fpga for no reason
<TD-Linux> still mad
<rqou> not a microblaze potato?
<jcarpenter2> it was fine, but very slow on the laptop we had, the one that came with the FRC package
<TD-Linux> oh yeah that netbook
<rqou> also, i thought the fpga was accessible for programming? (with labview fpga, not traditional HDL)
<TD-Linux> it wasn't when I did it. it basically implemented some servo PWM channels
<rqou> hmm
<rqou> well, pretty sure it was accessible with the internal toolchain :P
<rqou> (i did an internship at NI)
<TD-Linux> yeah probably. the FRC package abstracted away some things
<rqou> yeah i've never actually used the FRC package
<awygle> i did IT for our FRC group in high school
<TD-Linux> it was also super buggy. it really made me wish for an arduino :(
<awygle> i played with a Parrot drone using labview in college though
<awygle> which was actually pretty fun
<rqou> hmm, the (again, internal) tools were ok when i used them
<rqou> except the tool that searches for and configures hardware devices on the local subnet
<rqou> that tool was universally regarded as being awful and slow
<TD-Linux> yeah everything worked over ip but it was quite buggy
<TD-Linux> it took forever to upload your package to vxworks over ipo
<rqou> heh yeah
<rqou> internally we loaded a backdoor ftp module to load things :P
<TD-Linux> and then it was easy to break the system with a bad program
<TD-Linux> it was also really hard to attach a debugger, and you didn't have a filesystem
<rqou> btw you know what's even more fun?
<rqou> you know that terrible uploading tool?
<rqou> imagine what happens when you're at NI on one of the "dev" subnets with like a hundred devices attached
<TD-Linux> lel
<TD-Linux> I wish they at least had the decency to stick a dhcp server in the frc package or something
<TD-Linux> I later strapped an openwrt box to it which gave out dhcp in the same subnet as the ni box, that at least made it easier
<rqou> hmm i always got the impression that the FRC package was well supported
<rqou> i guess not :P
<TD-Linux> it's probably better now
<TD-Linux> also part of the butthurt is knowing that the box was $8k
<rqou> oh i never knew what the prices were on anything :P
<jcarpenter2> nice
<TD-Linux> weirds me out that migen platforms don't have pin directions
<awygle> migen platforms existing still kind of weirds me out. i now realize there's no very good reason for that, it just seems wrong.
<awygle> i'll get over it
Bike has quit [Quit: Lost terminal]
<TD-Linux> well, migen has hierarchical buses and pcfs are flat, so you need something
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
mumptai has joined ##openfpga
_whitelogger has joined ##openfpga
mumptai has quit [Remote host closed the connection]
<travis-ci> whitequark/Glasgow#47 (master - 5ec5f97 : whitequark): The build passed.
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
kuldeep has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Quit: Leaving.]
kuldeep has joined ##openfpga
rohitksingh has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
m_t has joined ##openfpga
Bike has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
Mimoja has quit [Remote host closed the connection]
Mimoja has joined ##openfpga
Mimoja has quit [Client Quit]
Mimoja has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
kuldeep has joined ##openfpga
Miyu has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
rohitksingh has joined ##openfpga
<felix_> TD-Linux: i'd advise against using most of the footprints that come with kicad; especially the qfn ones are often rather bad, some have big non segmented central pads... oh and i should try to get my partial rewrite of the qfn footprint generator into kicad upstream; that adds some features and fixes a few sort-of bugs
<gruetzkopf> mmh, solder-blob-generators
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
mumptai has joined ##openfpga
m_t has quit [Read error: Connection reset by peer]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
genii has joined ##openfpga
emeb has quit [Ping timeout: 252 seconds]
emeb has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
ym has joined ##openfpga
ym has quit [Client Quit]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
emeb has quit [Quit: Leaving.]
rohitksingh has quit [Quit: Leaving.]
<TD-Linux> felix_, please do! I haven't done enough qfns to really realize when the footprint is causing me trouble
<whitequark> hot take: qfns just suck
<whitequark> qfps suck badly
<whitequark> azonenberg_work: what does it say about me that i'm gonna reball my first bga chip before ever soldering one properly
m_t has joined ##openfpga
<awygle> sign me up for QFNs are bad
<whitequark> awygle: quick, replace all packages on glasgow with wlcsps
<awygle> on it
<whitequark> lol
<whitequark> isn't even the FX2 in BGA package a few dollars more expensive than the QFN?
<whitequark> oh no
<whitequark> it is in fact marginally cheaper
<whitequark> daveshah: Info: 6.3 6.3 Net $PACKER_VCC_NET budget 2.777000 ns (11,1) -> (12,31)
<whitequark> Info: Sink $gbuf_$PACKER_VCC_NET_$glb_clk.USER_SIGNAL_TO_GLOBAL_BUFFER
<awygle> yes, we discussed this wrt Rev c iirc
<whitequark> daveshah: this is a net for 1'b1 that goes into an instance, right? why is it even on critical path?
<whitequark> and that makes the design appear slower by a whole 5 MHz
<azonenberg_work> whitequark: yeah the limiting factor is likely to be pcb costs
<azonenberg_work> finer vias etc
azonenberg_work has quit [Ping timeout: 240 seconds]
<Prf_Jakob> awygle: Was the SODIMM stuff I sent you useful?
<awygle> Prf_Jakob: very! thanks again :-)
azonenberg_work has joined ##openfpga
<Prf_Jakob> awygle: Cool looking forward to how it all turns out :)
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master:
<openfpga-github> Glasgow/master cfef37d whitequark: Configure access for port AB by default....
<openfpga-github> Glasgow/master 53dc4ec whitequark: applet.spi.flash_25c: minor UI fixes.
<openfpga-github> Glasgow/master 65002cf whitequark: cli: implement `build -t zip`, for submitting bug reports easier.
<travis-ci> whitequark/Glasgow#48 (master - 65002cf : whitequark): The build passed.
genii has quit [Remote host closed the connection]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
m_t has quit [Read error: Connection reset by peer]
<awygle> Prf_Jakob: btw i appreciate the addition of the CC0 license, which seems to be ~contemporaneous with you sending me the link :) i was going to ask and then i hit refresh and realized i didn't need to
<zkms> for FPGA dev I know that more RAM is better, but would going from 32GB to 64GB in a machine make a significant difference?
<awygle> i don't actually know but presumably it depends on the size of the device. i routinely run 85klut ECP5 P&R in 16GB of RAM so that's some kind of ceiling (floor? data point.)
<awygle> meanwhile azonenberg_work has god's own workstation (128GB i think?) but he's doing Virtex UltraPlus stuff and frankly tends towards overkill anyway
<azonenberg_work> awygle: 192
<azonenberg_work> lol
<azonenberg_work> And i didnt pay for it :P
<awygle> ew, non-power-of-two
<azonenberg_work> awygle: six channel ram
<awygle> get behind me satan
<azonenberg_work> they tried to build it with 256 and i told them to take out some of the dimms
<awygle> you told them to take them out and ship them to me instead, right?
<azonenberg_work> Lol :p
<azonenberg_work> hate to say it, but if you want to optimize for max ram IOPS on a xeon scalable
<azonenberg_work> you need non PoT memory
<azonenberg_work> the mobo has two slots on every channel except one has four
<awygle> my poor desktop is RAM starved atm because DDR4 is bananas expensive lately
<azonenberg_work> to be fair, my personal system has 32GB
<azonenberg_work> of DDR3
<zkms> hmm ok so 32GB isn't unbearable for FPGA work?
<azonenberg_work> zkms: 32G is plenty for artix7 and smaller kintex parts for sure
<awygle> so i have 8GB of slow (2400) RAM in my desktop and 32GB (also slow 2400) in my laptop
<Prf_Jakob> awygle: Yeah I realized that I didn't have a license or readme so quickly slapped the cc0 license on it.
<azonenberg_work> i've used up to ~90 GB of ram on the big workstation when having multiple vivado instances active on virtex ultrascale+ designs
<azonenberg_work> Havent gone close to maxing it out, the 192 was probably overkill
* zkms nods
<awygle> so, if you're not doing ultrascale, or you're not running multiple P&R runs simultaneously, 32GB is probably fine lol
<zkms> i definitely won't be running multiple P&R runs simultaneously
<azonenberg_work> Yeah we built this rig specifically to build 2-4 xcvu9p bitstreams at once
<azonenberg_work> So dual socket xeons with a buttload of ram
<zkms> i was asking because i have a i7-8086k and i was trying to decide between getting a mini-itx motherboard or a micro-atx one and the former is very smol but only can have two sticks of DDR4 and the latter can have four
<azonenberg_work> I can do multiple artix builds on my personal desktop
<azonenberg_work> with an i5 4xxx i think
<azonenberg_work> and 32GB DDR3
<awygle> i have a micro-atx because i needed room for a real graphics card
<azonenberg_work> awygle: to give you an idea of the overkill i can play minecraft on that workstation with no perceptible fps loss while running a big rtl simulation and a P&R simultaneously
<azonenberg_work> (in 4k)
* awygle nods and smiles, assuming minecraft is demanding based on context
<azonenberg_work> awygle: its more, the sim + P&R doesnt load it down enough framerate drops whatsoever
<awygle> yeah that's a lot
<azonenberg_work> and looking at the CPU load in the taskbar i had ample headrom
<azonenberg_work> the only thing i've found that will max it out is a "make -j"
<awygle> i have been thinking about getting my first Real Server
<sorear> so i'm now looking to acquire, for mostly separate but potentially some joint purposes, a sbc and a fpga board
<zkms> so 32GB in a mini-itx board should be fine for FPGA stuff if i'm not running multiple instances of vivado at once right?
<azonenberg_work> awygle: do it :)
<awygle> zkms: sgtm
<azonenberg_work> awygle: over the past years i've been moving more and more toward the headless server for heavy lifting + thin client model
<azonenberg_work> I'm gonna have little odroids or something scattered all over the lab
<awygle> azonenberg_work: i don't spend money on things without real use cases and i'm not convinced i have one for a server yet
<azonenberg_work> then either run stuff locally or rdp/vnc/ssh to a server that does the heavy lifting
<awygle> but maybe i'll get one after christmas
<awygle> sorear: cool! which ones?
<azonenberg_work> awygle: well given my lab i want to have multiple decent computers scattered around
<azonenberg_work> the alternative is to have one decent computer and a bunch of thin clients
<azonenberg_work> Which costs less
<azonenberg_work> i dont know what your setup at home looks like
* zkms nods
<azonenberg_work> In my case i wanted to have a workstation in the office for, well, office stuff
<azonenberg_work> as my main computer
<zkms> oh also does anyone have motherboard recommendations for something that can take an i7 and is in mini-itx form?
<azonenberg_work> then something on the soldering bench for looking at my pcb design as i assemble/debug it
<azonenberg_work> something on the microscopy bench for running the cameras and CNC x-y stage
Miyu has quit [Ping timeout: 246 seconds]
<azonenberg_work> Something in the SAR room for inventory management and browsing manuals and stuff
<sorear> awygle: that's the question
<sorear> awygle: i don't have an electronics lab or ~any equipment besides a laptop, so shapr's offer of a used beaglewire is right out
<azonenberg_work> oh and i also wanted to have a little SBC on/attached to the server rack for use as a crash cart ssh client
<felix_> TD-Linux: upstreaming the patches for the qfn footprint generator is on my todo list, but there's more important and urgent stuff on it at the moment. ok and i have to split the patch into several patches that each do one thing
<sorear> probably eventually i'm going to have a pile of SBCs and peripheral equipment that can be hooked up to boards, (and even longer term a lab space), but i'd like to start small
<awygle> sorear: do you have some idea of what you're looking for? in terms of requirements, i mean
<awygle> happy to make suggestions if i can
<felix_> TD-Linux: the solder paste on the center pad should be segmented, so you don't have too much solder paste on that pad, but still get a rather evenly distribution of the paste
<awygle> 50-70% coverage typically recommended
<awygle> and i note that the kicad requirements specify such and i've had footprints kicked back multiple times for non-ideal belly pad stencil