Diskussion:Taktsignal

Boolesches Signal?

Noch nie gehört.-- Kölscher Pitter 19:34, 21. Jan. 2008 (CET)

Ich bin auhc am überlegen, ob diese bezeichnung richtig ist. Ich weiß zwar, was damit gemeint ist, aber den Begriff "Boolesches Signal" höre ich auch zum ersten mal. Gruß --JoBa2282 ^{Red mit mir} 07:42, 6. Mai 2009 (CEST)

Taktlose Computer

Es wird an Chips gearbeitet, die taktlos arbeiten (per Request/Acknowledge, also Handshake). Das sollte in dem Artikel wenigstens mal erwähnt werden. 213.196.246.25 09:42, 26. Feb. 2008 (CET)

Für was sollen denn solche Chips eingesetzt werden?

Ich kann mir das nur für eingebettete Systeme vorstellen, weil sehr schnell kann das nicht sein.

Dafür dürfte so ein Chip wahrscheinlich weniger Strom verbrauchen. --MrBurns 07:55, 27. Feb. 2008 (CET)

Asynchrone (taktlose) Chips (Schaltwerke) sind durch die fehlende Taktbeschränkung VIEL schneller. Es gibt ja keine künstlich eingeführte Beschränkung der Laufzeit mehr. Aber es ist ungemein schwierig, solche Schaltwerke zu entwerfen.

