Printpladeporno

Jeg har tidligere skrevet om min ny yndlingscomputer, den kørende Rational R1000/400 vi har ude i Datamuseum.dk og om projektet med at lave en software emulering af den.

Når man vil lave en software emulering af en gammel computer, plejer man at angribe problemet på niveau af instruktionssættet.

Problemet med R1000 er at den ikke som alle andre computere har et dokumenteret instruktionssæt, de 16 bit koder som Ada compilerens kodegenerator spytter ud og som mikrokoden fortolker, var et internt, udokumenteret API, mellem compilergruppen og mikrokodegruppen i Rational og de forandrede sig over tid.

Vores maskine ser ud til at køre version 15, hvilket fortæller os absolut ingenting, for ingen af versionerne er dokumenteret.

Den næste mulighed er at skrive en mikrokodeemulator, det vil utvivlsomt give den bedste performance i dette tilfælde, men det efterlader et meget stort hul, for selvom diagrammerne har temmelig gode detaljer om mikrokodens implementering er der stadig et stykke vej fra at kende et signals navn til at vide hvad det faktisk gør.

Det sidste sted man kan stikke kniven ind med en software emulering er at emulere hardwaren, det er f.eks hvad Mogens gjorde med GIER emulatoren.

GIER er en temmelig simpel computer, jeg ved ikke præcist hvor mange transistorer der er i den, men det er maksimalt nogle tusinde.

Til sammenligning er det en håndfuld milliarder transistorer i moderne CPU'er.

R1000 ligger et sted midt imellem, den er lavet i de tidlige 1980'ere, men det er på ingen måde en lille computer for tiden.

Jeg har i hast taget billeder af alle printkortene, i håbet om at disse billeder kan bruges som reference for projektet og tænkte at jeg lige ville give jer et indtryk af hvad jeg mener med "på ingen måde en lille computer for tiden":

Illus.: Poul-Henning Kamp

Denne printplade, kaldet "SEQ" indeholder den logik der styrer udførelsen af mikrokoden, jeg har ikke talt efter, men på øjemål er der ca. 14 * 49 - en snes chips, lad os kalde det 650.

De andre printplader, "TYP", "VAL", "FIU", "IOC" og "MEM" er af samme kaliber og dertil et I/O interface print kaldet "RESHA" der ikke har nær så mange chips.

(Man kan se hele forbrydergalleriet på vores wiki. Bemærk hvorledes bagsiden af printene har silketryk med komponenterns logiske navne, ikke bare "U%d", men navne som "DCDRV0")

Lad os kalde det 4000 chips alt i alt.

Det er et lidt stort tal i forhold til at skrive en software model der emulerer hardwaren.

Der er dog mange formildende omstændigheder, f.eks er det meste af MEM kortet identiske DRAM chips der ikke behøver at blive simuleret individuelt og ligeledes gør den samlede busbredde på 4*64 bits at der er rigtig mange driver-chips som en software model kan behandle under et.

Men selv 3000 ville være et stort tal.

Det særligt tiltrækkende ved at lave en hardwaremodel, er at vi kan bruge den meget omfattende samling af diagnostik programmer maskinen har, til at debugge emuleringen med, hvis vi emulerer på instruktionssætniveau, eller for den sags skyld mikrokode niveau, duer de ikke til noget.

Men 3-4000 chips... urg.

phk

Kommentarer (40)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Ole Kaas

Gad vide hvorfor man ikke bare har kastet "decoupling capacitors" i alle de huller der er designet til det? Tænker ikke det er prisen der er afgørende på dette stykke isenkram.

  • 0
  • 0
#2 Henrik Jacobsen

Gad vide hvorfor man ikke bare har kastet "decoupling capacitors" i alle de huller der er designet til det? Tænker ikke det er prisen der er afgørende på dette stykke isenkram.

Måske fordi designerne også var på forkant på det punkt, og vidste at det var unødvendigt. Hvis der er gennemgående power- og GND planer Naboer, evt. flere sæt) inde i printet, så virker printene formodentlig selv om man fjerner stort set alle de leadede afkoblinger.

  • 0
  • 0
#3 Poul-Henning Kamp Blogger

