[vea 0]

Здравствуйте!

Датчик общается со вторымм Циклоном по одной шине "single bus" - реализована как tri-state pin:

assign sb = (enable_sb) ? sb_out: 'z;

Написана FSM, инициализация проходит нормально, проблема возникает на этапе приема битов.

Логика проста - когда на входе "1" (датчик отпустил шину) - поднимаем флаг (new_bit).

Когда "0" - если флаг был поднят, увеличиваем счётчик принятых битов (cnt_bit) и сбрасываем флаг.

GET_BIT:     begin 
            if (sb == 0) begin
                if (new_bit) begin
                    cnt_bit <= cnt_bit + 1'b1;
                    new_bit <= 1'b0;
                end
            end
            else begin     
                new_bit <= 1'b1;
                result[39:24] <= {8'h00,cnt_bit[7:0]};
            end
        end

 

result выводится на семисегментный дисплей.

Проблема: битов должно быть 28 (в hex), но их то 24, то 27, то 28.

При этом на осциллографе флаг (new_bit) поднимается и опускается во всех случаях 28 раз - ровно по числу переданных бит,

а вот увеличение счетчика происходит не всегда.

 

Задержка на пине? Но как тогда опускается флаг?

Тактовая - 50Мгц. Fmax - 108.

 

Подскажите, с чем это может быть связано?

[khlenar 5]

У вас входной сигнал enable_sb ?. Возможно в неустойчевом состоянии пина идет "дребезг" сигнала. Попробуйте программный антидребезг ввести на этот сигнал.

У меня не правильный счет счетчика тоже был из за этого. А вывод на дисплей правильный?, ну имеется ввиду при выводе ни чего не теряется?

Но в первую очередь c TimeQuest все нормально?

[vea 0]

А что именно может быть ненормально в TimeQuest? Ограничений никаких не задавал.

Fmax в нем - больше 100, частота работы платы - 50. Что еще посмотреть?

 

Входной сигнал sb.

Дребезга, судя по осциллографу, нет.

Вывод на дисплей правильный - сравнивал по осциллографу.

Что ставит меня в тупик, так это невыполнение первой строки кода

cnt_bit <= cnt_bit + 1'b1;
new_bit <= 1'b0;

и выполнение второй. Как это может быть?

Они же находятся в одной и той же условной ветви!

 

[khlenar 5]

Вы попробуйте для входа вот этот фильтр поставить.

reg [3:0] ena;

 

always @(posedge clk) ena[3:0] <= {ena[2:0], PIN};

assign enable_sb = ena[3] | ena[2] | ena[1] | ena[0];

а для TimeQuest пропишите констрейн типа:

set_max_delay -from [get_ports {PIN}] -to [get_clocks {ena[0]}] 2.000

т.е. максимальную задержку сигнала со вх. PIN до фильтра.

[vea 0]

Iptash, спасибо, теперь я понял про дребезг на каком входе Вы говорили.

enable_sb - это не вход. Этот сигнал генерируется внутри FPGA, так что такой фильтр, если я не ошибаюсь, излишен.

Сейчас разобираюсь с констрейнами на tri-state входах - возможно, это что-то изменит.

 

[iosifk 3]

Сейчас разобираюсь с констрейнами на tri-state входах - возможно, это что-то изменит.

Когда tri-state переключаете на ввод, то какую задержку на чтение даете? Сколько тактов? Сколько времени на шине рассасывается заряд посте отключения выхода?

 

[khlenar 5]

Поэтому про вход я спрашивал в посте №2. Да, коли это внутренний сигнал, фильтр излишен. По идее в симуляторе должно нормально работать, так что разбирайтесь

в задержках счетчика. Попробуйте разделить счетчик на два 4р. счетчика.

 

[vea 0]

Когда tri-state переключаете на ввод, то какую задержку на чтение даете? Сколько тактов? Сколько времени на шине рассасывается заряд посте отключения выхода?

Задержку даю, 10 тактов, это 0,2 микросекунды. Судя по осциллографу, переход занимает не больше 7-8 тактов (0,16 мкс).

Переход происходит только один раз, после инициализации - после этого pin работает только на вход.

Сейчас попробую увеличть до 20 тактов, но судя по тому, что new_bit устойчиво сбразывается столько раз, сколько и дожен, проблема не в этом.

 

UPDATE: увеличение задержки ничего не дало.

 

Попробуйте разделить счетчик на два 4р. счетчика

Попробую, спасибо.

 

UPDATE: разбиение на 2 счетчика улучшило статистику: правильное значение начало появляться несколько раз подряд.Но как это понимать?

Что Циклон II за один такт на 50 МГц (20ns) успевает сбросить триггер new_bit, но иногда не успевает выполнить итерацию 8-мибитного счётчика?!

Изменено 5 февраля, 2013 пользователем vea

[vea 0]

С двумя счётчиками стало ещё интереснее: теперь их значение бывает больше 28.

Не знаю, что и думать. Код этого модуля можно найти здесь.

До состояния GET_BIT всё проходит нормально.

Изменено 6 февраля, 2013 пользователем vea

[khlenar 5]

В симуляторе прогоняли ?. Если нормально, то попробуйте проблемный участок отдельно запустить, и inout sb попробуйте сделать как вход input sb т.е. проработайте в одну сторону, возможно в этом сигнале все дело.

[BSV 0]

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

[iosifk 3]

Не знаю, что и думать. Код этого модуля можно найти здесь.

Код у Вас написан ужасно. Внутрь автомата засуното столько всякого, что сложно отследить "кто и что"... И счетчик управляется из нескольких мест.

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

Пример посмотрите у меня на сайте, в статьях, "Краткий Курс"...

 

[vea 0]

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

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

Более того, в примерах я видел, что триггер есть - но поскольку никаких комментариев по этому поводу не встретил, то решил сэкономить такт (и триггер).

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

Возможно, это слишком прямолинейный подход, но как тогда нужно рассуждать?

Посоветуйте что-нибудь для прояснения картины. Несоответствие представлений с реальностью просто мучительно:)

 

 

