azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
Patater has joined ##openfpga
DrPatater has quit [Ping timeout: 255 seconds]
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 255 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 255 seconds]
Degi_ is now known as Degi
Patater has quit [Quit: Explodes into a thousand pieces]
Patater has joined ##openfpga
<pie_>
gatecat: ah.
<pie_>
gatecat: well, thats not much better x)
<somlo>
pie_: reading back through the whole conversation, you're probably better off focusing on the HDL (gateware) layer for now. If you have some familiarity with low-level systems programming (e.g., writing (for) an OS), then the next interesting layer underneath that is how a CPU+peripherals do what they do
<somlo>
that's basically writing stuff in Verilog (or some other HDL)
<somlo>
you can "test" (or just straight-up deploy) that on an fpga
<somlo>
and once you're familiar with that, you're ready to "descend" another layer into the transistors and electronics and materials science that go into making actual physical chips
<somlo>
since we're talking about an undergrad thesis (correct me if I misunderstood that), the important thing is to pick something that will force you to learn as much as possible, but most importantly, to avoid overcommitting
<pie_>
somlo: yeah HDL is probably perfectly fine to start
<pie_>
(alt: why not both in parallel, besides general multitasking issues :P)
<somlo>
at my uni, ECE students typically have to do *two* of these things at the time -- take the systems programming sequence *and* the HDL sequence; alternatively, take the HDL sequence and the electronics (transistors and stuff, analog and/or digital integrated circuit design, and tapeopt) sequence
<somlo>
but it's much less fun having to juggle them and switch context :)
<pie_>
mm
<pie_>
i do seem to be trying to concentrate on one thing lately
<pie_>
well, ill keep this in mind in any case, thanks!
<somlo>
one of my favorite quotes is "multitasking is the art of doing twice as much as you should, half as well as you could" :)
<pie_>
x)
<Flea86>
somlo: I like your quote, but I see switching context as a means to give poorly understood subject matter time to absorb mentally :)
<somlo>
Flea86: yours is a very different "threat model" than what that quote is about :D
<Flea86>
lol perhaps
<gurki>
somlo: uh. synthesizing to fpga isnt that different from synthesizing to asic with enough hand-holding
<gurki>
(i still agree with starting with fpgas here :) )
<gurki>
yes, the tools are different, different things to be kept in mind, but ultimately, for the user ...
<gurki>
pnr is where things become tricky
<somlo>
gurki: you're right of course, assuming (rightfully) that as a designer you'll have rather little to do with the actual asic manufacturing phase -- your p&r tool will spit out some mask generated within the specifications of your pdk, and the rest is out of your hands
<somlo>
but particularly since that's the case, it's more rewarding (as a student, developer, whatever) to target an fpga and have much more immediate feedback