-- 28yearslater 06:03, 11. Jun. 2009 (CEST) (06:33, 11. Jun. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Es stimmt im Prinzip, dass es keine künstliche Beschränkung der Laufzeit gibt, aber dafür muß die CPU, wenn sie z.B. Daten aus dem Cache ladet mit der Datenverarbeitung erst darauf warten, dass die Daten auch angekommen sind (weil sonst im entsprechenden Register noch alte, also falsche Daten sind), während mit einem Taktsignal weiß man, wann das der Fall sein wird und kann dann die Operation sofort starten. --MrBurns 12:26, 11. Jun. 2009 (CEST)

Nein. Die Taktfrequenz muss vielmehr so langsam gewählt werden, dass der nächste Takt erst dann kommt, wenn die Daten bereits angekommen sind. Deshalb kann man z. B. bei einem Computer ja nicht einfach die Taktfrequenz nach Belieben erhöhen. -- Pemu (Diskussion) 12:42, 21. Dez. 2015 (CET)

Nicht unbedingt, wenn man weiß, wie lang die Daten au dem Cache brauchen kann man die CPU so programmieren, dass sie darauf länger wartet als einen Taktzyklus (und in der Zwischenzeit eventuell etwas anderes erledigt). Wenn die CPU die Daten nicht schon im Register hat, dauert es immer länger als einen Taktzyklus, beim L1-Cache ich glaub 2-3 Taktzyklen, bei höheren Levels mehr. Das einzige, was innerhalb eines Taktzyklus abgeschlossen werden muss ist die jeweilige Stufe der Pipeline. Bei CPUs ist heute die Taktfrequenz auch nicht hauptsächlich durch die Laufzeit begrenzt, sondern mehr durch die Wärmeentwicklung und die Signalqualität, die bei steigender Taktfrequenz abnimmt. Im einfachsten Fall ist die Leitungsaufnahme und damit auch die Wärmeabgabe linear zur Taktfrequenz, das gilt aber nicht wenn signifikante Leckströme auftreten. Des weiteren erfordert eine hohe Taktfrequenz eine lange Pipeline, was bei realen Anwendungen die Instruktionen pro Taktzyklus verringert. Daher hat man durch Netburst herausgefunden, dass es effizienter ist, mehrere langsamer getaktete Kerne zu haben als einen mit der höchsten erzielbaren Taktfrequenz. --MrBurns (Diskussion) 02:23, 23. Dez. 2015 (CET)

Na ja, beiße Dich bei "Daten" nicht so sehr auf einen Datenbus fest. Mir geht es ums Prinzip. Klar geht das mit dem Warten, aber dann muss halt die Taktfrequenz so niedrig sein, dass die Daten ^H^H^H^H^H^H^H Signale von dem Waitstate-Generator sicher verarbeitet werden können. -- Pemu (Diskussion) 12:32, 23. Dez. 2015 (CET)

Das stimmt im Prinzip, aber praktisch ist es seit dem Ende von Netburst so, dass man den Takt nicht mehr so hoch ansetzt wie möglich, sondern lieber auf Multicore-CPUs mit großem Cache und verhältnismäßig kurzer Pipeline setzt. Die kurze Pipeline führt dazu, dass die einzelnen Pipeline-Stufen komplexer sind und daher länger dauern und den Takt begrenzen, Multicore und großer Cache führt dazu, dass die CPU viele Transistoren enthält (oft im Milliardenbereich) die bei der höchsten signaltechnsich möglichen Taktfrequenz obwohl die einzelen Transistoren immer kleienr und damit sparsamer werden so viel Hitze abgeben würden, dass die CPU mit konventionellen Mitteln (Luftkühlung, Wasserkühlung) unkühlbar wäre. Das sieht man auch schon bei der Taktfrequenzentwicklung von Intel: mit NetBurst wurden bis zu 3,8 GHz erreicht (siehe Liste_der_Intel-Pentium-4-Mikroprozessoren#Prescott_.2890.C2.A0nm.29_2), danach wurde mit der Einführung der Intel-Core-Mikroarchitektur im Desktop-Bereich mit dem Core 2 Extreme die maximale Taktfrequenz auf 2,933 GHz reduziert, 3,8 GHz wurden erst viele Jahre später wieder erreicht (mit Turbo Boost 2010, also 6 Jahre nachdem Prescott erstmals (ohne Turbo Boost) auf diesem Niveau war, ohne Turbo Boost erst 2014, siehe Liste der Intel-Core-Prozessoren). Bei einer taktlosen CPU würde man also wohl wegen der Kühlungsproblematik keine höhere Performance erreichen, da die Zahl der Schaltvorgänge pro Sekunde ja trotzdem für eine Performancesteigerung erhöht werden muss, was egal ob mit oder ohne Taktsignal mehr Wärme erzeugt (ich glaube nicht, dass das Taktsignal direkt viel zur Wärmeentwicklung beiträgt, bin aber kein CPU-Entwickler). --MrBurns (Diskussion) 03:27, 29. Dez. 2015 (CET)

Bandbreite gemeint?

Ist z.B. mit den Angaben 2,6 GHz (bei der CPU) nicht eher die Bandbreite (ich meine nicht die Übertragungsrate) gemeint, mit der ein Prozessor arbeiten kann. Je höher die Bandbreite, desto kürzer können die Signale sein (--> Fourier)?

http://www.forum-3dcenter.org/vbulletin/archive/index.php/t-23634.html (Mitte des Threats)
(nicht signierter Beitrag von 84.160.70.146 (Diskussion) 13:24, 16. Aug. 2008 (CEST)) --JoBa2282 ^{Red mit mir} 07:39, 6. Mai 2009 (CEST)

Neine, mit den 2,6 GHz ist die Taktfrequenz des Prozessorkerns gemeint, welche sich bei modernen CPUs berechnen lässt mit Multiplikator*Referenztakt (klassisch ist der Referenztakt der FSB-Takt, aber z.B. bei der Nehalem-Mikroarchitektur ist dem nicht mehr so). --MrBurns 00:36, 6. Mai 2009 (CEST)

Ein Bandbreitenangabe ist in diesem Zusammenhang absolut unüblich. -- Pemu (Diskussion) 12:42, 21. Dez. 2015 (CET) (Wobei ich nicht weiß, wie es im Bereich der Grundlagenforschung aussieht. -- Pemu (Diskussion) 17:13, 22. Dez. 2015 (CET))

Einleitung

"In der der Digitaltechnik ist ein Taktsignal (engl. clock signal) ein Boolesches Signal, das der Koordination der Aktionen in zwei oder mehr Schaltkreisen dient"

Das ist echt hart! Der Begriff "Boolsches Signal" ist nachvollziehbar für jeden der mit Digitaltechnik vertraut ist. Aber trotzdem nicht üblich.

Und dass ein Takt PRINZIPIELL (also in ursächlicher Intention) zur Koordination zwischen >=2 "Schaltkreisen" dient ist einfach nur absurd!

Der Begriff "Schaltkreis" ist hier völlig fehl am Platz. Wenn wir schon von Digitaltechnik reden, sollten wir uns auf Schaltnetzte und Schaltwerke beschränken. In Schaltnetzen gibt es keine Rückkopplung, und somit auch keine Notwendigkeit für einen Takt. Bei Schaltwerken gibt es per Definition eine Rückkopplung (In der Theorie: Mealy- und Moore-Automaten). Die Rückkopplung in EINEM Schaltwerk, gibt historisch, ingenieurmäßig und logisch den entscheidenden Anstoß zur Einführung eines Taktes! Nicht falsch verstehen: Ein Takt ist für Schaltwerke, also rückgekoppelte Schaltnetze, nicht zwingend, aber ein notwendiges Übel. Man sollte dies im Artikel verdeutlichen: Der Takt ist eine Erleichterung im Entwurf und Beschränkung der Ausführgeschwindikeit. Sonst nichts.

Asynchrone Schaltwerke haben keinen Takt, sind vergleichsweise enorm schwer zu entwerfen und Stand der Forschung. Synchrone Schaltwerke können je nach erwünschter Funktionalität Schritt für Schritt entworfen werden. Nicht ohne Grund gibt es dafür Hardware-Beschreibungssprachen wie VHDL.

Selbstverständlich koordinieren sich etliche Schaltwerke, z.B. in einem PC, über einen gemeinsamen Takt. Aber keiner dieser Bausteine würde asynchron, also ohne Takt, in heutiger Bauweise funktionieren. Deswegen ist die Aussage, dass der Takt "der Koordination der Aktionen in (zwischen? argh!) ZWEI oder MEHR Schaltkreisen dient", zwar prinzipiell richtig, aber was denn Sinn dahinter betrifft einfach nur irreführend.

Ich lasse das mal so für einige Zeit hier stehen und bin gerne für Anregungen und Diskussionen bereit. Wenn aber letztendlich niemand einen Einwand hat, werde ich das Ändern. Um genau zu sein: Den ganzen Artikel.

-- 28yearslater 06:04, 11. Jun. 2009 (CEST)

Ich habe mal noch ein wenig in anderen Artikeln gelesen. Der begriff "asynchroner Prozessoren" oder Ähnliches wird gerne verwendet, wenn der IC unterschiedliche Taktraten für die Teilkomponenten zur Verfürung stellt. Aber ich konnte bis jetzt noch keinen Artikel finden, in dem darauf eingegangen wird, dass ein asynchrones Schaltwerk völlig ohne Takt arbeitet.

Nur um mal eine Referenz zu nennen, die nicht von Wikipedia stammt: siehe zum Beispiel "Grundlagen der Technischen Informatik" von Dirk W. Hoffmann (Carl Hanser Verlag München): in der 2. Auflage von 2010 findet man es in Kapitel 8 Schaltwerke mit 8.1.1 Asynchrone Speicherelemente. Allerdings ist ein asynchrones Schaltwerk nicht mit einem asynchronen Prozessor gleichzusetzen. --Flooowy (Diskussion) 19:10, 11. Mai 2014 (CEST)

-- 28yearslater 06:33, 11. Jun. 2009 (CEST)

Nach dieser Definition wäre aber jeder moderne x86-CPU asynchron, da zumindestens das Bussystem mit einem anderen Takt arbeitet. Und außerdem: beim Pentium 4 läuft z.B. die FPU mit doppeltem Takt, er wird aber trotzdem nicht als "asynchron" bezeichnet. --MrBurns 12:21, 11. Jun. 2009 (CEST)

Na es gibt offensichtlich zwei Verwendungen des Begriffes asynchron: Einmal für mehrere ICs die mit unterschiedlichem Takt zusammenarbeiten und einmal für ein takloses Schaltwerk. Ich wollte garnicht abstreiten, dass ersteres auch richtig ist, sorry falls das falsch rübergekommen ist. -- 91.66.122.119 21:28, 12. Jun. 2009 (CEST)

Das Bussystem ist aber auch zum teil auf der CPU-Die vorhanden, also rennt jedenfalls ein Teil der CPU mit dem niedrigeren Bus-Takt. --MrBurns 04:13, 2. Feb. 2010 (CET)

Ergänzungen

Eure Beiträge sind zwar schon etwas älter, allerdings finde ich, das die Einleitung immer noch verbesserungswürdig ist.

1. Ein Taktsignal wird nicht nur in der Digitaltechnik verwendet. Daraus folgt für mich, dass die Bezeichnung binäres Signal auch nicht ganz zutreffend ist. Besser finde ich folgendes: Das Taktsignal ist ein Signal, welches zwischen zwei Zuständen periodisch wechselt. Was mich auch gleich zu einem weiteren Punkt/Frage bringt.

2. Was ist mit aperiodischem Taktsignal gemeint? Die Defintion von Takt an sich ist folgende: Der Takt beschreibt die Einteilung einer Dauer in gleichgroße Einheiten. Das ist eine Veralgemeinerung der Tatkdefinition aus Wikipedia für die Bereiche Musik und Sport etc. pp. Diese Art der Definition ist auch für die Digital- und Analogtechnik aus meiner Sicht zutreffend. Was für mich übrigens nur auf ein periodisches Signal zurückzuführen ist. ACHTUNG: Man darf hier nicht periodisch mit einem Tastgrad (duty cycle) von 50% gleichsetzen. Deshalb frage ich mich was mit aperiodisch gemeint ist.

3. Die Bedeutung und die Anwendungsgebiete kommen in der Einleitung zu kurz. Das Taktsignal wird schließlich auch in der Nachrichtentechnik zur Synchronisation bei der Übermittelung von Information/Signalen verwendet.

Ich möchte hinzufügen, dass Taktsignale auch Störungen von anderen Signalen, die zum Beispiel durch elektromagnetische Effekte auftreten, zu einem gewissen Prozentsatz auslöschen. Denn es werden nur dann die Eingänge "eingelesen", wenn die aktive Taktflanke bzw. der aktive Tatkpegel (High- oder Low-Pegel) eintreten. Alle Störungen die nicht während dieser Zeit auftreten sind irrelevant. Zumindest im Bereich der Digitaltechnik. In diesem Zusammenhang fehlt auch eine Verlinkung zu der Setup und Hold Time.

Des Weiteren zur Aussage: "Man sollte dies im Artikel verdeutlichen: Der Takt ist eine Erleichterung im Entwurf und Beschränkung der Ausführgeschwindikeit. Sonst nichts." Die Frage warum wird hier gar nicht beantwortet. Da kann ich vielleicht helfen: Die Ausbreitungsgeschwindigkeit bzw. die Ausbreitungsverzögerung (propagation delay) der Signale innerhalb eines elektrischen Systems ist von äußeren Umwelteinflüssen abhängig. Ändert sich zum Beispiel die Temperatur, ändert sich auch die Geschwindigkeit. Dementsprechend kann es sein, dass an eine Komponente die richtigen Eingänge nicht zur richtigen Zeit anliegen und ein fehlerhaftes Ausgangssignal erzeugt wird, was vielleicht sogar noch weiterverarbeitet wird. Im Endeffekt kann das eine Menge Geld pulverisieren. Bei Asynchronen Systemen ohne Taktsignal muss man sich bei dem Entwurf von Systemen allerdings auf eine vorhersagbare Ausbreitungsgeschwindigkeit verlassen können, um überhaupt ein System mit korrekten Funktionen implementieren zu können. Dies hat wiederum zur Folge, dass die Portierbarkeit eines solchen System auf eine andere Architektur oder auf ein anderes Gerät nur schwer möglich ist, da alle Annahmen diesbezüglich nochmals geprüft werden müssen.(Nachlesbar unter http://www.altera.com/literature/hb/qts/qts_qii5v1.pdf Chapt. 12)

Ich wäre übrigens sehr begeistert, wenn dieser Artikel nochmal komplett überarbeitet würde. --Flooowy (Diskussion) 19:10, 11. Mai 2014 (CEST)

Ach je, so viel Verschiedenes auf einmal. Und dann noch ungeschickt unleserlich formatiert.

Ich hoffe es ist jetzt etwas besser.--Flooowy (Diskussion) 13:03, 12. Mai 2014 (CEST)

zu 2.: Takt muss nicht immer gleichgroße Zeitintervalle bedeuten. Beispiel: analoges TV-Signal, Zeilensynchronimpulse als Takt angesehen, die machen bei den Halbbildern des Zeilensprungverfahrens einen Sprung von einer halben Zeile.

Ehrlich gesagt, kann ich mir unter dem Beispiel leider nicht viel vorstellen, jedenfalls nicht im Zusammenhang mit aperiodisch. Ich habe mir deine Verlinkung zum Zeilensprungverfahren und auch zum Thema Fernsehsignal angesehen und bin etwas verwirrt. Ich stimme dir zu, dass der zeitliche Ablauf eines Fernsehsignals nicht periodisch ist, da der aktive Bereich die Bildinformation enthält und dementsprechend je nach Bild variiert. Allerdings wird jedes Bild, damit jedes Halbbild und somit auch jede Zeile durch eine gewisse Frequenz übertragen und dementsprechend findet der Zeilensynchronimpuls laut dem Beispielbild in Fernsehsignal unter der Überschrift BAS-Signal alle 64 Mikrosekunden statt. Was für mich periodisch bedeutet. Zur Verdeutlichung: Ich setze hierbei die Bildinformationen den Noten in der Musik gleich und den Zeilensynchronimpuls mit dem Takt selbst. Das heißt bei der Übertragung des Fernsehbildes werden aus meiner Sicht zwei überlagerte Signale transportiert, einmal der Takt und zum anderen die dazu synchronisierten Bildinformationen. Nochmal und diesmal mit Link, damit ich auch sicher sein kann, dass wir von der selben Sache sprechen: Nur weil der High-Pegel nicht so lange dauert wie der Low-Pegel ist das Signal nicht gleich aperiodisch. Es hat lediglich einen anderen Tastgrad. Allerdings muss ich noch ergänzen, dass ich dabei nichts Spezielles zu analogen TV-Signalen gefunden habe.--Flooowy (Diskussion) 13:03, 12. Mai 2014 (CEST)

zu den Störungen: Das ist eine zweischneidige Sache. Z. B. bei einer seriellen Übertragung gibt es verschiedenste Ansätze: a) In der Mitte eines Pulses abtasten, dann kann aber gerade da eine Störung sein; b) Am Ende auf der Taktflanke abtasten, wenn das Datenbit schön eingeschwungen ist, dann gilt aber das gleiche wie vorher, und das Datenbit ist womöglich auch schon in einer Taktflange zum nächsten Wert begriffen; c) man hat einen extrem schnellen internen Takt und kann mehr oversampeln, dann kann man mehrfach abtasten und eine Mehrheitsentscheidung treffen.

