PLL in Spartan6 FPGA

Beste forumleden,

Sorry voor de moeilijke vraag. Omdat anderen mogelijk iets aan deze ervaring hebben meld ik de oplossing van dit vraagstuk.

De essentie van het verhaal is de gebrekkige werking van de ISE14.7 software onder Ubuntu 18.04. Meeste functies in de ontwikkelingsomgeving werken goed maar het raadplegen van documentatie vanaf ISE werkt niet. Meestal is dat niet erg maar bij sommige toepassingen van de core generator, zoals de clocking wizard, werk je blind. Op internet vond ik uiteindelijk de tip dat een verouderde JAVA versie de schuldige kon zijn. In de mappen van het systeem zitten twee folders JAVA en JAVA6. Hierbij is 6 de nieuwere versie. Door de folders te renamen komt de nieuwe JAVA ter beschikking en krijg ik degelijke uitleg bij de te maken keuzes en fouten. Het is allemaal nog niet zo klaar als een klontje maar het werkt. Het tussenresultaat is dat ik nu twee PLL's in serie heb werken. Hiermee kan ik verder aan de slag om de 8 simultaan opgewekte draaggolven van mijn AM modulatortje met een aanvaarbare afwijking op het 9 kHz raster te laten
vallen.

Vriendelijke groeten,

Eduard

Op 26 september 2020 12:03:48 schreef Eduard2:
Sorry voor de moeilijke vraag. Omdat anderen mogelijk iets aan deze ervaring hebben meld ik de oplossing van dit vraagstuk.

Ja sorry, ik had je PLL-vraag wel gezien, maar ik heb het zo ook nooit gebruikt. Ik zou de Xilinx USM raadplegen en als het daar niet in staat zul je toch zelf moeten experimenteren. Je moet wel de juiste buffers gebruiken, dat uitmaken of het wel of niet lukt.

Dag flipflop,

Het kloksignaal is van de correcte frequentie. Na deling door 1024 kan het doorheen het LD filter dat aan de uitgang is verbonden. Na een hoop trial and error is dat uiteindelijk gelukt.

Een beginnersvraag: Wat is de Xilinx USM ? Ik raadpleeg 2 documenten:
DL160 Spartan6 family overview en UG382 Spartan6 family clocking resources. Vooral de tweede is nog te moeilijk voor me. Ik lees dat er verschillende soorten clocklines bestaan. Hun optimaal gebruik blijft onduidelijk. De link naar variabelen en de .ucf file in Verilog heeft wat weg van koffiedik kijken. Een goed boek of een tekst over dit onderwerp zou me meer houvast geven. Kan je iets aanbevelen ?

Op voorhand bedankt,

Eduard

De proza van Xilinx over de clock materie is inderdaad erg taai, heb ik zelf ook ondervonden.
Het probleem is dat een PLL geen digitaal ding is, het is niet in Verilog of VHDL te beschrijven, er is een aparte "instructieset" voor nodig om de zaken in te stellen.
Zelf gebruik ik Vivado 19.2, de clock-wizard deed het eerst niet, na de landinstelling en locale op Us-English (ook Ubuntu 18.4) gezet te hebben, werkte de wizard ...
Ik heb veel aan volgende link gehad:

https://forum.digilentinc.com/topic/9419-using-vivado-ip-clocking-wiza…

edit)
Zelf heb ik Spartan 7 en een Artix 7.

Op 26 september 2020 18:04:27 schreef Eduard2:
..Een beginnersvraag: Wat is de Xilinx USM ? Ik raadpleeg 2 documenten:
DL160 Spartan6 family overview en UG382 Spartan6 family clocking resources. Vooral de tweede is nog te moeilijk voor me.

Oh jee, ik bedoel inderdaad de UG, User Guide (USM staat voor User Manual, maar niet van Xilinx, hehe). Die je noemt zou toch wel degene kunnen zijn die je moet hebben. Daar staat precies in wat je wel en niet met (oa) een PLL kunt doen, en welke clk buffers je voor en achter de PLL moet plaatsen. Nou doet de synthese dat meestal ook al wel, maar je kunt het maar beter zelf gelijk goed doen.
Die verschillende soorten buffers zullen ook wel in die UG beschreven zijn. Voorbeeldje: een ibuf is een input buffer die altijd aan een input pin zit. Je kunt deze dus niet tussen de 2 PLLs plaatsen. Bufg is een global buffer, die een clk net kan driven, bv alle flipflops in je fpga.
PS, je hoeft een UG natuurlijk niet helemaal te lezen. Alleen dat wat je nodig hebt is genoeg

