First of all, what makes register design such a special task? My guess is because it is a higher-level aspect of the design: it describes an interface, which can be implemented in many different ways in hardware. Regular HDLs do not help you reason about register layouts in a good way. The register specification should also be used in other places than the hardware: in address definitions for device drivers, in manuals, and other documentation. All of this indicates that the information needs to be explicit, high-level, and in a format that facilitates automatic processing by tools. It basically screams for a domain-specific language (DSL) at some level of ambition (read my old post about how languages are grown from problems for more background on just how simple a DSL can be).

If you look at the register design tool vendors that Gary interviewed, you can essentially see two different approaches to how to support the task of register design. In particular, the input language differs quite radically between the tools.

There is domain-specific programming language approach. A register-design DSL makes it easy to work with register designs, and pretty hard to do anything else (imagine writing a sorting algorithm in a register-design language – I don’t think it can be done, and if it can be done, the result has to be absolutely contorted). The DSL approach assumes a willingness  on the part of a user to learn a new language, but it seems that for this domain, the languages are simple enough that learning them saves you time in the end. Especially if you maintain large register maps that keep changing or is updated and extended across generations of chips (indeed, ease of maintenance is an undersold aspect of most DSLs in my experience).

The underlying assumption of the DSL approach is that the entry language is not too important, as long as you can export data into other formats. To me, this makes sense. From a single source with sufficient descriptive power, you can ideally generate both HDL code to implement the decoder in hardware, as well as documentation, header files, and maybe even skeletons for virtual platform models. And standard formats like IP-XACT to feed into any other tool.

It does not matter if there is a single tool using each input language, since the outputs are what matters. This leaves the vendors free to invent on the input side, and provide a really powerful tool.

The second approach is transformation-based. Its idea is to not use a dedicated input language, but rather powerful import functions to read whatever specifications already exist in text files, Microsoft Word documents, Microsoft Excel spreadsheets, Framemaker documentation files, IP-XACT, or whatever you can come up with.  The assumption is that the tool is really about transforming data and not about compiling a language. Register designs kind of already exist, and since there is no standard language to compile, you just import whatever there is. It makes the assumption that the user base is not willing to learn a new language to handle register design. A funky side-effect is that we might end up actually doing programming work in Word docs.

Still, the transformation approach ends up generating the same outputs as the DSL approach. In  both cases, some of the outputs can be considered “industry standards”, like IP-XACT, while others are decidedly ad-hoc, like Excel sheets. To me, this demonstrates that the true value in standards is to enable tool interoperability, and not so much as a way to provide inputs.

Indeed, there is a clear difference between good input languages and good exchange formats. An input language tends to drive for expressive power and human readability, and it is OK to have a heavy compilation process associated with it. An exchange format like IP-XACT does not need to be human-readable, nor efficient to code in. It needs to be easy to parse and compile, so that as many tools as possible can work on it.

A typical example from the field of register design is dealing with repeated groups of registers (such as banks of registers for a DMA channel) and parametrized register designs. The input languages used by the tools that Gary Stringham covers all allow this – while the standard for register design exchange, IP-XACT, only uses a flat compiled map. It just lists all registers with sizes and offsets, not how these offsets were arrived at or if there is some logical grouping or iterated structure. Quite OK for a tool to work on, but not very useful as a repository for the actual information.

This distinction is worth to keep in mind.

I definitely side with the DSL idea, as that fits my idea of a good tool, but I can see why many people find the transformation from other formats attractive. In all cases, the goal is to have an original design specification that is as clear, succinct, and flexible as possible.

For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.

It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…

It turned out that it is not that easy to get it right. I was trying to have a few different tasks look at different sensors and steer the robot in different directions based on the sensor readings. However, this quickly turned into a literal deadlock: the robot just sat there, doing nothing, after the first time that my ultrasound sensor task tried to steer it. Failure.

The manual is quite silent on the tasking semantics, and there are no (or I have not yet found) shared variables, locks, or message-passing mechanisms to synchronize the tasks.

Looking for an answer on the web, I came across a nice tutorial on tasking:

• http://www.ortop.org/NXT_Tutorial/tasks.html

It is a video, and it ends with the note that the only reliable way to multitask in the NXT environment is to NOT try to control the same thing from multiple tasks. If I want to listen to multiple sensors, the only way is to create a loop with switching on inputs. I.e., manual polling. So much for using the natural language of tasks to handle naturally concurrent activities. At some point, I might figure out if I can construct it from tasks and data value transfers, but for now, I will just go with the flow and write (or rather draw) some polling loops.

