[Leka 1]

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

Задачу рассматривать, как учебную - разбор языков, методик, средств синтеза для ПЛИС. "Устройство печати таблицы умножения беззнаковых чисел 1..10000".

module test(output [7:0] data, output en, input rst, clk).

С нуля, без использования каких-либо готовых компонентов, библиотек, мегафункций, софт-процессоров, и тп. Минимальные ресурсы FPGA, аппаратный умножитель(те понадобится описать устройство преобразования числа в ascii строку), клок ~100МГц, вывод ~100 млн. символов/сек, 100 млн. + 2 строки:

"Таблица умножения:

1 * 1 = 1

1 * 2 = 2

...

10000 * 10000 = 100000000

Не забудьте выключить принтер."

[SM 0]

Ну при программной реализации на С тогда тоже нельзя использовать готовые библиотеки. Соотв. ни prinf, ни даже putchar :)

 

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

[Builder 1]

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

ПЛИСины пока что дорогие, что бы разбрасываться их ресурсами на "программирование мышкой"

Вот тут Вы ошибаетесь, ПЛИС сильно подешевели, уже стоимость ячейки не та что было 10 лет назад.

УЖЕ наметилась тенденция, когда в проект ставят бОльшую ПЛИС, с запасом и нужно сделать прокт не меньше по объёму, а

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

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

Но чем дальше, ем тенденция думаю будет усиливаться...

По моему всё будет как и у программеров, отличие железа только в том, что не просто сделать высокоуровневые средства разработки, что-бы они давали результат, сравнимый с результатом C-asm, в случае C-asm теория проработалась, формально. В HDL сложнее получается.

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

Или эволючионируют во что-то другое или появится замена. Но по аналогии с asm-C, полностью не умрут, просто менее обширно будут применяться.

Не в ближайшие годы, но к этому придём.

 

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

[Mahagam 0]

Вот тут Вы ошибаетесь, ПЛИС сильно подешевели, уже стоимость ячейки не та что было 10 лет назад.

УЖЕ наметилась тенденция, когда в проект ставят бОльшую ПЛИС, с запасом и нужно сделать прокт не меньше по объёму, а

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

в стоимости продукта.

именно что такое только в мелкосерийных изделиях. действительно _массово_ ПЛИС очень дороги. для массовости, правда, есть ультрадешёвый (в мегаобъёмах конечно) ASIC. но это ж не FPGA.

[SM 0]

для массовости, правда, есть ультрадешёвый (в мегаобъёмах конечно) ASIC. но это ж не FPGA.

Есть еще и промежуточные варианты. Gate array - ASIC, но с изготовлением всего лишь одной-двух масок вместо пары десятков - цена старта не велика. Ну и всякие там hardcopy - sctructured asic. Что же касается FPGA - на сегодня это по любому дорогое решение, но во многих случаях безальтернативное. Кстати о птичках - обсуждаемые тут перспективы ESL/HSL-синтеза и развития HDL в эту сторону на мой взгляд куда более актуальны для чипостроителей, нежели FPGAшников (ну то, что прототип чипа отлаживается на фпга, умолчу, это все равно не изделие на фпга). Потому что системы такой сложности, которые стоит синтезировать ESL-синтезом влезают разве что в фпга стоимостью более килобакса, и я очень сомневаюсь, что это широкий рынок. А вот чипы сравнимого объема - это налево и направо - любой SoC.

[Leka 1]

Соответствующая программа на Паскале, без библиотек и тп, с выводом числа в виде ascii строки. "write()" - просто вывод одного символа, в устройстве - формирование строба готовности данных. Алгоритм "printd()" - с учетом возможного распараллеливания в устройстве - первое, что пришло в голову, может и получше можно записать.

Задача - синтезировать устройство с подобным алгоритмом.

procedure prints(s : string; n : longint);
var i : longint; 
begin 
    for i := 1 to n do write(s[i]);
end;

procedure printd(d : longint); // 0 < d < 1000000000
const 
    s = '123456789';
    a : array[1..9,1..9] of longint = (
         (100000000, 200000000, 300000000, 400000000, 500000000, 600000000, 700000000, 800000000, 900000000),
         (10000000, 20000000, 30000000, 40000000, 50000000, 60000000, 70000000, 80000000, 90000000),
         (1000000, 2000000, 3000000, 4000000, 5000000, 6000000, 7000000, 8000000, 9000000), 
         (100000, 200000, 300000, 400000, 500000, 600000, 700000, 800000, 900000), 
         (10000, 20000, 30000, 40000, 50000, 60000, 70000, 80000, 90000), 
         (1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, 9000), 
         (100, 200, 300, 400, 500, 600, 700, 800, 900), 
         (10, 20, 30, 40, 50, 60, 70, 80, 90), 
         (1, 2, 3, 4, 5, 6, 7, 8, 9)
    ); 
