[SM 0]

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

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

клок ~100МГц, вывод ~100 млн. символов/сек

Что более чем явно означает вывод одного символа в один такт описываемого устройства (или я неправильно понял?).

Более того, у Вас на ЯП описано отнюдь не это, так как операции вывода перемежаются с операциями расчета, на которые тоже требуются такты. Т.е. описание на ЯП не соответствует задаче.

 

ЗЫ. Генератор случайных чисел это тоже арифметический блок, на раз делаемый в дв/десятичной арифметике. Так что не вижу ни одной загвоздки.

 

ЗЗЫ. Пора тему в офтопик отправлять... Обсуждение будущего функциональных описаний свелось к банальному флуду ЯП vs HDL на сегодняшнем уровне.

[Leka 1]

Что более чем явно означает вывод одного символа в один такт описываемого устройства (или я неправильно понял?).

Да, потактовый вывод символа. Алгоритм на ЯП - отправная точка, не более. Но по нему видно, где и как можно распараллелить.

 

Обсуждение будущего функциональных описаний свелось к банальному флуду ЯП vs HDL на сегодняшнем уровне.

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

[SM 0]

полезно взглянуть на настоящее без розовых очков.

И не менее полезно освободится от многодесятилетней догмы мышления последовательными мерками ЯП. Сделайте сами себе библиотеку, где будут все нужные параметризованные модули под удобную для Вас запись. Так нет, запретили делать библиотеки. Преобразование на делителях не нравится, видите ли ISE его не синтезирует, и места много занимает. А как будто бы прямой синтез с Вашего паскалеописания что-то принципиально другое бы насинтезил. Двоично-десятичная арифметика не нравится, видите ли усложнение проблемы. Хотя на самом деле наоборот, упрощение, ликвидация лишних не нужных в задаче преобразований, образовавшихся из-за записи на ЯП, а точнее даже не из-за записи, а из-за ориентированности программ, созданных с помощью этого ЯП, на исполнение на машинах с двоичной арифметикой. Предложу еще какое нибудь решение - заранее понятно, что оно не подойдет из какого-то еще принципиального соображения. Так что уж давайте как нибудь сами с этими задачками с невнятными меняющимися по ходу действия ограничениями по правилам записи.... То, видите ли "Речь о методиках записи/описания алгоритмов в синт.HDL", то вдруг приоритет меняется на какую-то там оптимальность.

 

Что касается сложности записи КА - нет ничего сложного. Вывод строки с "мгновенным" пропуском пробелов (нулевые кода, на которые заменялись бы ведущие нули при формировании строки) выглядит достаточно просто, как-то так

 

always @(posedge clk)
begin
  if (reset) cnt = 0;
  char_found=0;
  for (i=cnt; i<max_string_length; i=i+1)
    if (!char_found && |string[i])  
    begin
      output_byte = string[i];
      char_found=1'b1;
      cnt=i+1'b1;
    end
end

 

И синтезируется это всем чем ни попадя с закрытыми глазами. Специально не стал применять мало чем синтезируемое, но более понятное тоже самое:

always @(posedge clk)
begin
  if (reset) cnt = 0;
  for (i=cnt; i<max_string_length && !(|string[i]); i=i+1);
  output_byte = string[i];
  cnt = i+1;
end

 

Добавить сюда зануление cnt в конце строки - в шесть секунд, один if на код символа. Даже один "?:" в прсвоении cnt. И ничем не сложнее записи на ЯП, только, в отличие от ЯП, с привязкой ко времени, когда нужен результат.

 

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

[Leka 1]