Код у Вас написан ужасно...

... "Краткий Курс".

Спасибо, буду разбираться и переделывать. Сейчас автомат вообще перестал распознаваться как FSM.

Но меня очень смущают фразы "комбинационная логика для следующего состояния", "комбинационная логика для выходов" [Краткий курс HDL.Часть 5].

Здесь же регистровая логика (тот же счетчик). Как её правильно выносить из автомата я еще не понял.

В альтеровском HDL coding stile примеры тоже только с комбинаторной логикой.

 

Спасибо за советы!

Изменено 7 февраля, 2013 пользователем vea

[iosifk 3]

Но меня очень смущают фразы "комбинационная логика для следующего состояния", "комбинационная логика для выходов" [Краткий курс HDL.Часть 5].

Здесь же регистровая логика (тот же счетчик). Как её правильно выносить из автомата я еще не понял.

Спасибо за советы!

 

Есть регистр, который сохраняет состояние автомата.

Так вот, можно собрать логику на входе регистра, а число триггеров в регистре сделать таким, сколько нужно выходных сигналов из автомата. А можно триггеров сделать меньше, но на выходе регистра поставить кучу логики, как дешифратор и из этой логики вывести сигналы..

 

[BSV 0]

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

Более того, в примерах я видел, что триггер есть - но поскольку никаких комментариев по этому поводу не встретил, то решил сэкономить такт (и триггер).

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

Возможно, это слишком прямолинейный подход, но как тогда нужно рассуждать?

Посоветуйте что-нибудь для прояснения картины.

Это тот самый случай, когда экономия вредна. Сброс асинхронный, вестимо... Попробуйте по своему прежнему описанию представить схему в которую он синтезируется, возможно тогда придет ясность. Еще погуглите "состязания (гонки) сигналов" - это как раз Ваш случай. И еще совет - любой язык описания лишь описывает некий об'ект будь то триггер, счетчик или что-то еще. Когда описываете что-то, Вы должны четко понимать, как это будет понято синтезатором.