FPGA klokdeler voor Spartan6 op Mojo board

Waarom moet je per-se op die 16.6MHz lopen? Rare frequentie is dat. Tenzij je een goede reden hebt kun je beter alles op 50MHz laten lopen en daar waar je eens in de 3 cycles iets wilt doen een enable signaal gebruiken.
Een enkele klok houdt je constraints een stuk simpeler.

Hallo flipflop,

16,66..Mhz was een natuurlijke keuze omdat ik een DAC aanstuur die maximum 20 MHz updaterate kan verwerken. Meestal betekent lagere frequentie ook minder problemen met delays enz. Omdat ik verschillende dingen met dezelfde 16,66 MHz klok moet sturen dacht ik alles op 16,66 MHz te klokken.

Het blijft me storen dat ik de coregenerator niet kan gebruiken. Ik vraag me af of de ISE wel volledig werkt onder linux.(Ubuntu 18) Mogelijk heeft iemand op dit forum daar ervaring mee.

Vriendelijke groeten,

Eduard

Op 19 maart 2019 20:54:40 schreef Eduard2:
16,66..Mhz was een natuurlijke keuze omdat ik een DAC aanstuur die maximum 20 MHz

Vind ik een slecht argument om dan maar een heel stuk van je design op die freq te laten lopen. Hoe ga je het doen als je van dat 16M domein naar het 50M domein moet? Of heb je dat laatste helemaal niet?
Ik zou gewoon het hele spul op 50 laten lopen, moet makkelijk kunnen. Dan die interface gewoon klokken op 50, en eens in de 3 klokken een update naar de DAC doen. Is wat algemeen gezegd omdat ik de interface niet ken, maar in de basis moet het zo kunnen. Ben je al dat gedoe met klokdelers kwijt en wordt je build veel simpeler.

Details over de tools ben ik niet bekend mee.

Beste flipflop,

Je hebt gelijk. Ik probeer het op die manier. FPGA is voor mij nieuwe materie. Gelukkig is er dit forum.

Bedankt voor uw hulp.

Eduard

Op 19 maart 2019 21:08:46 schreef flipflop:
[...]
Vind ik een slecht argument om dan maar een heel stuk van je design op die freq te laten lopen.

Hij wil niet "een heel stuk" op 16 en de rest op 50, hij wil (dacht ik) het hele ding op 16 laten draaien. Niks geen cross-domain.

Het enige is dat de hardware oscilator 50MHz maakt en op een klokpin aanbiedt. het ingangs-clock-circuit moet daar zonder problemen 25 of 16.6 MHz van kunnen maken.

Dag rew,

Heel het domein naar 16,666 MHz blijft mijns inziens de beste oplossing. Als iemand me kan vertellen hoe ik met de centrale klokmodule die deling kan uitvoeren dan ben ik weer op weg.

Ik had mijn vraag ook algemener kunnen formuleren of een tweede vraag stellen. Graag had ik geweten of andere forumleden de Xilinx ISE en de coregenerator onder linux gebruiken. Met ISE heb ik geen problemen. De coregen is een ander paar mouwen. Sommige IP modules compileren probleemloos, andere eindigen met een foutmelding. In mijn project gebruik ik uit de IP bib de FIFO. Dat werkt als een fluitje van een cent. De klokdeler / pll is een module die vastloopt. Ook de DDS compileert niet. Ideaal was het te weten of iemand dit probleem kent en hoe dit kan worden verholpen.

Vriendelijke groeten,

Eduard

Ik heb rond 1994 een muntje opgegooid en met "Altera of Xilinx" voor Xilinx gekozen. begin jaren 2000 heroverwogen en Altera gekozen. Geen spijt van. Maar sindsdien weinig mee gedaan.

Dus ik weet dat het zou moeten kunnen, maar ik weet niet wat de specifieke oplossing voor jou probleem is.

Jou latere verhaal hint naar dat er installatie problemen zijn met de software. Dan is het helemaal essentieel dat je gewoon een log post met precies wat voor foutmeldingen je krijgt. Ook met de meldingen die naar jou idee niet relevant zijn. En het is van belang om te zeggen welke versie van de software je hebt genomen en welke Linux versie je gebruikt.

16.66MHz kristal aan de ingang solderen

Op 20 maart 2019 08:37:44 schreef Eduard2:
Heel het domein naar 16,666 MHz blijft mijns inziens de beste oplossing.

