Radiace vs. typy pameti

Středa Duben 16 09:48:08 CEST 2008

Ano o tom vim, uz jsem ho kontaktoval mailem. Cekam na reakci. Doufam 
ale ze ma nejake podrobnejsi informace. Test jednocipu je dost komplexni 
zalezitost, protoze tam ma ruzne typy pameti a musel by se kontrolovat 
obsah vsech zvlast, nestaci jen stav vystupnich signalu. Uvidime. Jestli 
tohle cte OK2PNQ, tak to muze jit popohnat ;-)

Tosa

Jan Půhoný wrote:
> Dobry den,
>
> s merenim radiacni odolnosti nejakych jednocipu (tusim ze jeste 
> PIC12C508) ma primo na URELu zkusenosti prof. Kasal. Alespon nam na 
> prednasce ukazoval fotku desky, kde bylo asi 10 procesoru se stejnym 
> programem. Cela deska byla vystavovana zareni a sledovala se spolehlivost.
>
> S pozdravem Jan Půhoný
>
> Petr Tošovský napsal(a):
>   
>> Ahoj.
>> Diky za rozsahlou odpoved. Samozrejme ze jsem nasel spousty dokumentu na 
>> internetu, predevsim co se tyce organizace NASA a hned za nimi CERN 
>> (predevsim dokumentace k detektoru ALICE). Jsou to ale vetsinou jen 
>> vysledky mereni, kdy vezmou zvolene typy FPGA (vetsinou ty nejvetsi) a 
>> na zvolenem designu sleduji spolehlivost zarizeni. Obvody zalozene na 
>> EEPROM strukture jsem nikde nenasel, jen par zbeznych konstatovani ze 
>> EEPROM jsou vyrazne odolnejsi. (???)
>> Zkusil jsem kontaktovat i dalsi dva lidi o kterych vim ze se aktivne 
>> podileli na konstrukci druzice, takze doufam ze maji nejake osobni 
>> zkusenosti. Konzultovat to s nejakym specialistou by bylo idealni, 
>> domluvime se.
>> K projektu - nemuzu si dovolit reload a nejlepe ani jeden vadny bit v 
>> datovem toku. Jsou to dost kriticke podminky, ale jedna se o mereni 
>> spolehlivosti prenosu, takze kazda chyba na vysilaci zmeni vysledky a 
>> neni mozne o teto chybe informovat prijimaci stranu. Ve vysledku by pak 
>> mohly vychazet vysledky mereni prenosoveho prostredi hodne spatne a 
>> nebylo by to prenosovym prostredim ale chybami vysilace. Takze tomu se 
>> potrebuji vyvarovat.
>> Jinak co se tyce pouziti spolehlivejsich prvku jako specialni FPGA od 
>> Xilinxu nebo Actelu - jsem z toho rozcarovany jeste ted. Cekal bych ze 
>> na podobne projekty bude mozne vyuzit kde co jen aby to bylo spolehlive, 
>> ale bohuzel to tak neni. Spis to vypada na praci podobnym stylem jako v 
>> nasem skolstvi. Tady mas vyvojove prostredi, programovaci kabel, takze 
>> se musis drzet tohoto vyrobce (konkretne Altera), nepouzivej nic 
>> specialniho jen to co sezeneme v beznem obchodu, ne BGAcka protoze ty 
>> nezapajime rucne a mel by ses vejit na dvouvrstvy plosnak. Vzhledem k 
>> cenam okolni techniky mi to prijde komicke. Z tohoto pristupu se mi po 
>> tech letech uz otvira kudla v kapse.
>> No nic, musel jsem si postezovat, sklapnout a jit dal vymyslet co s tim ...
>>
>> Tosa
>>
>>
>> balu@home wrote:
>>   
>>     
>>> trojite hlasovanie neriesi vsetko :-))
>>> skus sa trochu pohrabat na internete, najdes vela clankov, mnozstvo z 
>>> nich ma nieco spolocne s CERNom :-)))
>>> Dal som do googlu "design of radiation tolerant programmable logic" a 
>>> naslo to napriklad toto:
>>> http://ep-div-ed.web.cern.ch/ep-div-ed/programmable_logic.htm 
>>> Programmable logic
>>> http://www.iop.org/EJ/abstract/1748-0221/2/09/P09009/ Development of 
>>> SEU-robust, radiation-tolerant and industry-compatible programmable 
>>> logic components
>>> http://www.pldesignline.com/products/207002119 Xilinx introduce 
>>> highest-performance, largest-capacity FPGAs for space applications
>>> http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/8086/22361/01045530.pdf?arnumber=1045530 
>>> Ionizing radiation effects in EPF10K50E and XC2S150 programmable logic 
>>> devices
>>> http://www.fpgajournal.com/articles/20040803_space.htm FPGAs in 
>>> Space/Programmable Logic in Orbit
>>> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1688900 A design 
>>> approach for radiation-hard digital electronics
>>>
>>> tym som nechcel povedat ze sa mas najprv pozret co je na internete, ale 
>>> ze je tam celkom uzitocna literatura.
>>> Nas VF system tiez zapada do tejto kategorie a na zaciatku sme robili 
>>> mnozstvo simulacii aby sme vedeli odhadnut mnozstvo poruch.
>>> Osobne v tom nie som velmi zainteresovany, lebo v tuneli mam len pasivne 
>>> veci a vsetka inteligencia je az na povrchu :-)
>>> V principe je tam niekolko pristupov. V prvom rade musis mat nejake 
>>> specifikacie o aky druh radiacie sa jedna a aka bude intenzita. 
>>> Ionizacne ucinky vysokoenergetickych castic su zname, ked vies aka je 
>>> technologia tvojho programovatelneho pola a aka je hustota integracie 
>>> vies odhadnut aka je pravdepodobnost ze castica flipne bit v 
>>> konfiguracnej pamati. Cim mensie pamatove bunky na cipe tym vacsia 
>>> pravdepodobnost ze sa nieco stane, lebo je potrebna ovela nizsia energia 
>>> na zmenu stavu.
>>> Existuje rad-hard verzia Xilinxov, ak mate vela penazi mozete kupit 
>>> nejake fpga od Actel-u.
>>> Dalsia vec je samotny dizajn. Vela problemov sa da osetrit spravnym 
>>> navrhom tvojej logiky. V principe existuju dva typy problemov. 
>>> Poskodenie statickeho konfiguracneho bitu bud v logike alebo nejakom 
>>> registri. S tymto vela nenarobis a musis to osetrit.
>>> Druhy typ je poskodenie toku dat. Flipne ti nejaky bit (alebo viacej) a 
>>> data proste tecu dalej ale s tym ze jedna vzorka je napriklad nespravna. 
>>> Pokial mas spracovanie dat inteligentne, t.j. sa tvoja logika nespolieha 
>>> na to ze je vsetko spravne tak tie data jednoducho po nejakom case 
>>> vytecu von a nic sa nestalo.
>>> Toto je aj nas pripad, vsetku logiku sa snazime navrhovat tak aby 
>>> nehavarovala pri nezmyselnych datach. Aritmeticke funkcie a filtre maju 
>>> saturaciu, signalizuju pretecenie, v pripade zjavne neobvyklych dat 
>>> podrzia poslednu hodnotu, su navrhnute tak aby sa nezblaznili...
>>> Dalsia vec ktora sa robi v druziciach (a implementovali sme ju aj my) je 
>>> ze sa FPGA v pravidelnych intervaloch reloaduje. Na druziciach to moze 
>>> byt aj napriklad kazdu hodinu. U nas kompletne reloadneme vsetky FPGA na 
>>> VME kartach pred kazdou injekciou noveho zvazku. Takto je zabezpecene ze 
>>> FPGA nebudu postupne degradovat a akumulovat chyby, ale ze pri urcitej 
>>> pravdepodobnosti SEU mas akceptovatelne nizku sancu ze sa v 
>>> nasledujucich x hodinach nic nestane.
>>> Dalsie techniky su rozmiestnenie logiky tak aby neboli spracovavane data 
>>> routovane paralelne, ale rozhodene po celom cipe, takze ked je 
>>> zasiahnuta jedna strana nedostanes kompletne zlyhanie ale nieco z coho 
>>> sa dokazes zotavit.
>>> A samozrejme to trojite hlasovanie.. To je uz ale naozaj overkill, musis 
>>> mat naozaj extremne dolezitu aplikaciu ktora nemoze stratit ani jeden 
>>> bit a musi mat 100% uptime. Toto sa ale vacsinou riesi rozumnym 
>>> inzinierskym kompromisom a nastavenim rozumnych podmienok. Pokial 
>>> supervizor povie zo to tak bude a hotovo bez udania rozumnych dovodov je 
>>> to len strata casu a mrhanie zdrojmi. Ako vas klasik povedal pokial 
>>> nejde o zivot ide o hovno. A vacsine digitalnych obvodov strata par 
>>> bitov, resp. par vzoriek nevadi.
>>> Toto je otazka na strasne dlhu debatu a su v tom desiatky rokov 
>>> skusenosti. Pokial mas vazny zaujem o problematiku a riesis konkretny 
>>> problem skusil by som dohodnut konzultaciu s niekym od nas kto sa tymito 
>>> vecami zaobera. Jednym mailom sa to neda obsiahnut.
>>> b.
>>>
>>>
>>> Petr Tošovský wrote:
>>>   
>>>     
>>>       
>>>> Zdravim vsechny.
>>>> Uvedomuju si ze je to dost specificky problem, ale minimalne d. a b. by 
>>>> se k tomu mohli vyjadrit a mohlo by to zajimat i ostatni.
>>>> Premyslim tu ted jak se da navrhnout zarizeni s programovatelnou 
>>>> logikou, ktere bude fungovat v prostredi s velkou radiaci. Podle vseho 
>>>> co jsem si zatim precetl, se v takovem prostredi vyskytuji selhani typu 
>>>> SEU (zmena konfigurace) nasledovana chybou oznacovanou SEFI (preruseni 
>>>> funkce). V lepsim pripade pouze chyba SET, kterou chapu jako pouhe 
>>>> prehozeni urovne v registru ktery nema vliv na konfiguraci obvodu. 
>>>> Resenim je vetsinou pouziti techniky TMR (Triple Module Redundancy), 
>>>> takze vse v FPGA je trikrat + se pouzivam automaticka kontrola 
>>>> konfigurace podle CRC (u lepsich FPGA).
>>>> Narazil jsem na to ze EEPROM maji byt proti SEU imunni, jenze nikdo 
>>>> nepise jak mnoho a jestli vsechny EEPROM.
>>>> Otazkou tedy je jak se stanovuje cetnost SEU pokud znam uroven radiace 
>>>> (doufam ze ji zjistim). Bezne soucastky, ktere mam vyhlednute nemaji ve 
>>>> svych parametrech uvadenou odolnost, tak bych chtel vyjit z nejakych 
>>>> obecnych parametru podle struktury popripade technologie.
>>>> Pomohu si kdyz pouziju stare CPLD z rady MAX3000A, ktere maji 
>>>> konfiguraci v EEPROM, ale neumoznuji jeji prubeznou kontrolu jako 
>>>> moderni FPGA? S TMR nemohu zajit dal nez k hranici chipu, vnejsi 
>>>> soucastky nebudou mit zalohy, neni zpusob jak by se vyhodnocovala jejich 
>>>> spravna resp. spatna funkce. Takze by bylo dobre kdybych si dovedl 
>>>> alespon odvodit ze k chybam nebude s 99.99999% pravdepodobnosti dochazet 
>>>> 1000krat za sekundu. Kdyz se snazim vyloucit vse co by melo konfiguraci 
>>>> v SRAM, tak jsem jak v dobe kamenne, vse co ma seriove nastavovaci 
>>>> rozhrani je k nicemu.
>>>> Poradte nekdo za jaky konec to vzit?
>>>>
>>>> Doufam alespon ze jste z toho po precteni taky tak zmateni jako ja. ;-) 
>>>>
>>>> Tosa
>>>>
>>>> _______________________________________________
>>>> HW-list mailing list  -  sponsored by www.HW.cz
>>>> Hw-list@list.hw.cz
>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>>
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list@list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>   
>>>     
>>>       
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list@list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>   
>>     
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
>   