1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Chipvalidierung: ARM kauft Obsidian

Wer glaubte nicht an Verifikation ?

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema

Neues Thema Ansicht wechseln


  1. Wer glaubte nicht an Verifikation ?

    Autor: Thread-Anzeige 21.06.11 - 14:25

    Vor 50 Jahren schon wurde Software bewiesen. Das geht schon ewig. Aber das macht keiner und hat keiner gelernt. So wie beispielsweise Typografie.

    Java erbringt das bald vielleicht. Hoffentlich setzt sich das im Zusammenhang mit den blöden Sicherheitslücken-Meldungen durch. Vielleicht hat Oracle auch Abkommen mit M$ um Beweisbarkeit zurückzuhalten.
    Schon seit Jahren sollte keine unbewiesene Software mehr bei Ausschreibungen den Zuschlag kriegen.

    Software wiederbenutzt man weniger, weil man sie nicht neu tippen muss, sondern weil man sie nicht neu testen muss.

  2. Re: Wer glaubte nicht an Verifikation ?

    Autor: Specman_Fan 21.06.11 - 16:25

    Erstmal hallo!

    Ich denke man sollte hier ein bischen genauer nachfragen, was die von ARM gekaufte Firma eigentlich macht.
    Es handelt sich hierbei um funktionale Verifikation von Hardware Modellen (im Fachjargon auch RTL oder HDL Modell). Dies hat erstmal nichts mit Software im Sinne von Oracle und MS zu tun, sondern zielt darauf ab zu testen ob die entsprechende Modellierung eines Chips funktional korrekt ist.
    Ich kann zu diesem Thema auch nur empfehlen sich mal eine Sprache für diesen Zweck anzuschauen:

    http://en.wikipedia.org/wiki/E_%28verification_language%29

  3. Re: Wer glaubte nicht an Verifikation ?

    Autor: Thread-Anzeige 21.06.11 - 18:17

    Das sind halt die unteren Stufen wie z.b. im ISO-Layer-Modell.

    Ganz oben die Stufe ist "Wir wollen eine ARM-CPU für ein Android8.0-Tablett, das dem Ipad3 endlich mal das Wasser reicht". Das zerlegt sich dann immer weiter je tiefer man kommt.
    Das Problem ist ja immer, ob man beweist, was man wirklich will.
    Das Problem ist also eher die Frage und weniger die Antwort.
    Viele scheitern aber schon an der Antwort.

    Davon abgesehen funktioniert die CPU bei Übertaktung oder Überhitzung auch nicht mehr. Oder wenn man "Pech" hat und der längste Pfad (analoger Transistoren) zu langsam ist. Und sowas wie der längste Pfad ist halt genau so wichtig.

    Test ist wohl mit das teuerste an der Produktion. Das ist wieder eine andere Baustelle. 100% bewiesen nutzt ja nix, wenn die Produktion so fehlerhaft ist wie bei FERMI (?) von Nvidia war. Da lassen sich auch Fehler vermeiden durch anderes Design. Die Grenzen zwischen den Layers der Beweisung bzw. Validierung sind also fliessend.

  4. Re: Wer glaubte nicht an Verifikation ?

    Autor: SCF 21.06.11 - 19:02

    Fermi war nicht fehlerhaft im Sinne der Korrektheit. Fermi hatte nur "Fehler" die dazu geführt haben, dass der Chip zuviel Strom säuft und zu heiß wird. Die Frage ist dann, ob die Verifizierungssoftware imstande ist, auch solche "Fehler" zu erkennen.

  5. Re: Wer glaubte nicht an Verifikation ?

    Autor: Thread-Anzeige 21.06.11 - 19:26

    Produktions-Fehler und Design-Fehler.
    Verifizierung und Validierung betrifft eher nur Design. Man kann allerdings auch Designs machen, die z.b. weniger agressiv sind oder andere kritische Pfade haben, so das weniger Chips weggeworfen werden müssen.

    Konkrete Chips überprüfen nennt man "Test". Das kostet viel Zeit für nen ganzen Wafer und ist daher nicht zu vernachlässigen. Bessere Erklärungen sicher bei Wikipedia. (Auch wegen Verifikation vs. Validierung).

    Architekten-Plan und Statik sind ok (verifiziert). Böse Bauarbeiter machen ein Schrotthaus (Produktions-Fehler).
    Umgekehrt ist auch nicht besser: Mieser Plan => Mieses Ergebnis.
    "Die meisten und am schlechtesten/teuersten wegzukriegenden Fehler sind in der Planungsphase. Daher muss man von Anfang an draufschauen und nicht erst auf der Baustelle." (Bau-TÜV für ca. 3% des Hauspreises).

  6. Re: Wer glaubte nicht an Verifikation ?

    Autor: Specman_Fan 21.06.11 - 21:11

    Vom Entwicklungszyklus her gibt es leider noch viel mehr Fallstricke als nur die System-Architektur und den Software-Stack.
    Das Hauptproblem ist es die korrekte Integration der einzelnen Abstraktionsebenen. Jede Modellierungsebene ist ein in sich geschlossenes System und diese sind allein betrachtet schon schwierig genug... wer des Öfteren Spezifikationen liest weiß, wie vielfältig eine Beschreibungsweise ausgelegt werden kann, weshalb eben auf der unteren Ebene es so wichtig ist verschiedenartige funktionale Modelle gegeneinander abzugleichen um Missverständnissen vorzubeugen.

    Jedoch werden die Probleme dann richtig groß, wenn man verschiedene Modelle zusammenführen möchte, wie zB:
    ->analoge (full-custom) und digitalen Schaltkreismodellierungen
    ->taktgenaue und transaktionsgenaue Modelle
    ->mehrere konfigurierbare transaktionsgenaue Modelle im System
    ->Software die auf diesem konfigurierbarem System laufen soll

    Es wird zudem nicht einfacher wenn ein gewisses Zeitfenster von Konzeption bis Marktreife eingehalten werden muß und dann noch in einem globalen Team arbeitet.

    Sicher, es gibt eben durch vorgefertigte Komponentenblöcke (IP Blöcke) schon eine starke Zeitersparnis, aber wie schon gesagt, das größte Problem wird weiterhin die Kommunikation des spezifizierten Produktes und dessen Integration aller funktionalen Komponenten.

    In einem Satz, der menschliche Faktor ist das komplexeste in einem solchen Produkt und daher wird es niemals ein fehlerfreies System geben.

    Die Mathematik gibt ein schönes Gerüst um auf Fehlerfreiheit zu prüfen, aber eben nur an strukturellen Modellen. Die Prüfung der korrekten Semantik wird wohl so schnell nicht formal bewiesen werden können.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. DECATHLON Deutschland SE & Co. KG, Plochingen
  2. über Hays AG, Dortmund
  3. Friedrich Lange GmbH Fachgroßhandel für Sanitär und Heizung, Hamburg
  4. Allianz Deutschland AG, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. be quiet! SILENT BASE 802 White für 129,90€ + 6,99€ Versand)
  2. (u. a. LG OLED77CX6LA 77 Zoll OLED für 2.899€, LG 43UP75009LF 43 Zoll LCD für 399€)
  3. (u. a. Planet Zoo - Deluxe Edition für 19,49€, SnowRunner - Epic Games Store Key für 26,99€)
  4. (u. a. Mad Games Tycoon für 6,50€, Transport Fever 2 für 21€, Shadow Tactics: Blades of the...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme