Altera EP610PC software kopiëren

Ben inmiddels wel benieuwd om wat voor apparaat het gaat.

@Weardguy, is mij overkomen met een GAL. GAL werkt , er gebeurt "iets", en van 0 tot 100 (graden) binnen een seconde en defect.
Nog steeds geen idee.

Waarschijnlijk een a-synchroon design in the GAL waardoor race-condities (gate delay oscillaties) kunnen optreden en die gebeuren op fmax (of hoger) van het device.
GAL's hebben doorgaans ook al niet echt een laag stroomvebruik...

Nee, op max frequentie zal ie iets van 100-150 mA trekken. Dat is best veel en daar wordt ie dan "fors warm" van, maar niet "in enkele seconden naar 100 en dan kapot".

Het is een latchup. (zoals Arco ook al genoemd heeft). Dat gebeurt niet als je binnen de datasheet-specs blijft met spanningen op de IO pins < VCC+0.4 en > -0.4V.

Maar ga je daar buiten dan ben je de sjaak. Bij moderne chips staan die specs nog steeds in de datasheets, maar is het minder relevant. Ze hebben kennelijk een truuk gevonden om de latchup te voorkomen.

En ALS je zo'n latchup krijgt, dan roept de klant altijd dat ie zich streng aan het datasheet heeft gehouden en dat het hier niet door kan komen. Als fabrikant moet je dan de kapotte chip vervangen en als je gaat kijken is het TOCH altijd een latchup. Dat wordt een welles-nietus discussie. Uiteindelijk makkelijker om maar gewoon de latchup-preventie in de chip te doen en dan ben je van het gezeik af.

Zodra er latchup plaatsvind, dan gaat de parasitaire triac in de chip in geleiding en sluit ie de voeding kort (met rond de 2V resterende spanning). De hele voedingsstroom gaat naar dat ene chipje en hij fikt in no time door.

(En mosfet die kapot gaat, die wordt kortsluiting. Heel weinig spanningsval. Dan wordt ie dus ook niet verder warm... Dat is hier anders!)

Alle GAL's van Lattice hebben Latch-Up Protectie circuits op de die.

Het heeft even geduurd maar de acht gloednieuwe chips zijn binnen.

Prima webwinkel waar ik ze besteld heb.
www.radio741.com

radio741 : "We are a business that provides new and used, hard to find electronic and industrial components fast and at good prices."

Hopelijk heb je van hun de garantie gekregen dat de EP610 ongebruikt (dus nieuw) zijn...

Die garantie heb ik niet gehad, ben er ook niet echt bang voor.
De chips zijn alle acht identiek qua vorm en opdruk.
Maar we weten het pas als ze bij Henri62 zijn aangekomen.

Vorig jaar heb ik bij AlieExpress tien Z80 SIO's gekocht.
ze zouden nieuw moeten zijn maar dat waren ze duidelijk niet.
Geen opdruk was hetzelfde, met ook echt oude datumcodes.
Een of twee deden het ook niet of waren zelfs geen Z80 SIO.

Ik had er maar twee nodig en gebruikt of niet vind ik niet spannend, als het apparaat maar weer werkt.
In het geval van een geprogrammeerde chip zoals de EP610 zou het wel lullig zijn als deze geprogrammeerd zou zijn.

Zag net dat ze nog twee EP610's hebben, die had ik eigenlijk meteen mee moeten bestellen.
Zoveel vertrouwen heb ik in Radio741.com

Ik heb de nieuwe chips binnen, ze zijn inderdaad leeg en echt ongeprogrammeerd.

Maar nu het slechte nieuws: Van 1 originele chip is de inhoud niet terug te lezen. Alle bits zijn 0. Helaas pindakaas.

Van de andere chip (waar blijkbaar de meeste van defect zijn) is het me totaal niet duidelijk of er iets zinnigs in zit (mijn 'gevoel' zegt dat er iets niet klopt).
Ik kan die file met PLDSHELL (3.1) ook niet decompilen.

Heeft iemand toevallig ergens een werkend systeem met jed2eqn erop en een poging wil wagen?

Support je Dataman programmer de juiste EP610 chip?
Kun je de CHIP-ID wel correct uitlezen?

Ja wordt supported, volgens mij kan die alleen van eproms chip id's uitlezen.
Ik betwijfel of er in de EP610 een ID zit.