zur Beschränkung der Ausführungsgeschwindigkeit: nicht immer! Es gibt ein paar exotische moderne Prozessordesigns, die intern angeblich total asynchron arbeiten, dafür dann aber in den Fällen, wo wenig Aufwand nötig ist, auch signifikant schneller machen können. Asynchron heißt hier ja typischerweise, dass man sich nicht einfach auf den längsten möglichen Zeitraum einstellt, sondern dass man in einer Art Event-Verarbeitung auf Rückmeldungen anderer Einheiten wartet, bis die ein Fertig/Bereit signalisieren.

Ich hatte das mit der Ausführungsgeschwindigkeit so verstanden, dass synchrone Systeme langsamer machen und wollte eigentlich die Frage beantworten, warum man dann synchrone Systeme verwendet, statt der schnelleren asynchronen Variante. Den Teil muss ich wohl beim nächsten Versuch verständlicher gestalten.--Flooowy (Diskussion) 13:03, 12. Mai 2014 (CEST)

Insofern also in meinen Augen nicht so trivial, die Änderungswünsche. Und den großen Rundumschlag und alles neu machen: Probier es doch bei Dir auf Deiner Spielwiese, zeig uns nachher Dein Ergebnis, dann können wir darüber reden. Aber bitte nicht erstmal hier alles kaputtmachen und durch ein womöglich noch zweifelhafteres Elaborat ersetzen, das dann typischerweise an anderen Stellen umso klaffendere Lücken aufweist: alles schon gesehen... --PeterFrankfurt (Diskussion) 03:40, 12. Mai 2014 (CEST)