Ah, dan heb ik je situatie verkeerd begrepen. Als je het hele spul op 16.6 laat lopen kan dat ook prima als je daarmee weg komt wb performance.
Het probleem is dat die 50 nogal beroerd deelt naar 16.6, deeltal 3 en daarmee krijg je een asymetrische klok, geen 50% duty dus. Anders had je gewoon kunnen delen mbv een paar flip-floppen en dat als clk gebruiken.

De foutmelding van coregen lijkt me haast een installatiefout. Heb je gekeken wat de eisen zijn voor de ISE versie die je hebt? Misschien is je Linux distro niet compatible, of je tcl versie, of .... De halve wereld draait Xilinx tools op Linux, dus het zou fluitend moeten werken (daar heb je niks aan, snap ik).

Beste flipflop,

Als symmetrische klok belangrijk zou zijn dan kan ik bekijken of de klok tot 50/4 MHz kan dalen. Ik maakte een vergelijkbare opstelling al eerder met cmos ic's . Die gaf al behoorlijk resultaat met een 4 MHz klok.

"De halve wereld draait Xilinx tools op Linux". Ik hoop dat u gelijk heeft. Als dat zo is dan moet het lukken de coregen te gebruiken.

Mijn ISE versie is 14.7. De linux distro is Ubuntu 18.04.2 LTS. Waar de info over de tcl versie kan worden afgelezen heb ik nog niet ontdekt.

Tips en trucs zijn welkom.

Vriendelijke groeten,

ALS je klok 66/33 zou worden, dan ZOU het zo kunnen zijn dat je in "klok laag" in de problemen komt met timing terwijl je zeeen van tijd hebt in de andere helft van de klok. Wederom, als je niet de grenzen opzoekt van je FPGA zou het kunnen dat dit gewoon prima kan. Daarnaast: De PLL/klokmodule van de FPGA kan vast wel een *2/1 PLL doen van de externe 50MHz klok met dan een post-deler van 6. Gewoon symmetrisch.

Op 19 maart 2019 20:54:40 schreef Eduard2:
Het blijft me storen dat ik de coregenerator niet kan gebruiken. Ik vraag me af of de ISE wel volledig werkt onder linux.(Ubuntu 18)

Ja, ISE moet gewoon kunnen werken onder Ubuntu (alhoewel Xilinx geloof ik Red Hat opgeeft. CentOS mag ook).

Wat ik wel meegemaakt heb is dat Xilinx-tools onderuit gaan van localizatie-instellingen. LANG=NL e.d. gaat snel mis, LANG=C gaat beter. Ook alle LC_ enviroment variabelen zou ik unsetten.

Op 20 maart 2019 22:15:07 schreef flipflop:
[...]
Het probleem is dat die 50 nogal beroerd deelt naar 16.6, deeltal 3 en daarmee krijg je een asymetrische klok, geen 50% duty dus.

Das een kwestie van ook op de neergaande flank reageren. En dat lukt best met een Spartan 6 op 50MHz.