Gad vide hvorfor man ikke bare har kastet "decoupling capacitors" i alle de huller der er designet til det? Tænker ikke det er prisen der er afgørende på dette stykke isenkram.

Smarte print-folk gør afkoblingskondensatoren til en del af chippens PCB symbol, det halverer antallet af komponenter der skal placeres.

Umiddelbart kunne det se ud som om reglen har været:

DRAM = alle Chips med >16 ben = alle Resten = hver anden

Jeg tvivler meget på at det har været et omkostningsspørgsmål, der er generelt ikke sparet nogen steder i designet (Stykpris=$1M).

Det kan måske have været et spørgsmål om hvor stor den samlede, men distribuerede, kapacitans strømforsyningen skulle sparke igang måtte blive: (4000 * 0.1µf = 400µF).

  • 5
  • 0
#6 Poul-Henning Kamp Blogger

Samme banebredde i X og Y lagene?

Der er enkelte baner der er bredere, formodentlig alle en eller anden variant af "power", men ellers den samme på alt det jeg kan se.

Og ingen serietermineringer?

Der er vist nok nogle termineringer på "lange signaler", men det meste er så vidt jeg kan ser routet indenfor omkring 20cm.

Hvilken teknologi er det? 74S, F, eller (formoder jeg) noget helt andet?

Stort det det hele er 74F, men hist og her dukker der specialkredse op, f.eks AMD multipliers på VAL.

  • 4
  • 0
#8 Nis Schmidt

Off Topic? Måske, men ...

When CHM was 35! ->

Hvad har de mon udviklet R1000 på?

Jeg fandt ikke lige svaret på det "?", men fandt dog via ovenstående link ud af hvor længe CHM har eksisteret.

'Rational' blev overtaget i 2003 af "gæt hvem", som har sin egen udgave af "biblioteket" (se: "The Librarian" filmene eller serien, "Warehouse 17" m.m.m ) - ligesom CHM. Ikke så underligt at lille DK ikke rigtig kan være med i den klub.

Quiz; Hvor gammel er CHM, når "Tapeten" skal lukke for DDHF?

  • 0
  • 0
#10 Poul-Henning Kamp Blogger

Hvad har de mon udviklet R1000 på?

Den version jeg har hørt fra en af stifterne er:

De udviklede oprindeligt på og sigtede efter at sælge deres semantiske Ada-IDE på DG's Eclipse computere, men det kørte ikke hurtigt nok så de var nødt til selv at bygge en computer der kunne afvikle det.

Om hardwareudviklingen er det eneste jeg har fundet om værktøjer at de brugte en GenRad PCB tester og lavede en masse simuleringer på de samme DG computere.

  • 3
  • 0
#11 Poul-Henning Kamp Blogger

De må have vidst hvad de har gjort.

Jeg ser ingen tegn på noget andet, det er rigtig mange gennemtænkte detaljer.

F.eks har de to krystaller, et 20MHz og et 21MHz så de kan køre hw-tests med 5% clock-margin. PSU'en har en tilsvarende facilitet for at sænke +5V spændingen.

74F er nogen ballademagere pga hurtige flanker

Tjoe, men hvad var alternativet i 1980 ? ECL, 74S eller 74AS ?

Men vi har en enkelt dokumenteret ECO der taler om ringing, så de har bestemt ikke klaret frisag.

  • 5
  • 0
#13 Frithiof Andreas Jensen

Gad vide hvorfor man ikke bare har kastet "decoupling capacitors" i alle de huller der er designet til det?

EMC var mere kunstart end videnskab "I Gamle Dage".

Nogen gange overfører en dekoblingskondensator aktivt "støj" og "ground bounce" fra "ground" afhængigt af layout og fordelingen af impedanser. Dengang ville man typisk placere alle kondensatorerne med een per chip, hvis en chip fik problemer, tog man kondensatoren ud, hvis det virkede, så blev den ude.

Jeg har engang arbejdet med printkort designet på den måde. Vi talte meget om "magick capacitors". Til sidst blev vi meget trätte af skidtet og rullede det hele op i en FPGA, hvilket var super advanceret dengang.

  • 0
  • 0
#14 Poul-Henning Kamp Blogger

Tjoe, men hvad var alternativet i 1980 ? ECL, 74S eller 74AS ?