Keine Sorge, hätte ich einen Rundumschlag des Artikels ohne Rücksprache und Anregungen machen wollen, hätte ich nicht erst einen Diskussionsbeitrag geschrieben. :) Allerdings muss dieser Versuch noch bis Anfang Juni warten.--Flooowy (Diskussion) 13:03, 12. Mai 2014 (CEST)

Fein. Nochmal zum Zeilensprungverfahren: Bei uns (man muss jetzt schon sagen) wurde ein analoges TV-Signal so übertragen, dass zwei Halbbilder übertragen wurden, die um eine Zeile versetzt waren, das eine enthielt die geraden, das andere die ungeraden Zeilen. Aus irgendwelchen Gründen (vllt. Forderung nach äquidistanten Bildwechsel-Synchronimpulsen, keine Ahnung) musste der obere Anfang bei der gleichen y-Koordinate erfolgen, dazu hat man das zweite Halbbild dann mit einer halben Zeile oben in der Mitte des Schirms beginnen lassen. Am unteren Rand endete das Bild entsprechend mit einer Halbzeile. Wenn man sich nun die Zeilensynchronsignale ansieht, dann kommen sie während eines Bildes akkurat alle 64 Mikrosekunden, beim Halbbildwechsel halbiert sich dieser Abstand aber jeweils einmal! Also ist das ein Beispiel für einen Fall, wo die Taktsignale (hier die Zeilensyncimpulse) nicht immer exakt periodisch kommen und trotzdem regulär. Die Welt ist manchmal kompliziert und wir sollten vermeiden, bei einer Definition aus Versehen so wichtige Alltagsanwendungen wie das Fernsehen auszuschließen. --PeterFrankfurt (Diskussion) 02:26, 13. Mai 2014 (CEST)

