HW novinky: MediaTek představil 4+4+2jádrový ARM SoC (diskuse)

[pushkin]

...kupříkladu Lite-On (kdysi u nás známý jako výrobce vypalovaček)...

Jo, to byly časy. Kdykoliv jsem zahlédl nápis Lite-On, zježily se mi všechny chlupy a utíkal jsem se schovat. Docela by mě zajímalo, jak je na tom dnes s SSD (samozřejmě po kvalitativní stránce)...

[Michal Kubeček]

A pročpak to? Posledních zhruba 10 let jsem si jinou značku nekoupil a nikdy jsem s žádnou jejich mechanikou neměl problém.

[Attila]

Ja som na tom bol podobne s lite-onom. Bola a je to najmizernejšia značka, ktorú som vždy po roku ešte v záruke reklamoval, ale posledný kus sa pokazil až po 2rokoch a jednom dni, pričom som možno na ňom napaloval 10 ks medii a možno 50 krát bol použitý na čítanie.

Tú firmu by mali zakázať.

[pushkin]

+1

[koudy]

Proč se nevyplatí udělat pořádné 4 jádro, co by škálovalo od nějakých 300 MHz (asi tak na přehrávání mp3 + nějaké obslužné rutiny) až do x GHz?

V ideálním případě s vypínatelným jádrem(jádry), pokud není(nejsou) potřeba. (teď se předpokládám vypíná celé 4 jádro najednou a přepne se na druhé?)

Jako člověk příliš nepostižený HW (už vůbec ne CPU) mě tohle napadlo už když jsem viděl koncept BIG.little.

Intel zvládá rozsah 700 MHz - 3,5 GHz. (nemusí to být úplně přesně, ale je to přibližně 4-5 násobný rozsah, což se musí projevit na spotřebě)

Tenhle způsob musí být přece drahý.

Chápu, že to asi pěkně vypadá pro marketing a iOvce a roboOfce se mohou předhánět kdo má víc proužků, teda jader, ale technickou logiku v tom nevidím.

Ještě bych chápal, kdyby to fungovalo tak, že little poběží vždy a jen se zapojovalo BIG pokud by bylo potřeba. (nechtěl bych na to sice psát správce procesů, ale teoreticky by to šlo, někde jsem ten koncept zahlédl, že je možné mít zapnutých všech 8 jader najednou)

[Conscript89]

Rekl bych ze to bude narocnejsi na design a vyrobu nez tam proste pridat dalsi jadra a resit to softwarove.

[Pavel Píša]

Nejsem odborník na návrh na křemíku, ale obecně bude problém při 10 jádrech s L2 cache, takže tu budou nespíš vypínat po clusterech. Další věc je, že se dvě čtveřice jader, které mají stejnou architekturu a možná i logický návrh mohou lišit v implementaci tranzistorů (délka šířka kanálu). Jedna volba pak může být pomalejší optimalizovaná na nižší napětí a frekvenci a druhá na maximální výkon a tím i na nižší frekvenci vyžadovat pro spolehlivou funkci vyšší napětí nebo příkon. Další možnost je, že pomalejší čtveřice má v rozvodu hodin a signálů rezervu na další, agresívnější, vypínání bloků (buď jen hodin nebo i napájení) dynamicky po menších blocích a přímo po jednotlivých cyklech. Další možnost je, že jeden cluster má výrazně menší L2 cache. I když potom začne asi více brát hlavní paměť, protože do ní bude směřovat více přístupů. Řízené vypínání napájení a ignorování částí L2 cache by také mohlo mít značný význam, protože cache zabírá v dnešní době mnohem větší plochu než vlastní výkonná část procesoru. Přitom pro některé zátěže třeba stačí i CPU s malou cache.

Pro CMOS je teoreticky odběr daný jen počtem přepnutí, nabití hradel a kapacity vodičů za daný čas. Prakticky pro současné technologie tranzistorů a propojení již dochází k průsaku elektronů i jen v statickém stavu. Takže i statický odběr logiky začíná dohánět odběr dynamický. A tím se vracím opět k tomu, že se ty clustery mohou lišit topologií elementů.