Here is an example from the manual. Note that the top “beam” controls motor A, and the bottom controls motors B and C:

That last part about data wires is intriguing… but I will need to find some more reference materials.

Anyway, the way to express parallel tasks here is really quite neat. At least as long as they are dealing with completely separate aspects of the control of the robot.

If this had been a more hard-core environment, it would have been fun to put different tasks on the ARM7 and AVR processors that are inside the NXT 2.0 brick. Yes, it is a true multiprocessor, if very limited in capabilities. At http://mindstorms.lego.com/en-us/whatisnxt/default.aspx you have the specs. ARM7, 256 kB of FLASH, 64 kB of RAM, and the AVR has 512 bytes of RAM and 4 kB of FLASH. A nice real embedded machine!

This was the first multicore event that I have been to where we did not have a keynote speaker or technical paper from a hardware company. So there was really nothing here directly about how to build multicore chips. Rather, the workshop tended to be about how to program, use, measure performance on, verify software for, and generally work with multicore chips. From the perspective of software people, rather than hardware designers.

Obviously, hardware aspects enter into such talks, but it is the perspective of a user, not a designer. For example, a hardware designer could explain how an atomic compare-and-swap is optimized in a multicore device. But here, we saw measurements on the actual operation latencies observed on real machines using such operations. Quite refreshing, and closer to my personal interests.

The keynote by Andras Vajda of Ericsson was quite interesting. The slides are not online, but the main points that I picked up and that I might not have considered before:

• Software development costs can mean that the cheapest, fastest, most efficient hardware is not necessarily the most economic. Too hard to code for means the software development time and effort removes the advantage. Obvious, but worth reiterating. Software is king.
• The workload on a cellular basestation can sometimes be highly linear and single-threaded. For example, serving a single terminal with a very high bandwidth LTE connection. And suddenly shift to a massively parallel workload as a crowd of a thousand all suddenly appear and start doing data downloads. And then go back to serial again. This means that the age-old argument that signal processing naturally “conveniently concurrent” (and here) is not always true. Nice point!
• Thus, we need adaptable architectures that can trade serial and parallel performance over time, and rebalance quite quickly. In the same chip.
• He is a firm believer that homogeneous systems will win out in the end, I still hold on to a belief in accelerators and offload engines and DSPs. This is partially because of an admitted focus on servers and services processors, and not on the baseband and signalling side. Makes sense.
• Domain-specific languages (DSL) are the future of efficient programming. Agree.

On the topic of DSLs, there was a question about the cost to support them. To me, that is a non-issue. In the organizations that I have worked, it seems that maintaining a useful DSL requires at most one engineer. Developing one, a few good computer scientists for a fairly limited time. In any case, they tend to appear organically when good programmers generalize repeated tasks.

I gave a keynote about how multicore has impacted virtual platforms (in particular, Virtutech Simics) with the following main points:

• Multicore targets increase the performance pressure on a virtual platform, as more processors will have to be simulated.
• Multicore hosts means that sequential performance of the host is going down compared to the aggregate parallel performance demands from the targets.
• To handle large target systems, the virtual platform itself has to run multithreaded on a multicore host. Getting this in place is a major, interesting, and sometimes painful process.
• Once you have a parallel virtual platform, multicore hosts provide a very nice boost in scalability and the manageable system sizes. A single multithreaded virtual platform process is also a bit easier to manage from a user perspective.
• All features in the virtual platform have to be multicore and multimachine-aware… meaning that they often get a bit harder to use initially, as there is no “default processor” you can fall back to for debugging setups etc. Everything has to be explicitly targeted.
• Multicore targets have proven to  be a great sales driver for virtual platforms, as debugging software on a physical multicore, multichip, multiboard system is just too painful.

Overall, this was a fun event, looking forward to next year at Chalmers!

Quotes from the blog post:

Sequential languages hiding parallelism:

Sequential imperative languages are notoriously good at hiding or at least obfuscating inherent parallelism in the applications – which may be good news for compiler providers who spend – and charge – big bucks for building reverse engineering technologies that can detect parallelism from sequential code; as well as for highly skilled programmers capable of building parallel code using sequential tools; however, it weights heavily on the total cost of developing software, not to mention the recurring cost of porting to newer HW with e.g. more cores.

Applying DSLs to signal processing:

