GAL16V8 Problem

OP #2357742
Lesenswert?

Ich habe hier versch. Exemplare von GAL16V8 rumliegen und bei der 
Programmierung mit meinem WELLON VP-480 ne merkwürdige Erfahrung 
gemacht.

Also ich programmiere den GAL und der Wellon meint es ist alles ok, beim 
zurücklesen des GALs stimmt auch die CRC Summe immer, aber manche GAL 
gehen dennoch nicht in der Schaltung.

Kann mir jemand erklären was das Problem sein könnte ?

Vielen Dank sagt Ralph
Gast #2357759
Lesenswert?

GAL16V8 sind nicht gerade die aktuellsten Bausteine. Vor 30 Jahren waren 
sie sozusagen "state of the art". Kann leicht sein, daß diese ICs ihr 
Haltbarkeitsdatum überschritten haben und im Siliziumhimmel angekommen 
sind. Für Neuentwicklungen würde ich keine derartigen Bausteine mehr 
einsetzen. Soviel ich weiss sind diese Chips von den Herstellern 
(Lattice) seit einiger Zeit abgekündigt.

Otto
OP #2357765
Lesenswert?

Da magst Du ja Recht haben Otto :-) aber ich wollte mir eben nen 
Reservesatz für bereits lange laufende Baugruppen anlegen und bin dabei 
drüber gestolpert.

Seid bitte so nett und helft mir ne Lösung zu finden, und keine 
Belehrungen was aktuell oder eben nicht mehr ist, ok ?!

Fakt ist, die betreffenden GAL's sind inhaltlich wohl richtig 
programmiert, also können sie nicht im Siliziumhimmel liegen ....
Gast #2357767
Lesenswert?

Ralph H. schrieb:
> Kann mir jemand erklären was das Problem sein könnte ?

Hast Du ein kritisches Timing? Je nach Hersteller funktionieren die 
Teile dann, wie sie wollen. Das war schon immer so.
Die Lattice-Typen kamen meinen Erwartungen immer noch am nächsten und 
ich bin froh, auch diese nicht mehr verwenden zu müssen :-)
Gast #2357786
Lesenswert?

Ralph H. schrieb:
> ist ein Z80 Rechner wo die Dinger als Decoder drinne sind

Das sollte eigentlich kein Problem sein, außer, wenn die GALs im Laufe 
der Zeit einfach zu schnell geworden sind und das Timing von /RD, /WR 
und /CS nicht mehr eingehalten wird. Oder es war schon immer auf der 
Kippe und das fällt erst jetzt auf.
Gast #2358171
Lesenswert?

Willi schrieb:
> Hast Du ein kritisches Timing? Je nach Hersteller funktionieren die
> Teile dann, wie sie wollen. Das war schon immer so.

Das war noch nie so, nur muss man halt die technischen Daten beachten: 
es gab GALs von etwa 7 ns Schaltzeit bis 40 ns, das ist schon ein 
erheblicher Unterschied. Logischerweise muss eine Schaltung, die auf 10 
ns ausgelegt ist, mit einem langsameren GAL nicht unbedingt 
funktionieren, aber auch das Umgekehrte kann zutreffen. Der Fragesteller 
hat zu den Zugriffszeiten garnichts gesagt und ist sich wohl auch nicht 
klar über die Unterschiede.

Das Timing zu berechnen ist natürlich etwas schwieriger als nur die 
logische Funktion.

Gruss Reinhard
OP #2358198
Lesenswert?

Na dann will sich der "Fragesteller" mal äußern ;-)

Fakt ist, in meiner Schaltung sind bisher GAL16V8D drin.
Nun habe ich versucht GAL16V8B (schneller?) und GAL16V8S zu brennen.

Von beiden Typen, gehen je 2 Chips NICHT obwohl die CRC nach dem
auslesen identisch sind ! Ich denke damit kanns kaum am Timing liegen, 
oder?

Welche Rolle spielen eigentlich die Fuses SECURE ?

Viele Grüße
Gast #2358208
Lesenswert?

Ralph H. schrieb:
> Welche Rolle spielen eigentlich die Fuses SECURE ?

Dass man den Inhalt der GALs nicht auslesen kann - was die Frage 
aufwirft, ob du überhaupt einen gültigen Inhalt gelesen hast.

Die volle Bezeichnung laut Lattice lautet übrigens (Beispiel) 
GAL16V8D-10LP, dabei ist 10 die Zugriffszeit, L ist Low Power und P ein 
20Pin-DIP. D wird wohl eine Version sein, im letzten veröffentlichten 
Datenblatt steht nur die D-Version.

