About Esterel

I have long been nurturing a keen interest for all software that strays away from traditional software. 90% of the software currently written worldwide is

• imperative programming, as opposed to functional or declarative programming
• destined for sequential execution rather simultaneous / parallel execution
• manipulating discrete data (discrete signals) rather emulating continuous data (analog signals)
• respecting best effort execution time constraints instead of real time execution constraints (is this the same as sequential vs. parallel ? not quite : here it's about how software deals with inputs and the notion of time; there it was about how the resources are alloted to each task)
  

So I've looked into the reason and meaning the Esterel and Lustre languages. I have first heard about Esterel in university. I was studying telecommunications, with a major in optical, RF and microwave transmissions. So software was not really my cup of tea.

But one day the optics teacher said: "In order to become an optical networks engineer nowadays, there are a sum of skills to posess : a pinch communications theory, a drop of digital electronics, a whiff of programming".


I took a course in digital electronics, where I learned about hardware description languages, in particular Verilog and VHDL. The 'synchronous processes' paradigm that is characteristic to hardware was so much more appealing to me than old fashionned 'shoot and reload' approach of all interpreters, compilers and the like.

Later I went on to discover VHDL-AMS and the description of continuous-time, continuous-data systems. AMS stands for Analog and Mixed Signal. The world in which we live - sounds, light intensities, temperatures, concentrations, efforts, translations - are all analog signals, so suddenly software was no longer restrained to a 0 and 1 abstract space; it was so much closer to how I knew, felt and experienced the world due to my physics-oriented training.

Now back to Esterel ! Far as I have understood, it's meant to be a description language, just like VHDL, but on a higher abstraction level. It features a much facilitated description of parallelism. However Esterel is not just about specifying RTL netlists; it is meant to describe all possible finite state machines (FSM, automata), wether their implementation is to be written in software or in hardware.

"Esterel compiler[...]translates programs into C for simulation or software implementation and into Verilog or VHDL RTL-logic for hardware synthesis."

The designer can then chose which part of the automata is implemented software and which in hardware :

"One can use Esterel to first implement or simulate a system entirely in software, validate it, and then automatically turn it to hardware. Such a flow has many desirable properties, including the ability to keep a single specification for hardware and software while formally guaranteeing the same behavioral properties of the design. Furthermore, one has a lot of flexibility to partition the system description so that some of it is realized in hardware and the rest is mapped to software."

(from 'System Level Design and Verification Using a Synchronous Language', G. Berry, M. Kishinevsky, S. Singh)

In fact the role of Esterel is similar to other high level system description languages, such as SystemC and System Verilog. And its specificity with regard to those languages lies with its being a 'formally defined' language, which facilitates the formal verification of the described automata. I.E. ensuring that the computer behaves as expected, under all circumstances.

As to Lustre - it is also a synchronous programming language, but unlike Esterel - which is imperative, Lustre is a declarative language. Since it's been developped by the same company, I guess it is safe to assume that it is complementary in purpouse to Esterel.

For more insight into these languages, some in depth reading and coding practice is probably required.

Internal Combustion Engines and vibration

Today I've done some reading about the conversion of mechanical effort, from a translation setting - linear applied force, and linear movement - to a rotational one : torque and spinning motion.

What I had in mind is a piston, with a connecting rod and a crank that drives a wheel around an axis. The typical mechanism you see in a steam engine.

Then, while exploring the subject, I've realised that car engines are built mainly on the same principle, although they have -nowadays - not one, but 4, 6 or 8 pistons. As I had suspected, a single piston does a very imperfect conversion of mechanical power. Some of the translational effort is lost in the process, through friction or - even worse - vibration. I found out that the supression of the vibration movements that come from piston motion in an automobile engine is quite an engineering topic. It is called engine balancing or - as refering to what it is meant to achieve instead of the process itself - engine smoothness.
Better balancing of the engine means energetic efficiency - thus lower fuel consumption, - less mechanical stress on the crankshaft and pistons - therefore a car engine that lives longer - and, last but not least, less noise and vibration for the driver to endure. The gains become all the more important when the engine is designed to run at high rev.

The balancing of an engine is mainly an issue for the engine designer - who decides how many pistons, and their relative configuration - V, W, straight or boxer - as well as complementary balancing mechanisms, such as flywheels and balance shafts. But it is also a puzzle for the mechanic who tunes the engine: the balance is initially calculated for an engine with all its original parts. If some parts are replaced or simply become loosened through use, then a retuning becomes crucial.

Your usual car cruises between 2 000 and 6 000 rpm, but Formula 1 racing monsters can handle up to 20 000 rpm. When the rev doubles the centrifugal / centripetal efforts on the rotating parts quadruple ! Needless to say that F1 cars use the most accurate balancing techniques. And in spite of that end up in a museum (at best) after only a few races - well, engine wear-off is not the only one responsible for their demise. It would be actually interesting to know what can still be used from a racing car when it is deemed to be no longer fit for competition.

Back to engine smoothing ! The subject is vast; I'll come back to it later, perhaps with some math in support, to give a feeling of the challenges involved.

Definition of an interface

The blog is dedicated to displaying my personal areas of interest in science and technology, under a particular type of classification, based on interfaces between scientific domains, technology fields ar merely physical world aspects.

An academic definition of the word "interface" can be found here. What I focus on in the meaning of word interface are the "boundary surface" aspect as well as the "communication or interaction" aspects.

Let's have some examples of "interfaces" I'd like to explore in this blog.

• science / technology - those two domains have a common aspect, which is the manifestation of human knowledge and intellect. However, just like two phases of chemical a substance, there are very different laws governing each of them. Science and scientists are driven by the knowledge, understanding and explanantion of the (physical, social, economic ...) world in which we live, while technology and 'techies' are bent upon acting and modeling the world to their needs, views or ambitions. But here comes into play the 'communication' and 'cooperation' meaning of interface : for science to become ever more knowledgeable, complex measurement and observation tools need to be built (like the electron microscope or the LHC); these require a great deal of technology effort. Also, science needs to rely on complex social structures and organization to provide an environment for the most talented scientists to fulfill their goals. On the other hand, complex technical realizations are upon rigourous fundamental-science studies and theories. And the social hierarchy and structures ( companies, NGOs, governments, teams ) benefit from the development of social sciences.

So, basically what characterizes an "interface" is

1. two domains of equivalent importance that share some common aspect
   
2. very distinct laws that govern the cores of the two domains
3. a vague, changing, ambiguous frontier between the domains
4. a continuous give-and-take exchange, communication between them

Other examples:

• social sciences / exact sciences

• formal sciences / natural sciences

• technical language / commercial language

• technical innovation / commercial innovation

Within the technology branch:

• rotational motion / translational motion

• air / water (or gas / liquid)

• software / hardware

• digital / analog

• mechanical / electrical

Within sciences :

• biology / chemistry
  

• chemistry / physics