gchadwick

Does depend upon the project but I suspect this is far too low. Only thing you're likely to get in this price range is a small addition / tweak to an existing design.

A very minimal design from scratch that uses existing off the shelf hardware with no interfacing to anything remotely complex and no follow on support (pretty much developer hands it over showing some smoke test works and you're on your own from there) could also fit into this budget.

Not OP but my partner lived in Copenhagen for two years. As with all of Scandinavia fluency in English is very common, practically universal in cities so you can happily live there without speaking a word of the local language. Also unlike most of Europe it's a lot more acceptable to just assume English is spoken and lead with that rather than stumbling through in the native language to start with.

That said it's still polite to learn some basics, e.g. thank you to mix in. If you're planning on living there long term you will want to learn Danish for social purposes unless you're planning to mix exclusively with immigrant communities. It's a very international place so English can often be the default language that any given group will all speak.

Edit: oh and an interesting quirk English is often spoken with an American accent! I think because they watch a lot of American TV shows and movies.

Is GPU rendering used today for VFX? From a quick google it seems that yes GPU based rendering is definitely an option, even if there's various reasons to still prefer CPU. So in your case was it really what you were aiming to do was pointless or simply your particular solution failed to succeed?

You're right that as a small player it's very hard to gain traction, even if the tech is fantastic because it's risky to switch your tech stack over. Though if you do do a good job with the tech I'd say you have a decent chance of an acquisition from a bigger player who wants a ready-made (or 90% of the way there) solution they can make their own. Perhaps you can call this an aquihire but I think you're significantly underplaying the potential upside of this exit. Imagine this startup is seen as having a great ternary transformer solution and ternary transformers are the way to go you could get multiple large players eyeing up an acquisition to get ahead pushing the price up.

My feeling is custom ASICs for ternary transformers is a great area to look at. There is a genuine chance of providing a significant step up from GPUs in terms of power efficiency and potentially performance. Plenty of risk of course, ternary models might just not perform as well as the full fat equivalents and building custom silicon, especially as a start-up, comes with all kinds of issues.

Worth noting the story here has subtly that the headline cannot accurately capture. For one I wouldn't say this is about raising safety concerns or whistle-blowing, it's about how the employer views employees talking to the media.

The engineer in question was sacked for stating 'You’re talking about thousands of people squished into that space. It’s not just uncomfortable, it’s not just unpleasant, it’s unsafe.' in a media interview (see https://www.independent.co.uk/life-style/euston-trains-stati... looks like the unsafe part of that quote made the headline).

Here he was just amplifying already public information that the Office of Rail and Road had raised concerns and issued an improvement notice (which is reference in the article before he is quoted). I guess they hadn't actually declared it 'unsafe' though.

I think it is reasonable for employers to require employees don't go making negative comments in the media, though that is tempered by the public interest in raising the profile of safety concerns. Perhaps here the engineer felt no-one was taking the improvement notice seriously and needed more incentive to do so? Could also be he felt he wasn't trying to cause any upset at all and was simply stating what was already public known.

It does feel here that the minister that triggered the sacking was just being thin-skinned. He saw a newspaper headline that angered him and sought to take it out on someone. Perhaps some disciplinary action was warranted (maybe improvements were indeed underway and the engineer shouldn't go causing extra needless public alarm) but sacking him looks to be a big overreaction.

Improved hardware based abstractions to provide stronger security and better ways to isolate software components just seems like a good idea. Yes you can certainly do plenty in software (in particular using language like Rust) but presumably we still want hardware enforced security properties? So why not improve those as well as software?

To put it another way why not remove existing hardware security abstractions we do have? Ditch virtualization (or hugely strip it back), get rid of different privilege levels, loose page-table enforced permissions. After all you can just build safe software why bother with these things?

I for one don't think this is a sensible line of argument, defence in depth is a good idea, build your software to be as secure as possible then build your hardware such that if there is some flaw in your software's defences you can keep things contained though hardware abstractions.

Even with improved languages there's a giant body of existing code you need to work with, with compartmentalization in CHERI you can keep this stuff safely contained. Plus how do you guarantee everything running on the system has been built in your safe language and compiled with your blessed known good compiler? Feasible in some places (like embedded systems) far less feasible in others.

That's exactly what we're doing with OpenTitan: https://opentitan.org/

Which Google will be using in Chromebook for it's security chip https://lowrisc.org/news/nuvoton-develops-opentitan-based-se...

Would be interesting to know what verification they've done on this core. Given it's included as a bonus feature presumably they haven't done full DV on it.

The repository has a testbench for running binaries, which includes the RISC-V compliance suite plus some usage of RISCV formal https://github.com/YosysHQ/riscv-formal which is intriguing. Though nothing obvious of the level you'd need to close production level verification on a design.

At a guess it's because the author has been using Yosys for some formal verification work and maybe for doing some synthesis trials and it doesn't support system verilog natively. Though things are improving there: https://github.com/chipsalliance/synlig

This looks awesome a really great step up from the RP2040. I'm a big fan of the original and I'm excited to see all the improvements and upgrades.

I imagine with the new secure boot functionality they've got a huge new range of customers to tempt to.

Also exciting to see them dip their toe into the open silicon waters with the hazard 3 RISCV core https://github.com/Wren6991/Hazard3.

Of course it they'd used Ibex https://github.com/lowrisc/ibex the RISC-V core we develop and maintain at lowRISC that would have been even better but you can't have everything ;)

Are Google really pushing it a 'proper' security feature? You've quoted a line at the end of a blog that doesn't elaborate further. In the android documentation for instance it stats '[MTE] helps detect use-after-free and buffer-overflow bugs': https://source.android.com/docs/security/test/memory-safety/... without making any stronger claims.

> This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).

I might argue fixing is is actively bad. Helps push the idea this is a feature to actually use for security rather than augment bug detection. Still fixing it shouldn't be too hard, just speculate as you do currently but always assume the tag check passes so you get the same speculative behaviour regardless of tag values (likely easier said than done of course, probably some fun corner cases where they'd still differ).

