I'm currently using achronous in the paper -- it seems to fit well, and has the benefit of not having large numbers of confusing overloaded meanings. It's quite likely that we'll stick with it, but I have a few more days before I have to submit the final version to the journal.
What we're doing is basically a huge land-grab of techniques used to analyse (as in predict) the behaviour of an important class of electronic circuits -- we've come up with a very general framework which subsumes nearly all existing work as special cases, whilst also allows a few new things to be proven. This kind of thing happened in the analysis of software in the 1970s, but for some reason no one has attempted this for hardware. So we have. It's a bit scary, and (it seems) not too popular from some people in the hardware community, especially as we're seen as coming from the software world.
We are Borg! Resistance is futile! All your analyses are belong to us!
OK, specifically what I mean by 'achronous' is essentially to coin a new technical term that describes all analyses of circuits that do not take into account absolute time. As a simple example, if you turn on a light at 8am tomorrow morning, an achronous analysis of what was going on would simply say that the light transitions from off to on, whereas a non-achronous analysis might record the exact time at which the light turned on, or perhaps note that the light will be turned on strictly after you get out of bed and strictly before you brush your teeth.
Our kind of 'achronous' analysis, for obvious reasons, is quite abstract, but it can be proven correct, and is also capable of telling you what range of possible behaviours might occur. In a more real application, one might use this kind of technique to determine whether a particular unwanted case could ever possibly arise, such as (for example) an aircraft going outside its design parameters in response to incorrect pilot input. I know the people (at Ecole Normale Superieure in Paris) who are doing exactly that kind of stuff for the Airbus flight software at the moment, using closely related techniques. I also know people at NASA using it to validate the flight software for the Mars Exploration Rover project (aka Spirit & Opportunity), so this is all actually quite current and happening stuff.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2005-11-23 09:19 pm (UTC)What we're doing is basically a huge land-grab of techniques used to analyse (as in predict) the behaviour of an important class of electronic circuits -- we've come up with a very general framework which subsumes nearly all existing work as special cases, whilst also allows a few new things to be proven. This kind of thing happened in the analysis of software in the 1970s, but for some reason no one has attempted this for hardware. So we have. It's a bit scary, and (it seems) not too popular from some people in the hardware community, especially as we're seen as coming from the software world.
We are Borg! Resistance is futile! All your analyses are belong to us!
OK, specifically what I mean by 'achronous' is essentially to coin a new technical term that describes all analyses of circuits that do not take into account absolute time. As a simple example, if you turn on a light at 8am tomorrow morning, an achronous analysis of what was going on would simply say that the light transitions from off to on, whereas a non-achronous analysis might record the exact time at which the light turned on, or perhaps note that the light will be turned on strictly after you get out of bed and strictly before you brush your teeth.
Our kind of 'achronous' analysis, for obvious reasons, is quite abstract, but it can be proven correct, and is also capable of telling you what range of possible behaviours might occur. In a more real application, one might use this kind of technique to determine whether a particular unwanted case could ever possibly arise, such as (for example) an aircraft going outside its design parameters in response to incorrect pilot input. I know the people (at Ecole Normale Superieure in Paris) who are doing exactly that kind of stuff for the Airbus flight software at the moment, using closely related techniques. I also know people at NASA using it to validate the flight software for the Mars Exploration Rover project (aka Spirit & Opportunity), so this is all actually quite current and happening stuff.