[Bericht gewijzigd door henri62 op (22%)]

Met PLDShell Plus V4 een (.pds) voorbeeld design aangepast voor een iPLD610 (is pin en JEDEC compatible met de EP610) en gecompileerd naar een JEDEC file.
Deze JEDEC file vervolgens ontdaan van alle redundante informatie zodanig dat de Disassemble functie (jed2eqn equivalent) in PLDShell Plus V4 zonder errors een nieuwe en correcte .pds design file aanmaakt.
Vervolgens de fusemap en de checksum in deze JEDEC file vervangen door die van VCE-V1.4.jed file en de Disassemble functie er weer op los gelaten.

Maar helaas, PLDShell Plus V4 geeft dan de melding: ERROR E654—JDB: Illegal data in JEDEC record.

Of de fusemap of de checksum in VCE-V1.4.jed file kloppen niet.

Ik vermoed dat de fusemap niet klopt en dat er tegenstrijdige fuses actief zijn, misschien een effect van het uitlezen van een defecte EP610.

Ik vrees dat in de goedwerkende EP610 toch het Security-Bit actief is omdat, zoals je aangeeft, alle bits 0 zijn...

Misschien makkelijker om de PAL functioneel te copieeren en dan te kiezen voor een CE22V10. Dat is een PAL die je opnieuw kan programmeren, in tegenstelling tot de eerste PAL generatie die slechts 1 keer te programmeren was.

Als de PAL enkel gebruikt wordt voor address decoding zijn er geen registers in het "spel" en is de functie snel uitgevonden.

Wordt de PAL (ook) gebuikt om het design te beschermen en is er intern een statemachine gebouwd dan is het een heel stuk lastiger om de functie te copieeren.

Indertijd was AMD PALASM een veelgebruikt programma om de logic om te zetten naar Jedec. Het programma was gratis in tegenstelling tot het geavanceerdere DataIO Abel.

Anyway, succes met het project.

Op vrijdag 21 juni 2024 03:32:24 schreef Bobosje:
Met PLDShell Plus V4 een (.pds) voorbeeld design aangepast voor een iPLD610 (is pin en JEDEC compatible met de EP610) en gecompileerd naar een JEDEC file.
Deze JEDEC file vervolgens ontdaan van alle redundante informatie zodanig dat de Disassemble functie (jed2eqn equivalent) in PLDShell Plus V4 zonder errors een nieuwe en correcte .pds design file aanmaakt.
Vervolgens de fusemap en de checksum in deze JEDEC file vervangen door die van VCE-V1.4.jed file en de Disassemble functie er weer op los gelaten.

Maar helaas, PLDShell Plus V4 geeft dan de melding: ERROR E654—JDB: Illegal data in JEDEC record.

Dat is precies wat ik gisteren ook gedaan heb, een lege EP610 file gemaakt, compiled en de fuse data "getransplateerd" in de jed file en proberen te decompilen. Precies dezelfde foutmelding.

Vroeger kon je sommige PIC cpu's "half" beveiligen, alleen de lage 4 bits kwamen er dan nog uit. Dan kon je nog een stuk verifieren of de programmering goed was. Maar bij deze is dat niet zo.

Ik heb al gevraagd aan de TS of die na kan kijken welke pins allemaal aangesloten zijn om een idee te krijgen welke rows/cols in het array effectief zouden moeten zijn.

@Peter_dtn In het verleden heb ik inderdaad Abel gebruikt en de lattice tooling (isplsi?). Met uiteraard allerlei GALs.

Ik heb JED2EQN even gestart maar die klaagt dat de device name niet in de jedec file staat. Vervolgens kun je met de optie -d zelf een device meegeven maar de tool lijkt de EP610 niet te kennen. In de file DEVICE.LIB staan deze devices:


10H8    10L8    10P8    12H10   12H6    12L10   12L6    12P10   12P6

14H4    14H8    14L4    14L8    14P4    14P8    16C1    16C4    16H2

16H6    16H8    16L2    16L6    16L8    16P2    16P4    16P6    16P8

16PE8   16R4    16R6    16R8    16RA8   16RD8   16RM4   16RP4   16RP6

16RP8   16V8QS  16V8A   16V8    18L4    18H4    18P4    20C1    20H10

20H2    20H8    20L10   20L2    20L8    20P10   20P2    20P8    20R4

