Jump to content
    

Совмещение синхронной и асинхронной схем

А если обратиться в область МЧС то там они ваще плевали на то какой триггер для какой схемы поставиться:), лишь бы леса не горели....

 

Естественно есть специфика:

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

Одно дело, написание модели устройства на верилоге. Да хоть упрограммируйтесь! Другое дело - синтез и реализация надежного устройства по этой модели. Это "две большие разницы", и знания для этого нужны совершенно разные, и подходы тоже.

Share this post


Link to post
Share on other sites

Когда Вы успели со мной поработать то:)...

Добрее надо быть к людям, и мир станет светлее!

 

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

Share this post


Link to post
Share on other sites

Когда Вы успели со мной поработать то

А причем тут Вы конкретно? Я про всех "верилог-программистов" в общем и целом. Что из-за их подходов может быть, и когда-то наверняка будет.

 

важно какое выходное воздействие создает блок на входное

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

 

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

Share this post


Link to post
Share on other sites

RN/SN по дефолту именно асинхронные - по дефолту анализ recovery/removal, обычно, выключен вообще. А setup/hold таймингов у этих пинов нет.

 

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

 

То есть да, бывают редкие случаи, когда, почему-то, синтезатор/STA не проанализировал эту схему с SN/RN как ендпойнт клока, и тогда ему надо помочь руками. Но, как правило, оно само все получается, так как, как правило, на этом же инициаторе aload-а висят еще кучи разных других латчей.

1) "RN/SN по дефолту именно асинхронные - по дефолту анализ recovery/removal," - а кто этому возражает?

Но они точно не клоки. Они для тулзы видимы как и данные (только назывется там recovery/removal вместо setup\hold)

2) "именно по дефолту, получаются именно ендпойнтами клокового дерева" - Ничего подобного, особенно по дефолту.

3) Если RN/SN "нашей схемы" подключены к другим "aload" нормальных латчей, и есчё лутше когда этот ALOAD сформирован прямо с CLK на гейтыдклоке (а это не факт), то ТОЛЬКО ТОГДА наши RN/SN окажутся листьями клоктри CLK ....

 

Таким образо м имеем УСЛОВИЯ РАБОТОСПОСОБНОСТИ описанной схемы (см. выше):

а) ALOAD подключённый к RN/SN "нашей схемы"должен быть сформирован на гейтыдклоке (не делителе!) с CLK.

Только в этом неявном (как и для програмистов так и часто схемотехников) случае, время распространения сигналов к RN/SN будет отличаться на SKEW при дефолтных уставках STA.

б) Если не а), то сигнал ALOAD (выход Q флопа (напр. с делителя)), подключенный к RN/SN "нашей схемы"должен быть обявлен как Generated Clock в STA констрейнах.

в) Если не а) и не б), то "програмист" и "схемотехник" должны указать P&R сделать так, чтобы время распространения не отличалось на величину skew (желательно, при этом понимать как это делается до начала програмирования :)).

А именно, P&R должен заставить тул построить клоковое дерево с корнем в нашем локальном ALOAD и листьями на RN/SN....

Share this post


Link to post
Share on other sites

Таким образо м имеем УСЛОВИЯ РАБОТОСПОСОБНОСТИ описанной схемы (см. выше):

Ну кто же с этим спорит то, все на 100% верно. Скажу даже больше - условие работоспособности любой схемы в правильных констрейнах :)

 

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

Share this post


Link to post
Share on other sites

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

А вот вы господа схемотехники договориться не можете%). Сначала кое кто не правильно понял схему, не будем тыкать пальцами. Потом понял, лягнул программистов и сделал вид что так и думал, просто они его сбили. Сейчас вы в констрайнах не сошлись, но опять же виной верилог программисты).

 

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

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

Думал програмист ошибся и хотел другое...

как оказалось потом, успешно переписал код без асинхронщины...

 

-------------

Вопросс реализации изврата - "синхронного латча с асинхронной загрузкой" обсуждается скорее разминки для...

Вот для некоторых например возможность получить разные задержки по RN\SN новость....

Share this post


Link to post
Share on other sites

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

 

Ваще то может, и должна как минимум диагностировать это, как максимум восстанавливаться.

 

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

1. Система обнаружила что есть какие-то ошибки, даже примерно я знал в каком модуле

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

 

как то так...

 

 

желательно, при этом понимать как это делается до начала програмирования

