Comments for Observations from Uppsala

Comment on Kindergarten Robot 2: Going Programmable by Observations from Uppsala » Kindergarten Robot 3: Programming is Kid’s Play

Tue, 09 Mar 2010 16:40:29 +0000

[...] I finally got to try my MEPROM-equipped Lego Mindstorms robot with a larger group of kids. As expected, this did not go quite as [...]

Comment on Kindergarten Robot by Observations from Uppsala » Graphical Programming in (Mis)use

Observations from Uppsala » Graphical Programming in (Mis)use — Tue, 02 Mar 2010 21:20:58 +0000

[...] I got the Lego Mindstorms robotics kit that I have been blogging about before (1,2,3), one of my goals was to try my hands on some graphical “model-driven” programming. [...]

Comment on Concurrency in Lego Mindstorms NXT by Observations from Uppsala » Graphical Programming When It Works… or Not

Tue, 02 Mar 2010 21:13:01 +0000

[...] I got the Lego Mindstorms robotics kit that I have been blogging about before (1,2,3), one of my goals was to try my hands on some graphical “model-driven” programming. [...]

Comment on SAAB no more by Jakob

Jakob — Thu, 25 Feb 2010 11:45:00 +0000

I am happy to have been proven totally wrong on this post. For some reason, Dutch supercar maker Spyker has bought SAAB, and the deal is finally final yesterday. All my best wishes to SAAB! I really hope they can do something clever and unusual, and beat the odds that they are too small to survvive. Maybe they can be small enough to prosper in some good niche.

Comment on Kindergarten Robot 2: Going Programmable by Jakob

Jakob — Mon, 22 Feb 2010 19:26:40 +0000

Unfortunately, there is no lamp included in the Mindstorms kit. The lamp is the color sensor, and it is lighted to detect the colors. I fear that putting a box around it all will just make everything appear black to the robot. Still, the color sensor is a huge step up from the old light sensor on the RCX.

Comment on Kindergarten Robot 2: Going Programmable by Jan Tångring

Jan Tångring — Mon, 22 Feb 2010 07:55:05 +0000

Konstant ljus, dvs exempelvis bygga in läshuvudet i en svart låda med innerbelysning? HAr du testat det för att lösa färgavkänningsproblemet?

(ENGLISH: Constant lightinng conditions — did you try that for the reading color problem? E.g. enclosing the color sensor in a tight box which has a built in light.)

Comment on Kindergarten Robot by Observations from Uppsala » Kindergarten Robot 2: Going Programmable

Observations from Uppsala » Kindergarten Robot 2: Going Programmable — Sun, 21 Feb 2010 20:32:07 +0000

[...] discussed in my previous blog post about Kindergarten robots, I wanted to see if I can teach kids the core idea of programming. This [...]

Comment on Contributing to the Reversible GDB by Jakob

Jakob — Wed, 17 Feb 2010 19:20:29 +0000

Eclipse support is up to the Eclipse guys now. MI is the way that Eclipse drives gdb today, so with reverse support in MI, Eclipse should be able to finally use it.

But Eclipse has nothing to do with gdb per se, they are totally separate projects.

Comment on Contributing to the Reversible GDB by Eclipse

Eclipse — Wed, 17 Feb 2010 17:58:21 +0000

How about Eclipse support?

Comment on Describe is not the same as Design by Jakob

Jakob — Tue, 16 Feb 2010 07:04:05 +0000

Everett Lumpkin : I suspect that the Carbon folks may disagree with the sentence “There is no automagic getting to a fast abstract model from a design-oriented description.”

I don't think so. They are perfectly clear that their models are in the 10KHz range, at best, while a fast simulation is at 100MHz to 1GHz... faster than RTL certainly, but not a fast virtual platform by any stretch.

While not really a language should we consider the meta-data of IP-XACT also as a “description language”?

It lacks semantics for the registers, so let's say it is half a description language.

Comment on Describe is not the same as Design by Everett Lumpkin

Everett Lumpkin — Tue, 16 Feb 2010 04:03:53 +0000

I like your comparison of a “design language” vs. “description language”, and one of the faults of systemC for target software simulation is the (miss) use of the abstraction level I’ve heard referred to as systemC-ilog. It is just too common to create systemC models at too low of a level of abstraction for target SW simulation. Maybe Simics DML is a solution, but currently proprietary?

I suspect that the Carbon folks may disagree with the sentence “There is no automagic getting to a fast abstract model from a design-oriented description.”

