Ще клоча FPGA-та и MCU-та с USB2. LAN-ове засега не се предвиждат, та USB-то е най чувствителното. Всъщност не съм ровичкал още дали върху въпросния MCU (PIC32MZ2048EFH...) USB-то върви и от вътрешния RC, щото ако върви остава само FPGA-то. При първия ми проект с FPGA го клочих с кварцов генератор, ама беше гоУем, на фона на останалите чаркове, и не съвсем евтин.

Аз съм ползвал само генератор и там е точно с правоъгълен изход. МЕМС резонатори не знаех даже, че има.



В твоята конфигурация МЕМС-а не би следвало да прави ядове.

@sparkybg: и аз като Цецо мисля че изобщо няма от какво да се притесняваш. MCU-то ти дори да върви на вътрешен RC за device USB, ще е до Full Speed само. Виж какво казват за допустим jitter на USB High Speed и на USB PLL-ите на MZ-ката и ако MEMS-а не ги покрива ще те черпя бира с мезе - нямам конкретна идея, нека малко хазарт да има.
Jitter-ът от пулс до пулс на MEMS-a го извади от бюджета за достъпа до SRAM-а. И тези 125 MHz може и да са малко утопия.

Защо? Сегашния ми проект си работи безгрижно на 125Mhz със същия SRAM на Spartan 3AN. Наложи се леко да бъзикна закъсненията във FPGA-то, не помня за адресната или шината за данни, иначе си тръгна от раз. Без цикли на изчакване при писане от MCU-то. 16 битова шина за данни, с буфер във FPGA-то за 8 записа се емулира на над 30Mhz без цикли на изчакване от MCU-то. Просто сегашния процесор (RX630) прави запис за минимум 3 цикъла при 50 мегахерцива шина, тоест около 16Mhz, което е и 16 мегапиксела.

Същия модел на Spartan 6 поне според емулациите може да върви над 2 пъти по-бързо (предполагам главно заради 6-битовия LUT).

В новия ще има и опция за Palette based 8 битов цвят, и ако му друсна 32 битова шина за данни ще напълня шината към паметта на 100%, или нещо като 70-80 мегапиксела в секунда. Ще го мъдря върху LX9, та да имам мегдан за всякакви глупости, дето ми дойдат на акъла във FPGA-то. 3AN-a към края малко ми отесня откъм скорост заради 4 битовите LUT-ове. Пък и не съм баш магЕсник на тема FPGA, та по-добре да ми е по-широчко около врата.

Ей го стария:
https://www.youtube.com/watch?v=4BwgjhzX_xg

Мда, сещам се за стария, може и да сме обсъждали нещо.

За достъп от 8ns - тясно е и подозирам че може да си на ръбче, което при една бройка на бюро не е проблем. Tco на изходните драйвери не е пренебрежимо малко, после колкото максимален път има през платката на адреси и контролни сигнали, вътрешен достъп на SRAM чипа, обратен път на данните, Tsu на входните буфери на FPGA-то, плюс jitter на клока. Това ако го правиш синхронно откъм матрицата, и както виждаш е винаги по-голямо с някоя-друга наносекунда от самия достъп на паметта. Едно решение, може би каквото и ти си използвал, е да местиш входните сигнали (IDELAY ли да беше..), ама тогава как определяш колко да забиеш, като имаш и вариации? Вариант би било авто-калибрация, но по спомен поне старите IDELAY бяха твърди от конфигурацията.

И встрани, така и така се забавляваш, защо не си боднеш FG256 корпус със стъпка 1mm? LX16/25 също са с търпими цени.

И най-вече, успехи и да се похвалиш!

При 6-цата се програмират както искаш, като недостатъкът е, че закъснителните линии са температурно зависими. Демек не става с метода на Натъманенко. Но пък има фазов детектор, така че може да си следи и мести фронтовете динамично. Проблемът му е само в ODELAY че там не вижда какво мести и колко го мести... освен ако не измисли някаква заигравка с тест на паметта от време на време...

ODELAY не мисля че ще му трябва, с вътрешен клок.


Периодична автокалибрация, да, и почва да отива все повече към направата на утежнен контролер на паметта. Аз, бидейки консерва, просто бих върнал малко газта откъм клок (запас) и да спя спокойно. Което Спарки може да не го вълнува като подход, нали си споделяме само.

По спомен като си играх с предното, търпеше като вариации няколко сетинга на delay, и го турнах по средата. Мисля че го и пекох с духалката докато работи, без да засека каквито и да са аномалии. Беше нещо като на всеки 4-ти адрес да бърка, преди да сетна закъснението. Тоест проблема му е била 4-та адресна шина (от гледна точка на FPGA-то). Не съм се занимавал да анализирам по-дълбоко. Опитах няколко сетинга на закъснението, сложих го по средата на работещите, поопекох го и толкоз.

Всичките ми адреснидегистри са в "кракови" елементи и се зареждат с клока, тоест избягвам вариациите от вътрешния рутинг на FPGA-то. Данните пък се и зареждат и изпращат пак в "кракови" елементи. Вътрешния клок си е 125MHz. Единствено клока на LCD панела е отделен - на към него предавам през двупортова памет, която никога не е празна.

Абе помня че чак се учудих че тръгна толкоз лесно, предвид че преди това даже не знаех що е то FPGA и Verilog. Но пък и доста мотане ми струваше, докато на симулациите всичко започне да изглежда както трябва. И с модел на паметта го тествах и т.н...

Спарки, горните ми писанки за бюджет са в случай че регистрите са ти баш изходните (pad, I/O), както казваш. ISE се прави на умно и ги слага там в общия случай, както и трябва да бъде. Ако не са там вече става мътна и кървава, не се практикува.
Както го описваш ми прилича като да имаш по-бърза памет, което донякъде е нормално - но пък не можеш да разчиташ на това.
И една дреболия - статичният анализ на ISE по default кара на всички температури и захранвания, т.е. опитва се да вземе песималния случай. Ако му зададеш някакви по-лабораторни диапазони може да изстискаш още малко .. статичен анализ.

То аз и модела на паметта пипах, в песимистична посока. Иначе си е съвсем официално 8 наносекундна при 3.3V +/-5%. Дай по-подробно защо не мога да разчитам, ако може. Както казах - новак съм, не съм борил проблеми и освен на симулациите няма на какво друго да разчитам да ми покаже проблемите. Демек болшинството подводни камъни от живия живот не са ми известни. На симулациите не изглежда толкоз тясно. Преди 125-те го подкарах на 100. Между двете честоти се налага малка корекция във Verilog-а за да докарам клоците по средата на данните, и общо взето само това + закъснението ми е било заигравката след като тръгна.

На ISE-то се наложи аз да му казвам къде да са регистрите на шината за данни между FPGA-то и SRAM-а.



Тук вече не помня дали бърниках. Сигурно съм де, ама не помня.

Спарки, нека го продължим на по бира. Смесица от дизайн и статистика/MTBF е.