долго торпеда держался, деля ответственность между програмерами и схемарями, но в конце все таки сорвался:)...

надо было написать

желательно, при этом понимать как это делается до начала програмирования или схемосоздания(схемотехнирования)

как то так)

 

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

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

вы не до конца понимаете происходящее, тем самым не лучше верилог-программистов, хотя бы один из вас?

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

Share this post


Link to post
Share on other sites

Вот для некоторых например возможность получить разные задержки по RN\SN новость....

если про меня, для меня ваще все новость:) я готов удивляться этому миру...

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

для работы схемы вы попросили 10 нСек, я пошукала тут пошукала, у меня получилось 9.998 нСек, все хорошо все будет работать...

 

И главное если попросить 9 нСек, она может развести и в 9, но не хочет,потому что 9.998 меньше 10. Никакого запаса, вот как она так знает что все будет работать?

 

 

Share this post


Link to post
Share on other sites

Вот для некоторых например возможность получить разные задержки по RN\SN новость....

Просто, некоторые даже не знают, что есть такие "RN" и "SN", зачем же им знать еще и про задержки? Когда у них оно не работает, они сразу сюда кидают код, и задают вопрос "почему не работает", и им все за них делают те, кто знает про такие "RN/SN". Удобно, и мозги не надо лишней информацией загружать.

Share this post


Link to post
Share on other sites

Ну кто же с этим спорит то, все на 100% верно. Скажу даже больше - условие работоспособности любой схемы в правильных констрейнах :)

 

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

То что Вы согласны с моими условиями работоспособности схемы меня радует :) Значит я не ошибся....

 

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

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

- алоады по любому каким-то образом произрастают от объявленных клоков через Generated клоки (Q выходы)

такчто...

 

------------

Уровни дизайнера:

 

1) Я програмирую на Verilog.

Проблемы синтезатора как он это реализует.

Я это симулю (на уровне RTL) и оно работает.

Если я умный програмист, я есчё и смулю постлайоут (с SDF) чёэто теперь оно перестало работать....

2) Я думаю схемотехнически. Что я задумал - то и синтезилось.

Иногда мне надо схему с асинхронщиной и пусть P&R делает дальше всё сам...

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

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

3) Я описываю асинхронную схему.

я точно знаю какое соотношение задержек сделает её гарантированно работоспособной.

я знаю какое поведение "синхронных" P&R тулзов, и учитывая это, я способен задать SDC констрейны гарантирующие работоспособность.

 

 

Share this post


Link to post
Share on other sites

- алоады по любому каким-то образом произрастают от объявленных клоков через Generated клоки (Q выходы)

такчто...

Но, ведь, при этом, как правило, эти клоки бывают тоже объявлены, как create_clock или create_generated_clock... Вообще, на сколько я понимаю, первым делом, перед синтезом проекта, выписываются все клоки, и объявляются... Еще перед тем, как описать остальные констрейны.

 

Насчет "уровней дизайнера" - IMHO:

1) Я делал успешный backend для ASIC.

2) Я не делал backend, но знаю, как это делается.

3) Я понятия не имею, как он делается, я умею только описать модель, а разводите где нибудь еще.

 

При этом часть из этих 3-их еще и обладают сверхсамоуверенностью, что тулзы за них сами все остальное сделают.

Share this post


Link to post
Share on other sites

------------

Уровни дизайнера:

забыли еще 2 уровня

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

5) я Бог! я сделал землю и людей, схемы ее малая часть

 

к вашим уровням я тоже могу добавить

Насчет "уровней дизайнера" - IMHO:

1) Я делал успешный backend для ASIC.

2) Я не делал backend, но знаю, как это делается.

3) Я понятия не имею, как он делается, я умею только описать модель, а разводите где нибудь еще.

правда не знаю где выше или ниже

х) я понятия не имею что такое backend

 

 

И ваще!

Как-то вы все время обижаете программистов. Почему они не могут потом посмотреть что получилось в схеме? Почему у них должна обязательно перестать работать схема?

Простой пример раньше программисты писали в машинных кодах, потом на АСМ, теперь на С и выше. Когда вы пишите на С, вы всегда знаете какие машинные коды сделает компилятор? А запрещает ли вам писание на С проверить команды ассемблера в критических секциях? Запрещает ли вам знание и писание проекта на С++ переписать критические секции руками ассемблерными вставками?

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

 

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

 

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

 

 

Ну все можете глумиться дальше... я все равно кого-нибудь переживу!

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...