[KA_ru 0]

"И человек который хорошо владеет ими пойдет дальше простых схем."

 

jeto ty klasno skazal. :))

[-=KiV=- 0]

по моему рисовавть схемы проще, да и код более оптимальный

 

:) D). Я перешел на HDL описания ПЛИС практически сразу - тогда появились MAX7000 (самые первые, еще 5-Вольтовые) и мне необходимо было вставить в свою плату небольшой декодер с защелкой адреса и т.п. На мелкой логике это просто не влезало в габариты платы :). Сделали в альтеровском сапре схемку (ту-же, что не влезала в плату), просчитали, что влазит в 32-триггерную ПЛИСину, запустили трансляцию ....... НЕ ВЛАЗИТ!!! :). Переделали несколько раз схему, упростили .... НЕ ВЛАЗИТ! По логике вещей и по всем расчетам должно влазть - даже сами разложили на архитектуру ПЛИС! А оно НЭ ЛЫЗЕ!

Короче говоря, после недели мучений я залез в описание AHDL (тогда еще ни VHDL, ни Verilog синтезаторов не было в бесплатных САПРах).

 

К концу дня (!) худо-бедно заработало в железе! Через пару дней полный вариант схемки РАБОТАЛ! И все влезло так, как и хотелось :)

 

Короче после этого я не возвращался к схематику. Со временем переполз на Xilinx и VHDL но к схемам (принципиальным) на ПЛИС не возвращался. И не буду :).

 

Чего и Вам желаю :).

[custic 0]

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

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

 

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

 

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

 

 

Стремитесь к высокому и высокоуровневым языкам программированмя...

[maksya 0]

Стремитесь к высокому и высокоуровневым языкам программированмя...

<{POST_SNAPBACK}>

 

Но никогда не забывайте низкий уровень. Надо знать все!

[ucf 0]

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

[v_mirgorodsky 0]

Просто не могу смолчать. Свое мнение аж прет и хочу ним поделиться с глубоко уважаемым ALL'ом.

 

Каждое средство разработки применимо для своих целей и нужд. Если вам необходимо выжать последние крохи быстродействия из чипа, то ничего у вас с поведенческим описанием на высоком уровне не получится, как бы вы не старались. Для решения таких проблем необходимо абсолютно точно понимать во что скомпилируется тот или иной кусок кода на HDL, аккуратно строить связи между элементами, учитывать топологию ПЛИС и т.д. Необходимо абсолютно четко понимать, что синтезатор обладает лишь тем интеллектом, которим его наделили создатели. Для некоторых задач этого интеллекта просто мало :(

 

Чем хорош схематик. Он хорош тем, что вы абсолютно четко проектируете схему из элементов имеющих максимальное быстродействие в выбраном базисе. Сдесь был пример о 256-элементном сдвиговом регистре. К примеру на Xilinx данная задача может быть решена при помощи LUT'ов а может быть решена на триггерах и соответствующей обвязке. Если синтезатор не обучен использованию Xilinx LUT, то он сгенерит код, который будет занимать на порядок больше ячеек в ПЛИС и будет работать на прощентов 20-30 медленнее. То же самое с цифровым автоматом. Попробуйте создать автомат с 30-40 состояниями и быстродействием 200-250МГц на HDL - ничего не получится, или чип, который сможет это сделать будет стоить на порядок дороже, чем тот который вам доступен. В то же время просто прописав кусок блочной или распределенной памяти нужной информацией быстродействие автомата будет ограничиваться только быстродействием этой самой памяти.

 

Чем хорош HDL. Не нужно заботиться о мелочах, которые присущи схемному проектированию. Однако необходимо понимать Trade-Off - схема всегда будет намного менее оптимальна схематика.

 

Я пришел в схемотехнику из программирования. И я до сих пор лучший программист, чем электронщик. В программировании есть постоянный баланс между эффективностью кода и уровнем абстракции. Именно поэтому там есть язык ассемблера, на котором пишутся максимально эффективные и максимально нагруженные функции и есть Си, на котором пишут логику и связывают ассемблерные куски между собой. Это есть стандартный подход в написании драйверов устройств. Только так ожно получить эффективное решение, работающее на требуемой скорости и не занимающее вечности на свою разработку. Никто же не пытался приспособить Бейсик для написания драйверов, хотя технически это легко реализуемо.

 

Так и в схемотехнике. Если вам надо создать контроллер SDRAM на 133МГц с близкой к пиковой пропускной способностью, то вы будете ее синтезировать из максимально быстрых элементов базиса - счетчиков, триггеров, компараторов, считай, практически рисуя схему в схематике, но текстом (такой себе каламбур получился). И совершенно не имеет значения, на каком уровне вы напишете автомат управления бегущих огней на тактовую частоту в 10кГц.

 

Резюме: пользоваться HDL надо, но надо четко представлять себе, во что это скомпилируется синтезатором, иначе схемы будут субоптимальными, медленными и дорогими.

 

С уважением,

Владимир Миргородский

[Nixon 3]

Володя, по этому здесь было сломано куча копий.

Я согласен с тобой полностью, но ты забыл очень важный аспект - скорость разработки в современном мире становится все более важным фактором, чем скорость конечного изделия. И задач по обеспечению максимальной эффективности становится все меньше и меньше. Гораздо проще использовать более мощную элементную базу и быстро писать для нее на HDL, чем оптимизировать до бесконечности проект на старой базе. Ваш конкретный случай это скорее исключение из правил. Хотя и здесь можно усмотреть экстенсивный подход - не успевает Virtex3 - успеет Virtex4.

[v_mirgorodsky 0]

Ага, если бы мы жили и творили в Штатах, где лишних $20-30 на одном экземпляре устройства не есть проблема, то тогда возможно так и надо было бы поступать. А сдесь, если сказать начальству, что девайс будет им стоить на $30-40 дороже при общей цене в $300-400, то оно (начальство) просто не согласится с таким подходом. Сейчас у нас в Киеве :) хороший программист на C/C++ стоит от $600, то программиста на Visual Basic можно найти за $300-400 и меньше. Все определяет класс разработчика. Так и сдесь. Можно писать схемы на HDL не задумываямь во что это сгенерится, а можно пользоваться быстрым базисом ПЛИС, описывая на HDL только логику работы устройства. Для меня этот подход получился самым оптимальным. Я не пытаюсь кодировать FSM на отдельных триггерах, в то же время я не пишу сумматор как c <= a + b; а ставлю и подключаю библиотечный элемент, разный в зависимости от конкретного места в схеме и конкретного применения: с быстрыми переносами но более требовательный к ресурсам для быстрых схем, и обычный комбинаторный но сравнительно мало занимающий - там где максимум быстродействия не требуется. Автоматический синтезатор же всегда поставит тот сумматор, который по кго мнению будет ему удобнее, создавая в одном случае ненужный оверхеад, а в другом случае еффективно блокируя работоспособность схемы. Причем найти эту ошибку будет достаточно сложно, так как при поведенческом моделлировании схема даст правильный результат. Необходимо будет именно временное моделирование заданного куска схемы с этим сумматором. А если в схеме их десятки? И только у пары из них есть временные проблемы, причем зависящие от конкретной раскладки? Я понимаю, констраинты нам помогут, но не всегда все можно абсолютно точно законстраинить :(

 

С уважением,

Владимир Миргородский

[Димыч 0]

Все правы, и, как всегда - все хорошо в меру :)

