vea

О, тема развивается :) `define __USE_DEBUG__ работает вполне хорошо (проверено на нескольких небольших модулях), спасибо! С `define проще, на мой взгляд. Вот это не понял, не могли бы Вы чуть подробнее объяснить.

Спасибо! Буду проверять в квартусе.

Иногда приходится перепроверять\изменять функционал уже однажды отлаженных модулей. После этой первой отладки ненужные для работы (тестовые) порты были закомментированы\удалены, как и тестовые сообщения и т.п. Соответственно теперь нужно все это восстанавливать. В то же время в "обычных" языках программирования есть возможность включать режим отладки (debug) при компиляции, указав параметр. То есть там модули 2в1: в тексте остается весь код для отладки, а использовать его или нет - решается по ходу компиляции. Можно ли такое же сделать на языках описания аппаратуры? То есть (псевдокод): module foo #parameter DEBUG=0 ( input clk, input rst_n, output [31:0] odata, if (DEBUG) begin output [31:0] test_counter1; end ) if (DEBUG) begin assign test_counter1=counter1; end ... Если это невозможно, то как быть? Хотелось бы поменьше механической работы.

В статье Asynchronous & Synchronous ResetDesign Techniques - Part Deux, пункт 7.2 так и говорится: "[...] examine the transistor-level version of the model [...] the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]" (речь о втором регистре в каскаде, о третьем-четвёртом даже не говорится). Правда, схемы в этой статье не такие уж и простые.

Понятно, спасибо. Чтобы правильно подключить, достаточно ли ALTGX Transceiver Setup Guide и AN 553: Debugging Transceivers? Что-то еще нужно знать?

Возможно ли увидеть в SignalTap реально отправляемые данные (tx_dataout)? Сбросы, судя по картинке, отрабатывают нормально: Но при компиляции с добавленным в SignalTap tx_dataout возникает ошибка: Error (15761): Output port dataout of the GXB transmitter channel PMA atom "transmit_pma0" must be connected to an output pin хотя он подключен к выделенному для передатчика пину. Я бы еще понял, если бы ошибка была связана с низкой частотой тактовой в SignalTap (это еще один неясный момент, гигагерцевых тактовых же нет). В AN 553: Debugging Transceivers про SignalTap всего полстраницы, и то про приемник. Хочется убедится не в симуляторе, что на приемник уходят реальные данные.

В Q14.1 такой путаницы нет, все отображается правильно.

При отладке в SignalTap: В списке сигналов клок идет первым, но явно третий в полученных данных. Причем перепутан не только он - user_reset на месте pll_locked. Это исправимо?

Спасибо за развернутые объяснения. Пока все-таки буду перестраховываться и пропускать сброс через каскад - меньше шансов наделать ошибок.

Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)?

Интересно. И здесь как раз 4 регистра - с указанием, что их число определяет минимальную длину сброса (и только?). Но основная идея - нет особой необходимости в глобальном сбросе. Насколько это правильно? В pdf есть ссылка на "Get your Priorities Right – Make your Design Up to 50% Smaller" - там в том числе и про сброс, но с привязкой к конкретной реализацией в кристаллах Xilinx. Насколько это соответсnвует Альтеровским кристаллам?

Спасибо. Вот так? Получается, снятие сброса не будет "одновременным" для разных тактовых? Будет нарастающая задержка, которую надо компенсировать? Это обязательно? Хотелось бы единообразия.

Есть каскад из двух регистров для внешнего сброса (обычная схема, как в справке квартуса здесь). Этот каскад тактируется clk1 и (соответственно со схемой) сбрасывать им можно регистры, которые тактируеются также clk1. Как правильно сбрасывать регистры, которые используют clk2, clk3 и т.д.? Для каждого clkX делать отдельный каскад?

Спасибо, с наступающим! :santa2:

Спасибо. Это действительно clock передатчика, кроме него есть еще tx_dataout. На него тоже Error. Стандарт на SV смотреть?