What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

1
2
0
0
0

A few of the things I've learned in the run up to taping out our first chip that working with FPGAs had not prepared me for (fortunately, the folks driving the tape out had done this before and were not surprised):

  • There's a lot of analogue stuff on a chip. Voltage regulators, PLLs, and so on all need to be custom designed for each process. They are expensive to license because they're difficult to design and there are only a handful of companies buying them. The really big companies will design their own in house, but everyone else needs to buy them. The problem is that 'everyone else' is not actually many people.
  • Design verification (DV) is a massive part of the total cost. This needs people who think about the corner cases in designs. The industry rule of thumb is that you need 2-3 DV engineers per RTL engineer to make sure that the thing that you tape out is probably correct. In an FPGA, you can just fix a bug and roll a new bitfile, but with custom chip you have a long turnaround to fix a bug and a lot of costs. This applies at the block level and at the system level. Things like ISA test suites are a tiny part of this because they're not adversarial. To verify a core, you need to understand the microarchitecture-specific corner cases where things might go wrong and then make sure testing covers them. We aren't using CVA6, but I was talking to someone working on it recently and they had a fun case that DV had missed: If a jump target spanned a page boundary, and one of those pages was not mapped, rather than raising a page fault the core would just fill in 16 random bits and execute a random instruction. ISA tests typically won't cover this, a good DV team would know that anything spanning pages in all possible configurations of permission and presence (and at all points in speculative execution) is essential for functional coverage.
  • Most of the tools for the backend are proprietary (and expensive, and with per-seat, per-year licenses). This includes tools for formal verification. There are open-source tools for the formal verification, the proprietary ones are mostly better in their error reporting (if the checks pass, they're fine. If they don't, debugging them is much harder).
  • A lot of the vendors with bits of IP that you need are really paranoid about it leaking. If you're lucky, you'll end up with things that you can access only from a tightly locked-down chamber system. If not, you'll get a simulator and a basic floorplan and the integration happens later.
  • The back-end layout takes a long time. For FPGAs, you write RTL and you're done. The thing you send to the fab is basically a 3D drawing of what to etch on the chip. The flow from the RTL to the 3D picture is complex and time consuming.
  • On newer processes, you end up with a load of places where you need to make tradeoffs. SRAM isn't just SRAM, there are a bunch of different options with different performance, different leakage current, and so on. These aren't small differences. On 22fdx, the ultra-low-leakage SRAM has 10% of the idle power of the normal one, but is bigger and slower. And this is entirely process dependent and will change if you move to a new one.
  • A load of things (especially various kinds of non-volatile memory) use additional layers. For small volumes, you put your chip on a wafer with other people's chips. This is nice, but it means that not every kind of layer happens on every run, which restricts your availability.
  • I already knew this from previous projects, but it's worth repeating: The core is the easy bit. There are loads of other places where you can gain or lose 10% performance depending on design decisions (and these add up really quickly), or where you can accidentally undermine security. The jump from 'we have RTL for a core' to 'we have a working SoC taped out' is smaller than going to that point from a standing start, but it's not much smaller. But don't think 'yay, we have open-source RTL for a RISC-V core!' means 'we can make RISC-V chips easily!'.
  • I really, really, really disapprove of physics. It's just not a good building block for stuff. Digital logic is so much nicer.
0
6
0
0
1
1
1
0
0
0
0
1
0
0
공익광고

트위터에서 ~트랜스젠더~ 어쩌고 내용의, 어두운 배경의 사람 옆얼굴 동영상이 첨부된 광고를 보면 절대 클릭하지 마세요 우리가 기대하는 기사. 인권단체. 연구 이런 거 아니고

야동사이트입니다
0
0
0
0

1/

AFAIK, there isn't a way for an ActivityPub Actor (such as a Person actor) to specify a list of Service actors associated with it.

...

For example, imagine that there is a Service actor that represents a way to make a video call to me.

And, for example, I have my Mastodon Person actor.

And, I want to let people know about it (and other Service actors associated with me).

How do I do that using AP, etc?

...

0
1
0
1
0
1
1
1
1
0

Just had to add a workaround to for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.

https://github.com/fedify-dev/fedify/pull/631

0
0
0
1
2
1
0
2

Why subscriptions? A one-time purchase revenue graph, even for a moderately successful app, looks like this. Yet work required only increases in complexity — Pastel has had 40 multiplatform updates since it launched in 2020, including two system UI redesigns, and a whole new OS (visionOS).

One-time purchases just aren't sustainable, unless the product itself is also one-and-done — and that's just not possible on a moving target like Apple's OSes. Revenue can't be inversely proportional to time

Unlabeled graph: revenue in 2020 was 3x what it is in 2025 (the last full calendar year)
0
0
1
1

SPARTANS IN SPEEDOS & THE STAGED BEACH - my latest podcast on YouTube, a deep dive into art history, comparing the work of Charles Meere, Max Dupain and Frederick McCubbin with that of Anne Zahalka.

You can listen to it (and watch) here:

youtu.be/cI74D2jOP3Q

Please subscribe, like, comment.

0
0
1

We are pleased to announce the release of GNOME 50! You can read about what our contributors have been working on at release.gnome.org/50

We’d like to use this new release as an opportunity to thank all of the contributors who made it happen. ❤️

Let us know what you think!

0
13
1
1
0
1
0
1

🍝 친구 여러분, 우리는 날아다니는 스파게티 괴물 님께서 주신 이 날의 끝맺음에 와 있으니 겸손하게 우리 죄를 반성합시다.

"14. 오늘 하루 주신 기회와 사람들과의 만남에 감사드리며, 모든 것이 은총이었음을 고백합니다."

😋 전능하신 스파게티 괴물과 친구들에게 고백하오니 생각과 말과 행위로 죄를 많이 지었으며 자주 의무를 소홀히 하였나이다.
제 탓이요. 제 탓이요. 저의 큰 탓이옵니다.
우리 죄를 용서하시고, 주님 안에서 새로워지게 하소서.
라-멘 🍜

🍝 전능하시고 자비로우신 주님, 날아다니는 스파게티 괴물 님,
당신의 모든 죄를 용서하시고 사면하시며, 진정한 회개와 삶의 교정을 허락하시고, 당신 성면(the Holy Noodle)의 은총과 위로를 베푸소서.
라-멘 🍜

2026-03-19T19:38:58+09:00


0
0