[sazh 3]

Я имел ввиду то, что в квартусе IMHO нужно делать только финальный синтез/укладку.

Основной объём разработки идёт не в нём, а например ActiveHDL/Менторе - в них пишем, симуляем, тестим.

 

Тогда это не кристаллы Альтеры. Или Вы первый такой на Альтере. (Хотя бы потому, что ip core Альтеры текстово привязаны к моделсиму). Да и связка моделсим - Альтера самодостаточна. С ценовой категории в том числе.

Хочу заметить что с точки зрения одиночного продвинутого пользователя - это все равно что подцепить.

Но есть понятия коллектив. И он исходит из понятия разумной достаточности.

[Builder 0]

Все эти языки только мешают нормально работать.:) Процесс разработки похож на intrinsic'описательство в Си. В итоге половину или ресурсов, или мегаГерцев "дяде отдай".

В проектах с большим количеством микросхем это экономически заметно .

 

Первичны архитектура FPGA и place and route. :) :) Языки вторичны.

Ну дык, где он идеал... А так хочется, идеала.

 

 

Тогда это не кристаллы Альтеры. Или Вы первый такой на Альтере. (Хотя бы потому, что ip core Альтеры текстово привязаны к моделсиму). Да и связка моделсим - Альтера самодостаточна. С ценовой категории в том числе.

Хочу заметить что с точки зрения одиночного продвинутого пользователя - это все равно что подцепить.

Но есть понятия коллектив. И он исходит из понятия разумной достаточности.

альтера - не алтера, из постов автора я сделал вывод, что он не использует что-то кроме самого квартуса (судя по его реакции угадал). Исходя из этого я и исходил в том посте - для него в таком случае мало что поменялось, что AHDl что VeroLog. А Вы тут - вместе вместе, самодостаточно. Автор поста ещё не дошёл до необходимости использовать Моделсим.

[aprox 0]

Что такое ловушка ошибок. На примере UART не покажите?

UART обычно имеет статус-регистр, в котором размещены в том числе и флаги ошибок. Как минимум:

Overrun Error, Break Flag, Parity Error, Frame Error. Статус-регистр устроен в виде ловушки редких событий, - он хранит факт возникновения ошибок до первого опроса этого регистра. Точно также я устраиваю ловушки сбоев и редких событий в отдельных модулях проекта. Просто, на стадии проектирования не надо лениться изобретать и вставлять такие ловушки всюду, где это возможно.

[sazh 3]

UART обычно имеет статус-регистр, в котором размещены в том числе и флаги ошибок. Как минимум:

Overrun Error, Break Flag, Parity Error, Frame Error. Статус-регистр устроен в виде ловушки редких событий, - он хранит факт возникновения ошибок до первого опроса этого регистра. Точно также я устраиваю ловушки сбоев и редких событий в отдельных модулях проекта. Просто, на стадии проектирования не надо лениться изобретать и вставлять такие ловушки всюду, где это возможно.

 

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

Для этого есть стендовое оборудование. Отмоделированное железо это никак не затрагивает.

У меня понятие ловушки - это живая схема. Отложенное событие для последующей обработки - например арбитраж.

[aprox 0]

К тому что сказал Mahagam (на железе тестирование завершается, а не начинается), добавлю:

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

Так они ведь вообще тестируются до появления железа впринципе. Да, бывают ошибки и баг. репорты.

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

Я слышал другую версию создания ASIC. Сначала все обязательно отлаживается на железе, в качестве которого выступает некая FPGA. И уже потом, когда появляется надежда, что баги выловлены, делают заказ на партию ASIC. По крайней мере, я читал именно такой сценарий на сайте Altera. И даже знаю очень конкретный пример- фирма Paralax отрабатывала свой уникальный микроконтроллер Propeller на стратиксе. Это к вопросу- доверяют ли разработчики-практики симуляции на программных моделях.

Одно другому не мешает, такие куски могут быть и в проекте на xHDL. Это не является преимуществом именно AHDL или говорить об ущербности VeriLog/VHDL.

О преимуществе или ущербности никто не говорит. Я показал, каким образом можно обойтись без тестовых прогонов в симуляторе всего проекта целиком. Причем, с максимальным приближением к реальной жизни, без сомнительного моделирования. Отсюда, главная фича VeriLog/VHDL , моделирование, становится отнюдь не очевидной. Hа счет второй фичи, переносимость проектов, четко написал jojo- нет ее, легкой переносимости. Всегда надо перелопачивать ручками под конкретную архитектуру FPGA.

[Builder 0]

