[DPL 0]

Здравствуйте.

В связи с необходимостью принятия решения о целесообразности применения ПЛИС возник такой вопрос: а как можно (и можно ли) определить, правильно ли она функционирует? Вот, например, загрузили в нее файл конфигурации, она заработала, а затем произошел сбой в конфигурационных данных (скачок питания, помеха и тд). Как выявить эту ситуацию? Для ОЗУ, например, можно посчитать контрольную сумму. А как для ПЛИС?

Буду благодарен за любые советы или ссылки.

[Maksim 0]

Для Xilinx,например-это режим ReadBack (см. например XAPP176)

[makc 199]

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

 

Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic. Ну и конечно использовать дублирование. :)

[DPL 0]

Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic. Ну и конечно использовать дублирование. :)

<{POST_SNAPBACK}>

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

Кстати, есть ли у кого информация о том, насколько вероятно искажение конфигурации ПЛИС? Может, я слишком усложняю себе жизнь и такие искажения маловероятны?

PS: К слову, сейчас пока смотрим в сторону FPGA от Altera, т.к. есть небольшой опыт их использования (ACEX)

[3.14 0]

to makc

<Readback это, конечно, хорошо. Но ведь в процессе самого чтения конфигурации тоже может возникнуть ошибка, т.е. конфигурация будет правильной, но считана будет неправильно... >

Все таки вероятность этого мизерна.

 

<Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic.>

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

 

to DPL

Можно попробовать через JTAG контроллировать содержимое.

[one_man_show 0]

На мой взгляд самый верный способо достижения надежности помимо выбора "лучшего" компонента (что практически невозможно), это определение критериев сбоя. Что считать в Вашей системе сбойной ситуацией? Именно в этом случае и перегрузить конфигурацию ПЛИС и перезапустить другие компоненты, типа МК. Наличие сигналов PowerGood, мониторов питания и сторожевых таймеров в системах повышенной надежности считается аксиомой.

[vetal 0]

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

Возможные варианты отказа, приведенные вами, решаются схемотехнически и конструктивно.

Как вариант - взять микросхему подотолще, и реализовать встроенное резервирование.

[makc 199]

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

<{POST_SNAPBACK}>

 

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

[DPL 0]

На мой взгляд самый верный способо достижения надежности помимо выбора "лучшего" компонента (что практически невозможно), это определение критериев сбоя. Что считать в Вашей системе сбойной ситуацией? Именно в этом случае и перегрузить конфигурацию ПЛИС и перезапустить другие компоненты, типа МК.

<{POST_SNAPBACK}>

 

2 one_man_show:

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

 

2 vetal:

Спасибо, попробую посмотреть, что они пишут о сбоях.

 

2 makc:

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

[makc 199]

<Readback это, конечно, хорошо. Но ведь в процессе самого чтения конфигурации тоже может возникнуть ошибка, т.е. конфигурация будет правильной, но считана будет неправильно... >

Все таки вероятность этого мизерна.

<{POST_SNAPBACK}>

 

Согласен, она может быть небольшой. Но это будет зависеть он нескольких факторов, в т.ч. частоты работы JTAG'a. И все-равно эта вероятность будет.

 

<Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic.>

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

 

Ну почемуже сразу менять среду разработки? ;) Ведь можно использовать практически один и тот же софт (Synplify) и разные PAR. Так что я не могу сказать, что это большая сложность. И, к тому же, нужно выбирать для определенной задачи походящий инструмент, если есть такая возможность. :)

 

2 makc:

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

<{POST_SNAPBACK}>

 

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

[3.14 0]

to makc

<... Но это будет зависеть он нескольких факторов, в т.ч. частоты работы JTAG'a. ...>

Хотя это больше уже похоже на придерание к словам (моей стороны), но ошибка в JTAG цепи зависит от длинны линии (согласовывать или нет), а не от частоты работы (т.к. буфера не меняются), и от "экранированности" (наводок) линий. Вот с последним могут быть проблемы.

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

[makc 199]

to makc

<... Но это будет зависеть он нескольких факторов, в т.ч. частоты работы JTAG'a. ...>

Хотя это больше уже похоже на придерание к словам (моей стороны), но ошибка в JTAG цепи зависит от длинны линии (согласовывать или нет), а не от частоты работы  (т.к. буфера не меняются), и от "экранированности" (наводок) линий. Вот с последним могут быть проблемы.

<{POST_SNAPBACK}>

 

Никакого придирания к словам тут нет. :) Все верно, причины ошибок выделены верно. Но с ростом частоты вероятность ошибки будет расти, т.к. перечисленные факторы будут оказывать все большее влияние. К тому же нужно не забывать, что размер конфигурационной памяти большинства современных FPGA далеко не один килобит, а тысячи.

 

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

 

Для меня тоже. ;)

[3.14 0]

<... Но с ростом частоты вероятность ошибки будет расти, т.к. перечисленные факторы будут оказывать все большее влияние. ...>

При нормально согласованной линии, влияние будет оказывать только наводимая ЭДС, а она от частоты работы JTAG не зависит.

[makc 199]

<... Но с ростом частоты вероятность ошибки будет расти, т.к. перечисленные факторы будут оказывать все большее влияние. ...>

При нормально согласованной линии, влияние будет оказывать только наводимая ЭДС, а она от частоты работы JTAG не зависит.

<{POST_SNAPBACK}>

 

Вот мы и пришли к закономерному выводу. ;) Если все делать нормально (правильно), то проблем не будет. :) Но вот только одна есть проблема - даже если все правильно спроектировано, то это правильно спроектированное может быть неправильно изготовлено и это бывает довольно часто. Я думаю, что Вы с этим знакомы не по наслышке.

 

PS: А что касается наведенной ЭДС - так ведь можно же заэкранироваться. Хотя, если говорить про JTAG, разведенный на плате, то это опять же вопрос правильного проектирования платы.

[DPL 0]

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

<{POST_SNAPBACK}>

Как совершенно справедливо заметил one_man_show, "наличие сигналов PowerGood, мониторов питания и сторожевых таймеров в системах повышенной надежности считается аксиомой". А для чего это все? Вероятно, чтобы остановить|перезапустить систему в случае возникновения определенных отказов :). Т.е., как ни крути, система должна быть готова к тому, что перезапуск возможен и должна быть спроектирована так, чтобы этот перезапуск существенно не повлиял на ее работу. В свете этого перезагрузка ПЛИС - это лишь одна из операций по восстановлению работоспособности.