During the work on the domain-specific language for DSP programming we have seen some interesting results; for example, several pages of optimized C code were re-written to one PowerPoint slide worth of DSL code, while the DSL to C compiler was able to output efficient code comparable in size to the original code.

I agree fully with the final note:

The big question is not anymore if DSLs will take off – it’s more if your pain level is higher than the cost of accepting an alternative and different approach; as the cost for taking in a new language tends to stay constant while the complexity of developing software is increasing, odds are that there will be an uptake of domain-specific languages.

Go and read the full article!

My entry is called “Virtual Platforms unites Hardware, Software Engineers“, and is presented by Richard Goering (who used to be with SCDSource), in his “Industry Insights” section of the Cadence community of blogs. Richard Goering has a personal post pointing in the same direction, about EDA tackling embedded software. Worth reading.

Note that I do not say that hardware and software engineers should use the same programming languages as a result of using virtual platforms. Programming languages efficient for hardware design are quite different from those efficient for virtual platform creation, which are in turn different from good software engineering languages.  In some cases, some of them coincide, but in general, I believe in using the best tool for each job, and a programming language is just a tool. And the more designed it is for its task, the better. Some older posts of mine on this topic:

• DSL: Purpose-built languages
• DSL: The tyranny of syntax
• Multicore programming and DSLs
• What is the obsession with C in EDA?
• Kunle Olukotun on DSLs
• Modeling hardware at a high level for software development

And there is the ChipDesign article from last year about using virtual platforms in the hardware design process all the way out to customers.

His experience is just like mine: programmers create the tools they need to solve a problem, and over time, certain useful point solutions get generalized and suddenly appear as full-blown or semi-full-blown languages. He traces the interesting case of the UNIX “adb” debugger “macro language” from its beginnings as list of very simple operations in the PDP “odt” debugger (octal address plus single-character operator) to something that was used to encode quite complex OS kernel inspection operations in Solaris. And how he found it necessary to provide an implementation of the adb macros for the mdb debugger created for the Solaris 64-bit port. Good tools just won’t die…

Another point that I had missed but that really shows the prevalence of domain-specific languages in highly complex systems and advanced development practice is that Solaris 10 shipped with a few new languages added. The “D” language used for dTrace is the best-known example, but there were a few other ones as well… It sounds like the point I made at a DATE 2008 panel debate (last year, missed this year due to conflicts with other duties in my life) where I took issue with the idea that “embedded software is written in C or C++” and said that “any real system contains at least 10 different languages” and that “there is a zoo in there”.

The last important point, I think, made in the article is the common design pattern of taking the expression syntax of an existing language and use that as the core of a domain-specific language. C is especially popular for this, since it also makes compiling simple: just generate a C-language program containing the snippets of C expressions in your language (the yacc model). It also avoid reinventing the wheel…

So overall, I found this article a very interesting read, not the least thanks to its long historical view of language design and tools.

The best bit is the discussion around named parameters and how that was introduced into Visual Basic for Application in Excel — and at the same time they reduced the argument counts to most functions by replacing them with manipulating properties of objects. I think that approach does make some sense, if you have something that lends itself to that kind of expression. Their comparison of having a single function call with 83 arguments to change the style of text in Word by silently effecting a dialog box, or actually setting each of 83 properties of a dialog box object makes eminent sense… Sense that applies to simulators as well: in Simics, we do have a system like that, with attributes on all objects in the simulation that can be set to change their behavior and connections. Trying to configure that in the SystemC-style with function calls and constructors from scratch would be a pain, definitely.

Another topic that struck a chord with me was the notion that we are moving towards a world of “little languages” built for particular purposes. I definitely think this is the right way to go, as domain-specific languages do make getting particular things done easier. The more general a language is, the worse it is at any particular task. Better then to use a smaller language built to do one thing. As Jeff put it, for databases uses SQL, for text processing using Perl, etc… Using a multitude of languages is the hallmark of good software design and a natural instinct for a computer scientist.

They also found a YouTube video of the old computer science (CS) song “Write in C“. They do not seem to get that this is a really old song, I remember singing it way back when I was a fresh undergrad CS student here in Uppsala… and it was part of the first edition of our nice leather-bound songbook called “Manualen”. The lyrics are starting to feel a bit dated, but it is still a very elegant piece of writing that I think took place in the mid-1980s, judging from the other languages referenced.

Anyway, an unusually listen-worthy edition of Stackoverflow.