Nein. Die Zeilensynchronimpulse laufen hart alle 64 µs durch, auch über die (Halb-)Bildwechsel hinaus. (Lasst Euch hierbei nicht von den Vor- und Nachtrabanten verwirren. Diese haben den einzigen Zweck, den Aufwand für eine hinreichend gute Abtrennung des Bildsynchronimpulses im Empfänger zu minimieren. Nach Ende der Nachtrabanten hat das Zeilensynchronsignal wieder den gleichen Phasenbezug wie vor den Vortrabanten.) Das Bildsynchronsignal kommt alle 312,5 Zeilen, aber wie genau der Phasenbezug des (im Empfänger rekonstruierten) Bildsynchronimpulses zu den Zeilensynchronimpulsen ist, ist unerheblich (solange er sich nicht ständig ändert), weil die Zeile, in der das Bildsynchronsignal kommt (und die paar Zeilen vorher und nachher auch) nicht Teil des sichtbaren Bildes sind. Deshalb ist auch egal, ob der Bildwechsel ein paar Zeilen vorher oder nachher erkannt wird. -- Pemu (Diskussion) 12:42, 21. Dez. 2015 (CET), Ergänzungen -- Pemu (Diskussion) 12:15, 14. Aug. 2017 (CEST)

Zu 2. (aperiodisch): Praktischer Fall: Ein Prozessor mache per Softwareprotokoll eine SPI-Übertragung. Dabei sei die Ausführungszeit der Protokoll-Routine durch verschiedene bedingte Sprünge nicht immer gleich oder der Prozessor werde gar zuweilen durch einen Interrupt unterbrochen. Tut nix zur Sache (solange es nicht irgendeinem Busteilnehmer zu langweilig wird und er einen Timeout veranlasst), aber ist halt keineswegs periodisch.

