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.
Angehängte Dateien:
-
v002_measured.png
1 MB
Ich habe mal einen CH32V002 "geknackt" und die Diegröße vermessen. Der Die ist tatsächlich nur etwas halb so groß, wie im CH32V002.
Das zweite der "CH32V002" sollte sicherlich "CH32V003" heißen, wie?
Harald K. schrieb: > Das zweite der "CH32V002" sollte sicherlich "CH32V003" heißen, wie? Ja, natürlich. - CH32V002: ca 0.8 x 1.1mm² =0,88 - CH32V003: 1.7 x 1.2 mm²* = 2,04 *https://zeptobars.com/en/read/wch-ch32v003-risc-v-riscv-microcontroller-10-cent
'S wär schön, wenn Richi sich die mal zu Gemüte führen könnte.
Harald K. schrieb: > 'S wär schön, wenn Richi sich die mal zu Gemüte führen könnte. Ich frage ihn mal.
> Fangen wir mit dem bereits bekannten CH32V003 an:
Hast du beim cleanen zufaellig gesehen das PD6/PA1 und PD4/PD5/PD1
zusammen gebondet sind? Das ist naemlich so eine Vermutung von mir...
Vanye
Die Bonddrähte von Epoxid-Packages bleiben bei mir nicht erhalten. Was da wie verbunden war kann ich dir leider nicht sagen.
Richard K. schrieb: > Fangen wir mit dem bereits bekannten CH32V003 an: > > https://www.richis-lab.de/uC06.htm Sieht wirklich sehr sauber aus! Interessant, dass so viele Bondpads genutzt werden, obwohl ist sich nur um einen 8-pinner handelt. Es werden also offensichtlich einige IO Pins kombiniert.
Teilweise werden es Versorgungspotentiale sein, die mehrfach kontaktiert wurde. Bei den anderen Kontakten könnte es sein, dass IOs zusammengefasst wurden. Es könnte sein, dass IOs auf Bezugspotential gelegt wurden. Und es könnte sein, dass man über einen oder zwei Bonddrähte eine Konfiguration eingestellt hat. Schwer zu sagen...
Tim . schrieb: > Interessant, dass so viele Bondpads genutzt werden, obwohl ist sich nur > um einen 8-pinner handelt. Es werden also offensichtlich einige IO Pins > kombiniert. Das kann man den Abbildungen hier https://github.com/cnlohr/ch32fun?tab=readme-ov-file#quick-reference entnehmen, die die Pinouts der verschiedenen Gehäusebauformen zusammenfassen.
Richard K. schrieb: > Und hier noch der CH32V002: > > https://www.richis-lab.de/uC07.htm Wow! Super bilder. Beeindruckend, wie weit der CH32V002 optimiert wurde. Die Pads scheinen wirklich extrem schmall zu sein. Habe noch nie 12 pads an einer 0.8mm seite eines dies gesehen. Die balls sehen auch sehr merkwürdig aus. Sind da Al-wires?
:
Bearbeitet durch User
Danke, hat auch Spaß gemacht. :) Die Bondpads sind ungefähr 50µm x 60µm groß. Das ist schon stark optimiert. Aluminium-Bonddrähte würden mich wundern. Ich würde dagegen auf Kupfer tippen. Die Farbe könnte durch Oxidation entstanden sein. Schließlich öffne ich die Teile thermisch.
Sehr interessant! Das Logo auf dem Flash die ist das von Puya. Es könnte sich um dieses Flash handeln: https://www.puyasemi.com/download_path/%E6%95%B0%E6%8D%AE%E6%89%8B%E5%86%8C/Flash/P25Q21H_11H_06H_Datasheet_V2.2.pdf (Spannungsbereich passt zu den Angaben im V203 Datenblatt auf S.44. Größe muss 256kbyte, daher 2Mbit sein) Sie bieten auch einen known-good-die service an: https://www.puyasemi.com/en/h_series153.html#common Die beiden Blöcke links auf dem MCU-die scheinen mir etwas groß für den ADC zu sein. Evtl. handelt es sich hier einfach um einen aufgedoppelten Block aus peripherie und SRAM? Man kann nämlich sehen, dass sich zwischen F6 und F8/C8 nicht nur der Speicher, sondern auch viele Funktionsblöcke verdoppeln. Ich frage mich, ob sich auf dem Die vielleicht auch eine ARM MCU verbirgt (ähnlich RP2350)? Denn es gibt ja ein identisches ARM CM3 pendant als CH32F203
Puya Semiconductor, interessant! Ich frage mich immer noch was die großen Blöcke rechts mittig darstellen. Sicher bin ich mir bei den "ADC-Flächen" nicht. ADCs sind oft sehr groß und ich wüsste nicht wo er sonst sein sollte. Es müssen schließlich zwei sein. Ob sich da ein ARM MCU verbirgt kann ich leider nicht sagen. :)
Tim . schrieb: > Ich frage mich, ob sich auf dem Die vielleicht auch eine ARM MCU > verbirgt (ähnlich RP2350)? Denn es gibt ja ein identisches ARM CM3 > pendant als CH32F203 Du meinst es wäre möglich dass CH32V203 und CH32F203 ein identisches Die verwenden und nur am Ende der Produktion irgendeine Fuse umgelegt wird und entscheidet welcher der beiden Kerne aktiv wird? Bin mir nicht ob das bei der kleinen Die-größe geht. Ist ja nicht nur der Core, sondern auch das ganze Routing zu und von der Peripherie. Aber man könnte natürlich einen CH32F203 aufmachen und vergleichen. Ich hab leider grad keinen zur Hand den ich Richard schicken könnte.
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.