[iosifk 3]

Кстати после ПЛИСов, я в процессорах полюбил делать конечные автоматы. Прекрасно позволяют без операционок паралелить программу.

 

Ищите "Шалыто АА. Автоматное программирование"... У него на сайте этого мого и подробно расписано...

 

 

Естественно читал кое-какие материалы, но там не было описано, что "always @ (...)" является триггером-защёлкой.

 

Ищите "Краткий Курс"... Там про триггера написано...

 

[o_khavin 0]

И я как программист, тоже пишу программу. Вот одно мне не понятно, почему вас так это все коробит.

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

Вот решу я заняться написанием кода на С и начну, к примеру, с полного наплевателства на правила преобразования типов. Что мне скажут опытные С-писатели? Возможно пример не настолько удачен, но и я в С большого опыта не имею.

 

Что есть === почему три символа равно?

 

IEEE Std 1364-2001

(Revision of IEEE Std 1364-1995)

...

4.1.8 Equality operators

...

a ===b, a equal to b including x and z

...

a ==b a equal to b, result may be unknown

 

[SM 0]

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

Пишите программы на HDL, пишите... Это полное и неотъемлемое Ваше право. Потом только не удивляйтесь.... Меня это не коробит, я просто по этим граблям ходил лет так 10-15 назад, пробил ими себе пару раз башку, и теперь вот программирую на C и asm, а на HDL устройства описываю. И уважаю людей, желающих пройти по всем граблям самостоятельно, несмотря на то, что мы старательно окрашиваем эти грабли в яркие и заметные цвета и расставляем предупреждающие знаки.

 

П.С. А можете сделать меня немного умнее... что есть === почему три символа равно?

это сравнение с учетом 'x' и 'z' в аргументах, оба этих символа имеют в операторе одинаковый смысл, как 'x', аналогия - case / casex

[2inltd 0]

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

кстати, есть ещё пример из этого же:

module test (pin, led, clock);

input clock;
input pin;
output led;

reg led;
reg ld;

always @ (posedge pin)
    begin
        if (pin === 1)
            begin
                ld = 1;
            end
    end
    
always @ (negedge pin)
    begin
        if (pin === 0)
            begin
                ld = 0;
            end
    end
     
endmodule

Компилится нормально, но если я добавлю:

always @ (posedge clock)
    begin
        if (ld === 1)
            begin 
                led = 1;
            end
                else begin 
                    led = 0;
                end
    end

Опять выскакивает та же самая ошибка. (Error (10028): Can't resolve multiple constant drivers for net "ld" at test.v).

 

[SM 0]

Могу предположить, что если выход ld никуда не подключен, синтезатор его выкидывает вместе со всеми его входными воздействиями еще до того, как начинает разбираться, во что его можно замапить, и можно ли вообще во что-то. (В таком случае Вы должны видеть warning/info, что регистр ld умер своей смертью ввиду неиспользованности.

[Golikov 0]

кстати можно писать

 

always @(posedge pin or negedge pin)
begin

end

 

счетчик внутри можно сделать, можно даже внешним пином помахать с кучей варнингов...

 

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

 

[dxp 34]

Поддержу Golikov A.

 

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

 

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

 

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

[SM 0]

Ну что, пофлудим? :) Жаль уезжать через несколько часов... :D

 

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

 

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

 

 

UPD:

Собственно, аббревиатура HDL сама за себя все говорит - Hardware Description Language - язык описания аппаратных средств - а дальше каждый волен к этому притягивать за уши свои сущности.

[dxp 34]

Ни разу не возражаю против всего, что сказано. Так почему ж HDL не язык программирования, если на нём можно писать программы? :)

 

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

 

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

[SM 0]

Так почему ж HDL не язык программирования, если на нём можно писать программы? :)

 

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

 

 

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

 

for (...) begin

#10

a <= 1'b0;

#10

a <= 1'b1;

end

 

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

[dxp 34]

Никак не могу согласиться с утверждением, что сущность инструмента (язык - инструмент) полиморфно меняется в зависмости от имплементации. Язык - всегда один и тот же. И правила его одни и те же. А то, что имплементация накладывает ограничения и вынуждает следовать определённым правилам, паттернам проектирования, так с этим никто не спорит.

 

Если взять тот же ЯП С, то можно обнаружить, что и его применение тоже очень сильно от целевой платформы (имплементации). Попробуйте на МК со 128 байтами ОЗУ написать программу с malloc'ами - окажется, что это как-то не очень получается, в то время, как на PC даже задумываться на эту тему не приходится.

 

