23.08.2015 11:57
[#31]
Re: Kanapka FPGA dla A1200
@cahir, post #30
Orientujesz się w jakiej firmie? Czy nawet tego Ci nie zdradził?
Niestety nie, wysłałem mu maila z pytaniem o to, ale nie spodziewam się odpowiedzi....
Z tego co rozumiem Budgie generuje zegar 28MHz dla całego systemu. Zatem cykl trwa 35ns. Dodatkowo każde 15cm PCB wprowdza opóźnienie 1ns.
Na starcie mielibyśmy przesunięcie cyklu o około 8ns, czyli ponad 20% cyklu. To chyba sporo
Niektóre komponenty serii ALVT są jeszcze produkowane. Oczywiście są droższe niż LCX ale można się rozejrzeć, czy coś z tego by nie pasowało.
Jeśli chodzi o opóźnienie. Szczerze mówiąc to nie wiem, czy miałoby to tak duże znaczenie. Jeśli docelowo procesor byłby na naszej karcie, to raczej nie jest to problemem (trzeba tylko zmieścić się w timingach płyty głównej A1200 wykonując operacje do niej, ale karta turbo nie musi działać synchronicznie do zegara płyty, choć może). Wydaję mi się nawet, że pożądane jest aby karta turbo działała asynchronicznie (biorąc pod uwagę różne timing fixy itd.).
23.08.2015 12:21
[#32]
Re: Kanapka FPGA dla A1200
@strim_, post #31
Niestety nie, wysłałem mu maila z pytaniem o to, ale nie spodziewam się odpowiedzi....
Czyli szukamy dalej...
Jeśli chodzi o opóźnienie. Szczerze mówiąc to nie wiem, czy miałoby to tak duże znaczenie.
Ok, ale zauważ, że chcemy zrobić kartę do prototypowania. W połączeniu z FPGA może urodzi się z niej coś co będzie działać synchronicznie względem zegara płyty. Próbuję zminimalizować ilość potencjalnych problemów, która może wyniknąć z użycia układów o dłuższym czasie propagacji.
Niektóre komponenty serii ALVT są jeszcze produkowane. Oczywiście są droższe niż LCX ale można się rozejrzeć, czy coś z tego by nie pasowało.
A to?
Ostatnia aktualizacja: 23.08.2015 12:35:57 przez cahir
23.08.2015 15:00
[#33]
Re: Kanapka FPGA dla A1200
@cahir, post #30
Z tego co rozumiem Budgie generuje zegar 28MHz dla całego systemu. Zatem cykl trwa 35ns. Dodatkowo każde 15cm PCB wprowdza opóźnienie 1ns. Na starcie mielibyśmy przesunięcie cyklu o około 8ns, czyli ponad 20%. To chyba sporo?
Dla bufora szyny nie ma to żadnego znaczenia, transfery do i z płyty i tek nie będą szybsze niż pozwalałaby na to szyna procesora 020 14MHz.
Co do reszty zastosowań, to najpierw musisz zrobić analizę, do czego ci potrzebny ten zegar 28MHz, bo generalnie nic w A1200 nie jest nim taktowane, prócz układu generującego obraz (PAL), potem ten sygnał jest dzielony na kilka innych wolniejszych zegarów przesuniętych w fazie do sterowania logiki chipsetu.
Karta turbo może i nie musi działać synchronicznie z zegarem płyty głównej A1200, ale to nie ma znaczenia. Wszystko co działa szybciej, musi być dostosowane do szyny procesora 68020 14MHz, czyli jeśli włożysz procesor 68020 28MHz, to musisz symulować timingi przy dostepie do płyty głównej tak jakby to był procesor 14MHz.
Turbo do GBA na 060 musi mieć szybszą logikę, bo tam procesor wykonuje dostęp do pamięci w trybie burst , co przy 50MHz daje cykl 20ns, a biorąc pod uwagę, że pamięć będzie sterowana np. zegarem opadającym, to zostaje nam 10ns na wystawienie sygnału i reakcję pamięci, odejmij 8ns i zostaje 2ns na reakcję logiki i pamięci. Takie rzeczy jednak trzeba uwzględniać przy budowie karty turbo i powinny się na niej znaleźć na torze procesor-pamięć, na torze procesor-amiga już masz małe transfery i cykl procesora składający się z trzech taktów zegara.
Jeśli masz zamiar robić scandoubler, to wtedy może te 8ns by grały rolę.
Jak ktoś jeszcze wie do czego jest używany zegar 28MHz, to niech pisze.
Ostatnia aktualizacja: 23.08.2015 15:02:23 przez sanjyuubi
25.08.2015 13:21
[#34]
Re: Kanapka FPGA dla A1200
@sanjyuubi, post #33
@sanjyuubi: Dzięki za uwagi!
Eksperymentowałem na żywym sprzęcie jak to jest z tymi dostępami do zasobów zmapowanych pod clockport i inne urządzenia, które mogą być podpięte pod Gayle'a. Poniżej zamieszczam źródełko:
gayle1.s
Wychodzi na to, że Gayle jest taktowany zegarem 14.28 MHz i dla większości urządzeń zewnętrznych jest 16-bitowy - tj. 8/16 bitowe dostępy zajmują tyle samo, 32-bitowe dostępy są rozbijane na dwa mniejsze (za wyjątkiem ROM-u?). Liczyłem ile cykli zajmuje pojedynczy dostęp i wyszły mi takie wyniki:
Biorąc pod uwagę, że port zegara ma wystawione 4-bity danych, to maksymalny możliwy transfer to około 14285714[cykil/sekundę] / 16[cykli] * 4[bity] / 8[bit/bajt] ~ 435kB/sek (to by wyjaśniało czemu RapidRoad USB jest tak wolny). Gdyby rozbudować clockport do pełnych 16-bitów to mamy 1743kB/sek. Zamiast spare / rtc używać arcnet: 2790kB/sek, lub flash: 5580kB/sek.
No to się podzieliłem informacjami...
Ostatnia aktualizacja: 25.08.2015 13:31:13 przez cahir
Eksperymentowałem na żywym sprzęcie jak to jest z tymi dostępami do zasobów zmapowanych pod clockport i inne urządzenia, które mogą być podpięte pod Gayle'a. Poniżej zamieszczam źródełko:
gayle1.s
Wychodzi na to, że Gayle jest taktowany zegarem 14.28 MHz i dla większości urządzeń zewnętrznych jest 16-bitowy - tj. 8/16 bitowe dostępy zajmują tyle samo, 32-bitowe dostępy są rozbijane na dwa mniejsze (za wyjątkiem ROM-u?). Liczyłem ile cykli zajmuje pojedynczy dostęp i wyszły mi takie wyniki:
spare equ $d80000 ; 16 clks/word, 30clks/long
arcnet equ $d90000 ; 10 clks/word, 18clks/long
ide equ $da0000 ; 16 clks/word, 30clks/long
rtc equ $dc0000 ; 16 clks/word, 30clks/long
flash equ $f00000 ; 5 clks/word, 9clks/long
rom equ $f80000 ; 3 clks/word, 3clks/long
Biorąc pod uwagę, że port zegara ma wystawione 4-bity danych, to maksymalny możliwy transfer to około 14285714[cykil/sekundę] / 16[cykli] * 4[bity] / 8[bit/bajt] ~ 435kB/sek (to by wyjaśniało czemu RapidRoad USB jest tak wolny). Gdyby rozbudować clockport do pełnych 16-bitów to mamy 1743kB/sek. Zamiast spare / rtc używać arcnet: 2790kB/sek, lub flash: 5580kB/sek.
No to się podzieliłem informacjami...
Ostatnia aktualizacja: 25.08.2015 13:31:13 przez cahir
25.08.2015 14:43
[#37]
Re: Kanapka FPGA dla A1200
@sanjyuubi, post #33
W specyfikacji do Gayle'a można znaleźć następujący ustęp:
Pytanie do specjalistów... Czy mam rozumieć, że jeśli wyrobimy się z dekodowaniem adresu przed Gayle'em to możemy umieścić w fizycznej przestrzeni adresowej nasze wersje w/w urządzeń? Rozumiem, że nasze nakładki również obowiązuje zegar 14.28MHz?
In addition to its function in overriding the generation of ~DTACK, the ~OVR signal can override address decoding in GAYLE. Thus it can be used to allow external devices to reside in address ranges that are normally reserved for motherboard devices, such as the credit card interface. Use of ~OVR for this use basically requires that ~OVR is asserted earlier than ~AS. Address ranges where this is effective are shown below:
Address range | Normal cycle type
$A00000 - $A7FFFF | Flash ROM
$A80000 - $B7FFFF | Workbench ROM
$B80000 - $BEFFFF | Reserved for CDTV
$DB0000 - $DB0000 | External IDE drive
$DD0000 - $DDFFFF | Reserved for DMAC
$E00000 - $E7FFFF | System ROM
$F80000 - $FFFFFF | System ROM
Any address ranges where ~OVR is legal, use of the XRDY signal to extend the cycle is also legal. Other address ranges ignore the XRDY signal.
Pytanie do specjalistów... Czy mam rozumieć, że jeśli wyrobimy się z dekodowaniem adresu przed Gayle'em to możemy umieścić w fizycznej przestrzeni adresowej nasze wersje w/w urządzeń? Rozumiem, że nasze nakładki również obowiązuje zegar 14.28MHz?
25.08.2015 16:46
[#39]
Re: Kanapka FPGA dla A1200
@cahir, post #37
Małe sprostowanie, oczywiście chodzi o przedział $DB0000 - $DBFFFF:
Z tego co rozumiem wszystkie wymienione przedziały mogą lecieć na transferach 32-bit / 3 cykle. Przy zegarze 14.28MHz daje to około 18601kB/sek. Czy to ma sens?
BTW. Odnośnie Gayle'a... sygnał _ROMEN jest podłączony bezpośrednio do _WIDE. Zdaje się to tłumaczy czemu ROM jest obsługiwany przy pomocy 32-bitowej szyny danych. Możliwe, że prostą przeróbką dałoby się pod _WIDE podpiąć również _SPARE_CS, _RTC_CS i _NET_CS dublując przepustowość dostępu.
$DB0000 - $DB0000 | External IDE drive
Z tego co rozumiem wszystkie wymienione przedziały mogą lecieć na transferach 32-bit / 3 cykle. Przy zegarze 14.28MHz daje to około 18601kB/sek. Czy to ma sens?
BTW. Odnośnie Gayle'a... sygnał _ROMEN jest podłączony bezpośrednio do _WIDE. Zdaje się to tłumaczy czemu ROM jest obsługiwany przy pomocy 32-bitowej szyny danych. Możliwe, że prostą przeróbką dałoby się pod _WIDE podpiąć również _SPARE_CS, _RTC_CS i _NET_CS dublując przepustowość dostępu.
25.08.2015 17:11
[#40]
Re: Kanapka FPGA dla A1200
@cahir, post #37
Czy mam rozumieć, że jeśli wyrobimy się z dekodowaniem adresu przed Gayle'em to możemy umieścić w fizycznej przestrzeni adresowej nasze wersje w/w urządzeń? Rozumiem, że nasze nakładki również obowiązuje zegar 14.28MHz?
Procesor najpierw ustawia adres na szynie, a potem (dokładnie pół cyklu zegara potem) ustawia _AS. My musimy zdekodować adres i ustawić _OVR przed nim. Czyli mamy na to teoretycznie 35 ns, w praktyce trochę mniej, bo _OVR musi się dobrze ustalić, zanim procesor poda _AS. Prosta logika kombinacyjna powinna się spokojnie wyrobić, nie wiem tylko, czy może być na stałe podpięta do szyny adresowej, bo ona jest trójstanowa.
Co do obowiązywania zegara 14 MHz – w zasadzie skoro podaliśmy już _OVR to Gayle powinien się łaskawie odczepić i to my decydujemy kiedy podamy _DSACK. Oczywiście w jakichś granicach, w A4000 cykl trwający dłużej niż jakieś 1000 ns powodował zwieszkę i guru 80000002. No i oczywiście procesor próbkuje _DSACK raz na zegar i dobrze jest dobrać czas postawienia _DSACK tak, żeby nie wpaść w okno próbkowania, bo będzie nam to działać niestabilnie.
Procesor najpierw ustawia adres na szynie, a potem (dokładnie pół cyklu zegara potem) ustawia _AS. My musimy zdekodować adres i ustawić _OVR przed nim. Czyli mamy na to teoretycznie 35 ns, w praktyce trochę mniej, bo _OVR musi się dobrze ustalić, zanim procesor poda _AS. Prosta logika kombinacyjna powinna się spokojnie wyrobić, nie wiem tylko, czy może być na stałe podpięta do szyny adresowej, bo ona jest trójstanowa.
Co do obowiązywania zegara 14 MHz – w zasadzie skoro podaliśmy już _OVR to Gayle powinien się łaskawie odczepić i to my decydujemy kiedy podamy _DSACK. Oczywiście w jakichś granicach, w A4000 cykl trwający dłużej niż jakieś 1000 ns powodował zwieszkę i guru 80000002. No i oczywiście procesor próbkuje _DSACK raz na zegar i dobrze jest dobrać czas postawienia _DSACK tak, żeby nie wpaść w okno próbkowania, bo będzie nam to działać niestabilnie.
26.08.2015 16:27
[#41]
Re: Kanapka FPGA dla A1200
@cahir, post #34
Nie sugerowałbym się dokumentacją gayle, jest tam sporo błędów i niezgodności z mapa pamięci.
Gayle otrzymuje różne zegary, także 7MHz i chyba CDAC (7MHz przesunięte o 90 stopni) i są one wykorzystywane do generowania odpowiednich timingów.
Cykl do clockportu pod d80001 to około 900ns, a do d90001 około 700ns (piszę z głowy). Clockport ma 4 bitową szynę adresową (trochę małą).
Gayle otrzymuje różne zegary, także 7MHz i chyba CDAC (7MHz przesunięte o 90 stopni) i są one wykorzystywane do generowania odpowiednich timingów.
Cykl do clockportu pod d80001 to około 900ns, a do d90001 około 700ns (piszę z głowy). Clockport ma 4 bitową szynę adresową (trochę małą).
26.08.2015 22:50
[#43]
Re: Kanapka FPGA dla A1200
@sanjyuubi, post #41
Nie sugerowałbym się dokumentacją gayle, jest tam sporo błędów i niezgodności z mapa pamięci.
Mógłbyś podać więcej konkretów?
Cykl do clockportu pod d80001 to około 900ns, a do d90001 około 700ns (piszę z głowy).
Chodzi Ci o czas na jaki są wystawiane sygnały IORD / IOWR?
Clockport ma 4 bitową szynę adresową (trochę małą).
Czy po zdekodowaniu pozostałych adresów z przedziału RTC / SPARE Gayle również obniża odpowiednie sygnały CS?
28.08.2015 11:48
[#44]
Re: Kanapka FPGA dla A1200
@cahir, post #43
Nie sugerowałbym się dokumentacją gayle, jest tam sporo błędów i niezgodności z mapa pamięci.
Mógłbyś podać więcej konkretów?
Cześć z nich jest opisana w tym wątku.
Nie zgadzają się adresy IDE oraz adres wyłączający OVL.
Chodzi Ci o czas na jaki są wystawiane sygnały IORD / IOWR?
Nie, czas pomiędzy początkami tych sygnałów.
Czy po zdekodowaniu pozostałych adresów z przedziału RTC / SPARE Gayle również obniża odpowiednie sygnały CS?
Wydaje mi się, że tak, przestrzeń adresowa clockportu jest sporo większa niż te 4 bity, nie wiem czemu ograniczyli się do tak małej szyny adresowej, może to z powodu tych 16 rejestrów RTC, a może ówcześnie planowane urządzenia nie posiadały więcej niż 16 rejestrów.