[Vadim 0]

А это вы не подумавши сказали.

Неужели? Вы телепат?

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

Уже есть :) Ничего интересного, уверяю Вас. Схему рисую. Потому как стандарта языка описания печатных плат не существует. Да, кстати, понятие цикла в языках программирования Вам знакомо?

У нас тут библиотекари решили трансформаторы, которые нам на E1, E2, E3 стыки ставяться, прямоугольниками обозначать. Мол. вам не все равно. А нам удобно. Микросхема как микросхема. Ножки пронумерованы. Мне пришлось поднимать бучу и доводить до руководства, чтобы заставить их нормально трансформаторы рисовать.

Совсем библиотекари распоясались. Сочуствую Вам :)

[avesat 0]

...

У нас тут библиотекари решили трансформаторы, которые нам на E1, E2, E3 стыки ставяться, прямоугольниками обозначать. Мол. вам не все равно. А нам удобно. Микросхема как микросхема. Ножки пронумерованы. Мне пришлось поднимать бучу и доводить до руководства, чтобы заставить их нормально трансформаторы рисовать.

_off topic

А как это ваше руководство платы и схемы проверяет, а символы нет, а если косяк в шайбе на хххх ног, и все коту под хвост :crying: непорядок, нужно и каждый символ проверять, а если что не так, носом тыкать :rolleyes:

[kuzis 0]

Уже есть :) Ничего интересного, уверяю Вас. Схему рисую. Потому как стандарта языка описания печатных плат не существует. Да, кстати, понятие цикла в языках программирования Вам знакомо?

 

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

 

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

Так вот. Сможете сказать правильное название документа, обозначающегося шифром Э3?

 

_off topic

А как это ваше руководство платы и схемы проверяет, а символы нет, а если косяк в шайбе на хххх ног, и все коту под хвост :crying: непорядок, нужно и каждый символ проверять, а если что не так, носом тыкать :rolleyes:

 

Это руководство не проверяет. Это лежит на библиотекарях они несут ответственность. Руководство больше интересуется, соотвествует ли электрическая схема утвержденной функциональной схеме.

[Vadim 0]

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

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

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

Так вот. Сможете сказать правильное название документа, обозначающегося шифром Э3?

Конструкторов нужно ставить на место. Тоже распоясались. Но это не ко мне, обращайтесь в компетентные органы.

[kuzis 0]

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

Да знакомо мне это. Все-таки я пишу программы. Просто не всегда циклом можно воспользоваться.

А соединение функциональных узлов между собой в схемном редакторе дает несколько преимуществ:

1. Такое изображение легче для восприятия.

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

3. На этапе функционального проектирования можно ограничиться созданием entity для функциональных узлов (если их еще нет), и при проектировании функциональной схемы в схемном редакторе получить тоже несколько плюсов:

 

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

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

 

а вот на этом

функциональная схема в визио.

можно время сэкономить.

 

ИМХО: функциональные компоненты надо проектировать на VHDL (ну или verilog), а собирать из них конкретное решение луче все-таки в схемном редакторе.

[des00 25]

Да знакомо мне это. Все-таки я пишу программы. Просто не всегда циклом можно воспользоваться.

А соединение функциональных узлов между собой в схемном редакторе дает несколько преимуществ:

1. Такое изображение легче для восприятия.

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

3. На этапе функционального проектирования можно ограничиться созданием entity для функциональных узлов (если их еще нет), и при проектировании функциональной схемы в схемном редакторе получить тоже несколько плюсов:

 

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

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

 

Решил таки влезть со своим самоваром :))

 

1/2. Не верю, вот простой пример топлевел моего последнего проекта "весит" ~3500 строк, состоит из ~40-50 функционально законченных модулей (в среднем в каждом из модулей 4-5 подмодулей). Среднее количество сигналов на модуль ~15-20.

 

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

 

А уж сколько гемороя будет во время отладки, когда периодически нужно между модулями вставлять ловушки, логеры и т.д. Вы в графике будете дольше сигналы перерисовывать.

 

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

 