Does this actually have any real world implications? If you're using MTE you already know there's a simple attack that succeeds with 1/16th probability (or maybe greater if you reserve some tags for special purposes or have some exploitable pattern in how your allocator hands out tags). In that system this pushes the attack probability to 100%. A nice technique but (hopefully) you've already architectured things assuming MTE will be broken so this doesn't change anything.

Certainly MTE was always pushed as a debugging feature only.

> It is an extremely weird situation, and a deeply bad look

I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 the following happened:

  - Developer independent of RPi opens PR to add RP2040 support to PlatformIO

  - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems reasonable)

  - They discuss this with RPi, ultimately RPi don't want to pay the asked contributions so that PlatformIO are happy maintaining support (this also seems reasonable)

  - End result is no RP2040 support in PlatformIO

Ultimately maintaining things isn't free. RPi have chosen the development environment(s) they wish to support and it hasn't included PlatformIO. What's weird or a bad look?

The devil really is in the details here, a tweet further down the thread quotes the new terms of use: https://x.com/Stretchedwiener/status/1798390688830402802

> Solely for the purposes of operating or improving the Services and Software, you grant us a non-exclusive, worldwide, royalty-free, sublicensable, license, to use, reproduce, publicly display, display, distribute, modify, create derivate works based on, publicly perform, and translate the content

(typed from the image, may have some mistakes!)

Which to be seems astounding! Especially for professional software such as photoshop where many many of its users will be working on behalf of clients and this clause would likely breach agreements with those clients and for other users making content for themselves they understandably don't want to allow Adobe to 'publicly display' their work.

Indeed but I still feel my original point stands. If you can achieve their process half reasonably with a bodged espresso machine there's a reasonable chance it will become popular (assuming of course it does provide unique coffee!). If it's complex precision engineering even if they're directly working on commercialisation it'll be a struggle.