Beste flipflop en Rd12tf:

Die Xilinx manuals zijn best moeilijk als je een onderwerp op je eentje moet uitvlooien. Ze zijn kompleet en correct en daarom moeilijk voor de beginner.
Een manual is geen leerboek maar eerder een naslagwerk. Het is een ware kunst uit de massa informatie het stukje te isoleren dat je aanbelangt. Als er een leerboek bestaat dat een beginner op weg zet in de Xilinx FPGA dan wil ik dat graag aanschaffen.

@Rd12tf: Het nederlands is een klein taalgebied. Omdat ik met technische dingen en computerzaken bezig ben installeer ik steeds een engels operating system. Vaak is dat de taal van de ontwikkelaar. De engelse versie van een software zal al door veel meer gebruikers aan de tand zijn gevoeld dan de nederlandse. De kans op bugs en incompatibiliteit is bij de engelse versie kleiner. Zeker voor Xilinx software onder linux is dat het geval.

Vriendelijke groeten,

Eduard

Daar ben ik het mee eens,maar waren de foutmeldingen van Vivado maar niet zo cryptisch!
(Ik moest trouwens alleen de locale settings aanpassen, dus naar dollars en imperial enzo... )

Beste Rd12tf

Interessant uw opmerking over Vivado te lezen. Dat is voor mij een extra obstakel om op langere termijn de overstap naar Spartan7 te maken. Als ik me niet vergis bestaat de Spartan7 niet meer in TQFP144 behuizing. Zelfs als het zou lukken zelf BGA ic's te solderen zie ik in het verbinden van de bolletjes onder het ic een groot probleem. Met een dubbelzijdige print kom je wellicht niet ver. Overstap naar Spartan7 zal de zaken moeilijker maken.

Zou de concurent Lattice op dat vlak beter scoren ? Hun ICE reeks kan worden behandeld met open software. Mogelijk zijn ze toegankelijker voor de amateur. Als iemand daarmee ervaring hefft dan hoor ik het graag.

Vriendelijke groeten,

Eduard

Op 26 september 2020 21:43:46 schreef Eduard2:
Die Xilinx manuals zijn best moeilijk als je een onderwerp op je eentje moet uitvlooien. Ze zijn kompleet en correct en daarom moeilijk voor de beginner.

Dat klopt, is geen eenvoudige kost. FPGA ontwerp is ook een vak he, dat doe je er niet even bij als hobby. Nu wil jij ook iets doen wat niet echt van beginners nivo is, dus dat je daarvoor dingen moet lezen die voor een beginner moeilijk zijn is niet zo gek.

Een boek dat je uitlegt hoe je een PLL implementeert in een FPGA zul je niet zo snel vinden. Dat is heel specifiek voor het merk en type FPGA. En hele specifieke dingen als 2x een PLL staat niet in boeken. Zelf uitvogelen is dat.

Op 27 september 2020 10:08:56 schreef flipflop:
En hele specifieke dingen als 2x een PLL staat niet in boeken. Zelf uitvogelen is dat.

Wat ik me kan herinneren van toen ik tijden terug met FPGAs heb gewerkt is dat waar ik toen mee werkte dat gewoon absoluut niet zou kunnen. De PLL wordt gevoed uit 1 of 2 mogelijke bronnen, en de uitgang gaat al dan niet het clock netwerk in, maar zeker NOOIT een andere PLL. De mogelijkheid om dat zo te verbinden bestond toen gewoon niet.

Dag Flipflop,

Ik vrees dat je gelijk hebt. Die dingen zijn zeker niet eenvoudig. Mijn vader was lid van een vereniging met de naam:"geduld brengt vis". Bij een FPGA volstaat geduld niet, er hoort ook een brok studie bij. Stukje bij beetje vallen de puzzelstuksjes in elkaar.