можно время сэкономить.

 

ИМХО: функциональные компоненты надо проектировать на VHDL (ну или verilog), а собирать из них конкретное решение луче все-таки в схемном редакторе.

 

Не верю, вот пример из недавнего.

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

 

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

 

Нее, для меня, параллельно открытые SlickEdit + QuestaSim + Quartus + Visio + Word проще, быстрее и понятливее. Нужно просто не ленится синхронизовать документы и почаще комитится %)))

[dxp 69]

Нее, для меня, параллельно открытые SlickEdit + QuestaSim + Quartus + Visio + Word проще, быстрее и понятливее. Нужно просто не ленится синхронизовать документы и почаще комитится %)))

+1000, подписываюсь под каждым словом. :)

 

Тоже был опыт использования схематика для top level, накувыркался вдоволь, больше не желаю. В тексте, кстати, связи и межсоединения прекрасно просматриваются, если использовать хороший стиль описания, например, такой:

VC_in inVC
    (
        .clk        ( clk       ),
        .reset      ( rst       ),

        .ext_cam    ( 1'b1      ),

        .cam_pix    ( cam_pix   ),
        .cam_frame  ( cam_frame ),
        .cam_line   ( cam_line  ),
        .cam_data   ( cam_data  ),

        .psync      ( vc_psync  ),
        .fsync      ( vc_fsync  ),
        .lsync      ( vc_lsync  ),
        .data       ( vc_data   )
    );

[kuzis 0]

Не верю, вот пример из недавнего.

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

 

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

 

А вот у меня опыт совершенно противоположный :) .

Когда человек оставил в наследство текстовый файл, я готовы был его на новом месте работы поймать и порвать.

 

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

 

Мое мнение такое. Во всем важна мера. Не следует бросаться из крайности в крайность.

В каждом подходе есть свои плюсы, и надо ими пользоваться.

 

А уж сколько гемороя будет во время отладки, когда периодически нужно между модулями вставлять ловушки, логеры и т.д. Вы в графике будете дольше сигналы перерисовывать.

 

А вот чем мне нравится Active (возвращаясь к теме топика), так это тем что в нем в схемном редакторе можно совмещать схему и текстовое кодирование :)

[sazh 8]

А вот чем мне нравится Active (возвращаясь к теме топика), так это тем что в нем в схемном редакторе можно совмещать схему и текстовое кодирование :)

 

А в моделсим это можно перебросить?

[atlantic 0]

+1000, подписываюсь под каждым словом. :)

 

Тоже был опыт использования схематика для top level, накувыркался вдоволь, больше не желаю. В тексте, кстати, связи и межсоединения прекрасно просматриваются, если использовать хороший стиль описания, например, такой:

...

Кажется тут "незаметно" подменили понятия, насколько я понял, Михаил_K делал упор на схему железки(платы) а не схему RTL описания. Схему железки на языке описывать в принципе можно, но с точки зрения дальнейшей работы далее(разводка платы, настройка) будет проблематично. При работе с HDL вы опираетесь на синтезатор, котрый будет транслировать в "виртуальное железо" FPGA, а при разводке платы все детали это физические объекты с соответвующими свойствами, которые практически невозможно комментировать или генерить.

[vetal 0]

А в моделсим это можно перебросить?

Да. Active-hdl схемы и диаграммы преобразовывает в hdl код перед компиляцией.

[kuzis 0]

Кажется тут "незаметно" подменили понятия, насколько я понял, Михаил_K делал упор на схему железки(платы) а не схему RTL описания. Схему железки на языке описывать в принципе можно, но с точки зрения дальнейшей работы далее(разводка платы, настройка) будет проблематично. При работе с HDL вы опираетесь на синтезатор, котрый будет транслировать в "виртуальное железо" FPGA, а при разводке платы все детали это физические объекты с соответвующими свойствами, которые практически невозможно комментировать или генерить.

 

Да не совсем. Я просто на примере создания схемы "железки" хотел показать удобство схемного редактора в некоторых случаях. А именно для восприятия.

 

