fixed-point, matlab, fpga - помогите разобраться Опции

[_Ivan_33]

Добрый день.

Требуется совет на следующую задачу.

У меня есть алгоритм расчета нескольких величин(алгоритм управления), где присутствуют синусы, косинусы, возведения в квадрат, извлечение корня, деление, а также функции заданные поточечно в том числе двух аргументов...
Мне нужно сделать этот алгоритм в плис, и ксайлинкса и альтеры. Использовать ядра библиотек производителей - лучше не надо...
Для начала мне нужно определиться fixed point или float point арифметику мне использовать. Я изначально выбрал первое, так как если самому все писать с нуля, то очень много времени пройдет.
Потом стал вопрос об ошибке расчета величин из-за погрешности перевода fixed-point из float. Для этих целей я хочу использовать матлаб, чтобы если что в некоторых местах изменять разрядность данных, дабы оптимизировать проект по площади. Допустим я делаю простую модель в симулинке, где есть из источника ramp и она расходится на 2 ветки - double и fixed и умножается на коэффициент усиления. Как мне найти ошибку между результатом double и fixed?

[RHnd]

Почему нельзя вычесть результат одной ветки из результата другой?

[Fat Robot]

В симулинке, когда у вас готова fxp-модель, то ее можно преобразовать в flp, а потом обратно, с помощь одного чекбокса в model properties (не помню где, но точно помню, что делал).

Далее в симулинке есть Fixed-Point Designer, который по сути будет строить гистограмму распределения порядка значений в указанных точках, с тем, чтобы вы смогли оценить требуемую разрядность fxp числа.

[syoma]

В симулинке, когда у вас готова fxp-модель, то ее можно преобразовать в flp, а потом обратно, с помощь одного чекбокса в model properties (не помню где, но точно помню, что делал).
Далее в симулинке есть Fixed-Point Designer, который по сути будет строить гистограмму распределения порядка значений в указанных точках, с тем, чтобы вы смогли оценить требуемую разрядность fxp числа.

Да, только порядок действий наоборот.
С начала надо использовать FPD, чтобы преобразовать FLP в FXP. Причем процес интересно автоматизиуемый - нужно просто задать минимальные и максимальные значения на входе и нужную погрешность на выходе, и он сам рассчитает нужную разрядность всех сигналов.

Чекбокс в model properties нужен для того, чтобы модель можно было моделировать тем у кого нету Fixed Point Designer. Ну и помоему она ускоряет моделирование.

ПС. Кстати после получения fxp модели уже пол-дела сделано для получения ПЛИСовского кода - достаточно только задержки добавить и HDL Coderу скормить.

[Fat Robot]

Переход от FXP обратно к FLP нужен прежде всего для оценки шумов FXP-реализации. А то, что там у кого-то чего-то нет - это вторично.

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

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

Такие дела.

нужно просто

[_Ivan_33]

RHnd, спасибо, что-то я завис. Можно еще тупо построить 2 графика из командной строки матлаба - с помощью plot & hold on

syoma, круто! А минимальные и максимальные значения мы задаем на входе первого элемента схемы или это делается где-то в свойствах системы? А где посмотреть про то, как добавлять задержки?(имеется ввиду ступени конвейера, регистровые). И получается есть какой-то другой способ перегона модели в hdl код, кроме code -> hdl code -> generate hdl? Я еще тут немного поигрался, получается все блоки типа синуса, корня и так далее этот генератор делает как экземпляры, а разработчик уже дальше вставляет свой код ядра для вычисления этих величин?

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

[Fat Robot]

Речь шла про hdl-кодер, а не про симулинк в целом. Т.е. обычно делается bit-accurate модель в симулинке, дальше кто-то эту модель описывает на яоа. Далее тестовые векторы, сгенерированные в модели, используются для верификации rtl.

Если хочется инноваций, то можно

и HDL Coderу скормить