Насчёт прямого и кривого назначения, напомню, что исходно и Veriog, и VHDL (и последователи) разрабатывались как средства моделирования, т.е. как языки программирования. Т.ч. что тут прямое использование, а что кривое - это вопрос.

[2inltd 0]

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

 

for (...) begin

#10

a <= 1'b0;

#10

a <= 1'b1;

end

 

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

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

по мне так без разницы как это называть "писать программу" или "описывать схему". Главное понимать принцип этого действия. А главный принцип в языке HDL, что все процессы происходят параллельно. Здесь нет такого как в программировании на Cи например, где программа выполняется строчка за строчкой. И вы видимо считаете, что если человек занимается "программированием" на HDL, он не в состоянии понять это, да и другие моменты.

[Джеймс 3]

есть ещё пример из этого же:

module test (pin, led, clock);

input clock;
input pin;
output led;
reg led;
reg ld;
always @ (posedge pin)
    begin
        if (pin === 1)
            begin
                ld = 1;
            end
    end
    
always @ (negedge pin)
    begin
        if (pin === 0)
            begin
                ld = 0;
            end
    end
endmodule

Компилится нормально

 

Подождите, Вы продолжаете идти по тому же пути:

 

Я лично считал, что в данном примере создаю регистр под светодиод (reg led;). А потом уже в программе работаю именно с этим регистром

И естественно, я считал, что в регистр в любой момент времени могу записать любое значение.

 

Т.е. считаете что значение регистра можно изменять в разных always?

Для синтеза это в корне неверно.

 

Я правильно понимаю, что Вы изучаете Verilog ээ... интуитивно, а когда появляются трудности, просто задаете вопросы в форуме? Это путь неверный. Вам придется прочитать от начала до конца книгу (руководство) по языку и проработать примеры. Иначе это путь в тупик.

 

Советую начать со стандарта (причем для синтезируемого подмножества есть отдельный документ - IEEE Standard for Verilog Register Transfer Level Synthesis)

Далее советую "The Verilog Hardware Description Language" (один из авторов - Philip Moorby - разработывал Verilog в начале 80-х годов)

Также обратите внимание на великолепный preug.pdf, ссылку на который дал ув. SM

А вот здесь вся коллекция от Synopsys:

http://book.huihoo.com/pdf/crafting-a-chip...-flow/synopsys/

 

В стандарте Вы сходу найдете ответ на свой вопрос:

5.2 Modeling edge-sensitive sequential logic

Sequential logic shall be modeled using an always statement that has one or more edge events

Английский язык не допускает двояких формулировок и "an" означает "один".

 

 

 

 

 

 

Ну и наконец Вы уже достаточно долго возитесь с этой задачкой про светодиод - не находите??

Вот вам готовая логика зажигания:

reg led;
always @(posedge clock or posedge reset)
begin
if (reset)
   led <= #1 1'h0;
     else
       if (on)
         led <= #1 1'h1;
            else
              if (off)
                led <= #1 1'h0;
end

 

Обратите внимание, что в проекте появился reset!

Вам остается сформировать сигналы on и off как результат выделения положительного и отрицательного фронта

Даю их в качестве схемы - переведите в Verilog сами.

[SM 0]

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

 

Это не я так считаю, это так само выходит, в результате многолетнего наблюдения за этим форумом... Люди, занимающиеся "программированием" на HDL, плохо понимают, или совсем не понимают, на что мапятся те или иные конструкции языка в реальном железе - думая, что что бы они там не написали, умный "компилятор" как-то там реализует в железе. Ан нет - все наоборот происходит то... Синтезатор вовсе не умный, и требует соблюдения довольно жестких правил синтезируемого подмножества - поэтому - сначала изучение железа, как оно работает и из чего состоит, а потом уже - правил и конструкций, которыми оно описывается. И Ваш случай туда же относится - сначала посмотрите, есть ли в составе логической матрицы FPGA регистры, которые тактируются от двух разных клоков, или от одного, но по двум фронтам (I/O блоки для DDR не считаются, они описываются не языком, а "черными ящиками" - блоками), потом - изучите, как такие регистры описываются на HDL, а потом уже стройте always-ы.

[dxp 34]

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

Это ваше субъективное мнение, и оно, увы, ошибочно. Я знаю людей, которые прекрасно понимают, как и что происходит внутри ПЛИС, успешно выполняют свою работу, но при этом считают, что то, что они описывают на HDL, тем не менее, программа. И есть люди, которые исходно полагают, что они описывают некую аппаратуру на HDL, при этом делают грубые и мелкие ошибки.

 

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

 

Попутный вопрос: вот то, что компания nVidia предлагает в качестве расширений к ЯП С для поддержки технологии CUDA, - это "язык программирования" или HDL? :)