Здравствуйте, TailWind, Вы писали:

N>>В следующем варианте "ACPI-safe" есть защёлка (дополнительный регистр, в который, в простейшем варианте, переписывается значение счётчика в противофазе — например, если инкремент происходит по фронту, то запись в защёлку — по спаду;

TW>Так эту проблему не решить
TW>Тут фишка в том, что триггеры контроллера PCI работают от своего клока
TW>А триггеры счётчика от своего

Да. Но это решаемо. Конечно, я упростил описание ситуации.

TW>В результате, есть вероятность, что изменение значения счётчика попадёт точно под клок PCI, что переведёт его триггеры в бистабильное состояние (они начнут генерить (постоянно менять значения))

Именно такое с бистабильностью — я не знаю, как достигнуть
Проблема понятна, и есть несколько вариантов решения. В случае значительного превышения одной частоты над другой — а тут именно так, у таймера, грубо говоря, 3.5 МГц, а у шины 33 МГц и выше — идёт синхронизация по большей частоте. Примерно так:
Три регистра: int_value, out_value, temp1 — все три — группы синхронных D-триггеров с записью по фронту.
1. В любой момент времени, когда в таймере (int_value) значение N, на выходе сумматора готово N+1. Синхронность тут ещё не нужна.
2. По фронту сигнала инкремента таймера взводится однобитовый флажок want_set и выход сумматора копируется в полноразмерный регистр temp1.
3. По комбинации фронта тактового сигнала шины и флажка обновления — значение temp1 сохраняется в out_value и want_set сбрасывается в 0.

Или чуть экономнее: temp1 удаляем, но делаем ещё один однобитовый флаг need_inc.
2. По фронту сигнала инкремента таймера взводится однобитовый флажок want_set.
3. По комбинации фронта тактового сигнала шины и want_set — int_value записывается в out_value и взводится флажок need_inc; want_set сбрасывается в 0.
4. По любому перепаду тактового сигнала и need_inc — выход сумматора записывается в int_value, need_inc сбрасывается.

Повторюсь, для надёжности этого нужно, чтобы частота шины превышала частоту таймера (более чем в 2 раза), но тут это выполняется.

Вот если частоты близки или соотношение непредсказуемо — тогда суши вёсла Есть отдельная теория разработки полностью асинхронных и самосинхронных схем. Я знаю, кто в ней реально работает (хоть и на хобби), но сам не осилил.

Здравствуйте, TailWind, Вы писали:

N>>В следующем варианте "ACPI-safe" есть защёлка (дополнительный регистр, в который, в простейшем варианте, переписывается значение счётчика в противофазе — например, если инкремент происходит по фронту, то запись в защёлку — по спаду;

TW>Так эту проблему не решить
TW>Тут фишка в том, что триггеры контроллера PCI работают от своего клока
TW>А триггеры счётчика от своего

Да. Но это решаемо. Конечно, я упростил описание ситуации.

TW>В результате, есть вероятность, что изменение значения счётчика попадёт точно под клок PCI, что переведёт его триггеры в бистабильное состояние (они начнут генерить (постоянно менять значения))

Именно такое с бистабильностью — я не знаю, как достигнуть
Проблема понятна, и есть несколько вариантов решения. В случае значительного превышения одной частоты над другой — а тут именно так, у таймера, грубо говоря, 3.5 МГц, а у шины 33 МГц и выше — идёт синхронизация по большей частоте. Примерно так:
Три регистра: int_value, out_value, temp1 — все три — группы синхронных D-триггеров с записью по фронту.
1. В любой момент времени, когда в таймере (int_value) значение N, на выходе сумматора готово N+1. Синхронность тут ещё не нужна.
2. По фронту сигнала инкремента таймера взводится однобитовый флажок want_set и выход сумматора копируется в полноразмерный регистр temp1.
3. По комбинации фронта тактового сигнала шины и флажка обновления — значение temp1 сохраняется в out_value и want_set сбрасывается в 0.

Или чуть экономнее: temp1 удаляем, но делаем ещё один однобитовый флаг need_inc.
2. По фронту сигнала инкремента таймера взводится однобитовый флажок want_set.
3. По комбинации фронта тактового сигнала шины и want_set — выход сумматора записывается в out_value и взводится флажок need_inc; want_set сбрасывается в 0.
4. По любому перепаду тактового сигнала и need_inc — выход сумматора записывается в int_value, need_inc сбрасывается.

Повторюсь, для надёжности этого нужно, чтобы частота шины превышала частоту таймера (более чем в 2 раза), но тут это выполняется.

Вот если частоты близки или соотношение непредсказуемо — тогда суши вёсла Есть отдельная теория разработки полностью асинхронных и самосинхронных схем. Я знаю, кто в ней реально работает (хоть и на хобби), но сам не осилил.