20R6    20R8    20RA10  20RP4   20RP6   20RP8   20V8QSV 20V8QS  20V8AV

20V8A   20V8V   20V8    20X10   20X4    20X8    22CV10V 22CV10  22V10V

22V10   6001V   6001    MAPL128 MAPL144 MAPL244 MAPL268

Is een van deze types misschien compatible met de EP610 ?

Daar ben ik nu net ook achter gekomen, hoe heb je dat lijstje gemaakt?
(Op mijn XP bakje draait het jed2eqn)

Volgens mij is geen enkel device compatible met de EP610 of de 5C060.

[Bericht gewijzigd door henri62 op (12%)]

Dat lijstje is een copy paste uit DEVICE.LIB

Ah op die fiets. Ik had al allerlei files bekenen maar wie verwacht nu dat het in een LIB file zit. :+

-edit-
Blijkbaar is het QF#### nummer de device identificatie, voor de EP610 is dat QF6482 en die komt helaas niet voor in de device.lib file.

[Bericht gewijzigd door henri62 op (11%)]

Die 6482 is denk ik "de grootte" van het device? Kijk maar naar de regel headers in de jedec file, die tellen tot 6480 en dan nog 2 digits erbij.

Zou best ook kunnen. Ik denk dat je gelijk hebt.

Maar ik bedenk me nu wat anders, ik sta er niks van te kijken als ik in die VCE.jed file kijk dat er gewoon statische lijnen in geprogrammeerd zijn.

Dus de 10 output lijnen zijn gewoon in een bepaald patroon 1 en 0 gemaakt?
Er zit namelijk niks zinnigs in, alle pinnen zijn of 1 of 0 zo lijkt het.
Of een pin configuratie die als EPLD uitgevoerd is.

Gewoon om copieren en reverse engineering te frustrenen.

Dus @TS: Bij een werkend bord zou ik eens alle output pins met een scoop bekijken of die niet gewoon statisch zijn (1 of 0). Zelfs een output enable verwacht ik nog niet eens.

Ik sta er dan ook niks van te kijken dat een voetje met jumpers (of weerstandjes) erin naar de juiste output lijnen (volgen welke ook echt output moeten zijn) gewoon zou kunnen werken.

Een andere optie die de TS voorgesteld heeft is gewoon domweg met die jedec file een copy maken. Als de CLK niet aangesloten is kan ik gewoon ook een van mijn 5C060 erasable devices ervoor gebruiken, de snelheid boeit dan niet.

Helaas kan ik nergens een goede fusemap vinden om handmatig te kijken wat die laatste paar regels doen. Dat moeten de 2 mode bits zijn van ieder output macro blok maar wat is precies wat?

Op vrijdag 21 juni 2024 10:03:28 schreef henri62:
Zou best ook kunnen. Ik denk dat je gelijk hebt.

Maar ik bedenk me nu wat anders, ik sta er niks van te kijken als ik in die VCE.jed file kijk dat er gewoon statische lijnen in geprogrammeerd zijn.

Dus de 10 output lijnen zijn gewoon in een bepaald patroon 1 en 0 gemaakt?
Er zit namelijk niks zinnigs in, alle pinnen zijn of 1 of 0 zo lijkt het.
Of een pin configuratie die als EPLD uitgevoerd is.

Gewoon om copieren en reverse engineering te frustrenen.

Dus @TS: Bij een werkend bord zou ik eens alle output pins met een scoop bekijken of die niet gewoon statisch zijn (1 of 0). Zelfs een output enable verwacht ik nog niet eens.

Ik sta er dan ook niks van te kijken dat een voetje met jumpers (of weerstandjes) erin naar de juiste output lijnen (volgen welke ook echt output moeten zijn) gewoon zou kunnen werken.

Een andere optie die de TS voorgesteld heeft is gewoon domweg met die jedec file een copy maken. Als de CLK niet aangesloten is kan ik gewoon ook een van mijn 5C060 erasable devices ervoor gebruiken, de snelheid boeit dan niet.

Helaas kan ik nergens een goede fusemap vinden om handmatig te kijken wat die laatste paar regels doen. Dat moeten de 2 mode bits zijn van ieder output macro blok maar wat is precies wat?

Kun je niet uitvogelen wat in- en uitgang is en dan met een Arduino oid een waarheidstabel genereren ? Zo heb ik laatst een PAL10L8 gedaan. Dat werkt natuurlijk alleen maar als er geen vage "clock-dingen" en terugkoppelingen in zitten.