Kunle Olukotun‘s presentation on the work of the Stanford Pervasive Parallelism lab included a diagram where they showed a range of domain-specific languages (DSL) being compiled to a universal implementation language. That language is currently Scala, and in the end all applications end up being compiled into Scala byte codes, which are then optimized and dynamically reoptimized and executed on a particular hardware system based on the properties of that system. Fundamentally, the problem of creating and compiling a DSL, and combining program segments written in different DSLs, is solved by interposing a layer of indirection.

But this idea got me thinking about what the best such intermediary might be for large-scale general deployment.

And my conclusion is that the Java Virtual Machine might be the best candidate. Not the JVM as it is today, though. Here is my idea:

• The Sun Java JDK and its optimized HotSpot VM is now open-source, thanks to the OpenJDK. This opens the door to new innovation based on solid technology.
• The HotSpot is a pretty good VM, and therefore other languages are starting to use it as a potential backend. For example, Python can be compiled to the JVM, as can Ada, and I expect many other language environments to follow suit. The reason is that developing and optimizing a VM is hard work, and if there already is a good one in existence, targeting that is easier than doing you own.
• I think that long-term, this might well replace C as the universal language that you target when you do special-purpose code generators from custom languages… which are really DSLs.
• Thanks to this foreseen ubiquity of the OpenJDK JVM as a universal byte-code execution machine, it will provide a single point of leverage across a large range of applications in a multitude of programming languages.
• As demonstrated by the work of the PPL and the approach taken by RapidMind, the idea of using an abstract byte code for software delivery makes very much sense in a heterogeneous and networked environment. It also provides a good infrastructure for analysis and optimization. It simply is very sensible.

However, the JVM as it stands today is not really suitable for this. It will need some extensions, which I am not the man to invent. With an open-source common JVM, such innovation will be easier to do. Thanks to Sun for opening up Java! For example:

• Support for dynamic languages like Ruby and Python: not the same dependence on Java-type static typing and Java types. They work well for Java, but less so for other languages. It would be nice with lists for real as well, and not just as a library container.
• Support for threads. Not OS threads, but the typical very light-weight threads used in environments like Erlang and OZ. Or even lighter, like the serial units of computations in the kernels of RapidMind and CUDA and similar GPGPU efforts.
• Support for SIMD operations, to express data-level parallelism which is often pretty easy to find on a source-code level.
• Support for data blocking, locality, tiling of some kind, to control data locality. Maybe this already exists in X10 (which I heard about at last year’s Multicore Day).
• Support for communication using messages, and I assume that the best model for expressing the threads is through local data, share-nothing, message passing. With a special case for sharing large data blocks.
• Some kind of data sharing mechanism that is more structured and understandable for a runtime system than pure locks & shared data.
• And a system that takes such an advanced byte code and makes it run well on any particular machine, be it a Tilera Tile, an 8-core P4080, a 128000-core BlueGene, a GPGPU, or a plain middle-of-the-road UltraSparc T2.

So there is some work to be done. But I really think this idea has some merit… if only I had research funding and some good students. Or a crazy VC.

The interesting material in the article is the background on WHY he thinks that this is the case. He points to the immense popularity and rise of scripting in much of computing land. In the past ten years, it is clear to him (and I would agree with this too mostly) that languages like Perl, PHP, Awk, Ruby, JavaScript, and Python have eclipse Java and C++ as the most interesting and important programming languages for many practical tasks. Especially for web applications, where Java seems to have a presence but noone would dream of using something as clunky and impractical as C.

What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…

The reason that scripting languages have gotten so popular is primarily that they let you get the job done faster. In web land, this is due to a few important factors listed or hinted at in the article:

• The overall code tends to be shorter and more to the point
• A tendency to make any value into a string when needed (excellent debugging aid)
• Dynamic typing, variables that just appear when needed
• Automatic memory management
• Ease of handling strings
• Most tasks are pretty short
• Performance of computation does not matter very much when processors are as fast as they are today and a single disk or network access operations is likely to dominate programming time

What the article continues with a discussion that we need to focus on programming language pragmatics rather than syntax or semantics. How practical is the language for the everyday tasks of a programmer? And it seems that simple darwinian evolution has propelled scripting-style languages to the top of heap here. Purity and elegance and deep semantical properties are obviously less important than getting the job done in the shortest time possible.

What can this teach us modeling folks?

