Svenska ElektronikForumet

guckrum skrev: ↑16 oktober 2025, 08:03:25
Är själva systemet du skall använda detta i verkligen asynkront?

Tror så. Den implementation jag har nu är skriven in C och assembler. Sedan finns det dedikerade chip och de första kontrollersarna var maskprogrammerade 8045 och så, men de tidigaste implementationerna var faktiskt med rak TTL och jag har tagit inspiration av en sådan. gott om NAND SR-vippor där... Men låt mig förklara.

Som en POF tänkte jag testa förverkliga en GPIB mottagning. Bussen har då 8 bitar och tre styrsignaler: DAV, NRFD, NDAC. Det är negativ logik. När vi börjar är DAV och NRFD höga, NDAC låg, vilket betyder att vi kan ta emot data.
Sändaren sätter en byte på bussen och sätter DAV låg och efter en liten fördröjning (RC krets) så sätts NRFD låg och samtidigt klockas databyten in i en 8-bitars latch (så långt fungerar det)
NDAC sätts hög vilket gör att sändaren vet att det är mottaget.

Så då har vi fångat en byte.

Min tanke var att låta DAV som klockar i datat även sätta en vippa/signal som kan interrupta min MCU som sedan kan läsa latchen och sedan pulsa samma vippa för att resetta, vilket då sätter RFD hög och allt börjar igen.

Detta är ju ett hobbyprojekt och jag har noll erfarenhet av CPLDer. Köpte mitt lilla kit för ett år sedan för att bygga logik till ett minneskort, men den blev så enkel så det blev diskret TTL i stället Så jag har eg bara testat med enkel, kombinatorisk logik så här långt

Hittade följande dokument: ATMEL PLD Design Guidlines

ATF1500 family) have many different clock options, which provide design flexibility, but could add potential timing problems

Hittade även en möjlig orsak varför det inte fungerar att analysera i Digital, punkt 3.1 i den senaste manualen, inte den från 2019 som jag skrivit ut tidigare.

It should be noted that the circuit to be analyzed may contain only purely combinatorial elements
in addition to the built-in D and JK flip-flops. If a flip-flop is e.g. made from Nor gates, this circuit
is not recognized as a flip-flop and therefore it is not possible to analyse such a circuit.

Ävenså, de inbyggda logiska elementen, så ha vissa "Exportable to VHDL", andra inte och tydligen är det bara de som kan exporteras som kan analyseras.

Så är det. VHDL skrevs från början för att göra modeller av designer med, inte bygga saker med, det kom senare. Så det är bara ett subset av språket som man kan använda för att designa med. Och man måste uttrycka sig på precis rätt sätt för att det skall fungera. Och en del av det är "kompilatorberoende".

Att det går att uttrycka i språket betyder alltså inte att man kan syntha en krets som beter sig likadant.

Sedan är ju Digital ett verktyg främst tänkt för undervisning. För Atmel CPLDer fanns det tidigare kommersiella verktyg som nu är fria, men som är fulla av buggar. Alternativt en gammal version av Quartus.

Såg du vad jag skrev om GPIB-mottagning? Nåra tankar om det?

Det var inte igår man läste GPIB-protokollet senast

Du vill göra en "brygga" mellan GPIB och en microprocessor. Så i ena änden skall den prata (och "fånga") bytes från GPIB, och i andra änden sätta en interrupt samt prata med en CPUbuss via en tristate-buffer osv (eller kommer du läsa med dedikerade GPIO-pinnar)? I mitten sitter en latch. (Eller - teoretiskt behövs den väl inte, för GPIB-källan håller väl datan stabil tills man ackar den?)

Jag skall fundera lite på det, tror inte att det är så svårt att få till. Kan du köra den på samma klocka som CPUn?

OK. Jag skall försöka förklara hur jag tänker. Jag har, sedan 10+ år sedan ett hobbyprojekt.

I dagsläget finns det kanske 150 st byggda och färre än 10 av "turbovarianten" för HP1000 minidator. I orginalvarianten kör jag med en 5V PIC (PIC18 47K42) och inga speciella kretsar, utan signalen direkt in på pinnarna. I "turbovarianten" kör jag med en snabbare och 16-bitars PIC (dsPIC33CK256MP206I) och speciella SN75160/SN75161 kretsar. Dessa är dock end-of-life och min första tanke var att helt enkelt duplicera logiken i dessa i en CPLD, men så tänkte jag att man även kunde hantera en del av mottagningen oxå.

Hastighetsmässigt är ju inte GPIB/HPIB så lysande. Systemet med öppen-kollektor-handskakning gör det långsamt, men på en snabb HP9000/425 så klarar en HPDisk ca 100kb/s, dvs snabbare än de diskar man hade då. Dessutom har den ingen latens som en floppy eller annan snurrande disk. Funkar snorbra för BASIC och Pascal och tom RTE-A, men HPUX som är diskintensivt blir långsamt.