Вот мы, чтобы вовремя захватить определенный сектор рынка (конкуренты - шведы всякие :) ) идем на серьезные вложения, как то покупка всяких SDK, внесение избыточности в принципиальную схему в угоду большему удобству программирования и конфигурации устройства... Лишь бы в срок уложиться, иначе потом можно просто выкинуть эту разработку на помойку, будь она хоть супер-оптимальной :( И усовершенствования, удешевление, написание собственных серверов VS покупные - оставляем на "потом".

Да, все конечно зависит от типа разработки, от сферы применения и сбыта... Но у нас выходит вот так - главное сроки проекта. (в разумном сочетании с бюджетом, конечно ;) )

[ucf 0]

не успевает Virtex3 - успеет Virtex4.

<{POST_SNAPBACK}>

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

А по поводу начальства - когда устройство будет глючить на глазах у начальства, то оно воспримет ваши доводы на лишние 40$ (но будет слишком поздно).

[ASN 0]

В качестве иллюстрации к утверждению, что "поведенческое описание на HDL" всегда будет намного менее оптимальна схематика . Хорошо всем известный пример с подсчётом CRC для Ethernet (Igor Mohor & CRC Tool).

Код для подсчёта CRC 4-х битных входных данных (IMHO, оптимизированный под структуру):

library IEEE;
use IEEE.std_logic_1164.all;
package PCK_CRC32_D4 is
 function nextCRC32_D4
   ( Data:  std_logic_vector(3 downto 0);
     CRC:   std_logic_vector(31 downto 0) )
   return std_logic_vector;