Gruss Reinhard
OP #2358224
Lesenswert?

Hm.. ich denk schon das ich die GALS auslesen kann, bzw. mein WELLON 
kanns.
Auch die Daten kann ich ja sehen und um die CRC zu vergleichen, muss ich 
ja ins File schaun, denn dort steht sie ja am Schluß auch drin.

Die GAL's sind immer alle -25 also 25ns, was in Z80 Rechnern vollkommen 
ausreichen sollte.
Gast #2358229
Lesenswert?

Reinhard Kern schrieb:
>> Teile dann, wie sie wollen. Das war schon immer so.
>
> Das war noch nie so, nur muss man halt die technischen Daten beachten:

Ach so, das habe ich natürlich nie gemacht.

Ralph H. schrieb:
> Von beiden Typen, gehen je 2 Chips NICHT obwohl die CRC nach dem
> auslesen identisch sind ! Ich denke damit kanns kaum am Timing liegen,
> oder?

Was hat die CRC mit dem Timing zu tun?
Du mußt in Deine Schaltung kucken und "nur die technischen Daten 
beachten". Beispielsweise setup-Zeiten.
Gast #2358233
Lesenswert?

Ralph H. schrieb:
> Die GAL's sind immer alle -25 also 25ns, was in Z80 Rechnern vollkommen
> ausreichen sollte.


Anderherum wird ein Schuh daraus.
Früher brauchten 25ns GALs auch 25ns; bevor diese dann abgekündigt 
wurden, konnte ein 25ns-GAL durchaus schon nach 10ns fertig sein, was 
für ältere Schaltungsentwürfe zu schnell sein kann!
OP #2358239
Lesenswert?

OK, das GALS evl. schneller sind als declariert, ist ein Argument aber 
ganz sicher nicht die Ursache !

Ich schrieb ja schon ,das MIT STATISCHEM Betrieb falsche Pegel 
rauskommen !
Da kanns also nix mit Timing zu tun haben, denke ich mal !

Ich hab Timing übrigens NIE mit dem CRC in Zusammnhang gebracht. Es 
sieht von meiner Logik so aus, das der GAL tatsächlich nicht richtig 
programmiert ist, obwohl das Vergleichslesen (und damit die CRC) eben ok 
ist.

Ich verstehs nicht und werd wohl die Dinger einfach wegschmeissen und 
gut ist.
Gast #2358247
Lesenswert?

Warum lädst du dir nicht den PalAsm runter, verwandelst das JEDEC file 
zurück in die Equations und überprüfst, ob die Logic für dein Zielsystem 
korrekt ist? Der Rest wäre dann wirklich das timing.
OP #2358249
Lesenswert?

rudi schrieb:
> Warum lädst du dir nicht den PalAsm runter, verwandelst das JEDEC file
> zurück in die Equations und überprüfst, ob die Logic für dein Zielsystem
> korrekt ist? Der Rest wäre dann wirklich das timing.

Hm.. das ist ne Klasse Idee :) Danke das werd ich mal machen :-)
Schliesslich ist die Neugier und der Ehrgeiz da, das Problem zu finden 
:-)

Gruß Ralph
#2358305
Lesenswert?

Hallo Ralph,

eine Lösung für Dein Problem habe ich leider auch nicht, aber womöglich 
als Denkanstoß...

Vor vielen Jahren habe ich mal aus der Zeitschrift c't (vermutlich) 
einen Programmer für GAL16V8 nachgebaut (Bausatz), danach kamen GAL16V8A 
raus, dafür mussten Blöcke im JEDEC-File anders angeordnet werden - das 
konnte man im 2. Schritt tun. Für den später erscheinenden GAL16V8B war 
dies und noch eine Hardware-Änderung erforderlich, da habe ich es dann 
gesteckt...

Habe dann nichts mehr damit gemacht, kenne also nicht die Unterschiede 
der C-, D- und S-Typen. Wenn man also bei einem solchen Fehler ein für 
den falschen Typ assembliertes JEDEC-File reinlädt, dann wäre es doch 
möglich, dass die CRC stimmt, die Funktion aber nicht gegeben ist.

Allerdings komisch, dass in Deinem Fall zumindest einige ja doch 
funktionieren, was gegen einen solchen Fehler spricht.

Viel Erfolg
Hermann-Josef

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren