Услышал отзыв, что, в частности, в Spartan'e 2 в одном случае из 10 прошивка не "вставала" в микросхему.

Хочу услышать реальные случаи или мнение по данному вопросу.

ИМХО - В SRAM-микросхемах ведь есть внутренние супервизоры которые, при неудачной конфигурации ДОЛЖНЫ снова инициировать этот процесс.
А то получается - плата не включилась и и все?

При загрузке прошивки в кристалл производится проверка контрольной суммы прошивки. Если она не совпала, то сигнал об успешной конфигурации не появится. Это действительно так, проверял.

Другой причиной сбоя может быть внутренняя неисправность самой ПЛИС. Но тут уж ничего не поделаешь. Могу лишь сказать, что на моей практике такого не случалось для кристаллов, над которыми не издевались повышенным напряжением питания и другими способами.

Скорее всего у Вас проблеммы с согласованием DIN,CCLK, эти буфера достаточно быстрые, а цепи наверняка получились не короткими. Попробуйте поставить демфирующие резюки.

Читал в апнотах у Ксилинкса, что потребяемый стартовый ток достаточно сильно зависит от окружающей температуры. Причем чем ниже температура, тем этот ток больше. В разы. То есть есть смыл обвешивать кристалл как керамическими конденсаторами, так и простыми алюминиевыми электролитами.

Это еще не весь ужас. Вот DCM по какой-либо причине вышел из синхронизации - и трындец, его надо ресетить. А если вы ресет не предусмотрели, то дизайн остановился. А предусмотреть ресет непросто. Нужен отдельный дополнительный клок. И что-то типа супервизора. У меня DCM останавливался в произвольный момент времени по причине плохой формы опорного клока - там ступенька посредине фронта была. Это разводчик в штангу дал. Ему было сказано Звездой развести клок на два чипа, а он их последовательно daisy chain сделал. Вот отражение и портило фронт тому чипу, что посредине.

И что Ку? Или снова перегружает


Тут так было загрузка из флешки - 1 из 10 может так повиснуть при загрузке, что не реагирует даже не ресет, а если переконектить питание то снова загружается нормально. Я так понимаю, что нужен сепервизор питания. SRAM-технология к этому более критична, чем скажем Flash?




Вопрос более общий: не встала прошивка - это статистическая случайноть??? Или все таки что-то в схеме не по шаблону?

Для начала, у Вас DONE становится активным ("1") после включения питания?

У меня конфигурацию ПЛИС выполняет процессор. У него логика правильная - не получилось, пробуем снова. Но на моей практике повторов не было, всегда получалось с первого раза.

Что же касается варианта с внешней памятью конфигурации, то тут будет Ку, если не поставить дополнительной схемы, которая заново инициирует процесс конфигурации. Но и с конфигурационной памятью у меня ни разу сбоя конфигурации не было.



Схема Power-On Reset есть внутри самой ПЛИС. Она обеспечивать корректность выполнения процедуры конфигурации при включении. Если получается что в 1 из 10 случаев не проходит конфигурация - нужно искать причины этой проблемы, а не увешивать схему супервизорами. Это порочная практика, т.к. причины этих проблем могут вылезти позже, в самом неожиданном месте.



Это случайность. Но вероятность появления этой случайности определяется схемой. В случае, если в схеме допущены ошибки, вероятность появления ошибки конфигурации резко возрастает. Почитайте Application Notes, касающиеся процесса конфигурации. Там все подробно расписано. И уделите отдельное внимание схеме питания ПЛИС, т.к. от нее зависит очень многое (в частности, для некоторых кристаллов рекомендуется определенная последовательность подачи питающих напряжений, отклонение от которой может привести к сбоям и повышенному току потребления во время старта).

Это не у меня было, я с таким не сталкивался ниразу. Упоминули, что такое случалось - стало интересно, может и у других были такие случаи И как это объясняют производители.

Про DONE не знаю - но когда случалось микросхема не на что не реагировала пока не снимешь питание.

После засовывания конфигурационной последовательности в FPGA, сравнивается рассчитанная и принятая контрольные суммы, если они не совпадают, падает INIT (ест-но DONE тоже не поднимается). В случае, когда все ОК, поднимается DONE, после полной инициализации. Т.е. кроме Вас, в случае ошибки, никто не рестартанет загрузку.
Я не встрнчался с тем чтоб загружалось "через раз", или грузится или нет, первое происходило довольно часто пока не вбил себе привычку согласовывать DIN и CCLC.
Сейчас имею один глюк, нет пока времени разбираться в чем дело, на плате со Spartan3. После выключения питания, нужно выдержать некоторое время, прежде чем сноа включать, иначе не загрузится. Это как-то связано с медленным падением напряжений питания, их очередности.