• A key takeaway is the focus on short code. Code has to be short and focused to be quick and easy to write. You should not need to consult several header files and lots of documentation to understand and formulate your code, which is an ill that keeps hitting C and C++ programs.
• Memory management has nothing to do in a productive programming environment.
• Basic types have to be appropriate to the task at hand.
• Syntax has to be concise and powerful.
• Dynamic typing is much faster to code with than static typing and variable declarations.
• An interactive “try it out” environment is preferable to long compile/link/test cycles.

Obviously, some of these do not translate well into hardware modeling. Hardware entities tend to have very-well-defined types by nature. If I have a 16-bit register containing a 13-bit counter and three status bits, I cannot very well let that counter be a dynamic variable that can take on any numeric value. Or the atom “foo”. It kind of has to be restricted in semantics to how the hardware would behave… it is not just a “value” to be manipulated quite abstractly. Which means that what you probably rather need are types well-suited for the task at hand.

It is also nice if variables can just pop into existence when needed, with the least amount of declaration possible. Another C-family performance killer is the annoying need to declare a function before calling it. That made sense in linearly scanning compilers back in the 1970s, but today, just let the compiler take the entire program into account and find the function. It is not that hard, especially not for the quite small and isolated context that a virtual platform device model is (few device models are more than a few thousand lines of code in my experience).

The interactive nature of scripting is also interesting. The ability to just write new code directly into a running system without an explicit compile usually rests on a virtual-machine approach and does have some cost in terms of performance. And unlike webservers, virtual platforms need all the raw CPU performance they can get! However, it make excellent sense to use an interactive environment to prototype and test things, and then move the resulting code to a harder compile stage.

Right now, we really do not have such a tool at hand. Virtutech DML is in my opinion the most promising step along this road, but it is not really “perl for modeling” at this time. SystemC has too many C++ roots to really behave well in this respect… you get all the drawbacks of explicit memory management, rampant headerfiles, and statically declared types. It might be good to compile, but it sure is an absolute pain to write.

And if we want virtual platforms to really fly, it is not so much “all about the models”, but really “all about model programming” — since there is a huge volume of models that need to written out there, and getting the time needed to write these models down is a primary concern. The total work invested in modeling any particular device is what we need to focus on, really.

The themes are:

• The way there is to provide programming environments that express algorithms in a way that is clear in terms on intent but that does not constrain the implementation too much. It should hide parallelism to the user, and make that a property of the compiler and implementation, not the program. But to make this work, you need higher-level expressivity. For example, Kunle says that you want to say “do a matrix multiply” rather than “here is a pile of loops and expressioins implementing a matrix multiply”. Very sensible.
• The proper way to do parallel programming this is to be domain-specific. Create domain-specific languages that map to how domain experts think about a problem, and then have a compiler and runtime take care of how to implement it for a particular machine. Rather than provide a low-level language that lets you express parallelism explicitly, like CUDA, Brook, threading libraries, etc, you should be using MatLab if you are doing science (which is something that National Instruments have been doing with their LabView tools).
• Future hardware will be heterogeneous, with a mix of control-oriented simple cores (Niagara-style), data-processing-oriented cores (DSPs, security accelerators, etc.), and the occasional heavy-weight ILP-oriented core (Intel Core 2-style) for the occasional program that just needs maximal single-thread performance.
• Operating systems today were created in an era where processors were precious resources that had to be efficiently shared. This is no longer really the case, it makes sense to dedicate single cores to single tasks for extended periods of time, as this maximizes efficiency. There are cores to spare, no problem on that accord. Nice to hear this from a general-purpose proponent, and not just embedded people.

I fully agree with all of these, and I find the use of domain-specific languages and frameworks especially important. Software people in all ages have become more efficient by designing better languages, more suited for a particular task than a very general language. A language is a just a tool, after all, not a religion (even if some people seem to view it that way), and should be changed depending on the task at hand.

Final note for us embedded folks: when Kunle talks about how he realized around 1995 that lots of simple processors on a chip becoming feasible thanks to Moore’s law, the first real multicore chips were already shipping. Motorola had the QUICC 68000+CPM heterogeneous network processors on the market by then, and Texas Instruments had the C80 four-simple-DSPs-plus-a-simple-RISC multicore chip for digital video also out. But the ISCA crowd really did not notice this development at all, at the time.

Obscure note two: Virtutech Simics was actually used by Afara to help in the design work of the Niagara, since Simics had very good support for 64-bit SPARC architectures thanks to the early work done with Sun.