Forum: Projekte & Code CH32V003 Instruction Execution Timing


von Tim  . (cpldcpu)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Gerd E. (robberknight)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Ich habe mal einen CH32V002 "geknackt" und die Diegröße vermessen. Der 
Die ist tatsächlich nur etwas halb so groß, wie im CH32V002.

von Harald K. (kirnbichler)


Lesenswert?

Das zweite der "CH32V002" sollte sicherlich "CH32V003" heißen, wie?

von Tim  . (cpldcpu)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

'S wär schön, wenn Richi sich die mal zu Gemüte führen könnte.

von Tim  . (cpldcpu)


Lesenswert?

Harald K. schrieb:
> 'S wär schön, wenn Richi sich die mal zu Gemüte führen könnte.

Ich frage ihn mal.

von Richard K. (richi123)


Lesenswert?

Klar, kann ich machen!

von Tim  . (cpldcpu)


Lesenswert?

Richard K. schrieb:
> Klar, kann ich machen!

Yay! Die chips sind unterwegs.

von Harald K. (kirnbichler)


Lesenswert?

Super, ich bin gespannt!

von Richard K. (richi123)


Lesenswert?

Fangen wir mit dem bereits bekannten CH32V003 an:

https://www.richis-lab.de/uC06.htm

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Richard K. (richi123)


Lesenswert?

Die Bonddrähte von Epoxid-Packages bleiben bei mir nicht erhalten. Was 
da wie verbunden war kann ich dir leider nicht sagen.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Richard K. (richi123)


Lesenswert?

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...

von Harald K. (kirnbichler)


Lesenswert?

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.

von Richard K. (richi123)


Lesenswert?

Ja, das sieht plausibel aus.

von Richard K. (richi123)


Lesenswert?

Und hier noch der CH32V002:

https://www.richis-lab.de/uC07.htm

von Tim  . (cpldcpu)


Lesenswert?

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
von Richard K. (richi123)


Lesenswert?

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.

von Richard K. (richi123)


Lesenswert?

Und nun der CH32V203:

https://www.richis-lab.de/uC08.htm

von Tim  . (cpldcpu)


Lesenswert?

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

von Richard K. (richi123)


Lesenswert?

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. :)

von Gerd E. (robberknight)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.