19.04.2015 09:24
[#241]
Re: Apollo Phoenix Core v2000 Vampire 600
@spidi, post #234
Może źle to ująłeś, mosfety nie są wrażliwe na pojemność, tylko posiadają pojemność bramki, którą należy przeładować.
Weźmy rysunek wcześniejszy translatora na jednym tranzystorze mosfet.
Zasadniczo tranzystor ten odpowiedzialny jest za zwieranie do masy linii 5V.
Za zwieranie do masy linii 3v3 odpowiedzialna jest dioda która jest skutkiem ubocznym w tranzystorze.
Rezystory zapobiegają stanom nieustalonym.
Jakie czynniki niekorzystne mamy w takim układzie?
Pierwszy czynnik to pojemność bramki którą należy przeładować prądem o napięciu 3v3 a z drugiej mańki 5V.
Tu mamy problem ponieważ układy mające wyjście pullUP posiadają rezystory podciągające o wartościach 1K do 10k no mniej więcej.
Więc mamy tak: I= C(dU/dt); gdzie C pojemność bramki.
Ze wzoru ohma mamy: I=U/R
A więc nasze I = -(U/R) = C(dU/dt) więc dU/dt = -(U/(C*R))
Jak widać jest silna zależność czasu przeładowywania C od pojemności i wartości R.
Trzeba wiedzieć co się podłącza i do jakiego rodzaju wyjścia.
Jaka wydajność prądowa jest wyjścia przy zmianie stanu z niskiego na wysoki i odwrotnie, oraz jaką częstotliwość się chce uzyskać.
Czasami nie wystarczy poszukać odpowiedniego tranzystora, a zbudować dodatkowe układy przeładowujące tę pojemność (zwiększające prąd przeładowania), dla zwiększenia impedancji wejścia takiego układu.
Zwiększenie prądu przeładowania wymaga stosowania pojemności magazynujące energie jak najbliżej układu.
Dla tego, wszelakiego rodzaju procesory pamięci itp. Obkłada się kondensatorami na zasilaniu.
Należy pamiętać, że wyższe częstotliwości >100MHz wymagają analizy pojemności pasożytniczych.
Weźmy rysunek wcześniejszy translatora na jednym tranzystorze mosfet.
Zasadniczo tranzystor ten odpowiedzialny jest za zwieranie do masy linii 5V.
Za zwieranie do masy linii 3v3 odpowiedzialna jest dioda która jest skutkiem ubocznym w tranzystorze.
Rezystory zapobiegają stanom nieustalonym.
Jakie czynniki niekorzystne mamy w takim układzie?
Pierwszy czynnik to pojemność bramki którą należy przeładować prądem o napięciu 3v3 a z drugiej mańki 5V.
Tu mamy problem ponieważ układy mające wyjście pullUP posiadają rezystory podciągające o wartościach 1K do 10k no mniej więcej.
Więc mamy tak: I= C(dU/dt); gdzie C pojemność bramki.
Ze wzoru ohma mamy: I=U/R
A więc nasze I = -(U/R) = C(dU/dt) więc dU/dt = -(U/(C*R))
Jak widać jest silna zależność czasu przeładowywania C od pojemności i wartości R.
Trzeba wiedzieć co się podłącza i do jakiego rodzaju wyjścia.
Jaka wydajność prądowa jest wyjścia przy zmianie stanu z niskiego na wysoki i odwrotnie, oraz jaką częstotliwość się chce uzyskać.
Czasami nie wystarczy poszukać odpowiedniego tranzystora, a zbudować dodatkowe układy przeładowujące tę pojemność (zwiększające prąd przeładowania), dla zwiększenia impedancji wejścia takiego układu.
Zwiększenie prądu przeładowania wymaga stosowania pojemności magazynujące energie jak najbliżej układu.
Dla tego, wszelakiego rodzaju procesory pamięci itp. Obkłada się kondensatorami na zasilaniu.
Należy pamiętać, że wyższe częstotliwości >100MHz wymagają analizy pojemności pasożytniczych.
14.05.2015 19:04
[#243]
Re: Apollo Phoenix Core v2000 Vampire 600
@] SKOLMAN_MWS ˇ agrEssOr [, post #242
Warto też przytoczyć fragment jednej rozmowy:
eXeler0 - Cool, that is almost exactly the same performance as my 66MHz 060.
Majsta - this is just child's play, you will see what happens in next few days This is only proving that hardware part is working properly.
eXeler0 - Cool, that is almost exactly the same performance as my 66MHz 060.
Majsta - this is just child's play, you will see what happens in next few days This is only proving that hardware part is working properly.
14.05.2015 19:35
[#244]
Re: Apollo Phoenix Core v2000 Vampire 600
@lysyzastary, post #243
Tak, tak, tylko są 2 problemy:
1. kompatybilność z istniejącym softem - z tego co wiem konieczna i tak jest biblioteka łatająca kompatybilność pod systemem (czyli coś a'la 68040.library) - a co z gierkami z dyskietek? :)
2. kompatybilność z softem pisanym na 040/060 full (czyli z FPU)
Phoenix ZTCW aktualnie FPU nie emuluje, a sprzęt wykorzystujący softcore nie przewiduje współdziałania z 68881/2 więc ... niektóre programy najzwyczajniej nie będą działać, a nawet jeśli będzie ścieżka z "zoptymalizowanym" kodem wykonującym floaty na ALU (czyli wbudowane procedury obsługi typu float na procesorach bez FPU zajmujące kilkaset zwykłych instrukcji) to będzie to żałosna prędkość. Z drugiej strony targetem aktualnie są A500, A2000 i A600 więc maszyny, dla których FPU czy 040/060 za wiele i tak nie zmieni - dlatego jest się z czego cieszyć. A dla A1200 które kipper2k też już szykuje - no miejmy nadzieję, że jakieś rozwiązanie się pojawi.
1. kompatybilność z istniejącym softem - z tego co wiem konieczna i tak jest biblioteka łatająca kompatybilność pod systemem (czyli coś a'la 68040.library) - a co z gierkami z dyskietek? :)
2. kompatybilność z softem pisanym na 040/060 full (czyli z FPU)
Phoenix ZTCW aktualnie FPU nie emuluje, a sprzęt wykorzystujący softcore nie przewiduje współdziałania z 68881/2 więc ... niektóre programy najzwyczajniej nie będą działać, a nawet jeśli będzie ścieżka z "zoptymalizowanym" kodem wykonującym floaty na ALU (czyli wbudowane procedury obsługi typu float na procesorach bez FPU zajmujące kilkaset zwykłych instrukcji) to będzie to żałosna prędkość. Z drugiej strony targetem aktualnie są A500, A2000 i A600 więc maszyny, dla których FPU czy 040/060 za wiele i tak nie zmieni - dlatego jest się z czego cieszyć. A dla A1200 które kipper2k też już szykuje - no miejmy nadzieję, że jakieś rozwiązanie się pojawi.
15.05.2015 18:11
[#245]
Re: Apollo Phoenix Core v2000 Vampire 600
@abcdef, post #244
mysle ze wazne cytaty:
" Apollo core will have CPU 680x0 + FPU,
and others features, depending on board devices."
" Vampire 1200 V1 : C3 40000 LE (in early development)"
" All boards that are >=25000 LE will have the Apollo Core (full featured core)."
"The card also includes:
HDMI for full HD.
Network.
MicroSD as harddrive."
"Phoenix does support _ALL_ address modes of the 68K family
this includes _ALL_ address modes of 68020 to 68060.
Phoenix is designed to provide full compatibility to existing software. We are not aware of any incompatibilities."
biblioteka 680x0.library bedzie tylko dla programow ktore jej wymagaja do uruchomienia sie. W rzeczywistosci ona bedzie praktycznie "wydmuszka" bo proc ma po prostu obslugiwac hardwarowo wszystke tryby adresowania.Ta biblioteka bedzie ladowana automatycznie z flasha karty.Z kolei grac z dyskietek bedzie mozna ale nie beda one widzialy dodatkowej pamieci, chyba ze w s-s wstawi sie na paczatku c:phoenixinit.
Ostatnia aktualizacja: 15.05.2015 18:12:50 przez HanSolo
" Apollo core will have CPU 680x0 + FPU,
and others features, depending on board devices."
" Vampire 1200 V1 : C3 40000 LE (in early development)"
" All boards that are >=25000 LE will have the Apollo Core (full featured core)."
"The card also includes:
HDMI for full HD.
Network.
MicroSD as harddrive."
"Phoenix does support _ALL_ address modes of the 68K family
this includes _ALL_ address modes of 68020 to 68060.
Phoenix is designed to provide full compatibility to existing software. We are not aware of any incompatibilities."
biblioteka 680x0.library bedzie tylko dla programow ktore jej wymagaja do uruchomienia sie. W rzeczywistosci ona bedzie praktycznie "wydmuszka" bo proc ma po prostu obslugiwac hardwarowo wszystke tryby adresowania.Ta biblioteka bedzie ladowana automatycznie z flasha karty.Z kolei grac z dyskietek bedzie mozna ale nie beda one widzialy dodatkowej pamieci, chyba ze w s-s wstawi sie na paczatku c:phoenixinit.
Ostatnia aktualizacja: 15.05.2015 18:12:50 przez HanSolo
15.05.2015 21:57
[#246]
Re: Apollo Phoenix Core v2000 Vampire 600
@HanSolo, post #245
Dawno nie przeglądałem forum apollo-core, ale jak przeglądałem to nawet nie było "draftów" obsługi FPU, a jeśli już to jedynie idea, że można by kiedyś takie coś zrobić. Teraz przeglądam i też nie widzę żadnych konkretów, ani wykreślonego nawet timeline dla robienia obsługi FPU. Baaa... jak dobrze kojarzę na stronie apollo-core była nawet wzmianka o "możliwej ... kiedyś" emulacji 68881, natomiast teraz zupełnie brak tego typu informacji. Nie piszę tego żeby w jakiś sposób zanegować prace nad takim softcore, natomiast nie wydaje mi się by dla ekipy był to jakiś priorytet.
16.05.2015 18:57
[#247]
Re: Apollo Phoenix Core v2000 Vampire 600
@HanSolo, post #245
Tryby adresowania Motoroli to nie jest to samo co rozkazy Motoroli, to jest takie sciemnianie rzeczywistosci. Z tego co ja wiem to sporo rozkazow nie jest obslugiwanych przez to core. Ktore to nie wiem bo Gunnar zmienia zdanie dosc czesto, np. tryby adresowania 68020 sa a mialo ich nie byc, bo podobno mialo to spowalniac dzialanie tego core, ale to chyba nie bylo prawda. Inna sprawa jest to, ze zamiast dodac do core rozszerzenie w postaci jakiegos wolnego hexa jako ID, to robi brudne hacki, typu dodanie rejestru A8, do tego nie wiadomo zupelnie po co. Ale on nalezy do ludzi, ktorzy wiedza lepiej.
16.05.2015 20:29
[#248]
Re: Apollo Phoenix Core v2000 Vampire 600
@Don_Adan, post #247
Tak, gwoli ścisłości. Jak to wygląda z twojego punktu widzenia, tj czy faktycznie można można zrobić procesor kompatybilny z wszystkimi modelami rodziny 68k łącząc ich zalety i eliminując wady?
Gunnar pewnie zrobił ten rejestr na własne potrzeby, aby korzystało z niego oprogramowanie napisane dla phoenixa (jakieś hacki itp). Jestem ciekaw co podają programy do wykrywania procesora, jak jest włożony phoenix.
Gunnar pewnie zrobił ten rejestr na własne potrzeby, aby korzystało z niego oprogramowanie napisane dla phoenixa (jakieś hacki itp). Jestem ciekaw co podają programy do wykrywania procesora, jak jest włożony phoenix.
16.05.2015 22:52
[#249]
Re: Apollo Phoenix Core v2000 Vampire 600
@sanjyuubi, post #248
Ze wszystkimi to chyba raczej nie, ale w 99.9% to tak. O ile pamietam to jedna instrukcja dla 68030 jest inna niz dla 68040 w jej kodowaniu lub w dzialaniu. Ale to jest nie uzywana instrukcja. 68040 ma wszystkie wazne instrukcje CPU (w tym move16), i to powinien byc punkt wyjscia jesli chodzi o instrukcje CPU, jesli zas chodzi o szybkosc to oczywiscie punktem wyjscia powinna byc 68060, ale osiagi tego procesora trzeba porownywac z CT63 a nie Amigowymi turbinami. Co do programow testowych to nie wiem, pewnie zalezy co ktory sprawdza. Zas jesli chodzi o samego Vampire to 128MB to jest za malo, tyle ze jest ono wzglednie tanie, ale nie wiem jakie sa ceny 512MB i czy sa dostepne.
23.07.2015 00:39
[#250]
Re: Apollo Phoenix Core v2000 Vampire 600
@Don_Adan, post #249
Wyglada na to, ze Gunnar jednak zrozumial, ze dobry procesor z serii 68k musi miec wszystkie instrukcje 68040. Dodal juz movep, podobno bardzo szybkie. A ile ja sie z nim musialem nawalczyc o te instrukcje, ze niby niepotrzebna, ze wolna itp. W kazdym razie jest na dobrej drodze zeby zrobic najlepszy procesor 68k, musi jeszcze tylko pozbyc sie paru kiepskich pomyslow typu rejestr A8. A jak ten procesor bedzie wykonywal do 6 instrukcji w 1 cyklu to bedzie to bardzo szybki procesor.
24.08.2015 20:52
[#255]
Re: Apollo Phoenix Core v2000 Vampire 600
@harrik, post #254
http://obligement.free.fr/articles_traduction/itwmajstorovic_en.php Wywiad z Majsta...
07.10.2015 20:40
[#263]
Re: Apollo Phoenix Core v2000 Vampire 600
@HanSolo, post #261
Troche informacji jest na stronie projektu w Bring Up.
Wedlug AIBB osiagneli ponad 560 MHz szybkosci dla 68040, czyli jest niezle.
Jesli wszystkie instrukcje 68040 CPU i 68882 FPU sa zaimplementowane to moze byc bardzo dobry procesor. Pozostaje juz tylko (?) MMU i pozbycie sie glupich pomyslow typu rejestr A8.
Wedlug AIBB osiagneli ponad 560 MHz szybkosci dla 68040, czyli jest niezle.
Jesli wszystkie instrukcje 68040 CPU i 68882 FPU sa zaimplementowane to moze byc bardzo dobry procesor. Pozostaje juz tylko (?) MMU i pozbycie sie glupich pomyslow typu rejestr A8.
07.10.2015 23:10
[#266]
Re: Apollo Phoenix Core v2000 Vampire 600
@wawrzon, post #264
Nie wiem jak AIBB wylicza MHz, pewnie liczy ilosc instrukcji wykonanych w jakiejs petli w jakims czasie. Apollo mial wykonywac do 3 instrukcji w jednym cyklu, oraz do 6 instrukcji laczonych (fusion) w jednym cyklu zegara. 68040 mogl wykonac maks jedna instrukcje CPU w cyklu. Tak wiec to daje wedlug mnie jakies 100 do 166 MHz realnej szybkosci Apollo w uzytym FPGA, Cyclone 5 (?), bo chyba nie Stratix.