for (i=cnt; ...

И синтезируется это всем чем ни попадя с закрытыми глазами.

??? (если cnt - не константа)

Изменено 3 марта, 2010 пользователем Leka

[SM 0]

??? (если cnt - не константа)

Ну если Ваш синтезатор опять не берет, сделайте от нуля, а в if добавьте условие i>=cnt. Принципиальной разницы нет. Это уже подгонка под условия и не принципиально. Этот for не generate и не обязан быть весь из себя константами.

 

PS. Я же говорил - что не напиши, все равно придеретесь к какой нибудь непринципиальной мелочи. Так и оказалось. Все. Смысла продолжать эту бестолковщину нет.

[Leka 1]

PS. Я же говорил - что не напиши, все равно придеретесь к какой нибудь непринципиальной мелочи. Так и оказалось. Все. Смысла продолжать эту бестолковщину нет.

 

Квартус тоже не берет. Это не мелочь. Попробуйте придумать какой-либо работающий пример, демонстрирующий пользу от "while" в синтезируемом HDL - столкнетесь с теми-же ограничениями.

[SM 0]

Ну я не пойму - Вы издеваетесь? Самому переставить с

 

for (i=cnt; i<max_string_length && !(|string); i=i+1);

 

на тоже самое, но вид сбоку:

 

for (i=0; i<max_string_length && (!(|string) || i<cnt); i=i+1);

 

или вообще на for (i=0; i<max_string_length; i=i+1); и переносе проверки i<cnt в тело цикла?

 

никак не получается? Синтезатор не съел, все, тупик, кирдык, дальше поезд не идет, совет на форуме нужен?

 

Хотя отчетливо помню, что синтезировал я чем-то с присвоением начального значения от переменной. А вот в условии окончания цикла разрешало оно только константу. Поэтому первый вариант сделал именно с константой в условии окончания.

[Leka 1]

Просто очень удивился записи "for(i=cnt; ...", поэтому заострил на этом внимание, не поленился проверить в синтезаторах. Перенос проверки i>=cnt в тело цикла, конечно, решает проблему синтезируемости. Но не решает мою задачу - упростить описание последовательных алгоритмов. На чисто параллельном описании далеко не уехать (убеждать не буду).

[SM 0]

На чисто параллельном описании далеко не уехать (убеждать не буду).

А меня и не убедишь в этом. Потому как сам когда-то такой же был и столь же самоуверенный, пока не вышиб из собственной головы все эти догмы программирования, что "удобно только так, как это привычно и принято в ЯП", а шаг влево/вправо от догм ЯП (та же дв-десятичная арифметика, или вместо строк переменной длины строка постоянной, но с нуль-символами пропускаемыми, и т.п. "отклонения от общепринятой нормы") - сразу расстрел. Но я уже этот этап прошел... Описания на HDL после этого стали не сложнее описаний на ЯП, они просто были "принципиально неправильные" до поры до времени.

 

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

[Leka 1]

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

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

[SM 0]

Сейчас ломаю голову, как покрасивее обобщить понятие "клок".

И сильно сомневаюсь, что придумаете нечто более красивое, чем имеющиеся и так в верилоге "always @событие" или "wait событие". Кстати даже древнейший behavioral compiler умел синтезить последовательные описалки на верилоге c wait-ами. Но прекратил свое развитие. Так как (пока что) все со временем приходят, что та "простота" последовательных описаний лишь кажущаяся.

[cms 0]

Полное описание "устройства" на HDL по-любому (даже с делением) получится очень громоздким по сравнению с программой на ЯП

 

$write("%x",4'b1101);

 

Вот HDL-решение эквивалентное решению на ЯП.

[Leka 1]

$write("%x",4'b1101);

 

Вот HDL-решение эквивалентное решению на ЯП.

Речь о синтезируемом подмножестве HDL.

 

Лично я очень редко симулирую на HDL. Полуавтоматом перевожу синтезируемое HDL описание на ЯП, эмуляция получается намного быстрее.

[SM 0]

Речь о синтезируемом подмножестве HDL.

Ну все же обясните, почему поведенческие (behavioral) и ESL-синтезаторы Вы отмели как поганой метлой? У которых синтезируемое подмножество прямо вот на сегодня на порядок шире, чем у обычных синтезаторов?

[Leka 1]

Ну все же обясните, почему поведенческие (behavioral) и ESL-синтезаторы Вы отмели как поганой метлой? У которых синтезируемое подмножество прямо вот на сегодня на порядок шире, чем у обычных синтезаторов?

Не отметал, нет у меня таких супер-синтезаторов. А про их реальные возможности интересно было узнать. Поэтому и сделал предложение:

http://electronix.ru/forum/index.php?showt...st&p=724819

Задачку, из разряда "лампочкой мигнуть" - подобрал, разжевал...