Я внедряю контроллер DSO в FPGA, и у меня возникают проблемы со слишком большим количеством нарушений времени удержания (пока лучший результат P&R был 3 ошибки времени удержания где-то около -2 нс).
Суть моей проблемы в том, что у меня есть буфер FIFO с вводом от дециматора выборки АЦП, а затем вывод на синхронный FT245 (60 МГц). Прореживатель входного сигнала может быть настроен на прореживание в степени 2 (например, 1, 2, 4, 8, 16 ...), что также делит тактовую частоту выборок АЦП (150 МГц).
И теперь мой подход заключается в том, что я предоставляю разделенную (или прямую, если коэффициент прореживания 0) тактовую частоту для буфера, когда я захватываю данные, а затем я переключаюсь на подачу тактовой частоты 60 МГц от FT245, когда я отправляю образцы на ПК. В симуляции он работает отлично, но проблема заключается в размещении и маршруте, этот маршрутизатор выдаст эту ошибку:
Route:466 - Unusually high hold time violation detected among 226 connections. The top 20 such instances are printed below. The
router will continue and try to fix it
Затем он сжимается в течение 10-15 минут, пока не выдаст мне отчет о времени, информирующий меня, что все временные ограничения настройки были соблюдены и что есть 3 нарушения времени удержания для часов 150 МГц (часы 60 МГц в порядке).
Я читал, что проблема может заключаться в использовании стробируемых часов, что FPGA не может правильно распределять часы, но я попытался использовать подход вместо стробирующих часов FIFO, я подключил часы 150 МГц непосредственно к FIFO, и я стробировал данные в FIFO с помощью dataReady (это фактически закончился тем же сигналом, что и ранее стробированные часы), тогда у меня было гораздо больше (50-60) нарушений времени удержания, чем сейчас.
Есть ли какой-нибудь известный хороший подход для многочастотного FIFO? Не два (их много даже в примерах в Xilinx ISE). Или идея прореживания отсчетов АЦП в ПЛИС не годится?
Целевая ПЛИС - Spartan 6 LX25, класс скорости -2 (к сожалению, мне не удалось достать оценку скорости -3).
Вот пример слабости, которую он мне дает:
Slack (hold path): -2.031ns (requirement - (clock path skew + uncertainty - data path))
Source: decimator_clock_divisor/decimationRatio_0 (FF)
Destination: trigger_analog1/previousValue_2 (FF)
Упомянутый источник - это сигнал (и все нарушения, которые он мне дает), который не меняется очень часто, он фактически контролируется графическим интерфейсом, поэтому я не знаю, как там могло быть нарушение времени удержания. Это путь от соотношения дециматора к буферу триггера (или моему буферу FIFO при другом нарушении).
По сути, мой вопрос в том, стоит ли мне вообще заботиться об этих нарушениях?
Потому что после изменения коэффициента прореживания могут пройти тысячи тактов, прежде чем я фактически начну использовать результаты прореживания в триггере.
Я знаю, что маршрутизатор не может знать, как часто я меняю асинхронный сигнал (он асинхронный, поскольку я устанавливаю его из области тактовой частоты 60 МГц) и сколько времени мне потребуется, чтобы использовать результат какого-либо модуля. Проблема в том, что я не знаю, когда он показывает мне эти 3 нарушения после завершения PAR, окончательно ли, что нет других нарушений, которые были просто затенены этими 3 нарушениями?
Можно ли опубликовать симуляцию PAR, чтобы проверить, будет ли она работать на борту? Я бы попробовал его на плате, но мне нужно подождать 2 недели до пайки BGA, и у меня осталось всего 4 недели, чтобы закончить диссертацию, поэтому я хочу быть уверен, что мой дизайн будет работать.