Я слышал другую версию создания ASIC. Сначала все обязательно отлаживается на железе, в качестве которого выступает некая FPGA. И уже потом, когда появляется надежда, что баги выловлены, делают заказ на партию ASIC. По крайней мере, я читал именно такой сценарий на сайте Altera. И даже знаю очень конкретный пример- фирма Paralax отрабатывала свой уникальный микроконтроллер Propeller на стратиксе. Это к вопросу- доверяют ли разработчики-практики симуляции на программных моделях.

Согласен, слукавил, но только чуть чуть. Т.к. ASIC всё-же разрабатывают на xHDL и моделирование там не последнее место занимает. Сам ASIC не делал, но то что слышал - говорит за это. Можете в соответствующей теме спросить. Да, SM не в счёт :)

 

О преимуществе или ущербности никто не говорит. Я показал, каким образом можно обойтись без тестовых прогонов в симуляторе всего проекта целиком. Причем, с максимальным приближением к реальной жизни, без сомнительного моделирования. Отсюда, главная фича VeriLog/VHDL , моделирование, становится отнюдь не очевидной. Hа счет второй фичи, переносимость проектов, четко написал jojo- нет ее, легкой переносимости. Всегда надо перелопачивать ручками под конкретную архитектуру FPGA.

Ну, не скажите, приведённый пример не есть правило это раз, а во вторых кусок проекта оптимизировать, если надо - это Вам не весь проект переделать.

 

А Вообще, на мой взгляд тему обсудили, дальше сами смотрите, а то ща углубимся в мелочи.

[aprox 0]

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

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

Защита от видимых заранее багов сразу закладываются в проект. А непредусмотренные баги никаким симулятором не отловишь. Или вы имеете в виду ошибки синтаксиса?

ничего, что тестовые вектора и тестовое окружение могут рандомно генериться хоть неделю подряд? чего ж тогда все крупные конторы так свирепо развивают SystemVerilog со всякими OVM и проч?

"Рандомно генерится" они могут только по некоей модели поведения обьекта. А модель, увы, -это всего лишь модель и непредусмотренные, но очень реальные баги не генерит.

оригинально! :a14:

первым бетатестером проекта становится заказчик! то есть звонит он через неделю и говорит - мне тут с борды сообщение пришло, типа буфер переполнился. нада чёта делать :)

а промоделировать ситуёвину что будет пи переполнении и как его избежать - не судьба?

Не судьба. Особенно, если FPGA работает совместно с компьютером заказчика, а они, компьютеры все разные. Приходится сопровождать изделие примерно так, как вы описали выше. Реально доводка аппаратуры и ее регулярной апдейт уже у потребителя- это путь, которому следуют практически все софтописатели, включая мелкософт. Удивляться нечему.

сомневайтесь хоть до посинения. но факт есть факт - разработка софта под телефоны Nokia ведётся на моделях. то есть: Nokia при помощи весьма недешёвого софта создаёт программную модель своего телефона, который в данный момент существует только на бумаге. раздаёт эту модель софтописателям. и вуаля - железо и софт выходят одновременно.

так что симуляция исчезла только в вашей голове.

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

[Mahagam 0]

Я слышал другую версию создания ASIC. Сначала все обязательно отлаживается на железе, в качестве которого выступает некая FPGA. И уже потом, когда появляется надежда, что баги выловлены, делают заказ на партию ASIC. По крайней мере, я читал именно такой сценарий на сайте Altera.

давайте отделять мух от котлет. логику работы вашего алгортима можно отладить на FPGA, а как быть со взаимодействием вашей логики с теми модулями которые предлагает фабрика? например на заводе скажут, что есть готовые корки эзернет-контроллера с такими то вот и такими-то выводами. или вот вам PCI ядро. готовое. как такое отлаживать на FPGA? а как быть с абсолютно разными I/O? с тем, что умножители другие, что вообще ячейки на ASIC другие? а как быть с тем, что ASIC работает на куда более высоких частотах? как это проверить?

на сайте альтеры они этот ваш сценарий сводят к ненавязчивым советам купить HardCopy.

 

И даже знаю очень конкретный пример- фирма Paralax отрабатывала свой уникальный микроконтроллер Propeller на стратиксе.

а вам не сообщили, сколько часов моделирования прошло перед первой заливкой в стратикс?

 

Это к вопросу- доверяют ли разработчики-практики симуляции на программных моделях.

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

 

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

вот делал я эзернет-контроллер, и глючил он у меня на пакетах с определённым содержанием. 99% пакетов пропускает хорошо, а 1% - растягивался. и где какую контрольную точку ставить? куда рыть? а моделирование с запуском в симуляторе этого пакета тут же показало где ошибка. вот такое вот оно - сомнительное моделирование.

 

