FPGA timings probleem

Ik denk dat je even moet wachten tot free_electron dit leest. Typisch een vraag voor hem om te beantwoorden...

eerst naar je bord en kablage kijken. voedingsontkoppeling, lijnterminaite , singaalnievieveaus en dergelijke

gebruik je lvds in differential ? staat je 200 ohm terminatie er ?

als dat allemaal niet helpt et een re-synchronizer vlak voor je uitgang ( een stomme latch di eje clockt met je systeemclock : die re-alignt je timing dan terug

je moet ook eens naar je simulatie output kijken in quartus. klopt het daar ? als het daar al niet klopt loop je tegen de delay in de chip aan en moet je je ontwerp aanpassen of een snellere versie van die chip nemen,

10nS lijkt me veel . de skew in de fpga is meestal in de orde van picoseconden ... ik denk eerder aan bord en terminatie probleem

Hoi, de print waarmee ik werk is een bestaand ontwerp dus ik doe enkel de vhdl kant. Ik kan dus niets aan de print veranderen.
Voeding blijkt in orde. We hebben met de HighSpeed scope (6GHz) alles eens gemeten en dat blijkt in orde te zijn.

Ik moet zeggen dat niet alle pixels vershoven zijn, maar zo wat pseudo random waardoor het lijkt (en ook zo is) dat het beeld niet stilstaat.
De beweging is ook afhankelijk van testpatroon tot test patroon. En vooral bij een overgang van een kleur. (in een kleur is het niet op te merken of de pixels verkeerd staan).
Op de scoop zien we wel dat sommige pixels wel een juiste timing hebben en andere niet. Het delay is ofwel een paar ps ofwel rond de 10ns.

stel dat ik een testpatroon op het scherm genereer (1366x786px) met een zwarte achtergrond en op kolom 1 en kolom 1366 een witte lijn zet (daartussen ook nog een paar). Ik laat dan ook nog een wit vierkant van 100x100px tonen en een vierkant van 200x100px.
Ik zie dan dat de delay van de witte lijn na het tweede vierkant groter is (2 tot 4 pixels) dan bij het eerste vierkant (0 tot 1 pixel), waar geen vierkanten staan, daar is de lijn wel perfect afgebeeld.

oh ja, ik vertel hier wel delay, maar het zit zo dat de pixels naar links opschuiven, en dus eerder vershijnen dan verwacht. ze zijn echter wel onstabiel kwa plaats

Het lijkt mij dus geen hardware probleem, maar wss softwarematig.

excuseer voor de ingewikkelde uitleg, maar het is niet zo eenvoudig de correct symptomen uit te leggen. ik maar straks wel eens een duidelijkere tekening.

voila, de tekening van het beeld:

is die verschuiving groter naar mate je meer witte pixels op rij schrijft of maakt dat niks uit ? -edit- oja dat schreef je al. zie het nu pas na nog eens herlezen.

schuiven er soms pixels naar rechts of alleen naar links ?
verdwijnere er in verticaal bereik soms lijnen ?

het lijkt mij een probleem in je horizontaal scansysteem.
een asynchrone teller gemaakt omde line scanning te doen ? maar dan zou het eerder random shiften zijn ...

waar zit je framebuffer ? intern in de fpga of extern ?
kijk anders daar een naar of de data wel correct in de framebuffer landt....

tzou niet de eerste keer zijn dat het beeld gewoon verkeerd in de buffer landt.

je kan dit snel zien : eenmaal je de buffer gevuld hebt ( dus geen verdere update meer van het 'beeld' : verandert het beeld dan nog op het display of niet ? indien wel dan zit het in je scanlogica , indien niet dan zit het in de boel die de framebuffer laadt.

[Bericht gewijzigd door free_electron op vrijdag 14 juli 2006 22:32:23 ]

Op 14 juli 2006 22:24:04 schreef free_electron:
schuiven er soms pixels naar rechts of alleen naar links ?
verdwijnere er in verticaal bereik soms lijnen ?

wel, na zo een wit blok, schuift alles rechts ervan naar rechts, afhankelijk van hoe groot (breed) het witte blok is. maar de pixels die een verschuiving naar rechts gedaan hebben, die flikkeren wel steeds 1 pixel naar rechts (of hun juist plaats (die wel verschoven is)).

het lijkt mij een probleem in je horizontaal scansysteem.
een asynchrone teller gemaakt omde line scanning te doen ? maar dan zou het eerder random shiften zijn ...

ik zit met een synchrone teller (alles gebeurd in 1 process die de pixelklok in zijn sensetivety list heeft).

waar zit je framebuffer ? intern in de fpga of extern ?
kijk anders daar een naar of de data wel correct in de framebuffer landt....

tzou niet de eerste keer zijn dat het beeld gewoon verkeerd in de buffer landt.

je kan dit snel zien : eenmaal je de buffer gevuld hebt ( dus geen verdere update meer van het 'beeld' : verandert het beeld dan nog op het display of niet ? indien wel dan zit het in je scanlogica , indien niet dan zit het in de boel die de framebuffer laadt.

het beeld zit niet in een buffer of zo, maar wordt in de fpga ter plaatse gegenereerd vb:

heb een variabele lijn en pixel, die de huidige pixel en lijn bijhoudt die naar buiten gestuurd worden.

if  
    -- zo maak ik een horizontale lijn 
    lijn = 100 or
    -- zo maak ik een vertikale lijn    
    pixel = 200 or
    -- zo maak ik een shuine lijn
    pixel = lijn or
    -- zo maak ik een vierkant blok
    (pixel > 100 and pixel < 200 and lijn > 100 and lijn < 200) then
   r = X"3FF";
   g = X"3FF";
   b = X"3FF";
else
   r = X"000";
   g = X"000";
   b = X"000";
end if;

hola. gans dien nest is een asyncroon blok.
daar zit uw probleem. dat blok pakt lijn data binnen , doet zijn ding en stuurt buiten.
waarschijnlijk glitcht dat blok gelijk zot

pas dat eens aan zodat ; op de dalende flank van uw pixelclock de nieuwe 'input' voor dat blok gostockeerd wordt in een register.

op de stijgende flank van je pixelclock de output van dat blok in een register gelatcht wordt.

de uitgang van dat laatste register wordt gebruikt om de data aan te leveren naar je scanlogica.

de signaal trein is zo groot dat de ene keer een signaal veel vroeger naar buiten komt dan de andere keer. das de miserie van die synthese talen. je hebt daar moeilijk vat op. das trouwens een van de grote punten in mijn nieuwe boek . opgelet voor de post-synthese miserie. er is een groot verschil tussen 'papieren logica' en echte logica...

je hebt last van race condities.

andere vraag : wat voor display stuur je ? met andere woorden lever je ook de pixelclock aan dat display of alleen de frame en line klokken en sampelt dat display op zijn eigen clokgenerator ?

[Bericht gewijzigd door free_electron op zaterdag 15 juli 2006 18:33:50 ]

ik was misschien niet helemaal duidelijk maar de code was een deeltje als voorbeeld, gans dat blok staat in een process die op de pixelklok getrigerd wordt, en op de stijgende flank uitgevoerd wordt.

misschien moet ik eens wat originele code doorzenden zodat je een beter beeld hebt (posten op het forum doe ik niet).

De display's die ik aanstuur zijn verschillende soorten en merken, maar ze zijn allemaal bedoeld voor 'high-end' lcd en plasma schermen. HD-ready en full-HD. De bedoeling is om alles zo universeel mogelijk te doen zodat men andere soorten schermen ook testen.

ik ben misschien het belangrijkst nog vergeten vermelden.
Alles werkt nl goed wanneer ik een klok gebruik van 27Mhz ipv 64 of 90.

we hebben er vandaag code ingestoken die het zelfde doet, en die zich vroeger al bewezen had goed te werken (niet op de huidige print of fpga). Deze had dezelfde symptomen.

Het ligt dus wel aan de hardware (ik heef het 10% kans), of aan de instellingen kwa prioriteiten in de quartus II software of iets dergelijks (ik heef dat 80% kans) of het ligt aan nog iets anders (10%).

de experts in het bedrijf zijn jammergenoeg in vakantie momenteel dus ben ik een beetje op mezelf toegewezen :s

maar we komen er wel