Jinak scehduller Linuxu s rozložením zátěže na jádra s různou výkonností začíná počítat a taskům účtuje vyčerpání kvóty podle aktuálního předpokládaného výkonu jádra pro daný výběr na čipu a frekvenci. Nejsem si jistý jestli je to již plně v mainline, ale o patchích se na LWN psalo.

[pc2005]

Ideální by bylo udělat n-jádro, který by mělo asynchronní logiku (tedy žádný vnitřní hodiny a tranzistory by se spínaly jen při práci). Ale byla to šílenost navrhovat.

Jinak moderní procesory prakticky nepoužívají klasický CMOS struktury (co se lidi učí třeba na průmyslovce). Už jen taková věc jako CMOS4093 se dělá tak, že se ty tranzistory přetlačujou o VCC a GND. Flip-flopy se dělají dynamickou logikou (stejný princip jako DRAM). S tímhle se pak špatně navrhuje minimální frekvence. Navíc už od 486 mají procesory vnitřní násobičku frekvence a u PLL se musí hodnota držet ve vymezeném rozsahu, jinak se nechytí. Takže možná pokrytí rozsahu 100MHz až 2GHz by potřebovalo několik různých PLL.

Nevím ale (a teď to nemůžu najít), zda klasický ARMy tu dynamickou logiku používaj.

Další problém může být třeba řadič [S|D]DR-SDRAM. Ta paměť je synchronní, takže by se musela v případě moc nízké frekvence CPU připojovat přes nějaké FIFO buffery (zároveň wait stavy v architektuře CPU apod.).

Jinak přeladění PLL na jinou frekvenci chvíli trvá, stačí si párkrát pohrát s nějakým lepším mikročipem (ideálně bez IDE).

[koudy]

Pánové děkuji za osvětlení problému!

[frr]

Asi už chápu, proč se DMP u Vortex86 tolik chlubí tím, že ten procesor je plně statický. Sice jsem si nevšiml, že by desky podporovaly ACPI (usínací stavy) ale i jako akademické cvičení je to zajímavé Možná to vysvětluje, proč nemá takový vliv underclocking (až na 1/8 jmenovité frekvence, některé modely tuším i hlouběji), zato má citelný vliv, když OS volá HLT (rozdíl ve spotřebě DOS/Linux je značný).

[pc2005]

Velkej význam má taky Vcore napětí toho čipu.

[Pavel Píša]

No minimálně starší ARMy byly celkem statické. Když jsem spíš tak pro otestování naimplementoval před roky CPU frequency scaling pro naší destičku PiMX1 s FreeScale i.MX1, tak jsem při dodržení požadavků na poměry frekvencí jádra a sběrnic dokázal dynamicky/podle zátěže škálovat od 8 kHz do 200 MHz. Stím, že pod určitou frekvencí jsme dělil systémovou PLL a CPU PLL zastavoval a měl CPU hodiny se zběrnicí synchronní. V okamžiku, kdy se šlo nad frekvenci systémové PLL, tak se zapnula druhá PLL a přepla se konfigurace v jádře procesoru. ARM920T měl přímo požadavky na konfiguraci řídicího slova podle poměrů frekvencí. Nastavení zajišťovalo použití správného mechanizmu pro přenos dat sběrnic mezi hodinovými doménami. Nejsem si teď již úplně jistý, jak jsem při škálování systémových hodin řešil SDRAM a refresh, musel bych to dohledat. Ale mám pocit, že jsem jí také nechával jet jen na těch 8 kHz. Systém to zvládal zcela v pořádku, akorát byla zábava, jak při příjmu prvního znaku po sériové lince chvíli přemýšlel než vůbec poslal znak zpátky. Když dostal znaků více, tak začal škálovat frekvenci a pak chvilku odpovídal bystřeji.

V reálné aplikaci pro medicínské zařízení jsme si v té době Linux použít netroufli a z asynchronních sběrnic jsem měl také obavy, takže tam se používá RTEMS a podtaktovaný režim s konstatními hodinami. Ale otestování s Linuxem byla zábava a i nějakých 20 terminálů v jedné větší firmě s ním na naší desce běhá. Ale ani tam není škálování povolené, ani mírnější, těch 8 kHz by se s grafikou opravdu rádo nemělo.

