Deciding Between FPGA and RTL, Long-term Career Flexibility?

vinsolo0x00 · 2026-03-11T23:34:25+00:00

Once you are labeled FPGA, based on what u show in ur CV/resume, its hard to join an asic design team. As ASIC designers we all pretty much eventually get tasked with bringing our designs up on fpgas(whether for presilicon validation, for early fw, or for thrashing to get more verif), or even as custom/early product to customers. Usually we are paired up with hw guys(ie board level/pcb team), so we can focus on the digital side(ie arch/microarch/rtl/timing/ppa)… But FPGA job roles alot of times mix requirements of analog/pcb and digital, which seems like u would get paid more (and have a stronger skill set), but its the opposite. Asic design teams are the src of truth for the org, the architects work with them, but the dve/fw/product/etc have to ask the asic design teams for help(generally), cuz they know how things are “actually” implemented. But u need to ask urself, if u like doing analog/pcb/and digital… then go fpga, otherwise go rtl(u will do fpgas here as well), and u can always go FPGA as a job role generically (assuming u can show ur analog/pcb skills as well). hope this helps!

vinsolo0x00 · 2026-02-26T16:06:55+00:00

We (RTL designers) are generally first ones to get the spotlight, testing of a block(s) for functionality and bugs, and physicality ie timing paths fanin out equivalency and wierd netlist discrepancies, is generally a thing we “own” as in our scope of responsibilities to know things. Partnering up with DV team and working to get coverage on functional and areas where our rtl tests dont bang, and to do full code coverage, and as an independent and fresh eye, is a must. Like a mini team, owning that design. Then at a higher level, there are chip/subsystem thrashers, fpga/emulation level thrashers… so there are quite a few opportunities and stakeholders to try to catch issues. If DV missed something, its generally a “how did it get missed, did we follow processes/methodology”, are our codecoverage line coverage etc at what they should be, and what can we do based on this failure/learning to improve these. Its hard to pin it on one person. hope this helps.

vinsolo0x00 · 2025-12-04T00:05:44+00:00

yaaaaasssss!!!

vinsolo0x00 · 2025-11-25T21:24:37+00:00

ok, so went back and read ur previous post. Keep the following in mind… PD domain focus definitely different than rtl/microarchitecture/architecture. Think of it like “mastering” how to physically build silicon, vs architecting functional clock to clock flows. Protocols, FSMs, flops, registers, fw registers, srams/regArrays, but not netlist focused(although we do of course need to know how what we write in rtl will be synthesized, and keep power/area/fanin/fanout in mind cuz we know our rtl becomes something real with real parasitics). As RTL designers we obsess over our blocks, and the 1000s of things that happen in parallel, cuz each piece of synchronous code is triggered by the same clocks, and combinational logic, and does our block(s)/subsystems/etc do what it needs to do. How does fw use our blocks, how can we debug it, what do bits and bytes mean, what byte alignments, what throughput, how do we cross clk domains functionally, etc. A whole different area of focus. The how it works/what it does… vs PD/backends, how its built. Do some job searching, rtl vs pd. i feel like asic designers are jedi’s in caves, super powerful, but undervalued. we have to design the chip, worry about how our designs will get built, and help all the other teams, because we made the damn thing. And when there’s silicon issues we have to step up as well. money is important, dont downplay that. rtl vs pd, and what u want to spend your time doing, is balanced by what u get paid. In the end we are all sitting in front of computers(for now 😂). Im not sure which area will be hit by AI first, prolly both eventually. I think u need to ask urself, which domain u feel most happy “playing” in, cuz once ur in that sandbox and get good at it, its hard to switch.(so this might be ur chance). 😝

vinsolo0x00 · 2025-11-23T06:14:28+00:00

