На пульте управления есть ключи для ручного управления рабочими органами (РО), как компенсирующими РО, так и РО АР.
Если авторегулятор неисправен - звучит громкий сигнал. Оператор подходит к пульту чтобы выключить этот дурацкий громкий звук, мешающий ему спать) Заодно и переключит систему на другой, исправный авторегулятор. Их там обычно два.
В принципе, если авторегулятор мощности неисправен, то никто не запрещает ручное управление. Хотя, это конечно не самый удобный вариант. Само по себе ручное управление - это штатный режим.
Также я думаю, что в системе безопасности атомного реактора всё равно есть условный "инженер-начальник смены", который выше любой автоматики. Ну хотя бы потому, что он может ногами дойти до нужного блока, выдернуть его из сети и коротнуть нужные контакты.
Если просто так выдернуть или коротнуть, то система это сразу увидит и даст АЗ. Но при желании и понимании как работает система, отключить можно всё)
Систему можно разделить на две части: управления и защиты, информации и архивации.
Про управление и защиту:
Прием первичных сигналов с датчиков. Это нейтронные параметры и технологические. Эти сигналы идут на три отдельных стойки в каждой из которых свой отдельный блок. Технология - это АЗТП, нейтронные параметры АКНП. Эта аппаратура обрабатывает первичный сигнал и по защищенному интерфейсу передает информацию в три отдельные блока логики. На каждый блок логики приходят три сигнала для каждого параметра. Логика их складывает по 2 из 3. Например если два сигнала от АКНП были аварийными (АЗ), то формируется обобщенный авариный сигнал (АЗ-ОБЩ), который идет от каждого блока на выходные реле. На этих реле 2 из 3 трех для АЗ-ОБЩ, от каждого блока логики. Затем уже суммарный сигнал идет на рабочие органы (стержни). Для каждого стержня свой блок реле 2 из 3. Сигнал АЗ - это отсутствие тока. Он размагничивает муфту и стрежень АЗ под своим весом вводится в активную зону.
Компания, где я работал, разрабатывала всё полностью сама. Начиная от печатных плат, заканчивая прошивками uC и FPGA. Сейчас они даже делают свои детекторы нейтронного потока. Это весьма сложное устройство, вроде еще такое умеют американцы, французы и аргентинцы.
Отдельного уважения достоин главный конструктор. Это не очередной эффективный менеджер. Это человек прошедший путь, начиная от простого инженера. Он побывал наверное на нескольких десятков реакторов.
Ну и само собой никаких скрамов и аджайлов там нет)
Всё начинается во время плановой перегрузки топлива. Гипотетический злоумышленник через скомпрометированного подрядчика или инсайдера получает доступ к Service Unit. Во время регламентных работ, когда инженер вставляет и поворачивает ключ для смены уставок, вредоносное ПО использует это «окно доверия».
На этом шаге всё и заканчивается. Когда я ездил на объекты, и если бы мне кто-то предложил залить левую прошивку... То я сразу бы доложил об этом своему главному конструктору или главному инженеру на объекте. Он бы доложил куда следует)
На объект никто просто так постороннему человеку зайти не даст. А уж тем более зайти туда, где стойки аппаратуры стоят. Это не проходной двор)
Да, для асинхронного сброса нет защиты от метостабильности. Сигнал n_arst здесь напрямую идет на входы асинхронных сбросов всех триггеров. Это как возможность. Если она потребуется, то правильную последовательность сбросов нужно формировать снаружи. Если снимать асинхронный сброс в произвольный момент, то может возникнуть такое, что это снятие произойдет в момент фронта клока.
Да верное замечание. Но из личного опыта - никогда не встречал двух мастеров на одной шине. I2C - обычно для настроек используется. Записать/прочитать EEPROM на плате, настроить тактовый генератор и тому подобное. Что касается подтяжек - они обычно на платах сделаны. Но можно и на выходе ПЛИС pull-up поставить.
Кстати, есть одна забавная конспирологическая теория. Конечно же серьезно её рассматривать нельзя, но ради шутки привести можно. Суть в следующем:
Как известно, стратосферный озон (О3) является продуктом воздействия солнечного излучения на атмосферный кислород (О2). То есть под действием солнечного излучения в верхних слоях атмосферы кислород превращается в озон. Так вот, конспирологи заметили, что озоновая дыра над Антарктидой увеличивается в размерах к концу августа, как раз когда в южных широтах полярная ночь. В это время солнечные лучи не попадают в атмосферу над южным полюсом, и озон не образуется. А тот озон что был в атмосфере, постепенно распадается естественным путём. В январе-феврале ситуация противоположная. Ярко светит солнце, кислород превращается в озон и дыра уменьшается в размерах. Что то подобное происходит и над Северным полюсом, но в меньших масштабах. А в широтах, в которых нет полярных ночей - озоновых дыр не возникает вовсе. Там новые порции озона формируются каждый день.
Кроме того, долгосрочные изменение (увеличение/уменьшение) размера озоновой дыры объясняются циклами солнечной активности. Активнее светит наше Солнце - больше озона образуется за лето, больше его остается в конце зимы и тем меньше дыра.
И никакие фреоны, как и прочая хозяйственная деятельность человека, не оказывают влияния на естественный процесс изменения размеров озоновых дыр.
Вот такая весёлая штуковина от конспирологов. Конечно же мы можем только посмеяться над этой теорией, ведь она имеет принципиальные и неустранимые противоречия с реальностью :)
Прочитал статью, появился вопрос. Почему озоновая дыра возникает именно над Антарктидой? Имеются ли подобные дыры над территориями Китая, США или РФ? Ведь на этих территориях заводы коптят не меньше чем над Антарктидой, выбрасывая в атмосферу много различных не самых полезных веществ. Есть ли какие-либо наблюдения?
И еще вопрос - как обстоят дела с дырой над Северным полюсом? Вроде там что-то подобное наблюдается в зимние месяцы.
Не подумайте, что я вам не верю или хочу поспорить. Просто на SV и VHDL люди пишут код уже десятилетиями. И что самое главное он работает. И тут появляется новый язык, про который утверждается, что он в 10 раз лучше. Я вот сомневаюсь, имею право)
Спорить не буду, пустое это занятие. Но пока остаюсь при своём мнении - нужны объективные количественные оценки.
Может быть удастся выбраться на очередное заседание FPGA Systems. :)
Уважаемый коллега, давайте не будем обсуждать кто какие ошибки делает, как их исправляет, и через сколько десятилетий перестает понимать свой код. Это не инженерный подход)
И еще хочу заметить, что понимание или не понимание кода - вещь субъективная, сложно её оценить. А вот Fmax - он объективен. Так что давайте в инженерной работе будем использовать линейку, а не чувство прекрасного :)
Как я написал выше - у каждого свои задачи. Но раз уж зашел разговор про передачу данных... То у меня есть MAC-ядро для 10Gig Ethernet, там тоже не самый простой протокол ;) И это даже не просто MAC-ядро, а MAC-маршрутизатор. Так вот в чем дело, меня никогда особо не интересовал объем получившегося кода. Мне важны только два параметра - Fmax и объем задействованных ресурсов (в основном bram). И даже на относительно не быстром MAX10, это ядро вполне соберется на 170 МГц причем при балансной разводке. А сколько там в итоге строк кода? Да какая разница! Мне же не за строки деньги платят)
И основная идея для меня следующая:
Код - это не цель, это средство решения поставленной задачи. И красота и объем кода имеют второстепенное значение. Сравнение языков и исходных кодов должно осуществляться не по количеству написанных строк, а по быстродействию и аппаратным ресурсам, требуемым при имплементации этого кода.
И вот какой момент, почему мне не очень нравится ООП подход для ПЛИС. Если взять классическое ООП, то оно используется там, где огромные излишки ресурсов. Например в современных ПК имеются десятки гигабайт памяти. Фактически память там очень дешевая, ею можно разбрасываться не задумываясь.
А вот в ПЛИС ситуация иная. Даже в топовых микросхемах, блочной памяти не так и много - десятки мегабит (даже не байт, а бит). Но эти микросхемы и стоят по несколько тысяч долларов. Если же брать lowcost сегмент - то бывает, что и мегабита то и нету. И здесь уже приходится экономить память, и делать всё ручками, иначе алгоритмы не влезут.
И вот эта неэкономность ресурсов в современном ООП меня и отталкивает.
В статье было совершенно справедливо замечено, что производительность труда одного человек пишущего на Chisel равняется команде из десятка крутых спецов пишущих на Verilog/VHDL
Спорить не буду, но уж очень сомнительно звучит)
Ну тут еще вопрос задач. Я сейчас занимаюсь обработкой видео в реальном времени. Например у меня есть сделанный мною оконный фильтр 5x5, работающий на проходе. Там буферы строк, ими нужно управлять, читать и писать с точностью до такта. Переключаться между буферами, добавлять дополнительные 'пустые' пиксели и строки по краям кадра. В общем продумывать каждый такт, иначе всё сломается. И всё это с учетом относительно небольшого количества блоков памяти в используемой микросхеме. Мне сложно представить, чем мне поможет ООП подход Чизела.
Но в любом случае, у каждого свои задачи, может быть под ваши Чизел и более удобен. Но как некое универсальное средство для всех задач - пока сомневаюсь.
Если в этом году буде конфа по FPGA, было бы интересно встретиться и обсудить различные подходы за рюмочкой чая)
P.S. Кстати, надо предложить проводить конференции не по субботам, а по пятницам. Мы ведь не для развлечения встречаемся, а по работе. А работать надо в будни))
У меня сложилось впечатление, что Chisel - это для соединения уже готовых модулей на верхнем уровне. То есть язык для некой интеграции уже готовых блоков. Сами же модули пишутся по-старинке, на SV или VHDL. Особенно если важно быстродействие и оптимизация по ресурсам.
Да и вообще, мне кажется несколько сомнительным использовать ООП подход для описания цифровых схем. Ведь код на ПЛИС, это именно что описание схемы, а не набор команд.
Если я правильно понял, то Chisel и SpinalHDL - это основном для описания соединений модулей на верхнем уровне. Сами модули, например упомянутое "StreamFifoCC", используются уже готовые, вручную их не пишут. И скорей всего "StreamFifoCC" написан на SV. Если нужно что-то оптимизировать по ресурсам и быстродействию, то для этого нужно использовать классические языки описания SV и VHDL для написания модулей.
То есть Chisel не позволяет описать в одном модуле два регистра, так чтобы они тактировались разными клоками? Например, я хочу описать True Dual Port FIFO, это возможно на Чизеле или нет?
Вот для VHDL пример двух D-триггеров на разных клоках:
process(clk1, clk2)
begin
-- 1
if rising_edge(clk1) then
reg1 <= in1;
end if;
-- 2
if rising_edge(clk2) then
reg2 <= in2;
end if;
end process;
Допускать ничего не надо, надо знать)
На пульте управления есть ключи для ручного управления рабочими органами (РО), как компенсирующими РО, так и РО АР.
Если авторегулятор неисправен - звучит громкий сигнал. Оператор подходит к пульту чтобы выключить этот дурацкий громкий звук, мешающий ему спать) Заодно и переключит систему на другой, исправный авторегулятор. Их там обычно два.
Но можно управлять и руками.
В принципе, если авторегулятор мощности неисправен, то никто не запрещает ручное управление. Хотя, это конечно не самый удобный вариант. Само по себе ручное управление - это штатный режим.
Если просто так выдернуть или коротнуть, то система это сразу увидит и даст АЗ. Но при желании и понимании как работает система, отключить можно всё)
Если совсем кратко про то где я участвовал.
Систему можно разделить на две части: управления и защиты, информации и архивации.
Про управление и защиту:
Прием первичных сигналов с датчиков. Это нейтронные параметры и технологические. Эти сигналы идут на три отдельных стойки в каждой из которых свой отдельный блок. Технология - это АЗТП, нейтронные параметры АКНП. Эта аппаратура обрабатывает первичный сигнал и по защищенному интерфейсу передает информацию в три отдельные блока логики. На каждый блок логики приходят три сигнала для каждого параметра. Логика их складывает по 2 из 3. Например если два сигнала от АКНП были аварийными (АЗ), то формируется обобщенный авариный сигнал (АЗ-ОБЩ), который идет от каждого блока на выходные реле. На этих реле 2 из 3 трех для АЗ-ОБЩ, от каждого блока логики. Затем уже суммарный сигнал идет на рабочие органы (стержни). Для каждого стержня свой блок реле 2 из 3. Сигнал АЗ - это отсутствие тока. Он размагничивает муфту и стрежень АЗ под своим весом вводится в активную зону.
Компания, где я работал, разрабатывала всё полностью сама. Начиная от печатных плат, заканчивая прошивками uC и FPGA. Сейчас они даже делают свои детекторы нейтронного потока. Это весьма сложное устройство, вроде еще такое умеют американцы, французы и аргентинцы.
Отдельного уважения достоин главный конструктор. Это не очередной эффективный менеджер. Это человек прошедший путь, начиная от простого инженера. Он побывал наверное на нескольких десятков реакторов.
Ну и само собой никаких скрамов и аджайлов там нет)
p.s. есть еще аппаратура авторегулятора мощности
Я не специалист по авиационной безопасности.
Но если вам интересно, могу кратко рассказать подход к разработке систем управления и защиты для атомных реакторов.
На этом шаге всё и заканчивается. Когда я ездил на объекты, и если бы мне кто-то предложил залить левую прошивку... То я сразу бы доложил об этом своему главному конструктору или главному инженеру на объекте. Он бы доложил куда следует)
На объект никто просто так постороннему человеку зайти не даст. А уж тем более зайти туда, где стойки аппаратуры стоят. Это не проходной двор)
Так что это всё писал теоретик, далекий от темы.
Да, для асинхронного сброса нет защиты от метостабильности. Сигнал n_arst здесь напрямую идет на входы асинхронных сбросов всех триггеров. Это как возможность. Если она потребуется, то правильную последовательность сбросов нужно формировать снаружи.
Если снимать асинхронный сброс в произвольный момент, то может возникнуть такое, что это снятие произойдет в момент фронта клока.
Да верное замечание. Но из личного опыта - никогда не встречал двух мастеров на одной шине. I2C - обычно для настроек используется. Записать/прочитать EEPROM на плате, настроить тактовый генератор и тому подобное.
Что касается подтяжек - они обычно на платах сделаны. Но можно и на выходе ПЛИС pull-up поставить.
Спасибо)
На самом деле, на написание кода потратилось гораздо меньше времени, чем на статью. Оказывается писать статьи - не такой и простой труд)
Да, для многих вера и эмоции затмевают логику и здравый смысл)
Да, всё сложно...
Кстати, есть одна забавная конспирологическая теория. Конечно же серьезно её рассматривать нельзя, но ради шутки привести можно. Суть в следующем:
Вот такая весёлая штуковина от конспирологов. Конечно же мы можем только посмеяться над этой теорией, ведь она имеет принципиальные и неустранимые противоречия с реальностью :)
Прочитал статью, появился вопрос. Почему озоновая дыра возникает именно над Антарктидой? Имеются ли подобные дыры над территориями Китая, США или РФ? Ведь на этих территориях заводы коптят не меньше чем над Антарктидой, выбрасывая в атмосферу много различных не самых полезных веществ. Есть ли какие-либо наблюдения?
И еще вопрос - как обстоят дела с дырой над Северным полюсом? Вроде там что-то подобное наблюдается в зимние месяцы.
Не подумайте, что я вам не верю или хочу поспорить. Просто на SV и VHDL люди пишут код уже десятилетиями. И что самое главное он работает. И тут появляется новый язык, про который утверждается, что он в 10 раз лучше. Я вот сомневаюсь, имею право)
Спорить не буду, пустое это занятие. Но пока остаюсь при своём мнении - нужны объективные количественные оценки.
Главное, чтобы оно состоялось)
Уважаемый коллега, давайте не будем обсуждать кто какие ошибки делает, как их исправляет, и через сколько десятилетий перестает понимать свой код. Это не инженерный подход)
И еще хочу заметить, что понимание или не понимание кода - вещь субъективная, сложно её оценить. А вот Fmax - он объективен. Так что давайте в инженерной работе будем использовать линейку, а не чувство прекрасного :)
Как я написал выше - у каждого свои задачи. Но раз уж зашел разговор про передачу данных... То у меня есть MAC-ядро для 10Gig Ethernet, там тоже не самый простой протокол ;) И это даже не просто MAC-ядро, а MAC-маршрутизатор. Так вот в чем дело, меня никогда особо не интересовал объем получившегося кода. Мне важны только два параметра - Fmax и объем задействованных ресурсов (в основном bram). И даже на относительно не быстром MAX10, это ядро вполне соберется на 170 МГц причем при балансной разводке. А сколько там в итоге строк кода? Да какая разница! Мне же не за строки деньги платят)
И основная идея для меня следующая:
Код - это не цель, это средство решения поставленной задачи. И красота и объем кода имеют второстепенное значение. Сравнение языков и исходных кодов должно осуществляться не по количеству написанных строк, а по быстродействию и аппаратным ресурсам, требуемым при имплементации этого кода.
И вот какой момент, почему мне не очень нравится ООП подход для ПЛИС. Если взять классическое ООП, то оно используется там, где огромные излишки ресурсов. Например в современных ПК имеются десятки гигабайт памяти. Фактически память там очень дешевая, ею можно разбрасываться не задумываясь.
А вот в ПЛИС ситуация иная. Даже в топовых микросхемах, блочной памяти не так и много - десятки мегабит (даже не байт, а бит). Но эти микросхемы и стоят по несколько тысяч долларов. Если же брать lowcost сегмент - то бывает, что и мегабита то и нету. И здесь уже приходится экономить память, и делать всё ручками, иначе алгоритмы не влезут.
И вот эта неэкономность ресурсов в современном ООП меня и отталкивает.
Спорить не буду, но уж очень сомнительно звучит)
Ну тут еще вопрос задач. Я сейчас занимаюсь обработкой видео в реальном времени. Например у меня есть сделанный мною оконный фильтр 5x5, работающий на проходе. Там буферы строк, ими нужно управлять, читать и писать с точностью до такта. Переключаться между буферами, добавлять дополнительные 'пустые' пиксели и строки по краям кадра. В общем продумывать каждый такт, иначе всё сломается. И всё это с учетом относительно небольшого количества блоков памяти в используемой микросхеме. Мне сложно представить, чем мне поможет ООП подход Чизела.
Но в любом случае, у каждого свои задачи, может быть под ваши Чизел и более удобен. Но как некое универсальное средство для всех задач - пока сомневаюсь.
Если в этом году буде конфа по FPGA, было бы интересно встретиться и обсудить различные подходы за рюмочкой чая)
P.S. Кстати, надо предложить проводить конференции не по субботам, а по пятницам. Мы ведь не для развлечения встречаемся, а по работе. А работать надо в будни))
У меня сложилось впечатление, что Chisel - это для соединения уже готовых модулей на верхнем уровне. То есть язык для некой интеграции уже готовых блоков. Сами же модули пишутся по-старинке, на SV или VHDL. Особенно если важно быстродействие и оптимизация по ресурсам.
Да и вообще, мне кажется несколько сомнительным использовать ООП подход для описания цифровых схем. Ведь код на ПЛИС, это именно что описание схемы, а не набор команд.
Большое спасибо за ответы!
Если я правильно понял, то Chisel и SpinalHDL - это основном для описания соединений модулей на верхнем уровне. Сами модули, например упомянутое "StreamFifoCC", используются уже готовые, вручную их не пишут. И скорей всего "StreamFifoCC" написан на SV. Если нужно что-то оптимизировать по ресурсам и быстродействию, то для этого нужно использовать классические языки описания SV и VHDL для написания модулей.
То есть Chisel не позволяет описать в одном модуле два регистра, так чтобы они тактировались разными клоками? Например, я хочу описать True Dual Port FIFO, это возможно на Чизеле или нет?
Вот для VHDL пример двух D-триггеров на разных клоках:
Как такое будет выглядеть на Chisel?