а как вы узнаете при отладке, например, контроллера DDR2 памяти, что вы верно завершаете инициализацию этой памяти? что вообще верно формируете временную диаграмму?

 

Отсюда, главная фича VeriLog/VHDL , моделирование, становится отнюдь не очевидной.

мощный вывод. все эти моделсимы/квестасимы/VCS`ы - бесполезный софт. ага. :a14:

 

 

Hа счет второй фичи, переносимость проектов, четко написал jojo- нет ее, легкой переносимости. Всегда надо перелопачивать ручками под конкретную архитектуру FPGA.

опять у вас мухи и котлеты вместе.

что ж именно надо перелопачивать ручками в том простом тестовом проекте что выложил jojo? как ни странно, код там переносим абсолютно. речь же шла про выжимании максимума из каждой FPGA. хотя бы потому, что там 512-и разрядные шины, от разводки которых любой роутер окосеет без помощи человека.

 

"Рандомно генерится" они могут только по некоей модели поведения обьекта. А модель, увы, -это всего лишь модель и непредусмотренные, но очень реальные баги не генерит.

давайте думать перед тем как писать. генератор багов можно также написать и вставить в тестбенч. и отследить, что система среагировала на баг правильно, например фыркнула о несовпадении CRC. а если не фыркнула - значит это и есть глюк.

 

Не судьба. Особенно, если FPGA работает совместно с компьютером заказчика, а они, компьютеры все разные.

однако PCI-стандарт - он один. к примеру.

 

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

блин. этож не один проект.

упрощаем ситуёвину: вам даётся описание единственного радара. даже проще - 10 (100 ?) гигабайт записанного видеосигнала с него. даются чёткие алгоритмы по которым надо этот сигнал отработать. вопрос - нахрена в этом случае вообще железо?

[aprox 0]

давайте отделять мух от котлет. логику работы вашего алгортима можно отладить на FPGA, а как быть со взаимодействием вашей логики с теми модулями которые предлагает фабрика? например на заводе скажут, что есть готовые корки эзернет-контроллера с такими то вот и такими-то выводами. или вот вам PCI ядро. готовое. как такое отлаживать на FPGA? а как быть с абсолютно разными I/O? с тем, что умножители другие, что вообще ячейки на ASIC другие? а как быть с тем, что ASIC работает на куда более высоких частотах? как это проверить?

Фабрики ASIC обычно предлагают полную электрическую, временную и логическую совместимость с FPGA. По существу, речь идет о замене конфигурационной памяти на маску. Иначе, теряется практический смысл с затеей ASIC.

а вам не сообщили, сколько часов моделирования прошло перед первой заливкой в стратикс?

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

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

вот делал я эзернет-контроллер, и глючил он у меня на пакетах с определённым содержанием. 99% пакетов пропускает хорошо, а 1% - растягивался. и где какую контрольную точку ставить? куда рыть? а моделирование с запуском в симуляторе этого пакета тут же показало где ошибка. вот такое вот оно - сомнительное моделирование.

Повезло, ничего не скажешь. Hо, как говорится, исключение подтверждает правило.

а как вы узнаете при отладке, например, контроллера DDR2 памяти, что вы верно завершаете инициализацию этой памяти? что вообще верно формируете временную диаграмму?

Про DDR2 сказать не берусь, т.к. ни разу не использовал. Hо для синхронной видеопамяти просто нарисовал диаграмму чтения и записи в вектором редакторе и сразу получил прекрасно работающий вариант разводки, никакой отладки вообще не потребовалось.

мощный вывод. все эти моделсимы/квестасимы/VCS`ы - бесполезный софт. ага. :a14:

Может кому-то и небесполезный, но я прекрасно обхожусь без них. Заодно повторю- в области приложений на микроконтроллерах давно уже отказались от идеи симулировать на моделях в отрыве от реальной жизни. Думаю, что-то похожее грядет и в области FPGA, например, встроенные JTAG отладчики реального времени.

давайте думать перед тем как писать. генератор багов можно также написать и вставить в тестбенч. и отследить, что система среагировала на баг правильно, например фыркнула о несовпадении CRC. а если не фыркнула - значит это и есть глюк.

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

однако PCI-стандарт - он один. к примеру.

Один-то он один. Зато компьютер выдает гранты на доступ к шине каждый со своей скоростью. Вполне реальный вариант переполнить fifo мастера.

блин. этож не один проект.

Hет это один проект, но в постоянном развитии и спровождении.