. Но трудозатраты на подготовку модели для этого будут соизмеримы с описанием на яоа. Ну и конечно получившийся в результате код ни для какой серьезной дальнешей работы (sta, p&r и т.п.) не пригоден.

Просыпайтесь!

Fat Robot, насчет соизмеримости - мне кажется

[syoma]

Если хочется инноваций, то можно и HDL Coderу скормить Но трудозатраты на подготовку модели для этого будут соизмеримы с описанием на яоа. Ну и конечно получившийся в результате код ни для какой серьезной дальнешей работы (sta, p&r и т.п.) не пригоден.

Ваши знания по HDL Coderу, как бы это по мягче сказать, слегка устарели, или Вы так и не поняли как пользоваться данным продуктом.
Мы уже 6 лет пользуемя автоматической генерацией HDL Кода. Прошли и Xilinx System Generator и сейчас юзаем HDL Coder вместе с ним. Трудозатраты несоизмеримые, а главное процесс самого кодинга на ЯОА отсутствует, что позволяет самому разработчику алгоритма без знаний HDL, а только со знанием принципов построения ПЛИСов, разрабатывать, проверять и запускать свои алгоритмы в реальном железе.
Ну а на счет серьезной дальнейшей работы - у нас не студенчиские проекты, а вполне реальные системы управления силовой электроникой на сотни мегават на Virtex-6 с гигабитными трансиверами. И все на матлабе.
Понятно, что если важна сильная оптимизация по ресурсам, то нужен ручной кодинг. Но сами по себе проекты, где используются такие ПЛИС обычно не требовательны к минимальной стоимости чипов - в случае чего берется просто больший чип.

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

Что-то я не помню тут больших обсуждений и тем более такого итога.

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

Как говорил Fat Robot - это зависит от вашей модели. В случае с обратными связями может придется вводить разрядность вручную. Обычно задается для каждого входа индивидуально. Или создается Харнесс - генераторы сигналов нужной амплитуды, чтобы прогнать модель по всем возможным значениям, тогда FPD сам определит максимумы и минимумы.
По задержкам - можно задать вручную в свойствах блока, можно повставлять Delays. В этом HDL Coder немного проигрывает System Generator, так как в последнем задержки в блоках моделируются, а в HDL Codere нет - т.е. нет cycle true. Но зато в HDL Codere есть прикольная вешь, как автоматическия конвееризация - есть несколько каналов, задаешь задержку и шеринг фактор и оно генерит код, в котором один единственный умножитель апсемплируется и используется для всех каналов. А захотел - сгенерит несколько параллельных умножителей. Или что-то посередине.

И получается есть какой-то другой способ перегона модели в hdl код, кроме code -> hdl code -> generate hdl?

Да этим способам уже скоро десяток лет будет вообще-то. Есть Xilinx System Generator. Для Альтеры есть свой тулбокс. Есть у альтиума помоему что-то. HDL Coder, конечно. Смысл в том, что модель можно перегнать в синтезируемый HDL код по клику мышкой.

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

Нет. Для каждого блока генерится свой HDL код, либо используется IP библиотека от нужного производителя, которая выполняет данную функцию. Либо заменяется таблицей в BRAM. Все в зависимости от предпочтений. На выходе Вы получите полностью рабочий HDL код, который скармливаете синтезатору и P&R как он есть. Там уже все будет.
Свой код можно добавить если у Вас уже есть своя реализация какой либо функции на HDL либо вы хотите еще больше оптимизировать.

[Fat Robot]

То что вы рассказываете, это прекрасно. Выводы для области применения hdl-coder'a, исходя из вашего описания, для меня такие:
- Экспериментальные проекты и/или проекты на несерийное количество устройств.
- Нечувствительность к цене целевой fpga
- Нечувствительность к русурсам (gate count) и потреблению
- Нечувствительность к формальному управлению проектами (невозможность сделать diff, merge и т.п. для simulink-модели) Т.е. проекты скорее всего функционально не нагруженные, коллектив разработчиков невелик, нет разделения по специлизациям.
- Уровень ответственности при разработке функционала FPGA скорее всего невелик.

