 Sugar 2.0 tutorial
started 5/14/2002; 12:53:34 PM - last post 5/16/2002; 8:54:56 PM
|
|
Chris Rathman - Sugar 2.0 tutorial 
5/14/2002; 12:53:34 PM (reads: 1768, responses: 6)
|
|
| Sugar 2.0 tutorial |
|
Don't know if hardware specification languages fall under the guise of programming languages for LtU, but it's always interesting to compare the formalness of these with the looseness of software programming languages. I suppose that the ultimate goal of computer science is to get software engineering up to the same level of rigor.
Sugar is a language for the formal specification of hardware. It is used to describe properties that are required to hold of the design under verification.
Sugar consists of four layers. The boolean layer is comprised of boolean expressions. The temporal layer consists of temporal properties which describe the relationships between boolean expressions over time. The verification layor consists of directives which describe how the temporal properties should be used by verification tools. Finally, the modeling layer provides a means to model behavior of design inputs, and to declare and give behavior to auxiliary signals and variables.
I can't help but think that this has parallels with declarative programming languages and Design by Contract.
Posted to Logic/Declerative by Chris Rathman on 5/14/02; 12:57:33 PM
|
|
|
|
Ehud Lamm - Re: Sugar 2.0 tutorial
5/14/2002; 1:41:13 PM (reads: 980, responses: 0)
|
|
|
The temporal part is, of course, the most interesting. It is quite common these days to use temporal logic (e.g., LTL or CTL) to give hardware spcification. The logical formulas are then checked using the techniques of model checking.
Doing the same thing with software is more problematic, mostly because of the state explosion problem.
|
|
Keith Devens - Re: Sugar 2.0 tutorial
5/16/2002; 12:54:33 PM (reads: 953, responses: 1)
|
|
|
I'm late, this post has been around for a few days. Finals kept me from posting. Hopefully someone will see this and respond:
I've been wondering about this for awhile. **Why is hardware development more advanced from an engineering perspective than software development is?**
Is developing software fundamentally harder in some way, or are hardware developers just smarter - or have they had longer to formalize their work. Or, are they less held up by market constraints to use the neat new language proposed by some BigCo that's going to take over the world (Java, C#, etc.)?
|
|
Albert Y. C. Lai - Re: Sugar 2.0 tutorial
5/16/2002; 6:12:42 PM (reads: 937, responses: 1)
|
|
|
> Why is hardware development more advanced from an engineering perspective than software development is?
Because hardware is developed by accredited professionals who have received bona fide engineering training, and software is developed by alchemists who want to be called "software engineers"?
This view is of course extremist, and I personally hope it is not true. But Edsger Dijkstra has been holding this view for decades, and when I think about it, there is some sad truth in it. David Parnas also holds this view to some extent, but mildly and positively: he does not just complain about the status quo, he actually suggests methods in detail and carry out case studies to show the effectiveness of his methods. He also has a complete blueprint of a software engineering curriculum that deserves the name "engineering".
Other than that, the reasons you mention, except for who being smarter and which one being harder, are also true.
Admittedly, some software projects are harder than the hardest hardware projects, simply because we expect so much functionalty out of software. Linux is certainly more complex than P4. But equally well, many software projects are much simpler than many hardware projects, yet the former are miserable and the latter are reliable. Firmware for controlling the transmission system of a car ought to be simpler than the hardware chipset of your motherboard, I would bet, (and if not, I can try harder and find a better example), yet we still hear that car firmware needs replacement, showing that software development is still kept a black art even in the case it is simple enough to admit, and critical enough to demand, rigorous analysis by mathematics and logic.
|
|
Chris Rathman - Re: Sugar 2.0 tutorial
5/16/2002; 8:54:56 PM (reads: 890, responses: 0)
|
|
|
One other factor to consider is that EE's (at least of the Digital variety) are doing mostly what might be considered to be software - with programmable logic.
Spent many an hour with EE's staring blankly at oscilliscopes and logic analyzers, trying to find those glitches in the hardware (or embedded software). Wish all software design had tools which were as precise at locating coding bugs. Software debugging tools and profilers are rather crude in comparison.
|
|
Ehud Lamm - Re: Sugar 2.0 tutorial
5/16/2002; 9:30:22 PM (reads: 964, responses: 0)
|
|
|
In many respects sw is fundamentally harder (state space is larger, outside intefaces less welll defined, no formal specfication etc.)
|
|
Ehud Lamm - Re: Sugar 2.0 tutorial
5/16/2002; 9:34:10 PM (reads: 974, responses: 0)
|
|
|
Notice that there are two separate issues here: (1) Is sw fundamentally hardr (Yes) and (2) Is hardware design more mature, uses more robust methodologies and tools (also Yes).
|
|
|
|