Re: EDO vs FPM - wyniki testu

Autor: Michał Mosiewicz (mimo_at_lodz.pdi.net)
Data: Fri 22 Nov 1996 - 02:27:26 MET


Krzysztof Halasa wrote:
>
> Michal Mosiewicz <mimo_at_lodz.pdi.net> writes:
>
> > A ja chyba czaję. Jest różnica między czasem wystawienia adresu a
> > otrzymania odpowiedzi w przypadku EDO 'dość znaczna'. Po prostu, z
> > chwilą, gdy otrzyma się dane i one okażą się fałszywe, to żeby określić
> > gdzie nastąpił błąd, trzebaby się cofnąć w czasie (albo zapamiętywać
> > gdzieś poprzedni adres, w zasadzie mogłoby się coś takiego udać). De
> > facto nie eliminuje to chyba możliwości wykrywania błędów parzystości w
> > ogóle, ale tylko powoduje, że bez dodatkowego układu, który pamiętałby
> > wsteczne odwołania, nie jest możliwe określenie jaki adres błąd
> > sposowoał. Zatem nie wystacza już elementarny układ logiczny, bo musi to
> > być już układ logiczny z własną pamięcią.
>
> Dla mnie nonsens. To tak, jakby CPU/cokolwiek dostajac dane z RAM nie
> wiedzialo, z jakiego adresu one pochodza... Poza tym np. ECC nie musi

A czy CPU musi wiedzieć skąd jaki był adres danych, które dostaje? Od
czasów spectrusia i atari procesory już nie działają tak, że wystawiają
adres, czekają na dane a dopiero później wystawiają następny adres. Po
prostu z chwilą pojawiania się danych na szynie danych, adres który
został wystawiony, żeby je zebrać, może być już dawno zapomniany.

O ile w przypadku zwykłych pamięci MMU mógł łatwo poznać, gdzie jest
wada, o tyle w przypadku EDO musi mieć bufor na poprzedni numer kolumny,
żeby wiedzieć gdzie jest usterka. Czyli powiedzmy, że dość łatwo
stwierdzić numer trafionej linii, ale trudniej numer kolumny.

A to wynika właśnie z tego, że w EDO adres wyboru kolumny przegania o
jeden cykl dostępu pojawiające się dane. Na tym polega przyspieszenie
EDO.

Michał

-- 
********     MEMBER OF THE INTERNATIONAL PROGRAMMERS GUILD    ********
WWW: http://www.pdi.lodz.pl/~mimo   tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND


To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:57:06 MET DST