Puristen mögen nun einwenden, dass das kein Taktsignal sei, sondern ein Daten-gültig-Signal.

Wenn aber der andere SPI-Teilnehmer nicht die Signalleitungen (mit dem vermeintlichen Daten-gültig-Signal) mit eigener Taktfrequenz sampelt, sondern wirklich ein von der Taktleitung getaktetes Netzwerk beihaltet, ist es ein Taktsignal im Sinne dieses Artikels und kein Daten-gültig-Signal. -- Pemu (Diskussion) 12:15, 14. Aug. 2017 (CEST)

Systemtakt

O.g. ist ein adäquates Wort dafür und sollte m.E. verlinkt werden, wie sonst auch üblich. -- 217.224.226.7 00:26, 10. Dez. 2014 (CET)

Im PC-Bereich wird das Wort Systemtakt für den externen Takt des Prozessors verwendet (traditionell ist das der FSB-Takt, bei den neueren Architekturen mit ihren vielen Clocks ist es meist nicht mehr so eindeutig, was der Systemtakt ist, infrage kämen z.B. der Uncore- oder der QPI-Takt). --MrBurns (Diskussion) 10:24, 10. Dez. 2014 (CET)

Bedeutung von "Takt" im Zusammenhang

Beispiele:

• Taktfrequenz
  • Die Taktfrequenz der Prozessoren wird aus dem Systemtakt von 100 MHz und dem Taktmultiplikator generiert