Я счетчик ресета сажаю прямо на входной клок, с входа CLKIN. Если очень кумарит - можно через отдельный буфер, но у меня работает и так прекрасно.


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity reset_fpga is
generic(
RST_ACTIVE: std_logic:='0'; -- Active reset level for scheme
RST_CNT_WIDTH: positive:=26 -- DLL reset counter width
-- Xilinx DLLs has different lock times in different modes
-- 26 is appropriate for any mode
-- if the DFS in not in use - 16 can be used instead
-- or smaller values to speed up simulation
-- (the simulation model of the DLL locks very fast)
);
port(
CLKIN: in std_logic; -- should be the clock BEFORE DLL
LOCKED: in std_logic; -- LOCKED output of the DLL
DLL_RST: out std_logic; -- DLL reset, active HIGH, SYNC to CLKIN
RST: out std_logic -- scheme reset, active LOW, ASYNC
);
end reset_fpga;

architecture rtl of reset_fpga is
signal CNT: std_logic_vector(RST_CNT_WIDTH-1 downto 0):=(others=>'0');
constant CNTZERO: std_logic_vector(RST_CNT_WIDTH-1 downto 4):=(others=>'0');
signal LOCKEDL: std_logic;
signal LOCKEDLPRE: std_logic;
signal DLL_RSTOUT: std_logic;
attribute ASYNC_REG : string;
attribute ASYNC_REG of LOCKEDLPRE: signal is "TRUE";
begin

process(CLKIN)
begin
if(rising_edge(CLKIN))then
LOCKEDLPRE<=LOCKED;
LOCKEDL<=LOCKEDLPRE;
CNT<=CNT+1;
if(CNT(RST_CNT_WIDTH-1 downto 4)=CNTZERO and LOCKEDL='0') then
DLL_RSTOUT<='1';
else
DLL_RSTOUT<='0';
end if;
end if;
end process;

DLL_RST<=DLL_RSTOUT;

process(LOCKEDL,DLL_RSTOUT)
begin
if(LOCKED='1' and DLL_RSTOUT='0') then
RST<=not RST_ACTIVE;
else
RST<=RST_ACTIVE;
end if;
end process;

end rtl;


Если бы сделали звездой - было бы IMHO еще хуже. Делаю последовательно, смотрю в HyperLynx, 100МГц проблем пока не было. Резисторов туда, ежели чего. Но еще лучше клок завести в FPGA, а с него после DLL уже вывести сколько надо повторенных клоков.

На FLEX10k было так, если щупом осциллографа (с делителем) ткнуться в DCLK (а может DATA, не помню), то загрузка не происходила, а так все нормально. Видимо вносимая осциллографом емкость все портила.

За код супервизора спасибо, пощупаю.

А вот по второму вопросу вы не правы. Хайперлинкс у меня тоже есть. А еще у меня есть осциллограф Tek TDS5104B. И очень хорошо видна форма сигналов.

Я ж не все сказал. У меня один Ксилинкс на основе клока от генератора с помощью DLL генерирует выходной клок для еще ДВУХ Ксилинксов, которые должны работать абсолютно синхронно. Вот поэтому и была Звезда, точнее вилка с короткой ручкой и двумя зубцами. а разводчик сделал последовательно. Да и фиг бы с ним, пол наносекунды разницы там погоды не делало. Но из-за ступеньки на средине фронта того ксилинкса что оказался посредине его DLL после 10-30 секунд работы входил в ступор.

А что мешало вывести клок для этих двух на разные пины первой микросхемы и развести их как точка-точка? Только боязнь появления скоса между ними?

Да ничего не мешало. Но этот сигнал идет также на обратную связь для DCM. И получится, что один выход привязан по фазе, а второй - нет. Разбаланс нагрузки (один обратку тянет, а второй - нет). Ну и тянуть до ведомых чипов по-любому два провода.
А самое главное, плата-то уже изготовлена, пришлось выходить из ситуации подручными средствами (бросать клок двумя одинаковыми проводками на тестовые пятачки, благо они были предусмотрены и шли на Global Clock Input на каждом ведомом чипе).