Цифровая археология: 1801 и все-все-все

Цитата:

---

Сообщение от gid

1) логика только булева, состояний x и z нет.

---

Да, правильно, и эти состояния у меня в моделях не используются, только 'x' в сравнении с паттерном иногда, но это легко реализовать через ^/&.

Цитата:

---

Сообщение от gid

Особенно интересуют логические операции, и порядок выполнения.

---

Общая evel логика такая:
- назначаем переданные входные переменные
- отрабатываем все операторы assign во всем модуле таймера, вычисляем внутренние и выходные переменные. Бывает еще оператор always эквивалентный assign, но я такие не использую, поэтому не паримся
- смотрим, есть ли событие клока (clk или сброс)
- если есть:
- отрабатываем все блоки always с этим событием
- снова обрабатываем assing (переменные же сменились)
- возврашаем выходные переменные

Я вроде вот этой второй отработки блока assign-ов после сработки событий клока в Вашем коде не увидел.

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

Поэтому я бы методы назначения параметров и методы обработки событий (клоки и сбросы) разнес бы. Тогда модули сами снапшотили бы свое состояние при обработке событий, и можно было бы обработать события на всех модулях отдельными методами, а потом уже по результатам выполнить все assign-ы и назначения именившихся входных параметров.

Для assign-ов ситуация противоположная, надо их вычислять каждый раз когда меняется хоть одна использованная в них переменная, назависимо ни от каких событий. Поэтому - для вычисления в блоках assign порядок важен, чтобы не вычислять одно и то же по нескольку раз. В принципе, на порядок можно забить, поместить их всех в цикл в произвольном порядке и крутить до тех пор пока выходное состояние не "устаканится", но как бы не очень красивое решение. Но в случае с несколькими модулями (ведь эти assign-ы могут находится в разных модулях), если нельзя влезать внутрь - пригодилось бы.

Что-то как-то слишком сложно и запутанно.
Т.е. получается, что возвращаемые значения берутся из снапшота предыдущего состояния, до вычисления блоков always. Либо после assign, но до вычисления блоков always? А результат вычислений блоков always станет выходным значением при следующем вызове?
Ещё такой момент.

Код:

---