Vi modtog også et sæt reservekort til den tidligere model 300.

Forskellene på model /300 og /400 er meget små, det handlede primært om at pakke maskinen ind i et mindre kabinet, men jeg kan se på mine billeder at /300 kortene har 74S hvor /400 kortene har 74F.

Det kan forklare hvorfor strømforsyningen virker meget konservativt dimensioneret i model /400: Iflg wiki bruger 74F kun ⅓ så meget energi som 74S.

Det kan måske også forklare hvorfor man turde pakke maskinen i et mindre kabinet til at begynde med.

  • 5
  • 0
#17 Martin Hansen

Super spændende PHK. Er desværre ikke velbevandret i hardware og slet ikke fra denne generation. Kan du sige noget om kompleksiteten, hvor mange logiske gates er der på et sådant kort (og totalt)? Jeg slog de nævnte chipserier op og så vidt jeg kunne se var det "rå" gates d.v.s. hver IC på boardet implementerer et relativt lille antal (8-ish?) logiske gates? Så på det board du viser her er der ca. 5000 gates og samlet 32000 gates i hele maskinen? Altså er det den rigtige måde at tælle på? Er der en måde at scanne forbindelserne mellem IC'erne på printpladen så man i princippet kunne bygge en emulator ud fra det?

  • 1
  • 0
#20 Poul-Henning Kamp Blogger

Så på det board du viser her er der ca. 5000 gates og samlet 32000 gates i hele maskinen?

Typisk er der 4-8 primitive funktioner i de fleste af de brugte chips, så indenfor en træskolængde er det i den størrelsesorden.

Det primære problem ved at lave en direkte hardware simulering, evt. som springbrædt for efterfølgende optimering, er at 500 sider diagrammer i meget marginal grafisk kvalitet på en eller anden måde skal gøres maskinlæsbare.

Kig efte "Schematic" her: https://datamuseum.dk/wiki/Bits:Keyword/RATIONAL_1000/DOCS

Forslag til hvordan man kommer derfra til en eller anden form for netliste er meget velkomne.

  • 1
  • 0
#21 Martin Hansen

Interessant. Kan man være sikre på disse schematics er komplette? Har åbnet et par stykker af filerne og ud fra beskrivelsen på forsiderne ser de ud til at være udarbejdet i forbindelse med beskrivelsen af forskellige rettelser til problemer i maskinen f.eks. her:

https://datamuseum.dk/bits/30000957

Men omvendt indeholder filen en meget stor mængde schematics og de er vel ikke alle relateret til en enkelt rettelse. Men måske blev hele boardet gengivet ved en rettelse eller også er dokumentet flere der er klippet sammen således at schematics ikke har relation til fejlrettelsen?

Hvilken del af informationen i en sådan fil vil være den essentielle? Er det det som starter på side 10 f.eks. og frem og fortsætter til slutningen af dokumentet? Det ser ud til at være et diagram af hvordan det hele logisk er forbundet. Men skal man også bruge fx diagrammet på side 3 som ser ud til at være hvordan banerne i praksis er lavet (måske?)

Jeg er måske ude efter - hvis man kunne lave en OCR-scanning fra side 10 og frem og selvfølgelig med et domæne-specifikt lag ovenpå der 'fatter' syntaksen for diagrammet og kan spytte det ud på et eller andet brugbart format (noget netliste lignende), ville man så være i mål?

  • 0
  • 0
#22 Poul-Henning Kamp Blogger

Kan man være sikre på disse schematics er komplette?

Der er vist nok en enkelt side hvor vi mangler halvdelen, men det er vist nok en side fyldt med SRAM chips til en mikrokode-trace facilitet, så den bekymrer mig ikke.

Men derudover er diagrammerne, så vidt jeg kan gennemskue, komplette og skulle der mangle en enkelt side, har vi de orginale printplader vi kan ohm'e os igennem.

Diagrammerne kommer fra et ringbind hvor et par ECO notices var klasket ind foran, de blev bare scannet med diagrammerne.

Det interessante er alle diagrammerne, af hvilke der er ca. 400.

Jeg har leget lidt med tanken om at lave noget billedbehandling på dem, så man kunne loade det originale diagram som baggrundsbillede i kicad for at gøre det nemmere at tegne "ovenpå".

