Radku, mam to hotove.
https://www.ordoz.com/gdg2vhdl/3.0/Pridal jsem do programu par dalsich parametru. S pomoci -h si je muzete vypsat, at to tady porad nekopiruju.
Program je napsany tak blbe, ze vzdy nejprve nacita Mikesuv netlist a partlist a to i v pripade, ze pri nasledujici cinnosti nebude potrebovat. Neni problem to zmenit, nicmene primarne jsem psal program pro parsing Mikesovych dat a uz se mi na to proste nechce sahat.
Pokud se prida parametr -r cesty_blok.txt , tak se aplikuji RSUK data z tohoto souboru a je z nich mozne vyrobit VHDL, optimizovany VHDL, generovat schema v ISE, nebo vyhledavat cestu - tak jako se to da delat s daty ze SPICE.
Musel jsem na ty tve data udelat nekolik bugfixu - vse najdes v src/rsuk.c, kdyby jsi treba chtel menit vlastnosti vstupnich dat.
Data pri nacitani prochazeji stejnou syntaktickou kontrolou, jako ta Mikesova.
Porovnavani se zapina parametrem -c a povinnou volbou 1, nebo 2.
V prvni fazi porovnavani se vzdy pro jistotu udela kontrola, zda se v obou modelech nachazeji stejne soucastky na stejnych mistech.
Ve druhe fazi se pri volbe "1" projizdi postupne Mikesuv partlist takovym zpusobem, ze se vezme prvni soucastka a postupne se projdou vsechny jeji porty. U kazdeho portu se vyhleda jeho net a na nem se udela dotaz "kdo je tady zdrojem napeti?". Identicky proces se udela i nad stejne lokalizovanou soucastkou ze tvych dat a porovnava se, zda je v obou pripadech zdrojem napeti soucastka se stejnou lokalitou a portem - vysledek [Ano/Ne] je u tohoto porovnani na 100% pravdivy. V pripade, ze je zdrojem konstanta, tak se porovnava jeji hodnota 0/1 resp. GND / Vcc - tam by mela byt take 100% pravdivost odpovedi, nicmene konstant tam je poskromnu, takze ty lze projit i ocima. Komplikovanejsi odpoved na shodu zdroje napeti je i PIN pripojek, protoze neni jednotny system jejich identifikace. Za 100% pravdivou neshodu lze samozrejme povazovat i to, ze jeden modelel ma na netu jako zdroj uvedenu konkretni soucastku a druhy tam ma uveden nejaky PIN.
Program si pamatuje, ktere nety uz navstivil a kdyz na ne u dalsi soucastky ci portu narazi znova, tak uz je preskoci.
Volba "-c 2" provadi to same, ale listuje se tentokrat tvym modelem, ktery je proverovan proti Mikesovemu.
Diky ruznym odlisnostem v zapojeni a v identifikaci portu se muze stat, ze kazda metoda generuje jiny pocet nasbiranych chyb, protoze kazdy mate v modelu jiny pocet netu.
Vubec nepochybuji o tom, ze samozrejme ke spouste vadnych identifikaci muze dochazet i chybou meho parseru
Nicmene nahodny vyber z reportu:
Kód:
Different power source on 'xF302_2_3' (B0305) @ I2:
NET F111_1_3_out => F111_1_3 @ OUT
NET 270093 => F202_8_6 @ OUT
Znamena to, ze jsem u Mikese vzal do ruky soucastku 'xF302_2_3' (B0305), ktera ma na portu 'I2' pripojen NET s nazvem F111_1_3_out, u tebe jsem si vyhledal stejnou soucastku a net, ktery jsem u ni nasel na stejnem portu se jmenoval 270093 - kazdy net mel svuj zdroj napeti nekde jinde.
Coz odpovida SPICE netlist:
Kód:
F111_1_3_out F302_2_3 IN2 G
F111_1_3 OUT D
numIn: 1, numOut: 1
Vyber netu z RSUK:
Kód:
$ egrep ";270093;" cesty_blok.txt
489;270093;B305;I;IN2;F302;2-Input NAND gate;;;27;93;False;3537;635;1253;False;;0;0;3;1;0;0;True;True;
494;270093;B307;I;IN2;F303;3-Input NAND gate;;;37;93;False;288;480;1253;False;;0;0;3;1;0;0;True;True;
503;270093;B312;I;IN1;F306;6-Input NAND gate;;;65;93;False;1823;570;1253;False;;0;0;3;1;0;0;True;True;
1253;270093;B767;O;OUT;F202;2-Input NOR gate;;;52;198;False;4121;1350;1253;False;;0;0;0;0;3;1;True;True;
Metodou 1 program vyhleda 290 chyb, metodou 2 nalezne 250 chyb. Zadne dalsi zaludne porovnavaci metody se mi prozatim vymyslet nechtelo.
PS: jeste jsem to upgradnul na verzi 3.1 - je ve stejnem adresari - je tam metoda porovnani "3", ktera ignoruje to, ze nejakou cesu uz kontrolovala, takze se tim vlastne udela porovnani zdroju napeti pro vsechny porty vsech soucastek. Tato verze kontroly nalezla cca 1000 rozdilu.
Michal
Přihlásit se
Registrovat
OC Wiki 
OC GitHub 
FAQ
Hledat
