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.
<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
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?
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