В начале пути изучения VHDL, пишу простенькую программу следующего содержания

По приходу инициирующего сигнала запускается чтение битов из последовательной памяти. Инициируются клоки ROM-request, считываются данные по падающему фронту,которые затем выдаются на шину вывода,и далее устанавливается флаг Ready в положение '1'.

Собственно с этим и возникла проблема.
Сигнал объявляется в entity как

ready: inout STD_LOGIC:='0';

Далее в процессе ROM_clockong он ставится в положение 1

if (j=7) then ready<='1';

Ну и в процессе Read_complete, по приходу заднего фронта с шины, означающее что данные прочитаны, он снова сбрасывается в 0

ready<='0';

Если убрать процеес Read_complete, то все выполняется прекрасно, как надо (см. Graph2)

Если этот процесс раскомментировать, то сигнал получает значение Х (явно неопределенный).

Таким образом суть проблемы.
Если в сигнал Ready могут писать 2 процесса, то возникает ошибка. Если один — все в порядке. Прочитал про resolved и solved сигналы, но у меня то как раз вроде все правильно — STD_Logic resolved типа,в него могут писать разные процессы, STD_uLogic – solved, если описать ready так, то компилятор сам напомнит об этом.
Starter.vhd : (89, 0): Signal "ready" has two sources, but is not resolved signal

Что я делаю не так?


В мануалах приводятся примеры, в которых несколько процессов одновременно обращаются в переменной, в этом случае для решения конфликта один из них присваивает 1 или 0, другой слабые - H или L. Но в моем то случае происходит изменение сигнала в разное время.

такой вопрос возникает часто, поэтому в архиве могут быть лучшие объяснения

у меня вопрос: это описание устройства или описание теста?
(не могу понять по картинкам, в какой системе моделируете - активхдл или вендорский симулятор?) они скорее всего предполагают, что описываете устройство

описание устройство не может поддерживать присвоение одному сигналу из двух процессов (независимо от языка проектирования), потому что нет такого "физического" элемента
рекомендуется почитать главу RTL coding style в документации на тул/микросхему, и писать описания устройств в сооттветствии с документом

для VHDL я считаю правильным описание в виде двух процессов - в одном с помощью локальных переменных (variable) производится описание комбинаторной логики (список чувствительности процесса включает все входные сигналы)
на выходе сигналу присваивается значение переменной

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

----------

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

Среда Active HDL, стимулирование через временные диаграммы там же.

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

Микросхема Actel, но к синтезу я пока даже не переходил. Т.е. нормально реализовать работу нескольких процессов на один выход невозможно в принципе?

Материалы, которые я прочитал по этому поводу не внесли ясности. Как же все таки писать нескольким процессам в одну выходную шину? Поиск по форуму "resolved signal" тоже не дал ответа.

Друзья, я дебил и не понимаю прописных истин?

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

Бинго! Естественно, нужен некий арбитр.

В стандарте VHDL 2006 появились новые операторы: force, release; Они как раз и предназначены для включения и выключения драйвера для сигнала. Но Activ-HDL 8.1 похоже это не поддерживает.
Пример должен выглядеть так:


В этом примере сигнал a должен включится через 100 ns, выставить 1, а затем отключиться через 400 nc;
Эти операторы предназначены для работы со сложными типами данных, в которых трудно сделать функцию resolved. И предназначены в первую очередь для моделирования.

все понял, на одну шину несколько процессов писать не могут. Спасибо

Тогда я не понял, зачем вообще нужны Resolved сигналы?

1) Некий процесс_1 обращается к шине выставляя слабые значения, работает с ней. Если есть процесс_2 выставляющие свои слабые значения в этот сигнал, то они конфилктуют, на выходе U

2) Тут к сигналу обращается процесс_3 и выставляет сильное значение. И все, теперь уже кроме этого процесса никто с этим сигналом работать не сможет, иначе ошибка

Правильно ли я понял, что физически функция отключения драйвера сигнала не синтезируется? Если что, микросхемы
http://www.actel.com/products/pa3l/default.aspx

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

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

Понял, внутри делать шины с тремя состояниями.
А как сделать такую шину на выход?

Примеры из Xilinx ISE:

using When/Else:
<output> <= <input> when <enable> ='1' else 'Z';

Using Process:
process (<enable>, <input>)
begin
if (<enable>='1') then
<output> <= <input>;
else
<output> <= 'Z';
end if;
end process;