PDP-11 на FPGA

[svofski]

Можно я попробую парой строк кода проиллюстрировать тезисы AlexG про распределение клоков?

Было годно для симуляции, но катастрофически и непредсказуемо рушится при синтезе, как только дизайн становится сложнее :

reg [3:0] clock_div;
always @(posedge mclk) clock_div <= clock_div + 1;
wire evil_derived_clock_div16 = clock_div[3];
wire evil_derived_clock_div8 = clock_div[2];

.. 

always @(posedge evil_derived_clock_div16) begin
  // то, что будет тактировано этим клоком разойдется по фазе с mclk и с evil_derived_clock_div8
end

always @(posedge evil_derived_clock_div8) begin
  // то, что будет тактировано этим клоком разойдется по фазе с mclk и с evil_derived_clock_div16
end

Стало хорошо, годно для синтеза и устойчиво к попаданию мюонов потому, что теперь все регистры тактируется одним клоком. При синтезе достаточно только убедиться, что сигналы clock enable стабилизируются к приходу очередного фронта mclk. Это и человеку просто сделать, и Квартусу понятно, что надо оптимизировать.

reg [3:0] clock_div;
always @(posedge mclk) clock_div <= clock_div + 1;
wire clock_enable_div16 = ~|clock_div;     // держится один такт пока все разряды == 0
wire clock_enable_div8   = ~|clock_div[2:0]; // держится один такт, пока 0000 или 1000
...
always @(posedge mclk) 
if (clock_enable_div16) begin
  // все записи во все регистры тактируются одним клоком mclk, но разрешены только раз за 16 тактов
end

always @(posedge mclk)
if (clock_enable_div8) begin
  // все записи во все регистры татируются одним клоком mclk, но разрешены только раз за 8 тактов
end

[AlexG]

Йа йа натюрлих. Плисе плохеет, если обычный сигнал превращать в тактовый. см. первый пример.
на десерт:
https://electronix.ru/forum/index.php?showtopic=20307

[Hunta]

Нуу.. насколько я себе представляю, evil_derived_clock_div16 и clock_enable_div16 (как и вторая пара) ведут себя по разному, точнее, ээ.. скважность разная - термин правильно вспомнил?

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

_______________----------------________________----
-______________________________--__________________

Если я правильно понял мысль - тактовый клок и синтезируемый клок не должны одновременно меняться по разному - то есть если тактовый идёт из 0 в 1, то синтезируемый или стоит или тоже идёт из 0 в 1 и наоборот - да?
Кстати, насколько я понял код на Verilog (PDP-2011 на VHDL) - есть тоже момент, когда они в противофазе.
Поясняю, почему так понял (начало картинки - mclk = 0, reg = 15, ++ - переход в фазе, !! - переход в противофазе)

++!!
_-_-_

-____
_--__

Или я опять не допонял?

- - - Добавлено - - -

Плисе плохеет, если обычный сигнал превращать в тактовый

Ну, автор PDP-2011 этим несколько страдает....

на десерт:
https://electronix.ru/forum/index.php?showtopic=20307

Аха, спасибо.

- - - Добавлено - - -

Плисе плохеет

Чёт мне кажется, что не ПЛИС-е... Кстати, не ПЛИС-е, а ППВМ-у Так вот, не ППВМ (ака FPGA), а синтезатору

[svofski]

Hunta, я чего-то плохо паршу эти картинки, но кажется правильно. Суть в том, что clock enable держится только один такт из многих (один из 16, например, или один из 100 миллионов, если мы из 50МГц получаем 0.5Гц). Все остальные такты просто проносятся мимо. Эффективная тактовая и периодичность получаются те же самые, что и при деленном клоке.

(Это к тому же удобный механизм, если надо разнести несколько устройств во времени. Например, первая фаза на div == 0, вторая фаза на div == 1 итд).

VHDL или Verilog значения в этом вопросе не имеет, они транслируются в одно и то же. Но вот если автор оригинального проекта страдал использованием деленных клоков, то это проблема, с которой надо разбираться. Все это почти механически исправляется добавлением "if (ce)" во все тактируемые процессы.

- - - Добавлено - - -

Еще добавлю, потому что жто очевидно, но может быть не сразу бросается в глаза. Если clk_enable ошибочно сделать не "div == 0", а просто использовать clk_div[3], то получится эффективное деление всего лишь на 2. Будет работать пачка из 8 mclk, затем 8 пропусков итд.

Если в качестве условия использовать LFSR вместо константы, то можно сделать spread spectrum clock для уменьшения помех и требовательности к энергопотреблению. Что в проекте PDP-11 на FPGA, уверен, очень востребовано =)

[Hunta]

Hunta, я чего-то плохо паршу эти картинки

Делается просто - копируешь эти строчки в notepad, а в notepad-е ставишь шрифт покрупнее
Вот нарисовать их было сложнее - запарился считать такты

VHDL или Verilog значения в этом вопросе не имеет

Это я знаю, я больше про то, что Verilog мне надо было ещё въехать - в отличи от VHDL, который уже более менее неплохо читаю

Если clk_enable ошибочно сделать не "div == 0", а просто использовать clk_div[3], то получится эффективное деление всего лишь на 2