Jinak asynchronní návrhy procesorů existují a co se týče výkonu, tak jsem zahlédl, že to není špatné. Ale takový návrh vyžaduje obvykle alespoň 2x až 3x více tranzistorů než synchronní ekvivalent a tak nakonec právě díky těm průsakům může pro větší chip vyjít hůře než synchronní. Ale v posledních letech jsem výsledky nesledoval.

[pc2005]

Jo koukal jsem se na datasheet Zynqu (Cortex-A9 MPCore) a podle všeho může integrovaný PLL jet už od 30MHz a měl by jít bypassnout, takže zynq by mohl jet jen na hodinách z externího zdroje. S PLL na 222MHz (třetina) byly i nejaký testy v Linuxu, ale jinak nic moc. Řekl bych, že moc lidí to při těchto podmínkách nebude testovat (u FPGA jde spíš o přetaktování ).

SDRAM refresh na 8kHz? zajímavý :-O . Měnilo se u toho i.MX1 i napětí (to má vyšší vliv na odběr než frekvence)?

[Pavel Píša]

Musel jsem najít a prohlédnout zdrojový kódu, ještě že ho za mě archivují jinde

http://lxr.linux.no/#linux+v2.6.24.7/arch/arm/mach-imx/cpufreq.c

Do mainline se dostala méně agresivní volba, kde je minimum nastavené na 8 MHz

Výhodou i.MX1 je, že periferie měly vlastní děličky přímo ze systémové PLL a CSCR.BCLK_DIV se tedy uplatňuje jen pro BCLK (bus clock ARMu) a HCLK (hodiny na SDRAM a některé zbývající periferie - kamera atd). Škálování se tedy projevilo i na hodinách SDRAM - té to, zdálo se, potíže nedělalo. Starty refresh cyklů byly řízené podle intervalu z 32kHz krystalu, takže jich bylo také správně, akorát při pomalých sběrnicových hodinách asi zabírali téměř veškerý čas.

Naše destička (viz schéma na příslušné stránce) má pro jádro jen pevný zdroj 1.8 V. Takže snížení spotřeby s napětím otestovat jednoduše nešlo. Z testování jsem měl záznamy, ale již je nejspíš nenajdu. Spotřeba ale klesala celkem v přímé úměře k frekvenci. Celkově i maximální odběr byl někde okolo 100 mA, pak se zapnulo napájení 100 Mbit Ethernetu, a dalších 100 mA bylo potřeba navíc.

[Laco]

Pre tvorcov tohoto webu, ospravedlnuje sa ze off topic..

Chlapi sorac, ale uz sa na ten klasicky DejaVu Sans font neda pozerat. Neviem ako ine distra ale v Ubuntu je to pismo obrovske, siroke, rozmazane... proste blivajz. Pouzite prosim nieco ineho. Ovela lepsie vyzera Liberation Sans, Free Sans alebo Droid Sans..

[Ruža Becelin]

Tak si uprav styl, ne?

[nobody]

a jeste zanadavej abclinuxu za to silene pozadi co pouzivas na plose a mys z ktere te boli ruka

[helb]

Abclinuxu pouziva sans-serif font urceny prohlizecem, takze „obrovske, siroke, rozmazane“ pismo je jen problem vaseho nastaveni.

[FAWN]

Tato stránka Dejavu Sans explicitně nepožaduje. V css je prostě obvyklým způsobem nastaven sans-serif. O změně písma se pane kolego dohodněte se svým browserem.

[pc2005]

Selfpwn

[Ondrej Santiago Zajicek]

Staci nepovolit strankam pouzivat vlastni fonty a nechat vse na konfiguraci prohlizece. Divim se, ze nekdo tuto volbu nepouziva, bez ni je pulka webu dost necitelna vzhledem ke kreativnim fontum.

[Petr Tomášek]

s kapacitou před 2 TB

s/před/přes/