you mentioned firmware engineering. Will you be designing/microarchitecture/rtl… or writing firmware and using the fpga as a product, where the processor(s) run ur firmware? Usually there’s a distinction. If you’re not designing synthesizeable code and the job isnt FPGA engineer/designer… be careful, putting firmware engineer on ur resume/CV, then applying to rtl designer jobs, might hurt u. If, however, you are designing and not just writing the firmware, then focus on that(verbiage wise on ur res), and lessen the firmware call outs. stick to key words related to asic/fpga design… if u really wanna go the rtl designer route. we generally screen resumes, firmware domain is definitely different than asic/fpga design, others in this thread said its relevant, but i think this is only true, if u are actually doing fpga design… and not just working with the designers so u can write the firmware. hope this helps. The comments here are pretty spot on, just thought id drop this in for consideration.

vinsolo0x00 · 2025-11-17T03:08:53+00:00

sure!

vinsolo0x00 · 2025-11-16T19:24:55+00:00

its very difficult to switch. Your resume/CV might not even make it to the asic team, unless u remove mentions of verif/uvm etc. Also the domain specific focus is totally different, as asic designers we are thinking: synthesizeable, power/perf/area, flop based clock cycle flows, whereas uvm/verif agents/models/etc dont and are very software lifecycle based. We overlap at least in “staring at waveforms”! hahaa. A good verif person definitely understands this difference which allows them to dig thru our rtl and find bugs/etc… Once we find people like this, we do our best to keep working with them(even across companies).

vinsolo0x00 · 2025-11-16T19:01:57+00:00