• Taktzyklus
  • Ein Skalarprozessor verarbeitet eine Information (z. B. eine ganze Zahl, eine Gleitkommazahl oder Opcode) pro Systemtakt.
• Taktsignal
  • Der Takt wird an Pin 37 zugeführt.

Vielleicht kann man solche Beispiele mal im Artikel gebrauchen. -- Pemu (Diskussion) 12:30, 4. Sep. 2017 (CEST) und -- Pemu (Diskussion) 01:01, 30. Nov. 2017 (CET)

Ich hab im Artikel Skalarprozessor das Wort "Systemtakt" durch "Taktzyklus" ersetzt. Ich denke nämlich schon, dass da der interne Takt gemeint ist, nicht der (externe) Systemtakt. Eventuell stammt die Beschreibung (z.B. über ein Lehrbuch) noch aus einer Zeit, in der CPUs noch keinen Multiplikator hatten, daher externer und interner Takt identisch waren. --MrBurns (Diskussion) 18:39, 5. Sep. 2017 (CEST)

Hier wurde der Begriff eingeführt. Vermutlich kam der Text dabei vom Regen in die Traufe, kann daher MrBurns Änderung absolut gutheißen.

Witzig aber: der dortige einzige Diksussionsbeitrag.

-- Pemu (Diskussion) 21:41, 5. Sep. 2017 (CEST)

Rechteckschwingung

Das perfekte Taktsignal mag eine Rechteckschwingung sein, tatsächlich weichen Taktsignale aber stark von diesen Idealen ab, vor Allem hochfrequente Taktsignale, die oft eher einem Sinus entsprechen als einem Rechteckssignal. Siehe z.B. [1] (Fig. 8). --MrBurns (Diskussion) 08:59, 17. Sep. 2017 (CEST)

