[RobFPGA 28]

Приветствую!

47 minutes ago, SII said:

Интересно, починили баг с порядком нумерации линий в шинах в SystemVerilog?

А что за баг?  Mожете поделится ссылкой на описание на форуме?

 

Успехов! Rob. 

[SII 0]

9 hours ago, RobFPGA said:

А что за баг?  Mожете поделится ссылкой на описание на форуме?

https://forums.xilinx.com/t5/Synthesis/A-bug-in-a-part-select/m-p/1173425#M36790

[fguy 5]

11 часов назад, SII сказал:

Интересно, починили баг с порядком нумерации линий в шинах в SystemVerilog? (наткнулся, нумеруя биты не 31:0, а наоборот; запостил на форуме у них -- признали багом).

Мой любимый баг так и не починили со времен 2019.1 - пошел 3й год. Признание на их форуме багом и даже занесение в баглист для исправления со слов тамошних админов гарантирует ровным счетом ничего https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/HLS-2019-x-and-2020-x-generate-incorrect-param-MEM-SIZE-for-bram/td-p/985907

Изменено 23 июня, 2021 пользователем fguy

[Nick_K 0]

24 minutes ago, fguy said:

Мой любимый баг так и не починили со времен 2019.1 - пошел 3й год. Признание на их форуме багом и даже занесение в баглист для исправления со слов тамошних админов гарантирует ровным счетом ничего https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/HLS-2019-x-and-2020-x-generate-incorrect-param-MEM-SIZE-for-bram/td-p/985907

Объявление типа RAM отличное от рекомендуемых в Xilinx кодстайл гайде (или в Language Templat'ах) будет вертеться разработчиками на х... просто проигнорировано, потому что Ваша хитрость - это Ваша проблема, а не их.

Пользуйтесь рекомендациями и не будет ничкаких проблем.

[fguy 5]

1 час назад, Nick_K сказал:

Объявление типа RAM отличное от рекомендуемых в Xilinx кодстайл гайде (или в Language Templat'ах) будет вертеться разработчиками на х... просто проигнорировано, потому что Ваша хитрость - это Ваша проблема, а не их.

Пользуйтесь рекомендациями и не будет ничкаких проблем.

Какие рекомендации вы имеете в виду? Можно ссылку?

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

Изменено 23 июня, 2021 пользователем fguy

[SII 0]

1 hour ago, Nick_K said:

Объявление типа RAM отличное от рекомендуемых в Xilinx кодстайл гайде (или в Language Templat'ах) будет вертеться разработчиками на х... просто проигнорировано, потому что Ваша хитрость - это Ваша проблема, а не их.

Пользуйтесь рекомендациями и не будет ничкаких проблем.

Извините, но есть стандарт языка, и его ОБЯЗАНЫ придерживаться разработчики компиляторов. Недаром они признали ошибку. А уж то, поймёт компилятор или нет, что я хочу ОЗУ слепить -- это совсем другая проблема.

[Nick_K 0]

1 hour ago, fguy said:

Какие рекомендации вы имеете в виду? Можно ссылку?

Никаких ссылок не нужно. Всё есть в IDE.

По поводу поддержки и работоспособности - я согласен, что оно могла работать, но разрабы также могли добавить что-то или изменить "понимание" RTL'а синтезатором и потому всё накрылось.

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

1 hour ago, SII said:

Извините, но есть стандарт языка, и его ОБЯЗАНЫ придерживаться разработчики компиляторов.

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

[des00 25]

49 minutes ago, Nick_K said:

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

расслабился народ, то ли дело в ISE 9.1 объяснить что именно надо от синтезатора) а сейчас, в вивадо, левой задней ногой пишется DWC память, даже не погружаясь в детали)

[RobFPGA 28]

Приветствую!

50 minutes ago, Nick_K said:

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

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

  

Удачи! Rob.

 

P.S.  К какой то версии  Vivado у меня  было похожий глюк при синтезе памяти с типом структуры -  новая версия Vv генерила по целой BRAM на каждое  поле структуры независимо от разрядности  поля. Хотя  предыдущие  версии кушали такое описание нормально.  Потом  это исправили.  

[Nick_K 0]

2 minutes ago, RobFPGA said:

Это  разные  вещи  -  если  бы синтезатор просто не смог инфернить память по такому описанию - еще можно было бы попенять что "не по шаблону".

Ну да. Немного увлёкся. Тут и вправду распознаётся неправильная конструкция. Возможно они юзают где-то внутри своих IP такое и "подстроили" под себя просто 

[SII 0]

42 minutes ago, Nick_K said:

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

И причём здесь макроблоки? Если бы Вы внимательно посмотрели, что я писал на форуме Хилинха, то увидели бы, что ошибка -- не в том, что компилятор не понимал, что я память описываю (это он как раз очень хорошо понимал и всё правильно синтезировал) -- он игнорировал порядок нумерации разрядов в объявлени: я объявлял

reg [0:7]   RAM[Size];

а он считал, что я написал reg [7:0] -- и ругался в другом месте.

[Dr.Alex 0]

14 minutes ago, des00 said:

левой задней ногой пишется DWC память

А что это такое? Даже гугл не знает.

[fguy 5]

1 час назад, Nick_K сказал:

Никаких ссылок не нужно. Всё есть в IDE.

Все понятно - будьте внимательны когда читаете - в моем сообщении речь идет об интерфейсах для ядер в Vivado HLS.

[Nick_K 0]

33 minutes ago, SII said:

И причём здесь макроблоки?

При том, что ваш пост тут не единственный и я отвечал на этот: 

В Вашем же случае всё законно и должны исправить.

 

17 minutes ago, fguy said:

интерфейсах для ядер в Vivado HLS

Да, я уже вкурил, что направильно разрядность делает, а сам примитив вызывается и интерпретируется абсолютно верно.

[fguy 5]

2 часа назад, Nick_K сказал:

Да, я уже вкурил, что направильно разрядность делает

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