ISP Lever, wie explizit booleschen Term vorgeben?

Scuh mal, ob es die Möglichkeit gibt, über ein Attribut die Signale vor 
der Optimierung zu "schützen". z.B. gibt es in synplify dafür das 
"syn_keep" Attribut, das einem Signal zugeordent wird und dann dieses 
Singal nicht wegoptimiert wird.
Ab das bei den Gals aber auch so geht, weiss ich nicht.

Falls das alles nicht geht, dann könntest du versuchen, die Fusemap von 
Hand zu editieren. Die ist bei GALs noch recht trivial aufgebaut, so 
dass so eine kleine "Schaltung" mit ein wenig Mühe sicher hinzubekommen 
ist.
Allerdings weiss ich nicht, ob in der Fusemap am Ende eine Checksum 
angegeben wird und beim Brennen dann auch geprüft wird.

Schau mal hier, das könnte interessant für dich sein:
http://www.latticesemi.com/lit/docs/appnotes/an8068.pdf

Da gibt es ein Attribut LAT_RESERVE, das man in Abel verwenden kann. Was 
das jetzt allerdings genau macht und ob das für dein Problem taugt, 
musst mal selber lesen ;-)

Also so scheint das zu klappen:

1

MODULE xxx

2

3

DECLARATIONS

4

  A pin 1;

5

  B pin 2;

6

  C pin 3;

7

  Q pin 16;

8

9

  t1  node istype 'keep';

10

  t2  node istype 'keep';

11

  t3  node istype 'keep';

12

13

EQUATIONS

14

  t1 = !(A & B);

15

  t2 = !(B);

16

  t3 = !(C & t2);

17

  Q = !(t3 &t1);

18

END

zumindest spuckt ispLEVER folgende Post-Fit Equations aus

1