Ingen version av HPDisk har ju egentligen någon "buss" utan det är dedikerade pinnar för all 16 GPIB signaler, pinnar för SPI till SD-kortet etc.

Däremot tycker jag det är kul att lära mig nya saker, eller nya för mig så hela grejen med CPLDar verkade kul.

Det finns ingen kommersiell nytta med HPDisk, men den har blivit populär bland de som sysslar med retrocomputing och visst, vi lyckades återuppliva en tryckpress i Argentina med en HPDisk när dess hårddisk rasat. Den styrdes nämligen av en HP1000 A-Serie.

Tacksam för din hjälp och synpunkter. Skall labba vidare i morgon om jag hinner, som sagt var varför gör jag detta? Mja varför bygger man flaskskepp eller Bodens fästning som tändstickstavla

Något slags marknad verkar det finnas eftersom NI låtit konstruera och fortfarande säljer en GPIB-controller ersättare.

https://se.farnell.com/ni-emerson/nat72 ... dp/3623022

Visst finns det. Det finns massvis med svindyra mätinstrument, typ analysatorer för medicinskt bruk som fortfarande används.

swesysmgr skrev: ↑19 oktober 2025, 22:53:45 Något slags marknad verkar det finnas eftersom NI låtit konstruera och fortfarande säljer en GPIB-controller ersättare.

https://se.farnell.com/ni-emerson/nat72 ... dp/3623022

NAT7210.jpg

Nu har jag inte kollar just denna, men specifikt det jag gör, dvs diskemulering, så fungerar bara vissa chip. Det är nämligen så att HP valde att bryta mot IEEE 488 på en specifik punkt i sitt protokoll. Chips som fungerar är "NEC µPD7210 and all of its descendants" således denna, men priset är litet häftigt

Includes a simple editor for finite state machines (FSM). A FSM can then be converted to a state transition table and a circuit implementing the FSM

FSMs är annars en av mina favoriter för procedurell programmering. Blir väldigt tydlig och lättläst kod, däremot kanske inte alltid den snabbaste koden.

Jag har inte haft tid för någon GPIB ännu, men visst skall du använda tillståndsmaskiner om möjligt. Däremot föreslår jag att du skriver dem direkt i VHDL, om du nu har möjlighet att syntha VHDL till CPLDn. Jag skall kolla om jag hittar något bra exempel. Hastigheten är inget problem.

(Idealt vill du skriva som i kapitel 5.4 i denna boken
https://download.gaisler.com/research_p ... l2proc.pdf
av Jiri Gaisler, killen med rymdprocessorerna.)

OK. Tack, jag skall kika. Det kan hända att jag får bita i det sura äpplet och lära mig VHDL eller Verilog... Mattis postade tidigare denna länk.

Dvs ett projekt för att programmera ATF150x i Verilog, men även i VHDL enligt Mattis. För mig som dagligen programmerar i C/C++ känns kanske Verilog enklare?

Skall skriva ut PDFen och läsa. Digital kan ju exportera både VHDL och Verilog så jag kan använda den som "uppslagsbok"

Tillståndsmaskin - Har aldrig hört det på svenska förr, men det är ju vedertaget och ett bra ord. Tack!

OK:
Får inte parametrar till run_fitter att fungera, men editerade in chip och kåpa i cmd-filen

cd atf15xx_yosys\examples\test
..\..\run_yosys.cmd test
..\..\run_fitter.cmd test

atfu erase -d ATF1504AS

atfu program -d ATF1504AS test.jed

Funkar. Får sedan kolla vad Mattis ändrade för att köraVHDL och inte verilog

Poängen med Gaislers "metod" är att den minskar risken att det blir fel samtidigt som koden faktiskt blir enklare att skriva och underhålla. Det han gör är att lägga alla signaler som skall gå genom vippor i ett "record", eller "struct" som vi säger i C, och då blir det bara bättre.

En annan grej. En sak som gnager lite är att dina insignaler är asynkrona. Det är aldrig en bra idé att mata en synkron maskin med asynkrona signaler. I värsta fall (dvs statistiskt nu eller om en stund när du tittar bort) kommer insignalen att ändras ungefär samtidigt som klockan slår om, och detta kan sluta med att grinden hänger sig, beroende på hur den är implementerad. I vissa teknologier kan man "synkronisera" genom att skicka signalen genom en rad av vippor innan den används. Det löser sig, men jag har inte riktigt förståelse för exakt vad maskinen skall göra så jag har inte heller funderat på detaljerna.

Jo, jag vet problemet med asynkrona signaler och timing och att man kan synka upp med vippor. Skall kika på det. Sedan är ju utrymmet, antalet celler i en ATF150x mycket mera begränsat än i en modern CPLD.