end PCK_CRC32_D4;
package body PCK_CRC32_D4 is
 function nextCRC32_D4  
   ( Data:  std_logic_vector(3 downto 0);
     CRC:   std_logic_vector(31 downto 0) )
   return std_logic_vector is
   variable D: std_logic_vector(3 downto 0);
   variable C: std_logic_vector(31 downto 0);
   variable NewCRC: std_logic_vector(31 downto 0);
 begin
   D := Data;
   C := CRC;
   NewCRC(0) := D(0) xor C(28);
   NewCRC(1) := D(1) xor D(0) xor C(28) xor C(29);
   NewCRC(2) := D(2) xor D(1) xor D(0) xor C(28) xor C(29) xor C(30);
   NewCRC(3) := D(3) xor D(2) xor D(1) xor C(29) xor C(30) xor C(31);
   NewCRC(4) := D(3) xor D(2) xor D(0) xor C(0) xor C(28) xor C(30) xor C(31);
   NewCRC(5) := D(3) xor D(1) xor D(0) xor C(1) xor C(28) xor C(29) xor  C(31);
   NewCRC(6) := D(2) xor D(1) xor C(2) xor C(29) xor C(30);
   NewCRC(7) := D(3) xor D(2) xor D(0) xor C(3) xor C(28) xor C(30) xor  C(31);
   NewCRC(8) := D(3) xor D(1) xor D(0) xor C(4) xor C(28) xor C(29) xor  C(31);
   NewCRC(9) := D(2) xor D(1) xor C(5) xor C(29) xor C(30);
   NewCRC(10) := D(3) xor D(2) xor D(0) xor C(6) xor C(28) xor C(30) xor C(31);
   NewCRC(11) := D(3) xor D(1) xor D(0) xor C(7) xor C(28) xor C(29) xor C(31);
   NewCRC(12) := D(2) xor D(1) xor D(0) xor C(8) xor C(28) xor C(29) xor C(30);
   NewCRC(13) := D(3) xor D(2) xor D(1) xor C(9) xor C(29) xor C(30) xor C(31);
   NewCRC(14) := D(3) xor D(2) xor C(10) xor C(30) xor C(31);
   NewCRC(15) := D(3) xor C(11) xor C(31);
   NewCRC(16) := D(0) xor C(12) xor C(28);
   NewCRC(17) := D(1) xor C(13) xor C(29);
   NewCRC(18) := D(2) xor C(14) xor C(30);
   NewCRC(19) := D(3) xor C(15) xor C(31);
   NewCRC(20) := C(16);
   NewCRC(21) := C(17);
   NewCRC(22) := D(0) xor C(18) xor C(28);
   NewCRC(23) := D(1) xor D(0) xor C(19) xor C(28) xor C(29);
   NewCRC(24) := D(2) xor D(1) xor C(20) xor C(29) xor C(30);
   NewCRC(25) := D(3) xor D(2) xor C(21) xor C(30) xor C(31);
   NewCRC(26) := D(3) xor D(0) xor C(22) xor C(28) xor C(31);
   NewCRC(27) := D(1) xor C(23) xor C(29);
   NewCRC(28) := D(2) xor C(24) xor C(30);
   NewCRC(29) := D(3) xor C(25) xor C(31);
   NewCRC(30) := C(26);
   NewCRC(31) := C(27);
   return NewCRC;
 end nextCRC32_D4;
end PCK_CRC32_D4;

Код для подсчёта CRC 4-х битных входных данных (простое «влоб» переложение полиномиального деления):

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;

package PCK_CRC is
function CRC32_SLV (
      P:         std_logic_vector;
      Data:    std_logic_vector;
      CRC:    std_logic_vector
       )return std_logic_vector;
end package PCK_CRC;

package body PCK_CRC is
function ONE_DATA_BIT (
       P:       std_logic_vector;
       CRC:  std_logic_vector;
       DB:    std_logic 
       ) return std_logic_vector is
variable NewCRC:  std_logic_vector (CRC'range);
variable CRC_High:std_logic;
begin
      CRC_High  :=CRC(CRC'High);
      NewCRC(0):=CRC_High xor DB;
for i in 1 to CRC'High loop
     if P(i)='1'  then NewCRC(i):=CRC(i-1) xor CRC_High xor DB;
                    else  NewCRC(i):=CRC(i-1);
    end if;
end loop;
return NewCRC;
end function ONE_DATA_BIT;
    
function CRC32_SLV (
       P:        std_logic_vector;
       Data:   std_logic_vector;
       CRC:   std_logic_vector
       )return std_logic_vector is
variable C:   std_logic_vector(CRC'range);
begin
C:=CRC; for i in Data'High downto 0 loop C:=ONE_DATA_BIT(P, C, Data(i));end loop; return C;
end function CRC32_SLV;
end package body PCK_CRC;

При вызове функции объявляется

constant P:std_logic_vector(31 downto 0):="00000100110000010001110110110110";

Синтез выполнялся в Synplify Pro 7.6 для SpartanIIE. Результат – LUT 35, DFF – 32, NETS – 108. Для обоих схем.

Интересно мнения уважаемого All по указанному примеру.

З.Ы. Последнее время всё больше замечаю, что синтезатор умнее меня. :).

З.З.Ы Нечто подобное первому коду делалось «вручную» два дня. Второй я «набросал» за 1,5 часа, пока одним глазом смотрел «Время» и «Розыгрыш».

[Wilde 0]

Лучше пользоваться "конструкторами кода" Когда по графу или блоксхеме алгоритма синтезируется код. Так меньше ошибок. А вообще при достаточном опыте HDL позволяют намного быстрее проектировать. Причем, думаю все так делают, топ проекта в редакторе схем, сами модули - на HDL.

[kuchynski 0]

Именно так, что даёт:

а). наглядное представление проекта в целом;

б). быстроту изменения модуля в отдельности;

в). легко просматривается синхронизация;

г). наверное что-то ещё.

[Borka 0]

Нельзя путать два совершенно разных подхода: первый описание более менее больших проектов на высокоуровневом языке и заказное проектирование, с ручной схемотехникой и прочим. Оба подхода различны и применимы в рамках проекта, дополняя друг друга, но никак не исключая.. Конечно, схемотехника всегда будет быстерее и кушать меньше транзисторов, но кто будет схематить графконтроллер, например, и сколько на это уйдет времени.....