Op gebied van FPGA ben ik een beginner met 60 jaar evaring in het elektronica vak. Het fijne van na een loopbaan weer amateur te worden is dat je zelf kiest waar je mee bezig bent. Vandaag kan je bijna niet zonder FPGA als je iets wil maken dat vlug en complex is. De moeilijkheidsgraad moet ik erbij nemen.

Aan ieder een ferme bedankt voor de gekregen hulp.

Vriendelijke groeten,

Eduard

@Eduard. Naast Lattice en Xilinx maken ook Intel (Altera) en Microsemi FPGA's.

En eigenlijk verwacht ik dat ze allemaal nog wel een tijdje Spartan-6 achtige devices in niet-BGA packages blijven produceren, gewoon omdat er nog ontzettend veel producten gemaakt worden op basis van die technologie.

Xilinx verkoopt de XC9500 CPLD's ook nog steeds. Die dingen zijn volgens mij nog van vorige eeuw, ik heb ze sinds 2003 niet meer in een nieuw ontwerp gestopt!

Alleen alle nieuwe ontwikkeling gaat in BGA devices.

@rew: van PLL naar PLL kan bijna altijd wel, alleen soms moet je wat moeilijke (rare) dingen doen omdat een PLL output "bedoelt" is om een klok net te driven, en die kloknetten zijn nooit direct een PLL input. Soms moet je de klok dus door een flip-flop (logica) halen om een tweede PLL de driven.

Qua faseruis e.d. ga je er dan altijd op achteruit, en dat is een reden om geen PLLs in serie te zetten.
Uiteraard zijn er ook simpele devices geweest die echt alleen maar een externe inputpin voor een PLL konden gebruiken. Maar dat zijn uitzonderingen.

Op 27 september 2020 13:48:24 schreef blurp:
...Soms moet je de klok dus door een flip-flop (logica) halen om een tweede PLL de driven.

Gatverdamme! Viespeuk!
Nogmaals, of het kan hangt helemaal van het device af. Het kan best zijn dat een input vd PLL alleen maar aan een ibuf kan zitten, en dan kan ie dus nooit aan een ander kloknet. Dat soort dingen staat typisch in een UG (bij Xilinx).

Op 27 september 2020 13:48:24 schreef blurp:
@rew: van PLL naar PLL kan bijna altijd wel, alleen soms moet je wat moeilijke (rare) dingen doen omdat een PLL output "bedoelt" is om een klok net te driven, en die kloknetten zijn nooit direct een PLL input. Soms moet je de klok dus door een flip-flop (logica) halen om een tweede PLL de driven.

Ik dacht dat ik "buitenom" moest: Op een pootje en dan buiten de chip een doorverbinding maken. Maar goed. Zal van familie tot familie verschillen en het kan ook goed zijn dat de: "duw hem door een flipflop" truuk niet bij me opgekomen is toen.

De PLLs in FPGAs staan niet bekend om de lage ruis. Ben dus benieuwd of de ruis uit de PLL het signaal niet overstemt. Maar goed, dat zie je snel genoeg op de spectrumanalyzer.

Op 28 september 2020 10:07:15 schreef kojazz:
De PLLs in FPGAs staan niet bekend om de lage ruis....

Noem eens een voorbeeld waar ruis in zo'n PLL relevant is volgens jou. Het gaat hier om een digitaal systeem, waar je een deel op een andere (meestal hogere) clk wilt laten lopen.

dag flipflop,

kojazz kan gelijk hebben. De FPGA levert AM gemoduleerde signalen in het MG en LG gebied. Nu er twee PLL's in serie staan merk ik met een testradio een hogere ruis. Gelukkig blijft het geheel aanvaardbaar maar het loont de moeite de oefening eens over te doen met een andere externe klok die de hoge klokfrequentie met 1 ipv 2 PLL's opwekt. Eerder had ik ook al een wijziging in het kloksignaal aangebracht om de ruis te verminderen. Een 50 MHz externe oscillator doet het veel beter dan het 50 MHz kloksignaal dat ik eerder afnam van een PLL in de bijhorende Raspberry pi. Ik wil een test nemen door een oscillator met een 18,432 MHz kristal bouwen en die frequentie in de PLL met 16 vermenigvuldigen. Meten is weten.

Vriendelijke groeten,