По поводу того, что я понял или нет: FPGA не является для меня целевой архитектурой, равно как и не выполняется ни одно вышеприведенных условий.

[syoma]

То что вы рассказываете, это прекрасно. Выводы для области применения hdl-coder'a, исходя из вашего описания, для меня такие:
- Экспериментальные проекты и/или проекты на несерийное количество устройств.
- Нечувствительность к цене целевой fpga
- Нечувствительность к русурсам (gate count) и потреблению
- Нечувствительность к формальному управлению проектами (невозможность сделать diff, merge и т.п. для simulink-модели) Т.е. проекты скорее всего функционально не нагруженные, коллектив разработчиков невелик, нет разделения по специлизациям.
- Уровень ответственности при разработке функционала FPGA скорее всего невелик.

Первые три - правильно.
Насчет управления проектами - не совсем - да, коллектив разработчиков небольшой - всего 3 с половиной человека. И да, стараемся не делить по специализациям и каждый делает свой проект. Но SVN и diffы очень даже летают, так как для симулинка уже давно есть тулзы, позволяющие сравнивать все и вся. Плюс - широко используется т.н. Model Referencing, т.е. повторное использование отдельных систем в том случае, если в нескольких проектах используется одна и та же функция. Ну и соответственно все интегрировано с системами управления багами и требованиями - для каждой функции есть требование, по нему разрабатывается модель контроллера и верификацационная модель. Все проверяется. И потом другой человек еще делает верификацию в железе. Все требования трассируются до железа. Ну это упрощенно.
Ну и по последнему требованию - совсем не то. В наших проектах ПЛИСины используется в системах управления реального времени. Баг в софте для такой штуки будет стоить от 100 тыс $ тупо взорвавшегося оборудования. Поэтому все проверяется по десять раз до и после.

Но вот насчет понимания, где выгода всего этого - дело в том, что огромное количество ошибок и проблем возникает на этапе кодинга - то баг создал, то вдруг оказывается, что то и то нереализуемо в железе и нужно менять весь алгоритм. Ну а если этот кодер просто уволился после проекта - то можно вешаться. Уборка этого звена в разработке намного уменьшает количество ошибок, обнаруженных на конечных стадиях проекта, которые как известно стоят намного больше, чем в его начале. Опять же портация - мигрирование на следующую ПЛИСину сравнительно простое.

ПС. Кстати данный подход еще больше применяется для другой целевой архитектуры - Микропроцессоров и Микроконтроллеров. Си-код генерится только так.

[petrov]

А откуда в силовой электронике такие полосы сигналов чтобы virtex 6 требовался для их обработки?

[Fat Robot]

Т.е. я правильно понимаю, что включение в маршрут разработки hdl-coder'a как-то позволяет обойти аппаратные ограничения целевой платформы?

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

[syoma]

Т.е. я правильно понимаю, что включение в маршрут разработки hdl-coder'a как-то позволяет обойти аппаратные ограничения целевой платформы?

Не позволяет обойти, а позволяет учесть еще на этапе создания и проверки модели алгоритма. Например ту же фиксированную точку - погрешности, разрядности, шумы квантизации и особенности переполнения можно промоделировать задолго до генерации кода. Точно так же с влиянием задержек и регистров.
И в итоге в конце реально получается, что все алгоритмы, что можно представить средствами симулинка, DSP тулбокса или Stateflow легко превращаются в работающий HDL код.

А вот если разработчик напихает for loops или еще чего-то такого, а потом скажет - засунь-ка мне это в ПЛИС, да и еще чтобы тактовая была 400МГц и считало оно мне это все за один такт, и результат - как на бумаге и кодер скажет - нефиг делать, не особо вникая в алгоритм - могут приколы получиться...

[Fat Robot]

Ясно. Если квалификация инженеров такая, как в этом повествовании, то да. Без робота-кодера никак не обойтись.