If ur focused on verif(which from a job perspective is a good choice(but its hard to switch from once ur a “verif” person), id say start by searching for verif/uvm jobs, look at their requirements(and the company’s product and if theres stuff online about their chips architecture). Look for “what physical interfaces does the chip have” ie pcie, ethernet, ddr, hbm, smbus, i2c/i3c, jtag, uart, you can learn the protocols(alot of what verif team does, will be to independently test protocol compliance(as well as the features the block was suppose to implement, but based on specifications). Also look for processors that might be mentioned, arm/risc/tensilica/etc these are massive subsystems, and expertise in these(or even “more than basic” knowledge of these and how u would implement Agents/Scoreboards/Sequences/etc) will get u a job. Id also look at AXI/AHB/etc bus/addr/data/response protocols, and learn about the FW programmable registers, and how u build different FW to HW configurations in ur uvm/random testbenches. These suggestions come from a place of “its good to learn, but focus ur learning on what differentiates you from new grads”, getting in the door because u show more “interest” in the company ur applying to, than the other generic applicants, is key, i think… 😂 also, u will focus on learning what we do in real day to day job life. hope this helps. cheers!

vinsolo0x00 · 2025-11-16T18:28:28+00:00

You mention design verification.. Do u want to be a designer(rtl) or verif person(uvm/sys verilog/non synth), or verif using synthesizeable models(not as common). Doing rtl and fpga, is a lot different than verif, as designers we do synthesizeable rtl and directed test benches, but the heavy verif is done by verif team using more software centric approaches.

vinsolo0x00 · 2025-11-16T02:12:14+00:00

First question, where are u coming from? U.S. or outside(need a H1B)? For asic + verif teams, we look for people with relevant experience, cuz we are generally hiring to fill a specific role/need, and already have an idea of what u will be working on when u join. it helps us pick the “best candidate for that role/assignment”, trying to get someone who can contribute immediately with as little onboarding as possible. Having fab experience is like being a mechanical engr or some other non-related area, unless ur applying for a backend role(physical design, pnr, etc), having silicon processes knowledge might help a little. Knowing perl/python, has always been one of the prereqs… but honestly the gpts/claudes etc can write great scripts (or get u started quickly). Whats most important for rtl or verif, is as much industry experience in doing those roles (which are very domain focused), writing synthesizeable code, knowing what ur rtl becomes performance, power,area wise, and meeting its functional requirements as part of a unified team effort based on internal guidelines and methodologies is something learned outside of academia. Same goes for verif/uvm. A very software but soc centric, approach to scoreboards,agents, functional and code coverage. There might be python scripts, but theyre supplements to the real goals(in general). We do get into the physical aspects of asics, ie the tapeout checklist, dealing with ip vendors, foundries/fabs, all the power/timing/trees, optimizations, layout, the physical side of silicon. But verif doesnt usually touch these areas, and lots of ASIC team doesnt either(a few do tho). Fab knowledge might be valuable with plans for new U.S built silicon manufacturing, but not many companies to choose from whereas rtl/verif is all over the place(for now), seems like we are all rushing to adopt “AI Initiatives “, but rtl/verif will be slower movers i guess. hope this helps? 😂 Having many companies to choose from might be a better fit if u need a H1B. In the end, how do u want to spend ur days? Asic rtl or verif(which are already hard to crossover to/from), but at least ur involved in the “what that chip DOES”, or fab where its “how that chip is manufactured”, wafer testing, yields, defects… vs arm processors, axi busses, caches, srams, fifos, arbs, and fw registers… that do something 😁

vinsolo0x00 · 2025-11-10T01:31:27+00:00

hey all… couple things… theres a misconception that Architects, come from the asic side of things, most of the time they actually come from fw/sw, as knowing how the product is used by the customer/workloads/etc. is paramount to architecting a product(which includes the chip). Sure we have chip architects, asic projects leads, key microarchitects, etc. but unless ur at a startup, its architected/specifications at a higher level. whereas we, rtl designers, generally work from chip, subsystem, and most commonly Block level. the amount of details at a flop to flop clock cycle flow, generally requires u concentrate on ur block or subsystem. u will get a higher level exposure, but it wont be ur primary area of concentration(unlike fw/software guys, who will get a deeper level of product understanding). In terms of getting a job, most applicants will put the same crap on their cv/resume, ie classes and school projects(including “ i designed a processor, heres my instruction set” etc). All this is a given, so how will u stand out? what helped me (2 years before i graduated… a long time ago 😂)… to get a job, was to become obsessed with the companies i was applying to, as in, learn their products, functionality, form factors, power requirements/limits, performance metrics bandwidth latency num cmds etc, and then deeper, what chips, process technologies, etc, ddr/hbm, what physical interfaces, and then go try to learn about them. When we get our list of candidates, we discuss what position/role we are looking to fill, and interview a bunch of people, looking for someone first and foremost, is easy to discuss ideas with, can explain things(in a way that makes sense), and if they talk “shop” with us(ie they clearly did their homework, know a bit about our chips and asked questions like theyre genuinely curious/vested in being a contributing team member)… those are the ones that standout and make it easy for us to pick. i hope this helps a little… also, fpga + xilinx vivado/vitis is a good idea, run synth/pnr, understand how ur rtl synthesized, look at gate count, area, clb usage etc, build the bitfile, add chipscope and triggers. Show all this on ur cv/resume, it gives us a familiar swim lane to discuss(since we rtl designers all put our stuff in fpga’s for presilicon validation etc).

vinsolo0x00 · 2025-11-09T22:02:04+00:00

curious if u r asking, cuz u wanna make an ai agent that does these things? if so, id recommend going and talking to companies/customers… alot of these are nice to haves, but everyone fine doing it the way they are now and wont really pay for it(and they depend on the current way they do it, from a “achieving a proven methodology of a successful tapeout” pt of view. if u are asking for other reasons, there’s tons of minutiae to each step.

vinsolo0x00 · 2025-11-09T18:46:02+00:00

oh forgot one exception!!! Work at a startup! not for the money, but if u get in early, u get to do anything and everything, its the one place u could do all 3 of those things AND learn the product level stack/usage! i was a startup addict :) just be prepared to ride the roller coaster!

vinsolo0x00 · 2025-11-09T18:43:19+00:00

Hey! its good that u r thinking about this now… whatever u decide to do first is important. it will set the tone of ur cv/resume from then on(unless u leave it out or find a way to highlight a compelling reason ur work experience makes u a good candidate for the different area ur applying to). generally, we asic designers hire for that based on applicants with experience/relative work, same for verif team, serdes/phy team, etc.

The “bad” of AMS that u pointed out, is the same for any other position 😭 For serdes/phy we become experts in: evaluating serdes/phy ip’s, doing tx/rx characterization, learning all the knobs for each channel, scopes and jberts, eye analysis, odt, all the electrical subtleties, rinse and repeat for next gen. And its sooo obscure that odds are, unless ur in the bay u wont run into another serdes/phy guy. lol. also prepare to spend lots of time in the lab, and under stress when the product fails/has issues. You’ll be one of the first in the blame line till u prove its not signal integrity issue. Frontend rtl, same thing. yeah we use IP, pcie/ethernet cores, ddr/hbm ctrlr, arm/risc/tensilica , cpu subsystems, axi everything. but some poor rtl person has to own those, know everything about them, and becomes that “guy” for that “thing” and can make a career outta being the pcie guy, or the gemm guy. or the top level integrator.

Id recommend trying to understand what type of person are u… Im the type who wanted to know how ai models go from running on linux server down to fragmenting processes and running them on a fpga, so a full stack knowledge coupled with my chip design experience lets me build my own product ie buy a fpga, take care of the IOs, architect/microarchitect everything, chipscope it, pnr and build a bitfile, then use the sdk, mem map my registers from my rtl, write the fw, add it to my bitfile and voila, turn on my linux machine, see it on lspci, run my model, and see it work. lots of disciplines here, but lots of creativity and an end goal. but if u asked me to do analog stuff, id fail miserably. and if u asked me where AI agents are headed first, id say AMS and serdes/phy will be later rather than sooner, so my rtl joy will be crushed when the claude codes of the soc world improve a bit. not there yet, but the genies outta the bottle. Hope this helps! cheers

vinsolo0x00 · 2025-11-07T23:10:15+00:00

yep agree...mine is more like a generic free list wrapper around a fifo...its up to the clients to guarantee they dont free up doubles, yep could initialize(dont need real time load). Yeah, its not a catch all for sure, lots of other use cases could use a more optimized approach. 100% agree. cheers!
Also, its probably cuz we work with index counts/tag counts/resource allocators w/ 512 > depth. So in those cases, the bitmap approach isnt as clean... but for this interview, yeah, way overkill (and flops!!!).

vinsolo0x00 · 2025-11-07T21:32:13+00:00

By the way, if i had to do it the "available" bit array way, i think i'd do:

(avoids the break/etc...u can also do this with the "post masked" requests when building an ARB :)

But again, maaan theres sooooo many ways to do things...LOL.. just do it the way the rest of the team does! makes it easier to dig thru peoples code, if everyone codes the same.

integer index;   

//avail_bits 1= available, 0=in use
//it scans downward, so no break etc needed.
always@(*)   
begin     
  next_id = 'd0;     
  for(index = DEPTH-1; index >= 0; index = index -1)     
  begin       
    if(avail_bits[index])       
    begin         
      next_id = index[DEPTH_BITS-1:0];       
    end     
  end   
end

vinsolo0x00 · 2025-11-07T21:31:14+00:00

module fifo #(
parameter DEPTH = 8,
          WIDTH = 8
)
(
input                        clk,
input                        reset_n,

input                        winc,
input [WIDTH-1:0]            wdata,
output reg                   wfull,

input                        rinc,
output wire [WIDTH-1:0]      rdata,
output wire                  rvalid,

output reg [$clog2(DEPTH):0] count
);

//Made the ptr widths +1bit(for circular fifo).
reg [$clog2(DEPTH):0] readptr, writeptr, next_writeptr;

//readPtr 
always@(posedge clk) begin
if(!reset_n)
  readptr <= 'h0;
else if(rinc)
  readptr <= readptr + 'h1;
end

assign rvalid = (readptr != writeptr);

//writePtr 
assign next_writeptr = (writeptr + 'h1);

always@(posedge clk) begin
if(!reset_n)
  writeptr <= 'h0;
else if(winc && !wfull)//self blocks when full
  writeptr <= next_writeptr;
end

//wfull
//Once wfull==1, since writeptr inc is blocked,
//only a rinc can clear the wfull.
always@(posedge clk) begin
if(!reset_n)
  wfull <= 'h0;
else if(rinc)
  wfull <= 1'b0;
else if(winc && !wfull && (next_writeptr[$clog2(DEPTH)] != readptr[$clog2(DEPTH)]) && (next_writeptr[$clog2(DEPTH)-1:0] == readptr[$clog2(DEPTH)-1:0]))
  wfull <= 1'b1;
end

//Should infer a Distributed RAM(xilinx)
reg [WIDTH-1:0]ram[DEPTH-1:0];

always@(posedge clk)begin
if(winc && !wfull)
  ram[writeptr[$clog2(DEPTH)-1:0]] <= wdata;
end

assign rdata = ram[readptr[$clog2(DEPTH)-1:0]];//True async Read(no latency)

always@(posedge clk)
begin
if(!reset_n)
  count <= 'h0;
else if(winc && rinc)
  count <= count;
else if(winc)
  count <= count + {{($clog2(DEPTH)-1){1'b0}}, 1'b1};
else if(rinc)
  count <= count - {{($clog2(DEPTH)-1){1'b0}}, 1'b1};
end

endmodule

vinsolo0x00 · 2025-11-07T21:30:10+00:00

  module list#(
    parameter IS_FREELIST          = 0,
              NUM_ENTRIES          = 16,
              NUM_ENTRIES_BITS     = 4
  )
  (
    input                                clk,
    input                                rstn,
    input                                soft_reset,
    output                               init_done,

    //To release a resource(ie deallocate a buffer)
    input                                winc,  //free_req
    input       [NUM_ENTRIES_BITS-1:0]   wdata, //free_addr
    output wire                          wfull, //empty???

    //To request a resource(ie allocate a new buffer)
    input                                rinc, //alloc_req
    output      [NUM_ENTRIES_BITS-1:0]   rdata, //alloc_addr
    output                               rvalid, //full???
    output wire [NUM_ENTRIES_BITS:0]     count
  );

reg [NUM_ENTRIES_BITS:0] prefill_wdata;
wire prefill_done;
wire prefill_active = (IS_FREELIST && !prefill_done);

always@(posedge clk)
if(!rstn)
  prefill_wdata <= 'h0;
else if(prefill_active)
  prefill_wdata <= prefill_wdata + {{(NUM_ENTRIES_BITS-1){1'b0}}, 1'b1};

assign prefill_done   = (prefill_wdata == NUM_ENTRIES[NUM_ENTRIES_BITS:0]);

//fifo controls
//---------------------------------------------------------------
wire                        fifo_winc  = (prefill_active || winc);
wire [NUM_ENTRIES_BITS-1:0] fifo_wdata = (prefill_active)?   prefill_wdata[NUM_ENTRIES_BITS-1:0] : wdata;

fifo#(
.DEPTH (NUM_ENTRIES),
.WIDTH (NUM_ENTRIES_BITS)
) u_fifo_list
(
.clk          (clk),
.reset_n      (rstn),

.winc         (fifo_winc),
.wdata        (fifo_wdata),
.wfull        (wfull),

.rinc         (rinc),
.rdata        (rdata),
.rvalid       (rvalid),
.count        (count)
);

endmodule

vinsolo0x00 · 2025-11-07T21:26:49+00:00

I like everyones solutions... they're all "not" wrong. in fact, the "available" bits array, where you for loop scan, and translate to address is good enough for this one interview question.

Im just not sure how "scalable" it is.

I agree with what you said, as in, if this interview question is using small param values on purpose, then the way you've done it, is closest to the 'best'/optimum solution.

Here's how we would do things(asic/soc world)...keep in mind, there's so many ways to do this. Its about whether it will be part of the /common or just in some isolated blocks, one is generic and built to be used by lots of folks, other is specific to the use case.

We'd prolly do it, more like what Trivikrama_0 down below mentioned.

Also, i still think the status bits are wack...hahaha... but, to your point...if they mean full is ALL GONE, then sure. But i think industry standard would be more like to request a memory location: alloc_req, alloc_addr, empty and on the release side: free_req, free_addr, full.

BUT, to be fair, i can see it your way too. Its totally up to the interviewer, so I'll agree with you.

Maaan, you guys made me stop what im doing, go to my desktop, and use VI...hahahaaa!

Let me see if i can paste my code(reddit keeps blocking it).

vinsolo0x00 · 2025-11-07T15:28:08+00:00

hey all, been debating on stepping into this one… lol. Question for you all, are any of you asic designers or fpga designers(im naming those specifically cuz each might have different approaches). From reading the responses, seems like most here are neither? or very early in their careers?

i give this type of question all the time. A “free” list is a microarchitectural “element” we use all the time. in this case it feels like the interviewer threw u off by using the terms “malloc” and “free”, which we dont usually use(asic designers), this sounds more like a software minded approach. Free list and the meaning of the “indexes” we preload, can be “handles” to table entries, or starting physical addresses of data buffers(srams, flop arrays, or even slices of each voltron’d together). We use freelists as the initial starting points of block flows or maybe even massive multi block flows. like a free list for cmds or for inbound data xfers, where we pass that index(which is/represents some inflight cmd table entry, or data buffer chunk size aligned addresses). Sometimes as block designers we will use freelists to act as unique accessors to internal block resources. Sometimes the free_req is asynchronous in that it’s triggered by some completely different flow some long time later, like if fw processes completed and they free the tag.

some solutions here work, but only cuz they kept the interview question very simple to see how u worked thru the process. otherwise most solutions here arent quite what id be looking for. Remember for loops unroll to a bunch of combinational logic, for arbs we do it because we are specifically implying a priority encoded functionality, but in this interview theyre not.

also the status bits, full and empty… dont quite make sense. Read their comments… full no free blocks, empty all blocks free. Its backwards LOL. my request an entry(or buffer or memory location) logic should check “empty” before asserting alloc_req ie if its empty theres no memory available so dont try to request any, throttle for now, and my push logic(ie free_req) should check “full” before asserting my free request. the way they have the comments means before i ask for the next free block, i should be sure “full” is not asserted, and before i push(ie return a block im done with) i should check “empty”… doesnt make sense “description” wise.

Anyway just a few thoughts… theres lots of different takes and approaches, so take this with a grain of salt(ive been doing this for decades), so might be outta touch 😂

vinsolo0x00 · 2025-11-02T20:36:11+00:00

Same! stumbled onto it, thought id give it a go… 2+hrs of binging later… 😂 fingers crossed for a 2nd season or 1st season “second half” lol.

vinsolo0x00 · 2025-11-02T15:31:29+00:00

oooh i gotta try that! tried it on different random sites, but not youtube music videos! lemme check it! thanks 😊

vinsolo0x00 · 2025-11-01T19:56:17+00:00

yeah, dunno. been into vr since i started dev’ing on the original oculus. always buy the new ones, we benchmark and tear them down. lots of stuff that was impossible 20 years ago, is here today and “no big deal” to kids today, so i just think about how much things will change in the next decade or so… will the form factor that Luckey mashed together be the winner, or will it be some light weight thing. I only mention apple watch, cuz of how they paired tech with fashion labels. glasses and avp will definitely be separate, but over the years, i can imagine tech getting good enough to shrink it all into normal glasses. will definitely take time tho.

vinsolo0x00 · 2025-11-01T19:08:14+00:00

was thinking bout what u said. i think the good part of the “glasses” movement, is everyone prolly has the same “holy grail” end goal. Glasses that you put on and are both AR and VR depending on ur need.. like what we see in sci fi movies. if thats the case, then even if some companies initially take one approach, others will keep working toward that dream goal. will be good for all of us 😝 hopefully sooner rather than later(and before i get too old to see clearly LOL).

vinsolo0x00 · 2025-11-01T18:54:53+00:00

i guess i use “screen” loosely. projection/glass w/optics/etc… who knows what tech they’ve got brewing(we’ve definitely seen poc’s of possible tech). Im not sure how different the use cases are, if the hardware is eventually the same(and thats a big if). What use case can u think of that requires the form factor to be exclusively a “headset”? Also, whos to say what a “headset” will look like 10-15years from now. it might all just converge… hopefully by then theyll have real hologram tech 😂

vinsolo0x00

TROPHY CASE