Dat ben ik nu een klein beetje aan het doen.

Ik heb een 5C060 gepakt en die file erin gezet. Op een breadboard geprikt en alle pinnen met 100k naar GND gelegd.

Zowiezo zijn 1,13 clock inputs, 2,23,11,14 dedicated inputs.

Alle pin levels gemeten: Alles is nu 0V, dus nog geen patroon te zien.

Nu kijken welke pinnen hard driven worden: Met een frequentie generator op 1 kHz een signaal via 1k een voor een op de pinnen gezet en kijken welke pinnen actief driven worden (die sluit het bloksignaal dus kort naar GND), dat zijn deze pinnen: 7, 8, 9, 16, 17, 18 die zijn dus als output geconfigureerd.

De vraag is nu aan de TS: Wat is er aangesloten op die chip?

De volgende stap is kijken of andere pinnen reageren op een inserted blok signaal op een van de andere pinnen. Maar ik heb er nu niet zo veel tijd voor om dat uit te vogelen.

Dus ik wacht effe de reactie van de TS af of die een beetje reverse engineering kan doen op het bord.

Als de VCE-V1.4.jed file zinnige fusemap data zou bevatten dan zou PLDShell deze kunnen Disassembleren, dat gebeurt echter niet.
De fusemap is corrupt en daar kan PLDShell niets functioneel-zinnigs van maken.
Als je een goede EP610 niet kunt uitlezen omdat alle bits 0 zijn wat kun je dan beginnen met een fusemap uit een defecte EP610? Niets vrees ik.

Enige optie is nog een goede EP610 proberen functioneel te reverse-engineeren maar daar acht ik de kans van slagen zeer klein vanwege de evt. aanwezige interne node feedbacks (zoals bij een state-machine design bijv.) in de EP610.
De EP610 functie coverage van alle aangeboden externe test-vectoren zal laag of niet volledig kunnen zijn.

Het device wat ik uitgelezen heb is een goede werkende chip (althans zoals de TS me verteld heeft).

De 2-de, een ander device met andere inhoud (label: MPS-V2.0), is echt write protected want alle bits zijn identiek (0) dus niks meer aan te doen.

Waarschijnlijk is de syntax van de jedec file niet compatibel met PLDSHELL. Zowizo is de header anders, functioneerd niet.

Zal niet de eerste keer zijn dat een zogenaamde standaard niet echt standaard is.
Ik heb eens meegemaakt bij tooling dat de CRC/checksum berekening van een tool er precies 1 naast zat. Dus na uitlezen moest je de CSUM fixen (+ 1) en dan werkte die ook in een ander tool. Ik weet mijn god niet meer wat dat was.

-edit- Ik heb de jedec standaard erbij gepakt en de checksum wordt berekend over ALLE characters tussen de STX en ETX (inclusive) (dus ook CR/LF etc), als de header dus niet klopt en je moet daar wat in fixen en moet je dus de checksum geheel opnieuw berekenen. Het is een 16-bit checksum.

In de vele testen die ik heb gedaan (en vele malen op dezelfde en andere manieren en weer geverifieerd) heb ik puur en alleen de fusemap (de sequence van de 0-len en 1-en) en de fusemap CRC vervangen (de file transport CRC is don't care) met een werkende header van de originele PLDShell test JEDEC file dus alles met een correcte syntax maar dat mocht niet baten, PLDShell gaf steeds weer dezelfde error met de aangepaste test JEDEC file of met de VCE-V1.4.jed file.

Dat is inderdaad bijzonder. Ik heb het wel voor elkaar gekregen de software te laten hangen op de input. Was nog wel ergens mee bezig maar stopte zelfs na 5 minuten niet.

Ik denk niet dat de disassembler illegale fuse combinaties herkend.

Nog wat, ik zie dat je als transmission checksum 0000 op kunt geven volgens de standaard (om gelul met LF, CR/LF ellende te voorkomen) dan zou een programmer de file niet mogen afkeuren op de checksum.

-edit- blijkbaar zijn er 2 checksums C####* en <ETX>#### waarbij de laatste de transmission checksum is. C#### is alleen de FUSE checksum en die MOET kloppen zo te zien.

-edit- QF is inderdaad het aantal fuses (Q=Value, F=number of fuses).