Успехов.

А вот если разработчик напихает ..., а потом скажет ..., и кодер скажет...

[_Ivan_33]

Я посмотрел вот это видео https://www.mathworks.com/videos/introducin...link-81554.html и вроде разобрался
Получил ошибку в 3*10^-3, что для меня приемлимо при ширине слова в 16 бит.
А есть ли документик, где есть описание всех блоков HDL кодера, а то на сайте матворкса утверждают, что у меня нет на него лицензии
И все таки интересует реализация синуса и корня у HDL кодера в матлабе - это сделано на кордике и есть прям незашифрованный верилог или вхдл файл для установки экземпляра ядра?

[_Ivan_33]

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

[SemperAnte]

Команда hdllib внутри Матлаба открывает библиотеку поддерживаемых элементов для hdl кодера.

[_Ivan_33]

Все-таки остался висеть следующий вопрос:

Вот я сделал модель, прогнал симуляцию, перевел все в fixed-point, прогнал симуляцию, сравнил результаты. Теперь я генерю hdl код. Он у меня делается как wire, без регистров. Если вставить туда блок delay z^-1 то выходной график сдвигается на 2 единицы времени относительно модель без блока delay и отбрасываются биты дробной части из-за чего график становится угловатым. HDL код вообще не генерится. Что я делаю не так?

[SemperAnte]

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

Если вам нужно поставить регистры по входу или выходу подсистемы, то это можно сделать в настройках "HDL Code" -> "HDL Block Properties".

[_Ivan_33]

а вот еще вопрос - у меня получилось так, что длина слова меньше, чем длина дробной части - это глюк или фича? может я что-то недопонимаю, или прога мне намекает, что надо увеличить ширину слова?

[SemperAnte]

Просто динамический диапазон вашего числа меньше единицы.

Например, для типа unsigned:

ufi(x, 16, 16) - диапазон 0 <= x < 1
ufi(x, 16, 17) - диапазон 0 <= x < 0.5
ufi(x, 16, 18) - диапазон 0 <= x < 0.25
и т.д.

[_Ivan_33]

спасибо!

[_Ivan_33]

Еще вопрос - что то не получается у меня сделать конвеиеризацию дизайна. Я нашел в свойствах только HDL Block Properties и там есть Input pipeline и output pipeline, а также включение distributed pipelining. Но что-то не помогает. Подскажите, куда копать?

[SemperAnte]

Вроде, все так и делается. Включается опция "DistributedPipelining" и, скажем, в "InputPipeline" прописывается количество регистров конвейера.

На семинаре показывали пример, где Матлаб делал временной анализ через подключенный Xilinx ISE, находил наиболее критические пути, вставлял регистры, и прямо в окне Симулинка отображал время распространения сигнала на каждом отрезке.

Сообщение отредактировал SemperAnte - Sep 5 2014, 08:33

[_Ivan_33]

CODE

