gchadwick

I think their point is they worry too much time and money is going into cool concepts like this and not enough on practical steps forward in mobility that can actually make a difference in people's lives within a few years.

The author even gives a concrete example

> I would give at least a few of my quad fingers for a high quality, lightweight, low-profile indoor/outdoor power chair with the customizable seating and back options I rely on.

That doesn't sound like a wild concept, sounds like something achievable as a product if there was someone with deep pockets willing to chuck in the money (I doubt mobility aids are a great money spinner, money back with a bit of profit should be feasible?) and some good engineers enthused by making a real difference to people.

How much money and engineering time did Toyota spend on this I wonder?

If that's a drop in the bucket compared to the practical, creating real product, engineering happening in this space then it's all good. If most of the money is going to stuff like this then that's a problem.

> It baffles me that anyone still uses Mercator projection for any serious purpose.

Tell me you've never done any serious navigation off a map or chart without telling me...

I really enjoyed the book. Great for people who want to understand the real nuts and bolts and have worked examples of all of the calculations.

That's the beauty of side projects, you get to decide and you don't have to care about working with others.

Really yearning for crafted code that meets every one of your perfect coding style guide and preference with green checks across a huge set of static analysis tools and a large test suite, go for it!

Tired of conforming to your ultra strict style guide at work and code reviews that go in endless circles nit picking about use of spacing or whatever? Let loose and stop having to care/worry so much about the details.

On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.

The critical thing is what the author says:

> always make sure that you're doing them for yourself, and for the right reasons

For me my side projects are generally something to have fun with and something to learn new things with. When you're finding it a slog or you feel like you've learnt what what you need to it's fine to just dump it.

Actually finishing something is of course nice and for beginners in particular there's a lot of value in going from that it's mostly there just some loose ends to tie off stage to the actually done stage but you don't have to always do this (or indeed just do it in some select cases).

Remember OpenAI decided GPT 2 was far too dangerous to unleash upon the world when they first trained it!

A nice game, though the truth table lighting round is pretty punishing! Big contrast to the circuit building part where you can take your time. Personally I'd drop the time requirements from that quiz section.

> Also we found the formal waiver analysis tools to be very effective for waiving unreachable code, in case you aren't using those.

Yes we had used them just never got it slickly integrated into the verification dashboard. We had used this kind of analysis for internal sign off. You could generate the waivers manually and check them in but that suffers from the problem discussed above. Plus as OpenTitan was a cross company project you run into EDA licensing issues where not everyone has access to the same set of tools and a UNR flow could be running fine on one partner's infrastructure but isn't workable everywhere for multitude of reasons.

The ideal would be the nightly regression would do the UNR flow to generate the waivers and apply them when generating coverage but as ever there's only so much engineering time to go around and always other priorities.

I worked on OpenTitan for around 5 years at lowRISC. It certainly has its ups and downs but it's generated some great stuff and I'm very glad to see hit proper volume production like this. Whilst there's definitely open source chips out there and lots more using bits of open source that don't actually advertise this fact I believe this is the first chip with completely open RTL that's in a major production volume use case.

One of highlights working on OpenTitan was the amount of interest we got from the academic community. Work they did could actually get factored into the first generation silicon making it stronger. Ordinarily chips like that are kept deeply under wraps and the first time the wider security community can take a look at them development has long completed so anything they might find could only effect generation 2 or 3 of the device.

Academic collaboration also helped get ahead in post quantum crypto. This first generation chip has limited capabilities there but thanks to multiple academics using the design as a base for their own PQC work there was lots to draw on for future designs.

I'm no longer at lowRISC so I don't know where OpenTitan is going next but I look forward to finding out.

This is an interesting piece of hardware though when they go multi-chip for larger models the speed will no doubt suffer.

They'll also be severely limited on context length as it needs to sit in SRAM. Looks like the current one tops out at 6144 tokens which I presume is a whole chips worth. You'd also have to dedicate a chip to a whole user as there's likely only enough SRAM for one user's worth of context. I wonder how much time it takes them to swap users in/out? I wouldn't be surprised if this chip is severely underutilized (can't use it all when running decode as you have to run token by token with one users and then idle time as you swap users in/out).

Maybe a more realistic deployment would have chips for linear layers and chips for attention? You could batch users through the shared weight chips and then provision more or less attention chips as you want which would be per user (or shared amongst a small group 2-4 users).

> If copying user tokens was the bottle neck, batching would not achieve any speed up.

Reality is more complex. As context length grows your KV cache becomes large and will begin to dominate your total FLOPs (and hence bytes loaded). The issue with KV cache is you cannot batch it because only one user can use it, unlike static layer weights where you can reuse them across multiple users.

Emerging sparse attention techniques can greatly relieve this issue though the extent to which frontier labs deploy them is uncertain. Deepseek v3.2 uses sparse attention though I don't know off hand how much this reduces KV cache FLOPs and associated memory bandwidth.

Anyone else find reading things like this slightly exhausting?

I'm very much pro AI for coding there are clearly significant capabilities there but I'm still getting my head around how to best utilise it.

Posts like these make it sound like ruthlessly optimizing your workflow letting no possible efficiency go every single day is the only way to work now. This has always been possible and generally not a good idea to focus on exclusively. There's always been processes to optimise and automate and always a balance as to which to pursue.

Personally I am incorporating AI into my daily work but not getting too bogged down by it. I read about some of the latest ideas and techniques and choose carefully which I employ. Sometimes I'll try and AI workflow and then abandon it. I recently connected Claude up to draw.io with an MCP, it had some good capabilities but for the specific task I wanted it wasn't really getting it so doing it manually was the better choice to achieve what I wanted in good time.

The models themselves and coding harnesses are also evolving quickly complex workflows people may put together can quickly become pointless.

More haste, less speed as they say!