While not really a language should we consider the meta-data of IP-XACT also as a “description language”?

Comment on The Dream ESL Language by Observations from Uppsala » Describe is not the same as Design

Observations from Uppsala » Describe is not the same as Design — Mon, 15 Feb 2010 20:56:44 +0000

[...] discussion on my previous blog post about “the ideal ESL language” made me think some more about the purpose of a hardware modeling or description language. If [...]

Comment on The Dream ESL Language by Jakob

Jakob — Mon, 15 Feb 2010 20:56:14 +0000

Synthesizability is an interesting requirement. I think there is a fundamental problem with requiring that, as it makes the language too much geared towards hardware and much less into a software language. You want to able to stub things, use arbitrary data structures, etc.

Comment on The Dream ESL Language by Rishiyur Nikhil

Rishiyur Nikhil — Thu, 11 Feb 2010 03:44:22 +0000

Jakob, thanks for referring to Bluespec as “cool”! I fully agree with your desideratum: “Basic semantics given by a virtual machine”. The semantics of BSV (Bluespec SystemVerilog) are explained and understood in terms of an abstract collection of atomic rewrite rules operating on abstract state in abstract discrete time. We have gone through at least three radically different surface syntaxes for the same basic semantic idea, initially a Haskell-like syntax before Bluespec, Inc. was founded (which today we fondly refer to as “Bluespec Classic”), and now BSV which builds on SystemVerilog notations. For a while we even had a syntax based on SystemC (called ESE).

Regarding reflection and introspection in BSV, rules, functions, modules, and interfaces are first-class data types and are completely manipulable using higher-order functions during static elaboration. The FSM embedded domain-specific language in BSV, and our recently announced “PAClib” library (Pipeline Architecture Composers) makes extensive use of this capability.

Another desideratum I’d add is “full synthesizability”, so that even very high-level models can be mapped easily to FPGA/emulation platforms, thereby exploiting their parallelism to provide, effectively, VERY fast simulation.

Comment on The Dream ESL Language by Jakob

Jakob — Sun, 31 Jan 2010 08:41:19 +0000

But SystemC is far from a good language, as it is based on the quite old-fashioned C++ core language. No reflection, no support for running on virtual machines, no automatic memory allocation, horribly intricate semantics, no dynamic linking and loading of modules at runtime, … so I feel we need something better for people to actually program in. It is just not modern enough to be a good language for actual programming of models.

Comment on The Dream ESL Language by Ran Avinun

Ran Avinun — Sun, 31 Jan 2010 00:26:52 +0000

It seems like SystemC is emerging as the key language for ESL design being used for new IP design entry level, architectural analysis and virtual prototyping with link to implementation and verification. Read more info at my blog at http://tinyurl.com/ydf8pjx

Comment on Neat Register Design to Avoid Races by Richard Carlsson

Richard Carlsson — Fri, 29 Jan 2010 15:01:37 +0000

Hm. Interesting… assuming Moore’s law is still a good predictor, that would mean we’ll start hitting 64 bits somewhere around 2046. Let’s see: 40 bits today makes 60 years, which brings us back to 1950. Yep, almost spookily accurate.

Comment on Conquering Software with Software High-Level Synthesis by Observations from Uppsala » Neat Register Design from Gary Stringham

Observations from Uppsala » Neat Register Design from Gary Stringham — Thu, 28 Jan 2010 18:59:59 +0000

[...] devices get defined in successively higher-level languages (C, C++, UML, MatLab, …), and their programming interfaces and associated drivers get autogenerated, this solution makes eminent sense. Leave a comment | Trackback No comments [...]

Comment on I Got a Yubikey! by Katton

Katton — Thu, 28 Jan 2010 10:09:37 +0000

Have found an interesting information regarding YubiKey and Umikey, both OTP tokens. Now I have some doubts about them being secure – http://www.rohos.com/2010/01/umikey-otp-authentication-token/

Comment on Off-Topic: Vista, Laserwriter 12/640 PS, and FoxIt by Jakob

Jakob — Wed, 20 Jan 2010 19:21:54 +0000

Note that there is a tip at http://lawngnomemafia.com/flowergarden/?p=169 that suggests using the HP “LaserJet III PS Cartridge v52.2″ driver with the similar LaserWriter 16/600. I have tried this, and on my Vista 64 machine, this did produce noticeably smaller print files. About half the size for some graphics-heavy Word documents.

FoxIt works great to make PDFs printable still, reducing files from 20 MB+ to 200 kB.