computer architecture – Observations from Uppsala

“RISC-V in Practice” – Computer and System Architecture Unraveled Event Three

On Wednesday, March 13, we had our third CaSA, Computer and System Architecture Unraveled, meetup. Same place as the previous, the 25^th floor of the Kista Science Tower building, thanks to the kind sponsorship of Vasakronan and our collaboration with Kista Science City. The theme this time was “The RISC-V ISA in Practice”, with two speakers named Björn. Another great event!

“Packet Networks are not Socket Science” – Computer and System Architecture Unraveled Event Two

On Wednesday, November 22, we had our second CaSA, Computer and System Architecture Unraveled, meetup. Same place in Kista as the last time, the 25^th floor of the Kista Science Tower building, thanks to the kind sponsorship of Vasakronan and our collaboration with Kista Science City. This time, the theme was networking – but not at the socket level. Per Holmberg presented how his team used “micro sleep” for power management in line-rate network processing, and Hans Brandberg talked about the Precision Time Protocol. Another great event!

The first Computer and System Architecture Unraveled Event in Kista – Great Speakers, Great Fun!

On the evening of the last Wednesday in September, we had our first CaSA, Computer and System Architecture Unraveled, event. CaSA is a meetup in Kista (Sweden) for people interested in computer architecture, system architecture, and how software and hardware interact down towards the lower levels of the stack. The topic for the inaugural event was “Core Count Explosion: A Challenge for Hardware and Software”, and it was great in some many ways!

Intel Blog: Playing with Instruction Sets in the Public Simics RISC-V Platform

As noted previously, the Public Release of the Intel Simics Simulator has added a simple RISC-V virtual platform.

In my second blog post about the platform, I reconfigure the instruction set, crash Linux, debug the issue, and reconfigure the software to match the hardware.

The NUC12 Enthusiast

Right when our old NUC5 died, its replacement had been delivered and brought online – a new Intel NUC12 Enthusiast, also known as the NUC12SNKi72 (I work at Intel, but even I find that name a bit obtuse). This is a seriously fast machine in a fairly compact package, even though admittedly not as small as the old NUC5. On the other hand, as a machine with an ambition to be a replacement for a dedicated gaming PC, it sports a dedicated graphics card and not just the integrated graphics typical for the classic NUCs.

SystemC Evolution Fika: Parallel SystemC

The SystemC Evolution Fika on April 7 had threading/parallelism as its theme. There were four speakers who presented various angles on how to parallelize SystemC models. The presentations and following discussion provided a variety of perspectives on threading as it can be applied in virtual platforms and other computer architecture simulations. It was pretty clear that the presenters and audience had quite different ideas about just what the target domain looks like and the best way to introduce parallelism to SystemC. Here is my take on what was said.

Some Notes on Temporal Decoupling (Reposted)

This blog post was originally posted at Intel back in 2018, but it has since been retired from the Intel blog system. As it is of general interest (in my opinion), here is a reposting (with a few small updates here and there).

Temporal decoupling is a key technology in virtual platforms, and can speed up the execution of a system by several orders of magnitude. In my own experiments, I have seen it provide a speedup of more than 1000x. Here, I will dig a little deeper into temporal decoupling and its semantic effects.

Don’t Look behind the Curtain! (Please)

In a previous blog, I talked a bit about the hazards of coding to an implementation and not a specification, based on 1980s home computers. While the specifics and peculiarities of that case is hopefully confined to old hardware, the lessons are still worth contemplating. There is a modern variant of this phenomenon that is based on open-source software, and that I must admit to feeling a bit annoyed by. Fundamentally, the question is this: when figuring out how to use an API – should you look at the documentation or the implementation?

Easy to Assemble, just like Lego – Right…

When discussing the design and integration of systems on chip and models of systems on chip, the Lego analogy is often brought up. The idea being that with Lego, anyone can put together anything and every component can be combined with all other components. Right. My recent building of Lego set 21327, Typewriter, makes me wonder if the people who talk about Lego-like construction have actually built anything from Legos in the past few decades.

Code to the Spec(trum) or the Implementation

When writing software that uses any kind of API or hardware functionality, sooner or later there will be questions about what a particular API call or hardware operation is supposed to do. In principle, such questions should be answered by referring to the specification (and user documentation). I am a firm believer in writing readable and clear specs and keeping software coding to follow the spec, as that ensures future compatibility. But reality is not that simple. Things are generally better today than they used to be, though. Reading up a bit on the history of my first computer (the ZX Spectrum), I found some rather interesting cases of spec vs implementation, and “discovered functionality”.

Timesharing System Design Concepts (1970)

When I recently turned 50, a friend of mine gave me a book that was about as old as me – Timesharing System Design Concepts, by Richard W Watson. The copyright date is 1970, but the publishing date found online 1971. The book covers the hardware support and software techniques needed to provide multiple users with simultaneous access to a computer system. Typically, using remote teletype terminals. It is a wonderful book, reflecting on the state of computer technology around 1970. It shows both how many of the basic concepts we still use today were already in use back then, but at the same time just how far we have evolved computing since.

The SAMOS XXI Conference (Virtual)

The International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (SAMOS) XXI conference took place a couple of weeks ago. Like all other events in the past 18 months, it was virtual due to Covid-19. For more on the background on the SAMOS conference, see my blog post about SAMOS XIX (from 2019). This year, I presented a tutorial about our public release of the Simics simulator and took the chance to listen to most of the other conference talks.

DRAMsys – Cycle-Accurate Simulation using Transactions

DRAMsys is a simulator for modern RAM systems, built by researchers at Fraunhofer IESE and the Technische Universität Kaiserslautern. Over the past few years, I have heard several talks about the tool and also had the luck to talk a bit to the team behind it. It is an interesting piece of simulation technology, in particular for how it manages to build a truly cycle-accurate model on top of the approximately-timed (AT) style defined SystemC TLM-2.0.

Professor Reinhard Wilhelm on the History of WCET Analysis

Back when I was a PhD student working on worst-case execution-time (WCET) analysis, one of the leading groups researching the topic was the “Saarbrücken gang” led by Professor Reinhard Wilhelm. Last year, Professor Wilhelm published a retrospective look on their work on WCET in the Communications of the ACM. It is a really interesting history write-up from the perspective of the Saarbrücken group.

USB-C Works, but how would you Know?

Using USB-C to charge a laptop while simultaneously providing display and other IO traffic sounds a little bit too good to be true in practice. Maybe it would work for a set of devices from a single manufacturer (like a Thunderbolt-based USB-C-attached dock from the same vendor as a laptop). However, recently I was surprised (in a good way) when it turned out that I had accidentally got myself a USB-C-based single-cable-to-the-laptop setup. USB-C promises a lot, in this case it delivers perfectly, but what bothers me is the fact that there is really no way I could have figured this out ahead of time.