Перейти к содержанию
    

"схема" или "программирование"

Общался с товаришем по поводу разработки устройств на ПЛИС.

 

 

Сам я с ними не работал, поэтому реши спросить Вас.

 

Он утверждает

программирование - это одномерная информация

чтобы реализовать многомерность - это хрен как извращатся наверное нужно.

тут главное что лучше оптимизируется - схема или программа - еще вопрос

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Он утверждает

программирование - это одномерная информация

чтобы реализовать многомерность - это хрен как извращатся наверное нужно.

тут главное что лучше оптимизируется - схема или программа - еще вопрос

У меня на сайте в разделе письма смотрите. А каждый раз объяснять - долго...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

"Программа" для ПЛИС(описание на HDL) - это в сущности та же схема, только более гибкая, легко настраиваемая и дающая гораздо больше возможностей при моделировании. "Программа" на HDL (если для синтеза) это описание "железа": язык HDL = Hardware Description Language.

Что такое "одномерная информация" применительно к программированию?

Если многомерность = параллельность выполнения операций, то извращаться совсем не нужно - HDL поддерживают параллельные конструкции(это основа).

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

программирование - это одномерная информация

чтобы реализовать многомерность - это хрен как извращатся наверное нужно.

тут главное что лучше оптимизируется - схема или программа - еще вопрос

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

 

Итого:

программная релизация = последовательный во времени процесс

аппаратная релизация = параллельный во времени процесс

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

................................................

Итого:

программная релизация = последовательный во времени процесс

аппаратная релизация = параллельный во времени процесс

.................................................

а как же параллельное программирование, многопроцессорность и тд.? Может добавить тогда еще параллельно-последовательный процесс?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

программная релизация = последовательный во времени процесс

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если рассмотреть внимательнее, господа схематехники подались в программисты тому пример HDL, а программисты в схематехники выдумав FBD. А почему бы нет...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а как же параллельное программирование, многопроцессорность и тд.? Может добавить тогда еще параллельно-последовательный процесс?
Что Вы подразумеваете под параллельным программированием? Несколько параллельно работающих программистов? :) многозадачность... согласно моим скудным представлениям в области микропроцессоров, здесь бы больше подошел термин "псевдопараллельность", т.е., например, секретарше кажется что у неё на компьютере одновременно включены Microsoft Word и пасьянс "Касынка". А на самом деле эти программы просто делятся друг с другом процессорным временем, каждую наносекунду (ну или около того) единолично завладевая железякой.

 

Вот когда сможете в одном такте запихать в Instruction Pointer сразу два адреса команд, тогда и продолжим полемику.

 

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

Да, сложноватые процессорные системы стали в последнее время клепать. Куда проще было Тьюрингу :) А Вы не думаете, что описанный Вами частный случай является именно типичной ситуацией для программной реализации алгоритма? Я имею ввиду классическую модель вычислений.

 

Вообще-то Я предвидел подобные комментарии, поэтому и добавил в скобках небольшое поянение... Я просто к тому, что наличие большого количества отдельных функциональных блоков свойственно скорее аппаратной реализации, нежели программной. Другими словами, программная реализация базируется на фиксированной железяке (например, аппаратная платформа содержит только 2 таймера, и будь ты хоть супер-пупер программист, но больше чем 2 таймера одновременно использовать не получится. Поэтому и придется ждать пока они освободятся), а аппаратная реализация позволяет это самое железо спроектировать под конкретную задачу (например, в той же задаче, во всем алгоритме потребуется 100 счетчиков, так вот вы и ставите 100 счетчиков, каждый из которых вольны запустить в необходимый момент времени, а не ожидать их освобождения).

 

Если рассмотреть внимательнее, господа схематехники подались в программисты тому пример HDL, а программисты в схематехники выдумав FBD. А почему бы нет...
Победила дружба :) Действительно, достаточно перспективными выглядят такие вещи как FPNA (Field Programmable Node Array).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я говорю не о (псевдо)многозадачности, а именно о параллельном программировании - грубо говоря, это когда алгоритм разбивается на независимые участки, работающие параллельно на нескольких вычислителях. Для параллельного программирования используют, например компилятор Paralax. Он конечно не позволит запихать на одном такте в один IP два адреса команд, зато запихает их в два IP (или там сколько надо) и вычисление при этом будет выполнятся параллельно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что Вы подразумеваете под параллельным программированием? Несколько параллельно работающих программистов? :) многозадачность... согласно моим скудным представлениям в области микропроцессоров, здесь бы больше подошел термин "псевдопараллельность", т.е., например, секретарше кажется что у неё на компьютере одновременно включены Microsoft Word и пасьянс "Касынка".

Анекдот времен win'95-98:

Сын спрашивает у Билла Гейтса: "Папа, а что такое многозадачная ОС?" - "Сейчас, сынок, отформатирую дискетту и покажу."

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а как же параллельное программирование, многопроцессорность и тд.? Может добавить тогда еще параллельно-последовательный процесс?

 

Как-то почти недавно Флинн заметил,

что все программисты с "последовательным" мышлением,

а надо бы развивать "параллельное" мышление,

т.к. от распараллеливающих компиляторов для программ,

написанных такими программистами, никакого толку.

VHDL - классный параллельный язык.

1 оператор процесса на VHDL отображается в 1 очень специализированный процессорный элемент.

Такой процессор будет делать что захочешь,

правда, нужно уметь его заставить это делать.

В том числе и последовательные программки.

Какое-то подобие более адаптированной системы к этому делу

представляет система Celoxica - Handel-C.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я говорю не о (псевдо)многозадачности, а именно о параллельном программировании - грубо говоря, это когда алгоритм разбивается на независимые участки, работающие параллельно на нескольких вычислителях. Для параллельного программирования используют, например компилятор Paralax. Он конечно не позволит запихать на одном такте в один IP два адреса команд, зато запихает их в два IP (или там сколько надо) и вычисление при этом будет выполнятся параллельно

Так Вы по сути и описали аппаратный подход к решению проблемы (наличие отдельных вычислительных блоков): "... алгоритм разбивается на независимые участки, работающие параллельно на нескольких вычислителях... (DeadMoroz)". Каждый кусок кода, полученный после разбиения все-равно ведь будет выполняться на своем вычислителе последовательно. Не так ли? В идеале оптимальным вариантом является совмещение этих подходов (аппаратного и программного). Об этом Я тоже писал выше.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...