Не совсем понял, но (как понял) у нас будет восемь клоков держаться флаг в 1 и в это время схема будет реагировать на все mclk, а потом (флаг в 0) - восемь клоков тупо ждать, так что эффективное деление будет да - на 2.

Если в качестве условия использовать LFSR вместо константы

За LFSR пришлось лезть в инет (такое сокращение было не знакомо), но думаю, это может пригодиться после того, как я всё таки добьюсь цели номер 2 (работа SDRAM) и начну выжимать из железки все соки

[svofski]

у нас будет восемь клоков держаться флаг в 1 и в это время схема будет реагировать на все mclk, а потом (флаг в 0) - восемь клоков тупо ждать, так что эффективное деление будет да - на 2

Все правильно.

Вот нарисовать их было сложнее - запарился считать такты

Честно говоря, при всей полезности умственной гимнастики, для таких вещей все-таки стоит разобраться с симуляцией. Сделать маленький набросок, где без особой драмы можно будет написать ту или иную конструкцию и быстро посмотреть, что из нее получается.

[Advertiser]

[Hunta]

при всей полезности умственной гимнастики

стоит разобраться с симуляцией

Из опыта - это приводит к тому (по крайне мере в программировании), что начинаешь писать НЕБРЕЖНО (а чё, под дебаггером проверим и сделаем как надо), что в конечном итоге приводит к большему времени на написание кода. Да, периодически возникает мысля - надо бы с симулятором разобраться, но пока хватало тупого рассматривания кода и периодически - Signal Tap-а

Вопрос. Если скважность у клока, скажем 50 МГц, два - то понятно, сколько времени будет держаться высокий уровень и что на него успеют среагировать все, кто надо Но если у него высокий уровень будет держаться не 20 наносекунд, а 6,666666 нс (если мы его получили из 300 МГц) - успеют ли на него среагировать все, кто надо? Поэтому или придётся понижать тактовую или добавлять внутренний триггер, который будет держаться дольше, да? Или есть альтернативы?

И вроде как в PLL можно задать скважность, да? То есть если мы делаем на PLL, то проблему предыдущего вопроса снимаем? И она актуально только на ручных клоках?

[svofski]

Отвечаю на вопрос, как я его понял. При клоке 300 МГц и clock enable равномерно пропускающим один клок из 6, мы получаем эффективную тактовую частоту 50МГц. Если вся логика завязана на один и тот же фронт клока, вся комбинаторика должна устаканиваться за один период 50 МГц, или 20нс.

Cкважность собственно клока имеет значение только при передаче сигналов от процессов на posedge к процессам на negedge, или наоборот. При записи на negedge вся комбинаторика должна будет успеть успокоиться со времени posedge и это время будет зависеть от скважности клока.

[Hunta]

Э.. не совсем то имел ввиду.. Что то типа

  base_addr_match  <= '1' when (base_addr(21 downto 15) = FromBus.Addr(21 downto 15)) and (clk = '1') else '0';
  ...
  process(clk)
  begin
    if rising_edge(clk) then
      if (base_addr_match = '1') then
         ...

base_addr_match будет в 1, пока совпадает адрес устройства с адресом на шине и высокий уровень clk

Логика в процесс должна успеть отработать, пока base_addr_match будет в 1.

Одно дело, когда base_addr_match будет в 1 - 20 нс, другое дело, когда - 6.666 нс. Технически, во втором случае внутренности process-а могут не успеть среагировать. Я понимаю, что пример кривой и так делать не надо, но это попытка объяснить

- - - Добавлено - - -

комбинаторика должна устаканиваться за один период 50 МГц, или 20нс.

То есть у них есть время до следующего клока 1?

- - - Добавлено - - -

Попробовал переделать клок процессора До переделки синтезировалось от 25 до 35 минут, после переделки - чувствую, минут 55 будет пахать

- - - Добавлено - - -

Ню... на частоте 50 МГц не запустилось, на частоте 0.5 Гц начало кода в ПЗУ начало отрабатывать, а потом встало. Скорее всего по вектору 4
Щас посмотрим, где оно сломалось

- - - Добавлено - - -

Пока выбирало команды из ПЗУ, всё нормально. Потом полезло через регистры в ПЗУ и в какой то момент - УПС...

- - - Добавлено - - -

Вырубил синтез ОЗУ (у меня впечатление, что иногда ОЗУ откликается, когда не надо), посмотрим, что получится...

[svofski]

base_addr_match будет в 1, пока совпадает адрес устройства с адресом на шине и высокий уровень clk

base_addr_match <= '1' when (base_addr(21 downto 15) = FromBus.Addr(21 downto 15)) and (clk = '1') else '0';

Так делать не надо, я даже подозреваю, что где-то в варнингах Квартуса есть на этот счет замечание. Дело в том, что в этом случае условие if (base_addr_match = '1') в процессе rising_edge(clk) никогда не выполнится. Вот почему: clk становится входом комбинаторной схемы, которая имеет задержку. В то же время выход этой схемы является входом enable регистров, которые должны записываться в процессе rising_edge(clk). clk приходит всюду напрямую, равномерно, с минимальным разбросом. Таким образом, в момент rising_edge(clk) на проводе base_addr_match всегда будет установившееся значение выражения при clk = 0.

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