упрощаем ситуёвину: вам даётся описание единственного радара. даже проще - 10 (100 ?) гигабайт записанного видеосигнала с него. даются чёткие алгоритмы по которым надо этот сигнал отработать. вопрос - нахрена в этом случае вообще железо?

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

[Mahagam 0]

Фабрики ASIC обычно предлагают полную электрическую, временную и логическую совместимость с FPGA. По существу, речь идет о замене конфигурационной памяти на маску. Иначе, теряется практический смысл с затеей ASIC.

вы это там серьёзно? сведения достоверные? или это махровая отсебятина? не позорьтесь.

 

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

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

 

Один-то он один. Зато компьютер выдает гранты на доступ к шине каждый со своей скоростью. Вполне реальный вариант переполнить fifo мастера.

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

[Builder 0]

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

Ваша проблема в том, что вы пытаетесь прежде всего себе доказать почему Вам не нужен xHDL,

не обращая внимания на то, что xHDL не отрицает всех Ваших методов, но при этом он даёт новые возможности.

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

[aprox 0]

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

Извините, но вы ошибаетесь. Задержка времени между запросом мастера и выдачей гранта на доступ к PCI-шине не нормируются стандартом. Она зависит от множества неконтролируемых причин. Например: количество других PCI-устройств, количество и качество активных тредов, неверные настройки ОС, глюкавость драйверов материнской платы и, наконец, присутствие вирусов.

 

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

[dvladim 0]

Тогда это не кристаллы Альтеры. Или Вы первый такой на Альтере. (Хотя бы потому, что ip core Альтеры текстово привязаны к моделсиму).

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

 

Я слышал другую версию создания ASIC. Сначала все обязательно отлаживается на железе, в качестве которого выступает некая FPGA. И уже потом, когда появляется надежда, что баги выловлены, делают заказ на партию ASIC.

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

 

Защита от видимых заранее багов сразу закладываются в проект. А непредусмотренные баги никаким симулятором не отловишь. Или вы имеете в виду ошибки синтаксиса?

Что за понятия такие: "предусмотренные баги" и "непредусмотренные баги"? Баги это баги. Плюсы моделирования в том, что можно проверить граничные условия работы системы. То, что на реальном железе встречается достаточно редко. Вот если этого не делать, то выше шанс получить устройство "работает нормально, но иногда глючит" и стабильно воспроизвести этот глюк "на столе" не получается.

Опять же, есть ситуации, которых в жизни получить тяжело. Типичный пример - проверка времянок. В тестбенче можно сделать окружение каким хочешь, а в реале - такое какое сделали подрядчики.

 

Фабрики ASIC обычно предлагают полную электрическую, временную и логическую совместимость с FPGA. По существу, речь идет о замене конфигурационной памяти на маску. Иначе, теряется практический смысл с затеей ASIC.

Ну это вообще полный бред. :(

no comment © Черчилль

 

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

Моделирование и макетирование не заменяют друг друга, а дополняют.

 

Может кому-то и небесполезный, но я прекрасно обхожусь без них. Заодно повторю- в области приложений на микроконтроллерах давно уже отказались от идеи симулировать на моделях в отрыве от реальной жизни. Думаю, что-то похожее грядет и в области FPGA, например, встроенные JTAG отладчики реального времени.

Это уже есть, примером можно привести встроенные логические анализаторы - SignalTap и как-то там у Xilinxa (забыл).

 

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

 

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

Очень полохо, что при проектировании вы не представляете диапазон рабочих условий для устройства. Симуляторы помогут промоделировать самые тяжелые рабочие условия. Повторюсь, в реальности такие условия (сочетания факторов) могут возникать крайне редко.

 

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

Интересно как вы ведете проект? Какому выходному тестированию подвергается новая версия? А то один баг поправили, а пару новых сделали. Отдуваются заказчики. С маркетинговой точки зрения это плохо выглядит. Лучше бывает подождать неделю и выдать протестированный продукт, чем сразу, но сырой.

[Chainichek 0]

Всем здрасьте. В короткие сроки нужно изучить Quartus, Verilog. 3 - дня покопалась, пробовала коды. Никак не могу понять, как посмотреть результат на экране? Куда выводится результат системной задачи $display? Есть ли в Quartuse консоль вообще? :07:

[iosifk 3]

Всем здрасьте. В короткие сроки нужно изучить Quartus, Verilog. 3 - дня покопалась, пробовала коды. Никак не могу понять, как посмотреть результат на экране? Куда выводится результат системной задачи $display? Есть ли в Quartuse консоль вообще? :07:

поскольку Ваш личный ящик не работает, то пишу здесь.

Найдите у меня на сайте статьи по "Краткий Курс HDL".

Удачи!