Det vil naturligvis kræve at der bruges symboler der er magen til, men det vil under alle omstændigheder være nødvendigt, for R1000 brugte "bit 0 er MSB" konventionen. (Check ben-numrene på en ram chip f.eks).

Men det er stadig 400 sider...

  • 1
  • 0
#23 Nis Schmidt

For mange år siden (i 1996) fandt jeg via "Alt om Data" en Red Hat Linux 2.4 og 'diglog' og en ny hobby. Senere i nullerne eksisterede der binære builds blandt andet en Windows udgave i 32 bit.

Linux havde jeg en del sjov med at bygge og luge ned til det nødvendige for min daværende mono-core konfig, så Chipmunk (CM) tools kørte rimeligt.

Dengang kunne man ikke så meget med det, jeg nåede til at simulere "en fetcher" til PDP-11 instruktioner og nogle RAM-og bus-moduler til dem ,,,

Da jeg så de uplodede schematics, kom jeg til at tænke på CM og at man kunne generere netlister fra diglog (SPICE o.a.). Der findes forhåbentlig en kortere (og lettere) vej i dag, men jeg slog "diglog analog" og fandt:

A starting point for Chipmunk

Ellers er vejen at modde CM til at vise baggrunde og "bygge" "glowing wire" schematics til netlisterne. CM er open source og John kan sikkert kontaktes.

  • 0
  • 0
#27 John Nielsen

Jeg prøvede lige at OCR læse diagrammer. Hverken Finereader eller Tesseract kunne læse noget som helst. Så tanken om at lave en netliste ud fra PDF diagrammerne har ikke mange chancer.

Al diagramsoftware har import fra hinanden, men det forudsætter originaler.

Så eneste vej er at eftergøre diagrammerne og så lave en netliste, en enorm opgave, reelt sætte alle komponenter og tegne alle linier og navngive IC'er og signaler. Diagrammerne er nutidige i form så den del er simpel kopi.

Jeg overvejede en anden mulighed VHDL som er lidt mere i din boldgade, editor med copy and paste, autoeditering osv. Så har man også mulighed for at flytte det i FPGA hvis ?

  • 0
  • 0
#28 Poul-Henning Kamp Blogger

Så eneste vej er at eftergøre diagrammerne og så lave en netliste, en enorm opgave

Jep, heller ikke lige hvad jeg havde regnet med at bruge et par års fritid på :-)

Jeg tror dog godt jeg kan lave noget håndkodet "hjælpe-OCR", som kan gøre noget af arbejdet og med så mange diagrammer kan det nok godt betale sig at bruge lidt tid på.

I forhold til software emuleringen kan der også snydes: Et ark fyldt med ram-chips kan erstattes med en enkelt større ram-chip, 8x8bit buffere/latches kan erstattes med en 64 bit ditto osv.

Men det sparer ikke ret meget i det store billede.

Hvis det bliver en emulering af den rå hardware bliver det næsten helt sikkert i SystemC, for målet er et program folk kan køre på deres egen computer.

  • 0
  • 0
#29 John Nielsen

Jeg kom til at tænke på PAL kredse som en ekstra komplikation, for de pakker en masse logic som kan skjules ved programmeringen. Det ser ikke ud til at de har været anvendt her og det er nok oppe i 1980'erne de overtog den løse logic. Jeg har stadig PROM og PAL brændere/programmere selvom de ikke har været anvendt i masser af år. Jeg har ligeledes masser af kredse fra den tid.

  • 0
  • 0
#30 Henrik Jacobsen
  • 0
  • 0
#31 Poul-Henning Kamp Blogger

Jeg kom til at tænke på PAL kredse som en ekstra komplikation, for de pakker en masse logic som kan skjules ved programmeringen.

Jo, der bruges PAL kredse og jeg har været igang med at læse.

Langt de fleste har ikke haft read-protect, så dem kunne jeg læse uden videre.

Tilbage er en håndfuld der er loddet i og en anden håndfuld der havde read-protect.

Ingen af delene anser jeg for show-stoppere for projektet.

De iloddede kan vi lodde ud af det sæt R1000/200 printkort vi modtog fra Pierre-Alain Muller og de andre er mit sommerferie-projekt i år.