Да. Active-hdl схемы и диаграммы преобразовывает в hdl код перед компиляцией.

Как и другие схемные редакторы, например ISE

[des00 25]

А вот у меня опыт совершенно противоположный :) .

Когда человек оставил в наследство текстовый файл, я готовы был его на новом месте работы поймать и порвать.

 

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

 

Не верю, если текст хоть немного читаем, редактор с тегами и все полетит. На худой конец используем хакерский софт. HDS + Convert to Graphics а дальше IBT и вперед.

 

 

А вот чем мне нравится Active (возвращаясь к теме топика), так это тем что в нем в схемном редакторе можно совмещать схему и текстовое кодирование :)

 

Вы еще HDS попробуйте, его IBT очень неплохое изобретение. Я пробывал использовать графику в 3-х пакетах, но не пошло, мне с текстом проще работать.

 

Если у вас такой большой опыт в графике, выложите топ левел проекта, уровня который я привел(модулей 40). Интересно посмотреть на такие "понятные функциональные схемы". Ни разу не видел %))

 

 

 

 

А в моделсим это можно перебросить?

 

смысла нет никакого, используйте HDS если он вам понравиться.

[kuzis 0]

Если у вас такой большой опыт в графике, выложите топ левел проекта, уровня который я привел(модулей 40). Интересно посмотреть на такие "понятные функциональные схемы". Ни разу не видел %))

 

Я до такого никогда не доводил. Принцип "разделяй и властвуй" здесь тоже применим. неужели из этих 40 модулей нет нескольких таких, которые можно было бы объеденить отдельный блок и на верхнем уровне использовать его?

[des00 25]

Я до такого никогда не доводил. Принцип "разделяй и властвуй" здесь тоже применим. неужели из этих 40 модулей нет нескольких таких, которые можно было бы объеденить отдельный блок и на верхнем уровне использовать его?

 

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

 

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

 

вот например маленький кусочек кода

 

  //------------------------------------------------------------------------------------------------------
  // decicion scaler
  //------------------------------------------------------------------------------------------------------
  decision_scaler
  #(
    .pIN_W  ( cDECISION_SCALER_IN_W   ) ,
    .pOUT_W ( cDECISION_SCALER_OUT_W  )
  )
  decision_scaler
  (
    .iclk   ( decision_scaler__iclk   ) ,
    .iena   ( decision_scaler__iena   ) ,
    .idat_i ( decision_scaler__idat_i ) ,
    .idat_q ( decision_scaler__idat_q ) ,
    .oena   ( decision_scaler__oena   ) ,
    .odat_i ( decision_scaler__odat_i ) ,
    .odat_q ( decision_scaler__odat_q )
  );

  assign decision_scaler__iclk   = prm_clk4_3  ;
  assign decision_scaler__iena   = nequ__oena  ;
  assign decision_scaler__idat_i = nequ__odat_i;
  assign decision_scaler__idat_q = nequ__odat_q;
  //------------------------------------------------------------------------------------------------------
  // hard decision logic
  //------------------------------------------------------------------------------------------------------
  decision
  #(
    .pW ( cDECISION_W )
  )
  decision
  (
    .iclk   ( decision__iclk   ) ,
    .iqam   ( decision__iqam   ) ,
    .iena   ( decision__iena   ) ,
    .idat_i ( decision__idat_i ) ,
    .idat_q ( decision__idat_q ) ,
    .oena   ( decision__oena   ) ,
    .odat   ( decision__odat   )
  );

  assign decision_idat_mux  = 1'b1;   // каналы встали так 
  assign decision__iclk     = prm_clk4_3;
  assign decision__iqam     = qam_mode  ;

  always_ff @(posedge decision__iclk) begin
    decision__iena    <= decision_scaler__oena   ;
    decision__idat_i  <= decision_idat_mux ? decision_scaler__odat_q : decision_scaler__odat_i ;
    decision__idat_q  <= decision_idat_mux ? decision_scaler__odat_i : decision_scaler__odat_q ;
  end