Eduard

My 2 cents: je moet RF opwekken met componenten die daarvoor bedoeld zijn, en dus niet met een FPGA. Die PLLs zijn niet ontworpen voor een lage faseruis. Die levert gewoon een klok waar je een enorme bak met flipflops mee kunt klokken. Dat het werkt is leuk, maar voor een goede performance moet je je systeem anders opzetten.

Als voorbeeld: voor een SDR ontvanger heb je een ADC. Die heeft een sample-klok nodig. Die zou je dus met een losse, stabiele generator moeten maken en niet door een klok die je uit de FPGA laat komen.

dag flipflop,

Kan het lukken,via een pootje, een 294 MHz klok in te voeren ? Als blijkt dat 1 interne PLL minder ruis geeft dan loont het misschien de moeite om een externe PLL te voorzien.

Het positieve nieuws is dat het geheel al redelijk goed werkt. Het kan enkel maar beter worden.

Vriendelijke groeten,

Eduard

Uiteraard kan dat. Maar zoek dan wel goed uit of je alle inputs kunt gebruiken voor die bewuste PLL. Vaak heb je specifieke clk inputs die optimaal koppelen op de clk netten.

Beste forumleden,

Flipflop en kojazz hebben gelijk. Twee PLL's in cascade dat geeft behoorlijk veel ruis. Vandaag heb ik goed nieuws te melden. Ik heb de 50 MHz oscillator vervangen door 18,432 MHz. Er blijft nu nog 1 ingebouwde PLL van de FPGA in dienst. Door vermenigvuldiging met 16 bekom ik nu de 294,912 MHz. Mogelijk kan het nog beter door ipv de ingebouwde PLL een externe te gebruiken. Het resultaat is nu dermate goed dat voor mij die aanpassing niet nodig is.

Iedereen bedankt voor de geboden hulp.

Vriendelijke groeten,

Eduard

Op 4 oktober 2020 17:37:42 schreef flipflop:
[...294 MHz over een pinnetje... ]
Uiteraard kan dat.

Dat is nog maar de vraag: Veel "normale" io pins kunnen maar tot rond de 50mHz. Voor hoger ga je vrijwel altijd naar differentiële signalen. Je moet je ook realiseren dat als je 5pF aan trace-capaciteit hebt en 7pF aan input capaciteit, dan zit je aan 12pF totaal. Ga je dat 300 miljoen keer per seconde op- en onladen dan... Hmm 3.6mA. Dat zou moeten kunnen. Of ik heb een rekenfout gemaakt.

Dag Rew,

Als ik geen rekenfout maak dan liggen de zaken nog 10 keer slechter. 12pF bij 300 mHz geeft 44 ohm. Als we 3.3V voedingsspanning aannemen kan ik grofweg stellen dat de ac amplitude 1,6V bedraagt. Enkel in de parasitaire capaciteit zal de bron 36 mA extra moeten dumpen. 300 MHz is geen lachertje. Daarom ben ik blij dat 1 enkele PLL binnen de FPGA de klus klaart. Die PLL is wellicht niet de beste ter wereld. Toch doet hij het goed genoeg om genietbare radiosignalen op te wekken.

Iedereen nogmaals bedankt voor de verkregen hulp.

Vriendelijke groeten,

Eduard

Op 4 oktober 2020 14:59:23 schreef Eduard2:
Kan het lukken,via een pootje, een 294 MHz klok in te voeren

De traagste Spartan 6 kan 400Mb/s op een single ended IO. Dus 200MHz
De snelste haalt 800Mb/s, dus 400Mhz.
Maar dat is geschakeld als DDR3 memory interface, niet als klok-net de PLL in.

Normale mensen gebruiken daar een diff-pair voor. De maximale klok net input klok varieerd tussen speed grades van 250 to 540 MHz.

Wat we in telecom vaak deden (waar je een veelvoud van 155.52MHz wil met een frequentie-nauwkeurigheid van atoomklokniveau (of minimaal stratum 3)), is een externe VCO (voor de lage faseruis) aangestuurd (PWM+laagdoorlaatfilter) door de FPGA.

En een 19.44MHz VCO met 8x multiplier in de FPGA is goed genoeg, en goedkoper dan een 155.52MHz VCO.