Passt es jetzt besser? -- Pemu (Diskussion) 00:37, 18. Sep. 2017 (CEST)

Ja, ich denke jetzt ist es besser. --MrBurns (Diskussion) 01:04, 18. Sep. 2017 (CEST)

Weblinkvorschläge

​Pittimann schlägt folgende Links für den Artikel vor:

Weblinks

1. IT Wissen Taktgeber (abgerufen am 29. September)
2. Taktsignale und Taktverteilung (abgerufen am 29. September)
3. Taktsignal-Modellierungsschaltung (abgerufen am 29. September)
4. Wie wählt man die richtige Pll-Bandbreite? (abgerufen am 29. September)
5. Flipflops (abgerufen am 29. September)

Ich habe im Moment nur Zeit, sie zu überfliegen.

• Die Nr. 1 scheint nicht viel Mehrwert zu bieten. Vielleicht kann sie etwas belegen, aber als weiterführende Literatur habe ich die Tendenz zu sagen: raus.
• Nr. 2: scheint Mehrwert zu bringen.
• Nr. 3, das Patent (wie gesagt, nur überflogen) bezieht sich auf verschiedene Bilder, die ich nicht sehe.
• Nr. 4: Thema verfehlt, passt vielleicht bei Phasenregelschleife?
• Nr. 5: Thema verfehlt, passt vielleicht bei Flipflop? Link auf Flipflop scheint hier sinniger zu sein als auf das PDF.

Weitere Kommentare? -- Pemu (Diskussion) 14:43, 29. Sep. 2017 (CEST)

Literaturvorschläge

Pittimann schlägt folgende Literatur für den Artikel vor:

Literatur

1. Stephan Eggersglüß, Görschwin Fey, Ilia Polian:Test digitaler Schaltkreise. Oldenbourg Wissenschaftsverlag GmbH, München 2014, ISBN 978-3-486-72013-6.
2. Norbert Heesel:Mikrocontroller Praxis. Friedrich Vieweg & Sohn Verlag, Wiesbaden 1993, ISBN 978-3-528-05366-6.
3. Klaus Wüst:Mikroprozessortechnik. Mikrocontroller - Signalprozessoren - Speicherbausteine und Systeme, 1. Auflage, Friedrich Vieweg & Sohn Verlag, Wiesbaden 2003, ISBN 978-3-528-03932-5.
4. Albrecht Rost:Grundlagen der Elektronik. Springer Verlag, Wien / New York 1983, ISBN 978-3-7091-8700-5.
5. Rainer Pickhardt:Grundlagen und Anwendung der Steuerungstechnik. Petri-Netze - SPS - Planung, 1. Auflage, Friedrich Vieweg & Sohn Verlag, Wiesbaden 2000, ISBN 978-3-528-03927-1.

Keines der Bücher kenne ich, in keines habe ich versucht, einen Blick zu werfen, weshalb ich dazu nichts sagen kann.

Weitere Kommentare? -- Pemu (Diskussion) 14:43, 29. Sep. 2017 (CEST), erg. -- Pemu (Diskussion) 21:12, 29. Sep. 2017 (CEST)

Maschinenzyklen

Der mit diesem Edit neu hinzugekommene Teil "Bei aktuellen Prozessoren entspricht das […] dauert auf anderen hunderttausend Takte." kann IMHO so nicht bleiben. IMHO ist die Kernaussage die, die auch von "Die Rechenleistung (gemessen zum Beispiel in MIPS oder FLOPS) ist nicht nur […] pro Taktzyklus mehr Rechenoperationen und rechnet daher schneller" gemacht wird. Ich denke, man sollte den neuen Text gutmütig straffen. Was von dem neuen Text soll bleiben?

Außerdem bitte ich die Mitautoren, den Abschnitt Abgrenzung zu beherzigen und nicht entsprechend mehrdeutig zu schreiben.

-- Pemu (Diskussion) 00:28, 26. Nov. 2018 (CET) erg. -- Pemu (Diskussion) 00:39, 26. Nov. 2018 (CET)