[Bericht gewijzigd door blurp op donderdag 21 maart 2019 17:04:36 (24%)

Op 21 maart 2019 17:02:34 schreef blurp:
Das een kwestie van ook op de neergaande flank reageren. En dat lukt best met een Spartan 6 op 50MHz.

Wacht even, dit zie ik nu pas. Je wilt een een setje flip-flops op beide flanken gaan klokken? Hoe stel je je dat voor?!

@blurp hieronder: ja ok, zo bedoel je. Ik dacht even dat je dezelfde FF op 2 flanken wilde klokken.

[Bericht gewijzigd door flipflop op zaterdag 23 maart 2019 21:48:08 (14%)

https://electronics.stackexchange.com/questions/286052/divide-clock-fr…

Beste forumleden,

Ik wil iedereen bedanken die een duwtje heeft gegeven aan dit projectje. Het doel is bereikt en nieuwe uitdagingen komen er weldra aan. (zoals het verkennen van de Coregen)

Zonder de klokfrequentie te wijzigen is het gelukt de DAC aan een samplerate van 16,666 MHz uit te sturen. De beginnersproblemen raken stuk voor stuk opgelost. Tussen 2 opgaande flanken van de 50 MHz klok is er voldoende tijd om het cijferwerk eigen aan AM modulatie uit te voeren. ISE meldt geen knelpunten in de timing.

Wat mij betreft mag deze draad worden gesloten.

Vriendelijke groeten,

Eduard

Op 25 maart 2019 17:18:14 schreef Eduard2:
ISE meldt geen knelpunten in de timing.

Heb je wel constraints dan?

Topics sluiten doen we hier niet (niet zomaar voor de lol).

Dag flipflop,

Dit is mijn eerste FPGA projectje. Mijn info over timing komt uit dit artikel:
https://alchitry.com/blogs/tutorials/fpga-timing
Hierin staat een voorbeeld van hoe met een hoop vermenigvuldigingen de timing wordt overschreden. Bij mijn opstelling verschijnt de mededeling dat er geen timing probleem is. Ik heb verder gebouwd op het basisproject dat de leverancier van het mojo bordje heeft aangeleverd. De ucf file heb ik enkel aangepast naar de nodige io pinnnen.

Moet er in die file nog iets worden veranderd voor timing ?

Aangezien het modulatortje intussen al een paar uur muziek aanlevert uit internet veronderstel ik dat de werking in orde is.

De kennismaking met FPGA valt best mee maar echt simpel is anders. Als iemand een goed boek over de Spartan6 kan aanbevelen dan luister ik zeker.

Met de draad sluiten wil ik enkel zeggen dat jullie intussen de informatie hebben aangeleverd waarmee ik het probleem kon oplossen. Iedereen nogmaals bedankt voor de hulp.

Vriendelijke groeten,

Eduard

Als het een compleet project is, dan zou je verwachten dat de ucf wel compleet is. Ik zie 'm zo snel niet staan. Wat je in elk geval nodig hebt zijn timing constraints waarvan de belangrijkste de klok constraint is. Daarmee geef je op wat de frequentie van je klok is. Dat is nodig omdat de synthese moet weten wanneer ie voldoende z'n best heeft gedaan om de timing sluitend te krijgen. Anders zegt de melding "no timing problems" ook niks.
Dus kijk gewoon voor de lol eens wat er in de ucf staat.

dag flipflop,

In de ucf file wijzen enkeldeze lijntjes naar timing:

#Created by Constraints Editor (xc6slx9-tqg144-3) - 2012/11/05
NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 50 MHz HIGH 50%;

Ik neem aan de ISE hiermee weet hoeveel tijd er beschikbaar is voor het doorlopen van reeksen poortjes. ISE meldt dat de timing en orde is. Omdat het systeem werkt denk ik dat alles in orde is.

Vriendelijke groeten,

Eduard

Dat is inderdaad een klok-spec. Daarmee (als jij inderdaad die klok ook gebruikt als klok) kan ISE de timing (voor 50MHz) doorrekenen.

Je kunt natuurlijk nog steeds andere inputs hebben die anders behandeld moeten worden, en het zegt ook niets over de timing naar buiten. ISE weet niet wat jij aan je FPGA hebt hangen.

Op 29 maart 2019 22:07:49 schreef Eduard2:
Omdat het systeem werkt denk ik dat alles in orde is.

Dat is nooit een garantie dat timing ok is. ISE zorgt er nl voor dat de timing over temperatuur, spanning en proces (variatie in de chip) binnen de grenzen komt. En jij kijkt maar bij 1 temp, 1 chip en met stabiele voeding.

Maar... je hebt dus een clk constraint staan, dat is goed. I/O constraints waar blurp het over heeft moeten eigenlijk ook, maar is meestal veel minder belangrijk. Je zou nog kunnen kijken of je iets kunt doen op die DAC interface, waar timing toch wel belangrijk is. Nou vallen er geen doden als het niet klopt, dus...

Ik krijg de indruk dat TS het geheel gebruikt om audio te maken. Bij voldoende oude oren is het dan niet erg als je 0.01% van de samples op de DAC mist, dat hoor je niet.

Als je daarintegen ethernet-pakketjes met een dergelijke bit-error-rate probeerd te versturen heb je voor alle praktische doelen gewoon geen verbinding.

dag blurp,

Inderdaad, het is gemoduleerde audio. Zowel mijn oren als de ontvangtoestellen hebben al heel wat jaartjes op de teller staan. De FPGA moduleert audio in AM en stuurt dat naar buizenradio's. De FPGA zorgt zowel voor het opwekken van de draaggolf als voor het moduleren ervan.

Vriendelijke groeten,

Eduard