`timescale 1 ns / 1 ns

module Calc_X4
(
clk,
reset_n,
clk_enable,
In1,
ce_out,
Out1
);


input clk;
input reset_n;
input clk_enable;
input signed [15:0] In1; // sfix16_En10
output ce_out;
output signed [15:0] Out1; // sfix16_En10


wire enb;
reg signed [15:0] in_0_pipe_reg [0:2]; // sfix16 [3]
wire signed [15:0] in_0_pipe_reg_next [0:2]; // sfix16_En10 [3]
wire signed [15:0] In1_1; // sfix16_En10
wire signed [31:0] Gain4_mul_temp; // sfix32_En24
wire signed [15:0] Gain4_out1; // sfix16_En10
wire signed [15:0] Add6_out1; // sfix16_En10
wire signed [15:0] Saturation4_out1; // sfix16_En10
reg signed [15:0] Saturation4_out1_1; // sfix16_En10


assign enb = clk_enable;

always @(posedge clk)
begin : in_0_pipe_process
if (reset_n == 1'b0) begin
in_0_pipe_reg[0] <= 16'sb0000000000000000;
in_0_pipe_reg[1] <= 16'sb0000000000000000;
in_0_pipe_reg[2] <= 16'sb0000000000000000;
end
else if (enb) begin
in_0_pipe_reg[0] <= in_0_pipe_reg_next[0];
in_0_pipe_reg[1] <= in_0_pipe_reg_next[1];
in_0_pipe_reg[2] <= in_0_pipe_reg_next[2];
end
end

assign In1_1 = in_0_pipe_reg[2];
assign in_0_pipe_reg_next[0] = In1;
assign in_0_pipe_reg_next[1] = in_0_pipe_reg[0];
assign in_0_pipe_reg_next[2] = in_0_pipe_reg[1];



assign Gain4_mul_temp = 21105 * In1_1;
assign Gain4_out1 = Gain4_mul_temp[29:14];



assign Add6_out1 = 10222 - Gain4_out1;



assign Saturation4_out1 = (Add6_out1 > 16'sb0100110000000000 ? 16'sb0100110000000000 :
(Add6_out1 < 16'sb1011010000000000 ? 16'sb1011010000000000 :
Add6_out1));



always @(posedge clk)
begin : out_0_pipe_process
if (reset_n == 1'b0) begin
Saturation4_out1_1 <= 16'sb0000000000000000;
end
else if (enb) begin
Saturation4_out1_1 <= Saturation4_out1;
end
end



assign Out1 = Saturation4_out1_1;

assign ce_out = clk_enable;

endmodule // Calc_X4

что-то не то...


в модели delays блоков не ставил, поставил distributed pipelining в on, input pipieline - 3, output pipeline - 1

[des00]

CODE

`timescale 1 ns / 1 ns

module Calc_X4
(
clk,
reset_n,
clk_enable,
In1,
ce_out,
Out1
);


input clk;
input reset_n;
input clk_enable;
input signed [15:0] In1; // sfix16_En10
output ce_out;
output signed [15:0] Out1; // sfix16_En10


wire enb;
reg signed [15:0] in_0_pipe_reg [0:2]; // sfix16 [3]
wire signed [15:0] in_0_pipe_reg_next [0:2]; // sfix16_En10 [3]
wire signed [15:0] In1_1; // sfix16_En10
wire signed [31:0] Gain4_mul_temp; // sfix32_En24
wire signed [15:0] Gain4_out1; // sfix16_En10
wire signed [15:0] Add6_out1; // sfix16_En10
wire signed [15:0] Saturation4_out1; // sfix16_En10
reg signed [15:0] Saturation4_out1_1; // sfix16_En10


assign enb = clk_enable;