assign  tve_zero = (tve_count == 16'h0000) & ~tve_csr[1];
assign  tve_back = tve_csr[4] & tve_csr[1] & tve_spclk & tve_tclk4;
assign  tve_load = tve_zero & tve_tclk4 & ~tve_csr[1];

---

В assign tve_load используется какое значение tve_zero, которое вычислено в вышеидущем assign tve_zero, или предыдущее его значение, до этого assignа?

Цитата:

---

Сообщение от Vslav

Я вроде вот этой второй отработки блока assign-ов после сработки событий клока в Вашем коде не увидел.

---

Ещё б. Я же этого не знал.

Цитата:

---

Сообщение от Vslav

Еще момент, вероятно, Вы знаете

---

Именно что не знаю. И всех тонкостей, описанных в посте, не знал.

Цитата:

---

Сообщение от Vslav

Поэтому я бы методы назначения параметров и методы обработки событий (клоки и сбросы) разнес бы

---

Очень не помешал бы пример реализации. Я смотрел код, который строит Verilator, там всё очень и очень сложно и похоже на то, что вы описываете. Но уж очень сложный код там строится, мне почему то кажется, что можно это сделать проще, тем более если подойти к модулям индивидуально.

Цитата:

---

Сообщение от Vslav

поместить их всех в цикл в произвольном порядке и крутить до тех пор пока выходное состояние не "устаканится"

---

А если assignы взаимно модифицируют значения друг-друга, то мы зациклимся навсегда, или это признак неправильно построенной схемы?
Вторая итерация Вложение 51688

Цитата:

---

Сообщение от gid

Что-то как-то слишком сложно и запутанно.

---

Увы, я не очень хороший объясняльщик :| Не стесняйтесь, задавайте уточняющие вопросы, попробую ответить.

Цитата:

---

Сообщение от gid

Т.е. получается, что возвращаемые значения берутся из снапшота предыдущего состояния, до вычисления блоков always. Либо после assign, но до вычисления блоков always?

---

Это зависит от того чем является возвращаемое значение - assign или always. Assign - это логическая комбинационная функция. Если assign - то надо вернуть результат немедленно, если always - то из снапшота.

Я старался писать в такой парадигме - assign это логика, always - триггеры. Вроде нигде этот принцип не нарушал (там ниже будет особый случай always - асинхронный сброс).

Код:

---

assign y = ~(x1 & x2);

---

Это аналог ЛA3. Никакой памяти предыдущего состояния. Есть на входе набор переменных - на выходе получаем однозначные результаты. Но таких assign-ов несколько, часть выходов одних может являться входами для других - это микросхемки ЛА3 соединили последовательно.

Код:

---

always @(posedge clk) q<= d;

---

Это аналог триггера, типа ТМ2, например.

Цитата:

---

Сообщение от gid

А результат вычислений блоков always станет выходным значением при следующем вызове?

---

Можно и сразу, главное не передавать их другим модулям до того как они отработают свои always. То есть - вызывали метод события клока, модуль внутри взял свой снапшот, вычислил все always, вычислил все assign до статического состояния (когда больше в комбинационных функциях ничего не меняется, а замкнутых петель, порождающих генерацию, нет - на них квартус ругался бы), сохранил новое состояние в актуальных переменных, снапшот выбросил в мусорку и пока все - аналогично вызываем события клока для остальных модулей в системе. А потом уже начинаем обрабатывать связи между модулями как assign-ы, сообщая им новые вычисленные состояния других модулей. При этом могут возникнуть события по типу асинхронного сброса (установки вроде нигде в ВМ1 не применял), но такое как комбинационная логика работает - можно (и наиболее просто) обработать как обычный assign.

Цитата:

---

Сообщение от gid

Ещё такой момент.

Код:

---

assign  tve_zero = (tve_count == 16'h0000) & ~tve_csr[1];
assign  tve_back = tve_csr[4] & tve_csr[1] & tve_spclk & tve_tclk4;
assign  tve_load = tve_zero & tve_tclk4 & ~tve_csr[1];

---

В assign tve_load используется какое значение tve_zero, которое вычислено в вышеидущем assign tve_zero, или предыдущее его значение, до этого assignа?

---

Это assign - значит берется вычисленное новое значение. Можно этот блок взять в цикл и крутить его до тех пор пока выходные значения не перестанут меняться - то есть все вычислено окончательно:

Код:

---

do
{
  tve_zero_prev = tve_zero;
  tve_back_prev = tve_back;
  tve_load_prev = tve_load;

  tve_zero = (tve_count == 16'h0000) & ~tve_csr[1];
  tve_back = tve_csr[4] & tve_csr[1] & tve_spclk & tve_tclk4;
  tve_load = tve_zero & tve_tclk4 & ~tve_csr[1];
}
while( (tve_zero_prev != tve_zero)
      ||(tve_back_prev != tve_back)
      ||(tve_load_prev != tve_load));

---

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

Цитата:

---

Сообщение от gid

Очень не помешал бы пример реализации.

---

Хорошо, для начала пример синхронного сдвигового регистра с асинхронным сбросом подойдет? Возьму модуль из одного триггера, соединю модулей несколько в цепочку, и рассмотрим обработку?

Цитата:

---

Сообщение от gid

Я смотрел код, который строит Verilator, там всё очень и очень сложно и похоже на то, что вы описываете. Но уж очень сложный код там строится, мне почему то кажется, что можно это сделать проще, тем более если подойти к модулям индивидуально.

---

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

Цитата:

---

Сообщение от gid

А если assignы взаимно модифицируют значения друг-друга, то мы зациклимся навсегда, или это признак неправильно построенной схемы?

---

Не зациклимся, квартус за такое по голове бьет, поэтому петель обратной связи быть не должно. Вообще, если циклов вычисления assign понадобится больше одного до "устаканивания" - это значит просто что мы неоптимально выбрали порядок их вычисления. На Верилоге порядок значения не имеет, а вот для программного последовательного исполнения - важно.

Цитата:

---

Сообщение от gid

Вторая итерация

---

Да, уже лучше. Такой момент - события reset проще рассматривать как комбинационные, это НЕ тактовый сигнал, это просто такая форма описания асинхронного сброса (через always). То есть, во всех блоках always что я применял, этот сброс работает как асинхронный - если пришел, то выход немедленно обнуляется и удерживается в нуле несмотря на все события. Это как вход R в микросхемке ТМ2. То есть - тактовых в модели ВМ1 всего два события - положительный и отрицательный фронты клока - posedge vm_clk_p и posedge vm_clk_n.

Цитата:

---

Сообщение от Vslav

Можно и сразу, главное не передавать их другим модулям до того как они отработают свои always

---

Ну так для того и вводится класс, с набором своих внутренних переменных, недоступных никому и функцией eval, которая принимает набор входных переменных, изменяет по своему заданному алгоритму внутренние переменные и выдаёт в конце работы результаты. Пока функция не отработает, результат никому доступен не будет.

Цитата:

---

Сообщение от Vslav

Хорошо, для начала пример синхронного сдвигового регистра с асинхронным сбросом подойдет?

---

Ок, лишь бы был нетривиальный случай. А ещё было бы неплохо посмотреть, как assign со временем (assign #5.25 y1 = x1; ) можно реализовать.

Цитата:

---

Сообщение от Vslav

события reset проще рассматривать как комбинационные

---

Т.е. так?

Код:

---

if (tve_reset)
{
        //отрабатываем все блоки always для reset
}
else if (posedge(tve_clk, tve_clk_prev))
{
      //отрабатываем все блоки always для clock
}

---

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

Цитата:

---

Сообщение от gid

Код:

---

if (tve_reset)
{
        //отрабатываем все блоки always для reset
}
else if (posedge(tve_clk, tve_clk_prev))
{
      //отрабатываем все блоки always для clock
}

---

---

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

Цитата:

---

Сообщение от gid

Вот кстати ещё вопрос возник.
В модуле vp_037 есть сотни вызовов других модулей. Предполагается, что все они вызываются одновременно, и выходное значение предыдущего модуля не влияет на это же входное значение последующего, или их можно выполнять последовательно как assignы?

---

Вот как раз в 037 и во многих остальных автосгенерированных моделях ВП1 есть петли обратной связи и моделировать "в лоб" их нельзя. Квартус матерно ругается на петли, синтезирует с "unsafe behaviour", модельсим же такое переваривает и спокойно моделирует, но это уже далеко не примитивный симулятор.

Все автогенерированные модели ВП1 не предназначались для синтеза, только для моделирования. По-хорошему - 037 надо нормально переписать ручками на вменяемом Верилоге, но я думал что в таком виде - с шиной Qbus - оно никому в синтезабельном виде не понадобится. Потому что саму реальную микросхему никому не надо, а в FPGA оно потребует другой шины и другого интерфейса к памяти, то есть от оригинала не останется ничего.

Я думаю, что пока следует на 037 не смотреть вообще, и с эмуляцией времянок типа #5 не заморачиваться, потому что это очень-очень сильно усложнит эмулятор - придется делать полноценную модель с событиями и их диспетчирезацией. К тому же неадаптированная модель 037 потянет за собой модель платы БК и модели динамической памяти 565РУ5/РУ6. В-общем, имеющийся сейчас автосгенерированный 037 - это очень плохой пример для понимания и написания эмулятора.

ИМХО, пока следует сосредоточится на модели процессора и просто подсовывать ему данные по Qbus-у с регулируемой задержкой по RPLY, когда я буду заниматься БК, то перепишу 037 во вменяемый вид, она несложная, займет немного кода и ее будет гораздо легче эмулировать чем макароны из Базовых Функцикональных Ячеек 1801ВП1.

Цитата:

---

Сообщение от Vslav

Я думаю, что пока следует на 037 не смотреть вообще

---

Ну тогда аналогичный вопрос про vm1_qbus.v, вызов внутри модулей vm1_timer, vm1_pli, vm1_plm обрабатывается по принципу как assign или тоже им на вход нужен снапшот текущего состояния данных, как для always?

Цитата:

---

Сообщение от gid

Ну тогда аналогичный вопрос про vm1_qbus.v, вызов внутри модулей vm1_timer, vm1_pli, vm1_plm обрабатывается по принципу как assign или тоже им на вход нужен снапшот текущего состояния данных, как для always?

---

Зависит от того что внутри модуля и чем формируется выходной сигнал - ЛА3 или ТМ2. Общая картинка такая - есть у нас топовый проект на верилоге, скажем, что это плата, на ней стоят ЛА3 (assign) и ТM2 (always) - внутренние операторы, и есть какие-то еще именованные модули. Вот эти модули можно рассматривать как отдельные более сложные микросхемы/платы внутри у которых тоже ЛА3 и ТМ2. В итоге эмулятор должен докопаться до ЛА3/ТМ2 которые стоят на самом нижнем уровне, т.e. сосбственно до неделимых assign/always, независимо сколько оберток-модулей над ними наворочено.

Непонятно. Значит зайдём с другого бока.
Внутри модуля vm1_qbus вызывается
vm1_pli pli_matrix(.rq(rq), .sp(pli)); и vm1_plm plm_matrix(.ir(ir), .mr(ma), .sp(plx));
и ещё vm1_timer timer(много параметров);
Первые два модуля тривиальны, там внутри только assignы, и их можно рассматривать как обычные функции y=f(x), выдающие мгновенное текущее выходное значение, в зависимости от входного значения, vm1_timer чуть посложнее. А среди входных значений для всех них есть регистры, которые модифицируются внутри always.
Так вот, какое входное значение для них должно быть? То же, что и для блоков always, т.е. снапшот состояния перед выполнением всех always или после выполнения или в середине выполнения, там где вызов по коду встретился?
И когда можно выполнять вызов vm1_pli, vm1_plm и vm1_timer , вместе со всеми assignами для vm1_qbus или вместе со всеми alwaysами?
Когда мы пишем программу на обычном Си, мы не можем заставить все функции выполняться одновременно, для этого есть другие языки и средства, поэтому нужно расписать что за чем последовательно выполняется.

И ещё такой вопрос. Как я понимаю, assignы назначают значения только переменным типа wire, а внутри always модифицируются переменные только типа reg или есть исключения?
И имеет смысл снапшотить только те переменные, которые сами модифицируются внутри always. А то в vm1_qbus переменных чуть больше чем дофига, и надо как-то оптимизировать процесс снапшотинья.

Цитата:

---

Сообщение от gid

, выдающие мгновенное текущее выходное значение, в зависимости от входного значения, vm1_timer чуть посложнее. А среди входных значений для всех них есть регистры, которые модифицируются внутри always.
Так вот, какое входное значение для них должно быть?
То же, что и для блоков always, т.е. снапшот состояния перед выполнением всех always или после выполнения или в середине выполнения, там где вызов по коду встретился?

---

Аргументы должны делиться не по тому КОМУ они поступают, а по тому ЧТО является их источником. Если источником является сигнал, назначаемый в always, то это триггер ТМ2, он на выход выдает значение из снапшота пока вся схема не отработает событие клока. Если источник assign - то это ЛА3, надо использовать текущее значение. Если assign на входе имеет только аргументы с триггеров, то и результат его будет фактически из снапшота. Если assign использует еще какие внешние сигналы (допустим внешние входы процессора), то результат будет меняться мгновенно при измении этих входов.

Цитата:

---

Сообщение от gid

И когда можно выполнять вызов vm1_pli, vm1_plm и vm1_timer , вместе со всеми assignами для vm1_qbus или вместе со всеми alwaysами?

---

assign-ы модулей выполнять вместе со всеми assign-ами
always-ы модулей выполнять вместе со всеми always-ами

Вот есть многоплатная/многомодульная система, все равно на какой плате находится ЛА3 - она работает точно так же как и ЛА3 на других платах. Или ТМ2 - все равно где он находится, он будет работать синхронно с другими ТМ2 на других платах, если у них тактовая общая. Так и тут - все равно где, в каком модуле или файле находится assign - он работает параллельно со всеми остальными assign-ами в проекте. И always-ы - точно так же.

Цитата:

---

Сообщение от gid

средства, поэтому нужно расписать что за чем последовательно выполняется.

---

Для комбинационных схем без петель обратной связи нет разницы в порядке выполнения (если будем крутить цикл до "устаканивания", а для триггеров мы вводим снапшот, чтобы нивелировать последовательное вычисление. То есть, есть массиыв триггеров, на вход им приходят значения, и мы берем триггеры из этого массива и вычисяем по одному, а результаты заносим в другой массив, чтобы не ранее вычисленные триггеры не мешали вычислять оставшиеся.

Я предлагаю упростить еще представление таким образом. В блоках always оставить только присвоения триггерам. А выражения представить как функции assign. Пример, было:

Код:

---

always @(posedge vm_clk_n)
begin
        plm_ena <= ~sop_out[0] & (mjres | ustb1_h | ~alu_busy_rp) & ~qbus_nrdy;
end

---

Стало:

Код:

---

assign plm_ena_fc = ~sop_out[0] & (mjres | ustb1_h | ~alu_busy_rp) & ~qbus_nrdy;

always @(posedge vm_clk_n)
begin
        plm_ena <= plm_ena_fc;
end

---

Абсолютно весь проект можно свести к парам "комбинационная функция-триггер":
assign v1 = f1(x1 ... xN, t1 ... tM)
always @clock t1 <= v1;

В исходном проекте функция f1 может быть "размазана" по нескольким модулям, так же как триггеры tn могут находится в разных модулях (они не "размазываются", входят в модуль целиком). Я много где в таком виде писал, суффикс "_fc" означает входная функция триггера срабатывающего по falling clock, а "_rc" - по raising clock.

Сначала вычисляем все комбинационные функции ("ЛА3"), включая асинхронные сбросы триггеров. А потом просто переписываем вычисленные значения в триггеры ("ТМ2") для которых имеет место событие клок. Потом можно снова вычислить комбинационные функции по новым значениям триггеров, можно только для тех которые формируют выходные сигналы для провышения скорости. В этом случае роль снапшота играет массив "вычисленные значения функций".

Цитата:

---

Сообщение от gid

И ещё такой вопрос. Как я понимаю, assignы назначают значения только переменным типа wire, а внутри always модифицируются переменные только типа reg или есть исключения?

---

Да, исключений не бывает, в моем проекте ВМ1 так точно.

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

Цитата:

---

Сообщение от Vslav

assign-ы модулей выполнять вместе со всеми assign-ами
always-ы модулей выполнять вместе со всеми always-ами

---

т.е. следуя этой логике, vm1_pli pli_matrix(.rq(rq), .sp(pli)); нужно внутри модуля vm1_qbus развернуть как include и все его assignы выполнять как assignы модуля vm1_qbus и не вызывать его как внешнюю функцию. Там и без того получается описание функции длиной с рулон обоев, надо как-то упрощать, разбивать на подфункции.

Цитата:

---

Сообщение от Vslav

Для комбинационных схем без петель обратной связи нет разницы в порядке выполнения

---

А для программы есть. Программ - это последовательное исполнение инструкций одна за другой. Поэтому важен порядок правильного описания последовательности действий. Даже если все действия должны выполняться параллельно одновременно, при алгоритмическом описании, их выполнение расписывается последовательно для определённого кванта времени. Поэтому хочешь-не хочешь, а придётся как-то расписать порядок последовательного выполнения всех assignов и alwaysов, таким образом, чтобы это соответствовало их реальному одновременному параллельному исполнению в определённые дискретные промежутки времени.
Поэтому, если с assignами и alwaysами как-то более-менее понятно, то с вызовом модуля из другого модуля, если его рассматривать именно как внешнюю функцию, возникает неясность.

Цитата:

---

Сообщение от Vslav

Я предлагаю упростить еще представление таким образом.

---

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