This is my very first iteration of VCO layout (first time CMOS layout as a total beginner), I haven't even ran a DRC yet but I just want to share! I love analog and chip design!

As title says, I submitted on July 7th and I can't stop thinking about it.

Let's start with the fact that this tapeout is my master thesis project and it was my very first approach to ic design, microelectronics in general (I had general knowledge, but never had dedicated courses)

I liked it a lot, but it was one of the most stressful things I've done my whole life. And the worst thing is that I am realizing that I may have underestimated some stuff only now, after submission (the circuit goes at cryo, so some stuff has to be implemented knowing that the result may be different from simulations)

I had seven months to design the chip and now that it's submitted I have continuous thoughts about how I could have done better/realization for minor fuckups that may be fixable.

So my question is: is it common to make stupid mistakes? Or better, how do you cope with it?

I always hear about people in the lab doing silly mistakes, but now it may happen to me the whole world feels like it's crumbling under my feet. What stresses me out the most is that I feel like the impression of myself I left on my supervisors is getting destroyed at every mistake I tell them (now that I left it's even worse since I can't even talk to thema face to face)

Can someone explain the process of tape-out and why it is such a valuable experience for a research student? I don't have the finances/opportunities to send my chip for tape-out since i am working on some other research topic in digital in my uni, but can I do everything on my own before sending it, since after tape-out it's binary — either working or not — so there isn't really much to learn from the outcome itself?

Everyone here has debugged a reset-release metastability at 2am, and everyone knows the testbench never sees it. We built an open evaluation layer that adds declared intent (clock groups, reset discipline, power-on state) plus a structural oracle on top of the functional result, and ran frozen generation studies against it.

The finding practitioners will recognize: at least 14 of 57 functionally accepted candidates wire raw async reset into operational state, and every single one also contains a correct two-flop synchronizer in the same file, with its output used as a synchronous qualifier while the async pin stays raw. A junior who does not know the idiom omits the synchronizer, which review catches. These candidates build it and route around it, which defeats exactly the heuristic reviewers use.

One public example even carries the comment "Synchronized active-low reset applied directly to counter state" above the wrong wiring.

An independent RTL engineer reviewed the frozen packet blind this weekend and concurred on every case he examined, including calling the synchronizer bypass unprompted. Artifacts, prompts, and both oracles are public; `svgap demo` reproduces the witness split in one container command. For FPGA folks: yes, sync-reset methodologies change the flavor; the intent declaration question stays.

Curious what this crowd thinks belongs in a task-level intent contract: which production question does a functional pass leave unanswered in your flow?

  Repo and artifacts: https://github.com/shsridhar-beep/svgap

I’m preparing for design interview and saw a synchronous FIFO coding problem and want a sanity check on the full-boundary behavior.

(original problem: ASIC.FYI Q892⁠ )

My implementation is:

assign rd_valid = !empty;

wire pop = rd_valid && rd_ready;

assign wr_ready = !full || pop;

wire push = wr_valid && wr_ready;

——
If the FIFO is full and a read is accepted, this also allows a new write on the same edge. Occupancy stays full and there’s no bubble.

The downside is that wr_ready now has a combinational dependency on downstream rd_ready. The simpler alternative is probably assign wr_ready = !full;

That removes the path, but the replacement write isn’t accepted until the following cycle.

If a spec only says “implement a synchronous ready/valid FIFO,” which behavior would you normally assume? Is the full-boundary exchange part of expected FIFO behavior, or just a throughput optimization that needs to be stated explicitly?

Hi guys.. has anyone worked on PHY layer as firmware side for SERDES protocols? Have interview lined up tomorrow I want to know what to expect in general topics wise? Thanks

Hi,

Is there anybody who did a RISCV verification course from maven silicon in the past or similar course related to verification, do they reach well ? Will they be providing actual RTL and explain verification or just a high level system verilog model which is not what companies do