always @(posedge clk)
begin : in_0_pipe_process
if (reset_n == 1'b0) begin
in_0_pipe_reg[0] <= 16'sb0000000000000000;
in_0_pipe_reg[1] <= 16'sb0000000000000000;
in_0_pipe_reg[2] <= 16'sb0000000000000000;
end
else if (enb) begin
in_0_pipe_reg[0] <= in_0_pipe_reg_next[0];
in_0_pipe_reg[1] <= in_0_pipe_reg_next[1];
in_0_pipe_reg[2] <= in_0_pipe_reg_next[2];
end
end

assign In1_1 = in_0_pipe_reg[2];
assign in_0_pipe_reg_next[0] = In1;
assign in_0_pipe_reg_next[1] = in_0_pipe_reg[0];
assign in_0_pipe_reg_next[2] = in_0_pipe_reg[1];



assign Gain4_mul_temp = 21105 * In1_1;
assign Gain4_out1 = Gain4_mul_temp[29:14];



assign Add6_out1 = 10222 - Gain4_out1;



assign Saturation4_out1 = (Add6_out1 > 16'sb0100110000000000 ? 16'sb0100110000000000 :
(Add6_out1 < 16'sb1011010000000000 ? 16'sb1011010000000000 :
Add6_out1));



always @(posedge clk)
begin : out_0_pipe_process
if (reset_n == 1'b0) begin
Saturation4_out1_1 <= 16'sb0000000000000000;
end
else if (enb) begin
Saturation4_out1_1 <= Saturation4_out1;
end
end



assign Out1 = Saturation4_out1_1;

assign ce_out = clk_enable;

endmodule // Calc_X4

что-то не то...


в модели delays блоков не ставил, поставил distributed pipelining в on, input pipieline - 3, output pipeline - 1

по коду все верно. 3 на входе, 1 на выходе. что именно вам не нравится ?

[_Ivan_33]

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

[des00]

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

Ретайминг оставляют на совести средства синтеза. по феншую это руками или кодом

ЗЫ. уберите saturation который по умолчанию у вас стоит. частотку валит достаточно сильно

[_Ivan_33]

Увы, saturation стоит осознанно. То что синтезом будут добавляться новые регистры - знал, но то, что это очень сильно исправит тайминги - нет. Буду иметь в виду, хотя по всей видимости придется все дописывать ручками.

[des00]

Увы, saturation стоит осознанно. То что синтезом будут добавляться новые регистры - знал, но то, что это очень сильно исправит тайминги - нет. Буду иметь в виду, хотя по всей видимости придется все дописывать ручками.

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

[_Ivan_33]

Спасибо за разъяснения, des00, но моя совесть должна быть чиста, ибо проект будет использоваться и на альтере и на ксайлинксе и не хотелось бы полагаться на САПРы чипов заморских...

[syoma]

Saturation обещали пофиксить в следующем релизе, который уже не за горами. Мы тоже на эти грабли попадали, пока не разобрались и не научились обходить.
Еще текущая версия имеет особенность, что по умолчанию стоит асинхрониий ресет, и этот самый ресет при попытке использовать DSP48 на ксайлинксе просто не дает синтезатору распределить регистры внутри этого примитива, что ессно приводит к очень плохим таймингам. Мы долго мудохались, впихивая по 5 delays и не понимая, чего ISE не хочет их правильно распределять. Потом галочку убрали и дизайн полетел.

[x736C]

syoma, тенденция как раз такая, что чем более ответственное применение (Ваш случай), тем обширнее использование кодогенерации проверенными (квалифицированными) инструментами. Аэробус более 80% кода производит кодогенераторами. Да и вообще, все хорошо расписали. Просто hdl-кодогенерация в Матлабе слегка отстает от «сишной», т.к. и появилась она позже. На Си все получается даже оптимальнее (по нашему опыту), чем ручками. Хотя сами ребята из Софтлайна говорили, что код на 10% больше и тормознее «ручного».

[Fat Robot]

А можно ли прочитать где-нибудь про эту практику Airbus?

Аэробус более 80% кода производит кодогенераторами.

[x736C]

А можно ли прочитать где-нибудь про эту практику Airbus?

Не знаю, можно ли почитать про саму практику, все-таки конкретные процессы это во многом коммерческая тайна.

Но в подтверждение своих слов, например, древняя статья airbus efficient code generation за 1997 год из гугла:

http://websrv0a.sdu.dk/ups/SWC/materials/c...-generation.pdf

Утверждается, что для A340 Airbus на автоматически сгенерированный код приходилось 70% от общего объема. И далее много всего.

Вот еще статья за 2009 http://gforge.enseeiht.fr/docman/view.php/...o_sept_2009.pdf

В ней пишут, что в Airbus провели сравнение двух методов проектирования — классического и с 75%-м преобладанием сгенерированного кода. Сравнение показало общее снижение стоимости в три раза, цикл разработки сократился в четыре раза.

Ну, а если брать авионику, всякий Гармин и подобное, то подозреваю, что там доля сгенерированного кода стремится к 100%.

В сети можно найти утверждения, что Eurocopter в своих автопилотах использовали 90% автокода от SCADE.

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

Сообщение отредактировал x736C - Sep 19 2014, 10:07