Until James Hoffman (https://www.youtube.com/@jameshoffmann/videos) has done a video on it, it may as well not exist ;)

Interesting idea, always nice to see new ways to brew coffee. I wonder how easy it is to replicate their process? The article isn't hugely clear. It talks about using a modified off the shelf domestic espresso machine but the picture at the top looks like a custom built device with potential complex machining involved to build.

If it's the case you can buy an ultrasonic transducer and bodge it into an espresso machine lots of fun possibilities for coffee geeks (and to my point above someone like James Hoffman will give it a go and build up a bunch of interest in the technique)

If it's the case you need a bunch of complex machining and significant technical skills (say those possessed by chemical engineers conducting cutting edge research...) then I imagine this will struggle to go anywhere.

According to this: https://assets.publishing.service.gov.uk/government/uploads/... yes.

Note that the foundation has had a majority stake in RPi ltd (as a private company) for a long time this is not a new structure.

This is already the setup, the foundation owns the trading company and it is the trading company going to IPO.

From a quick scan it's not clear to me what share of ownership of RPi ltd the foundation would retain post IPO other than the foundation will be selling at least some of its stake:

> The Offer would be comprised of new Shares to be issued by the Company and existing shares to be sold by certain existing shareholders, including the Raspberry Pi Foundation, Raspberry Pi's existing majority shareholder.

Ah yes I meant D1-3!

This is a good point though I'd argue that the spec isn't all that readable for some important things.

For example the description of exception handling is sprinkled between the CSR definitions of the CSRs involved. There's no section that just lays out the exception model.

> No document that I could find has ever tried to specify an instruction set independent of an actual implementation.

What do you mean by this? I'd say most ISA specifications do this (e.g. the Arm spec doesn't refer to Arm's CPU implementations and has well defined ways to discuss things that can be implementation dependent).

Another issue I take with the RISC-V spec is it relies on a common understanding of technical terms without actually defining them precisely anywhere.

To take one example it never defines what an interrupt is and more broadly never defines terminology around exceptions. Contrast to the arm ISA which precisely describes what it means by asynchronous Vs synchronous, precise Vs imprecise etc (see section D3-1 in https://developer.arm.com/documentation/ddi0487/latest/).

The original authors may see this as a virtue, the small size of the RISC-V ISA manuals Vs Arm was portrayed as a great benefit but in part that size is because it's missing lots of stuff like this that I view as highly important for a specification.

ISAs are complex things so you can't say one is technically superior to the other.

I would say you're right though in that RISCV enjoys the success it's seeing due to the open specification and licensing model. People generally aren't drawn to RISCV because of technical innovation.

Getting the tools and skills to do PCB assembly and SMD rework seems like a no-brainer (indeed I'd say essential!) if you're aiming to do serious work with building hardware. Not something I've done myself but soldering an LGA-12 doesn't look too hard with appropriate tools.

For an article extolling the benefits of embeddings for developers looking to dip their toe into the waters of AI it's odd they don't actually have an intro to embeddings or to vector databases. They just assume the reader already knows these concepts and dives on in to how they use them.

Sure many do know these concepts already but they're probably not the people wondering about a 'good starting point for the AI curious app developer'.

This looks like a nice piece of work but worth noting that as it uses a stock RP2040 Pico board any hardening against physical attacks will be done purely in software so cloning the HSM entirely or extracting keys may not be too complex for an attacker. Hardening against physical attackers and significant resistance against them is normally seen as a key component of an HSM.

Indeed from a very quick glance at the source, it's using the mbedtls library (from arm) and I think this is an unmasked implementation. This means key extraction, if you have physical access to the device, will be trivial.

Another source here: https://twitter.com/duncan_2qq/status/1773752269395099774

Incredibly sad news, a great loss.

The RP2040 is a great MCU for playing with graphics as it can bit bang VGA and DVI/HDMI. There's some info on the DVI here: https://github.com/Wren6991/PicoDVI

I wrote a couple of articles on how to do bit banged VGA on the RP2040 from scratch: https://gregchadwick.co.uk/blog/playing-with-the-pico-pt5/ and https://gregchadwick.co.uk/blog/playing-with-the-pico-pt6/ plus an intro to PIO https://gregchadwick.co.uk/blog/playing-with-the-pico-pt4/

Cool! I found the hello blog here illuminating to understand the creators intentions: https://www.furygpu.com/blog/hello

As I read it, it's just a fun hobby project for them first and foremost and looks like they're intending to write a whole bunch more about how they built it.

It's certainly an impressive piece of work, in particular as they've got the full stack working, a windows driver implementing a custom graphics API and then quake running on top of that. A shame they've not got some DX/GL support but I can certainly understand why they went the custom API route.

I wonder if they'll open source the design?

For anyone interested in CHERI for embedded/IoT and other similar use cases lowRISC (whom I work for) are building a couple of FPGA based evaluation platforms for CHERIoT (The Microsoft created CHERI variant referred to above): https://www.sunburst-project.org/

The first is the Sonata system: https://github.com/lowRISC/sonata-system. This comprises a dedicated PCB with an FPGA along with various peripherals and headers. The PCB design is done and will be available through Mouser (plus it's open source including the board layout so you can assemble your own if you like). We're currently working on the RTL for the FPGA. When complete you'll have a complete CHERIoT based microcontroller like system with documentation and tooling.

Additionally we're building the Symphony system, which combines Sonata with the OpenTitan Earl Grey root of trust: https://github.com/lowRISC/symphony-system

Powerful generative capabilities aren't always as useful as you might think. There's two major issues:

1. Verification - You can verify one particular part of the configuration space but verifying the full generic component is something else entirely. As far as I'm aware there's no new HDL which seriously tries to address this point.

2. Implementation - If you're generating something sufficiently advanced you likely want different micro-architecture for different configurations to reach the most optimum design (in terms of power, timing and area). As an example, take a CPU, a single, dual and triple issue core will need to be designed in very different ways. You could aim to build something which can generate all of these wrapped up as a nice CPU module with an 'IssueWidth' parameter but that's going to be harder than just writing separate 1, 2 and 3 issue width CPUs.

Certainly for more mechanical things like interconnects, interrupt controllers, pin multiplexers etc yes it can work well. However building those things in System Verilog is often done with separate generator programs anyway and overall doesn't consume much of the total project engineering time, it's just tedious work.

It does seem a lot of new HDLs focus on eradicating the annoyances and tedium you get developing with System Verilog but increase the difficulties you get in point 1 and 2 which are the actual hard bits that take up the bulk of the time.

Early days for Veryl but it's taking a different direction for most (i.e. just building a more sane System Verilog) I shall be watching with interest!