Q = (!t3 # !t1);

2

t1 = (!A # !B);

3

t2 = (!B);

4

t3 = (!C # !t2);

Ohne "istype 'keep'" kommt folgendes raus:

1

Q = (A & B # !B & C);

Ich glaub, das ist das, was du suchst, oder?

Ich habe mal das Programm vom Schrotty im ISP Lever simuliert und es 
schaut sehr gut aus, der Glitch ist drin! Ich brenn das nun auf den Gal 
aber kann es erst heute Abend testen.

Vielen Dank schon mal im Voraus!

Gern geschehen. lass mal hören, ob die Glitches dann in "echt" auch da 
sind. Aber ich geh davon aus, dass das funktioniert.

Ich wollte das Programm und die Gals gestern Abend testen nur leider 
ohne wirklichen Erfolg. Denke auch nicht, dass es am Programm liegt denn 
wie schon gesagt, wenn ich im ISPLever simuliere schaut alles sehr gut 
aus und ich bekomme auch beim Schaltungstester und den ganzen Instanzen 
grüne Häkchen. Leider fängt beim Beschreiben des Gal (16V8 von Lattice) 
der Ärger an. Erase, Blank, Write, Read, Verify, alles OK. Wenn ich nun 
nochmals auf Verify klicke kommt ein Fehler. Ich hab mir dann nix weiter 
gedacht und die Teile später getestet. Das Ergebnis ist, dass die 
Ausgänge irgendwelche Werte annehmen und sich nicht Abhänig der Eingänge 
ändern. Der Eingang B zum Beispiel soll ja nur negiert werden. Da wo B 
negiert als T2 ausgegeben werden soll ist dauer High angesagt, egal was 
am Eingang ist.
Liegts vielleicht an dem USB Prommer, den genauen Typ kann ich erst 
später angeben. Ich habe bei reduce Equasion im ISPLever auf none 
gestellt, oder muss da doch was rein?

Danke für die Geduld...

hmm sehr komisch, dieses Verhalten. Hast du mal versucht, nur ein AND 
oder sowas zu "brennen"?
Denn wenn das auch nicht klappt, dann scheint es wirklich so zu sein, 
dass da was anderes schief geht

@Bu
Ich habe auch mit Gals angefangen.
Hompage  von
Holger Klabunde
------------------------------------------------------
Ich habe dem sein MULTIPROG vor ca. 10 Jahren gekauft
mit dem habe ich meine eigenen PC-Karten gebastel.

Conrad Elektronik verkauf das als Bausatz..
"Multiprog"
(für GALS,AVR,.....)
------------------------------------------------------

Mach mal bitte ein Bild von deinem System.


------------------------------------------------------
Ich muss sonst so veil schreiben.
------------------------------------------------------


Hast du das Datenblatt gelesen ?

-------------------------------------------------------
ERASE GAL BITTE VORHER MACHEN
-------------------------------------------------------

GALTYP 16V8D      der D-TYP ist neu. .(BILD)

Vor dem Proggen muss das GAL wie ein EPROM gelöscht werden.

(ERASE GAL ) danch Prog.


------------------------------------------------------------------------ 
-

Such mal in deinem MENU was für Gal-Typen von 16V8_x da drin sind.

244 ersatz für Avr zu proggen.

Baue doch die Schaltung mit Einzelgattern auf, sind doch nicht viele.

Die Schaltung hatte ich bereits mit diskreten Gattern aufbgebaut, doch 
wir wollen das Problem der Laufzeitverzögerung am konkreten Fall GAL 
betrachten.

Ich habe es nun endlich hin bekommen den GAL zu beschreiben, nur leider 
war ich vom Ergebnis enttäuscht. Habe mir dann nochmal die reduzierte 
boolesche Algebra aufgemalt und durchgespielt, leider kommt mit den OR 
Gattern kein Glitch mehr zustande.

aus

t1 = !(A & B);
t2 = !(B);
t3 = !(C & t2);
Q = !(t3 &t1);

wird wie oben schon beschrieben:

Q = (!t3 # !t1);
t1 = (!A # !B);
t2 = (!B);
t3 = (!C # !t2);

Gibt da keine Möglichkeit ihm quasi zum benutzen von NAND Gattern zu 
zwingen?

Ich kann auch gerne nochmal ein Bild der kleinen Schaltung mitliefern. 
Sinn soll sein die "schädliche" Gatterlaufzeit, in Form von LOW Spitzen 
an einem eigentlich dauer High führenden Ausgang zu demonstrieren.

Vielen Dank im Voraus!

Hier nochmal das ganze als Prinzipdarstellung.
Diese einfache Schaltung funktioniert mit diskret aufgebauten Gattern 
auf dem Steckbrett einwandfrei...

Oder liegt es einfach daran, das ein Gal dieser Bauart nur mit OR Logik 
arbeitet?

Ob du das mit AND oder OR darstellst, sollte keinen Einfluss haben. Denn 
De Morgan gilt! ;-)
Aber du koppelst deine Signale intern zurück (t1, t2, t3) Das heisst, 
die Laufzeit dieser Signale könnte je nach Speedgrade des GAL recht kurz 
sein und somit währen auch die Glitches recht kurz.
Und wenn du diesen Glitch dann über einen Pin rausgeben willst, dann 
muss dieser auch imstande sein, die Kapazität deines Tastkopfs, Leitung 
etc zu treiben. Und zwar so schnell, dass der Glitch nicht "verwischt" 
wird.
Das Eingangssignal muss natürlich auch eine ordentliche Flankensteilheit 
haben!

Also wenn dein Glitch z.B. nur 2 ns lang wäre, dann muss die Rise- und 
Fall-Time des Pins < 1ns sein, dass du den Glitch noch sehen kannst.

Klingt jetzt ein wenig konstruiert, aber eine bessere Erklärung fällt 
mir grad net ein.
Vielleicht mal mit nem GAL mit langsamem Speedgrade ausprobieren.

hi,


vielleicht lieg ich auch falsch aber haben GALs nicht nur eine UND- und 
eine ODER-Matrix? Dann würde das nix werden mit NAND Gattern...