(Hvis der er nogen der kender til literatur eller åben kode til brute-forcing af PAL'er hører jeg gerne om det!)

Worst case tror jeg alle de manglende kan udledes fra diagrammer og anden information med noget besvær, men det klart letteste er at læse dem.

  • 0
  • 0
#33 Morten Andersen

Realistisk er der vel to måder det kan komme til at ske: crowd sourcing hvor fx 400 mennesker investerer den max 1 søndag det vel taget at få skrevet et diagram ind på et eller andet format (tænker enten ved "tegning ovenpå" som PHK nævnte, eller måske i et DSL til formålet som kan bruges til at beskrive forbindelser, chips etc)... alternativt udvikle en specifik og god OCR. informationen er jo i billedet, og selve "sproget" er jo ikke ret kompliceret. Er desværre ikke god til billedbehandling men tænker at der findes mennesker ude i verden der ved lige hvad der skal til og kan bygge en pipeline på nogle få dage, og som så kan refines... og som med mpske få ugers indsats kunne lave noget der kunne scanne en meget stor procentdel af diagrammerne.

  • 0
  • 0
#34 John Nielsen

Jeg mindes svagt en mulighed for at løbe logiske muligheder igennem og af den vej finde logikken. Det er en AMD LabPro jeg har og om det er vectortest eller et specielt program kan jeg ikke huske. Jeg graver lidt. Jeg har en del ubrugte PAL kredse hvis det er et problem.

  • 0
  • 0
#36 Poul-Henning Kamp Blogger

Hvor store er PLA'erne?

Det er kun 16v8'ere der udestår og jeg ved endnu ikke om de har "hidden states", dvs. register termer der ikke dukker op på output-benene.

Min antagelse var at der måtte da være nogen der har forsket/skrevet om reverse-engineering af PAL'er så jeg ikke skulle genopfinde den varme tallerken, men det kniber mig med at finde nogen "prior art"...

  • 0
  • 0
#37 Morten Andersen

Ok hvis der ikke er hidden states kan den vel brute forces... Men hvis den har hidden states... Kan det mon blive nødvendigt at studere chippens opførsel mens den er på pladen og interagerer med de andre i et kørende system? Fx hvis den er afhængig af at der sker nogle forudgående lookup fra nogle andre chips, som fungerer ændrer staten og fungerer som en opløsning?

  • 0
  • 0
#38 Poul-Henning Kamp Blogger

Men hvis den har hidden states...

Så kan den naturligvis stadig brute-forces, det tager bare meget længere tid :-)

Grunden til at jeg er interesseret i at læse hvad andre har fundet ud af, er at jeg kan se nogle ret store genveje for udlæsning af PAL'er der ikke er direkte ondskabsfuldt programmeret, men inden jeg kaster tid efter det, ville det være rart at høre om andre har tænkt noget smartere :-)

  • 0
  • 0
#39 Keld Laursen

En gang i slut '80'erne lavede en kammerat og jeg reverse engineering af nogle PALer på nogle ethernet netværkskort for et amerikansk firma. Det tog sin tid, og afslørede at der ikke var nogle latches indeni. Vores fremgangsmåde var meget Monte Carlo-agtig: Vi gemte alle output-states sammen med de før-liggende output states og nyt input state, som blev genereret via en random funktion. Så lod vi en PC printerport eller tre om at læse og skrive PALens in- og outputs, og loggede alle nye kombinationer af output-1 + inputs 0 outputs samt tiden siden vi sidst havde fundet en ny kombination. Vi forventede at vi ved latch-funktioner ville finde forskellige outputs til samme inputs. Da vi efter halvandet døgn ikke fik flere nye kombinationer gik vi i gang med at skrive inputs og outputs sammen i Karnaughkort, reducerede alle in- og outputs som ikke påvirkede et givet output væk, og endte ud med en ret simpel PAL definition, som vi kunne brænde og erstatte originalen med, og verificere at designet fortsat kørte. Men jeg ved ikke om kildekoden til dette projekt er blevet til vapourware i mellemtiden. Jeg er ret sikker på at det er skrevet i Turbo Pascal.

  • 0
  • 0
Log ind eller Opret konto for at kommentere