var 
    i, j, k : longint; 
    c : char;
    en : boolean;      
begin
    en := false;
    for i := 1 to 9 do if (en or (d >= a[i, 1])) then begin
        en := true;
        c := '0'; 
        k := 0;
        for j := 1 to 9 do if (d >= a[i, j]) then begin
            c := s[j];
            k := a[i, j];    
        end;
        d := d - k;
        write(c);
    end;
end;

const 
    s1 = 'Таблица умножения'#13#10;
    s2 = ' * ';  
    s3 = ' = '; 
    s4 = #13#10; 
    s5 = 'Не забудьте выключить принтер'#13#10; 
    n1 = length(s1); 
    n2 = length(s2);    
    n3 = length(s3); 
    n4 = length(s4);   
    n5 = length(s5);     
var i, j, k : longint;
begin
  prints(s1, n1);   
  for i := 1 to 10000 do for j := 1 to 10000 do begin
      k := i * j; 
      printd(i);  prints(s2, n2); 
      printd(j);  prints(s3, n3);
      printd(k);  prints(s4, n4);       
  end;    
  prints(s5, n5);   
end.

[Leka 1]

Ну и когда синтезируемые HDL достигнут уровня ЯП 70-х годов прошлого века?

[SM 0]

Вам надо, Вы и пишите сами. Как - я уже подсказал. Ни умножения не надо, ни "printd" - сразу в двоично-десятичном коде все делать.

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

[Methane 0]

Ну и когда синтезируемые HDL достигнут уровня ЯП 70-х годов прошлого века?

Та давно уже достигли. Опишите процессор и к нему ROM с программой. Сложно чтоли?

[Leka 1]

Та давно уже достигли. Опишите процессор и к нему ROM с программой. Сложно чтоли?

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

[SM 0]

основу алгоритма преобразования числа в строку

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

 

Хотите синтезируемое число->строка? Пожалуйста. До нужной разрядности сами добейте.

 

module int2str( input [7:0] byte, output [23:0] string);

 

assign output[7:0] = (byte % 10) + 48;

wire [7:0] temp_a = byte / 10;

assign output[15:8] = (temp_a % 10) + 48;

assign output[23:16] = (temp_a / 10) + 48;

 

endmodule

 

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

[Leka 1]

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

Речь о методиках записи/описания алгоритмов в синт.HDL и ЯП, конкретная задача с конкретными условиями - только чтобы разговор конкретным был. Сначала хотел предложить задачу N-ферзей, потом подобрал задачку попроще. Так что двоично-десятичная арифметика не принимается, это уход от сути проблем.

 

Хотите синтезируемое число->строка? Пожалуйста. До нужной разрядности сами добейте.

module int2str...

1) Для вывода 9-значного результата понадобится 9 делителей --> 9 мегафункций с индивидуальными настройками, тк ISE не синтезирует "/" и "%". Не говоря про скорость, луты, ...

2) printd() - далеко не вся задача.

[Des333 0]

... тк ISE не синтезирует "/" и "%"...

 

Хехе, Альтера рулит!  :)

[SM 0]

Речь о методиках записи/описания алгоритмов в синт.HDL и ЯП

.....

1) Для вывода 9-значного результата понадобится 9 делителей --> 9 мегафункций с индивидуальными настройками, тк ISE не синтезирует "/" и "%". Не говоря про скорость, луты, ...

 

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

 

И, в конце концов, почему ISE синтез? Чем BlueSpec ESL-синтезатор с SV хуже? А на том уровне Ваша задачка будет в пол-строчки. Образно. И тоже синтезируема. Весь топик ведь о развитии HDL-описаний и функциональных описаний в общем смысле. О будущем синтеза как аппаратных реализаций с функциональных описаний, так, возможно, и программных. А не о настоящем, причем в рамках имеющегося у Вас лично ISE.

[Leka 1]

Вот именно, с методиками записи все нормально.

Ничего не нормально. Полное описание "устройства" на HDL по-любому (даже с делением) получится очень громоздким по сравнению с программой на ЯП - надо еще описать КА, мультиплексоры, учесть переменную длину строк... И - операция деления дорогая, оптимальным будет посимвольное(последовательное) преобразование числа в строку с одним блоком делителя --> по сложности алгоритм сравнится с printd() на основе сравнения-вычитания.

 

Чем BlueSpec ESL-синтезатор с SV хуже?

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

 

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