Ich habe einige Experimente gemacht, um das Timing der Befehlsausführung auf dem CH32V003 besser zu verstehen: https://github.com/cpldcpu/DRAM_exploration/tree/master/instruction_timing Alles nicht so einfach. - Ein Flash-Zugriff benötigt 2 Taktzyklen (Bei 48MHZ core clock). Durch einen prefetch-Buffer im Flash Controller können dieses teilweise versteckt werden, so dass man compressed instructions in einem Taktzyklus ausführen kann. - Taken branchnes sind sehr langsam, da Pipeline und prefetch-buffer neu gefüllt werden müssen. - Code-Zugriffe aufs SRAM benötigen nur 1 Takt, allerdings scheint es hier keinen prefetch-buffer zu geben. - Zugriffe auf GPIO belegen den AHBI-Lite Bus, an dem auch das SRAM hängt, dadurch benötigen Speicherzugriffe (und GPIO) immer zwei Zyklen. Ich hatte gehofft, dass es beim CH32V003 möglich ist, GPIOs mit einem Taktzyklus zu togglen. Leider scheint das nicht möglich zu sein (bzw. nur bei 24MHz core clock). Die neueren CH32V002/006 haben ein Flash waitstate mehr und sind daher noch langsamer.
> Ich hatte gehofft, dass es beim CH32V003 möglich ist, GPIOs mit einem > Taktzyklus zu togglen. Leider scheint das nicht möglich zu sein (bzw. > nur bei 24MHz core clock). Von dieser Idee wirst du dich bei allen neueren Teilen die mit >20Mhz arbeiten, verabschieden koennen. Einfach weil das Flash zu lahm ist und deshalb heute Cache standard geworden ist. > Die neueren CH32V002/006 haben ein Flash waitstate mehr und > sind daher noch langsamer. Also DAS finde ich beaengstigend. Das sagt mir naemlich das sie gemerkt haben das es bei aelteren Teilen ein Problem gab und das da was im Errata stehen sollte... Vanye
Tim . schrieb: > Die neueren CH32V002/006 haben ein Flash waitstate mehr und sind daher > noch langsamer. Die CH32V002 haben einen V2C-Core, die CH32V003 einen V2A-Core. Ähnliche Kategorie, vermutlich haben sie das noch mehr auf Kosten und Ausbeute getrimmt. Denn das dürfte ja der Hauptgrund sein warum man die nimmt. Hast Du zufällig noch eine Nummer größer da um zu vergleichen wie es da dann aussieht? Also z.B. der CH32X035, das wäre ein V4C-Core. Vanye R. schrieb: > Also DAS finde ich beaengstigend. Das sagt mir naemlich das sie gemerkt > haben das es bei aelteren Teilen ein Problem gab und das da was im > Errata stehen sollte... Muss nicht sein. Wie ich oben schrieb ist das ein anderer Core. Und der kann durchaus absichtlich so entwickelt worden sein um z.B. die Kosten zu drücken oder die Ausbeute zu erhöhen.
Vanye R. schrieb: >> Ich hatte gehofft, dass es beim CH32V003 möglich ist, GPIOs mit einem >> Taktzyklus zu togglen. Leider scheint das nicht möglich zu sein (bzw. >> nur bei 24MHz core clock). > > Von dieser Idee wirst du dich bei allen neueren Teilen die mit >20Mhz > arbeiten, verabschieden koennen. Einfach weil das Flash zu lahm ist und > deshalb heute Cache standard geworden ist. Bei der Ausführung aus dem SRAM spielen Waitstates keine Rolle. Was beim CH32V003 ungünstig ist, ist dass der Prefetech-Buffer Teil des Flash-controllers ist.
Vanye R. schrieb: > Also DAS finde ich beaengstigend. Das sagt mir naemlich das sie gemerkt > haben das es bei aelteren Teilen ein Problem gab und das da was im > Errata stehen sollte... Vermutlich haben sie eine andere Technologie genutzt, um den Die weiter zu shrinken. Der CH32V003 die ist für ein "$0.10" Produkt relativ gross: https://zeptobars.com/en/read/wch-ch32v003-risc-v-riscv-microcontroller-10-cent Ich vermute, dass der CH32V002 auf eine kleinere die-Fläche getrimmt wurde. Das ging vermutlich zu Lasten der Flash-Geschwindigkeit.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.