Jump to content

    

Yuri124

Участник
  • Content Count

    328
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Yuri124

  • Rank
    Местный

Recent Profile Visitors

643 profile views
  1. Активный щуп нужен всего лишь для того, чтобы 1. не повлиять на исследуемый сигнал 2. возможно - его усилить при необходимости 3. доставить сигнал по дешевому RF кабелю (который есть под рукой, т.к. как правило низкоемкостные высокооммные коаксиальные кабели с полувоздушным диэлектриком очень недоступны) без искажений к тому месту, где этот сигнал будет обрабатываться (оцифровываться).
  2. Так проблема у ТС в том, что там мультиплексируемая шина данные/мл байт адреса, WR_RD это не зафиксирует. С клоком от МК - да, лучше всего было бы, учитывая, что МК не от кварца, а от внутреннего RC генератора с хз какой погрешностью. Тут не такой уж и большой запас по времянке может оказаться. У МК может быть нога, на которую можно вывести системный клок с каким-нибудь коэфф-том деления - подать его в ПЛИС на умножитель, только вымерять сдвиг фазы и скомпенсировать его в блоке PLL ПЛИС.
  3. скорее всего: http://radiowiki.ru/index.php?title=Файл:Радио_1990_г._№03.djvu&page=45# - смотрите схему. уж в таком случае - чтобы улучшить чувствительность от исходных 100 мв и получить лучшую битность оцифрованного сигнала. На Казусе есть люди, понимающие в аналоговой схемотехнике. Но на этих частотах - сотни мегагерц - уже и форма проводков на плате будет играть роль. а что задержка?! кабель всего лишь доставит сигнал к ПЛИС, какая разница - за секунду или две, лишь бы форму не исказил.
  4. если отечественный ящик - ИМХО там не очень транзюки (с граничной частотой на 500-700МГц), уж лучше проверенную схему из той подборки, что Вы дали ссылку. Тем более - компаратор будете покупать. Ну или если именно на тех транзюках схему щупа найдете, чтобы потом самому не долбаться с АЧХ. Хотя - если мегагерц до 50 смотреть, или как показометр - то можно и их использовать.
  5. Да, но только в случае гарантированно стабильной времянки с МК. Перечитал еще раз Ваши сообщения в топике - обнаружил Вашу фразу Если это просто фигура речи, а на самом деле времянка и частота соответствует картинке в первом посту - то такое должно сработать. Если же времянка обращения к памяти плавает - то так просто не получится. Но у меня было такое - передача от МК в ПЛИС - там времянка была гарантированной (можно было только регулировать число wait state), и частота МК стабильной, не менялась. Работало всё без синхронизаторов - защелкивалось в регистры сигналами от проца (как в Вашм случае - ALE), потом - флаг готовности, не помню уже, чем формировался... Но скорости потоковой не требовалось - пока ПЛИС обрабатывал данные, МК писал в начало конвейера регистров и ждал разрешения на след. запись.
  6. это если настраивать нужно точно. Мне - иногда надоо ткнуть в кварц - узнать, работает ли. А 12МГц определить хватает и точности 2-3 знака после запятой.
  7. Поставить в клоковом домене ПЛИС (150 МГц) 2-3 триггера синхронизатора на wire ale: reg ale_r, ale_rr, ale_rrr; - количество триггеров взял исходя из картинки (там адрес появляется после фронта ale) и из частот 32 и 150 МГц. Поставить автомат: 1. ждать 1 на ale_rrr 2. address_150 <- address_MC; adress_valid <- 1'b1; - формируется строб вылидности адреса, импульс, написать автомат так, чтобы этот импульс длился 1 такт 150 МГц 3. ждать 0 на ale_rrr 4. преход на 1. Т.е. 4-й такт 150МГц пишет в регистр в домене 150 МГц адрес (можно весь, не только младший байт) - судя по картинке, должно работать норм. Но нужно посчитать точно, с каким разбросом выдает МК адрес по отношению к ALE, может быть получится и 3-м клоком защелкивать в регистр. Таким образом - адрес будем иметь не позже спада ALE и гарантированно валидный в домене ПЛИС. От фронта ALE можно посчитать каким клоком писать данные в домен ПЛИС - если это нужно. Тогда просто дополнить автомат еще 1-2 состояниями. Посчитать и прописать min/max задержки rising edge ale и мах задержку адреса (возможно - понадобится и min задержку адреса) - от ножек ПЛИС до клока 150 МГц.
  8. Смотрю 12 МГц на ногах кварца - подключен к STM32 - (опорные емкости на землю по 10 пикофарад) стандартным 100 МГц щупом с делителем 1:10 - норм. Ну да, на частоту немного влияет, в каком-то знаке после запятой.
  9. ну смотрите - если делать защелку, то мл. байт точно будет раньше, чем по спаду ALE (хотя защелка медленнее, чем D-триггер, насколько помнится, но при таких частотах МК думаю наносекунд 10 выиграете. С другой стороны - данные придут только в след. такте, при быстрой SRAM, если ей не нужен большой setup по адресу - эти 10 нс без разницы (если не вести далеко по кристаллу, но так и данные тогда тоже надо будет, наверное, далеко вести). А так квартус сам по себе может наставить латчей, если некорректно ( с его точки зрения) описан автомат, и предупредит об этом - т.к. латч часто не самое хорошее решение. Такое было у меня, тоже принимал данные с МК, регулировал через wait state МК, но тогда многого не знал по описанию констрейнов, да и скорость устраивала - обработка была настолько медленной, что все равно приходилось притормаживать МК.
  10. Если скорость не поджимает. Но гемора то особо не вижу - данные то МК выдает всё равно на такт позже.
  11. без разницы. В схеме присутствует латч, он в любом случае появится после компиляции с каким-то именем, это имя и использовать в констрейнах. Только внимательно читать отчет компилятора. Было такое - задал в констрейне имя как в проекте (это был даже не латч - регистр, а именно логика) - в отчете оппа - констрейн проигнорен, т.к. нет такого имени сигнала. Пришлось смотреть, как оно обозвалось компилятором и подправлять.
  12. ну почему же, судя по приведенной Вами осциллограмме - МК выставляет этот байт адреса синхронно с ALE в такте Т2. Поскольку этот байт не используется сразу после того, как ALE стал 1, то можно смело пропускать этот байт в латч, и защелкивать (запрещать изменение) после того, как ALE стал в 0 - это ИМХО будет наиболее быстро. Сложно только описать задержки, да еще с переходом в другой домен - ну так или делать синхронизатор готовности данных и адреса (чтобы точно знать, когда всё готово, при этом - возможно, еще придется запоминать и остальной адрес и данные) - это ИМХО будет проще всего. Тем более что нужно передать всё это дальше в SRAM. Но с учетом чуть ли не 5-кратного превышения частоты ПЛИС над частотой МК - очень вероятно, что можно обойтись без промежуточных регистров (зависит от времянки SRAM и задержек ПЛИС в выходных блоках). Только всё подробнейшим образом разрисовать и просчитать.
  13. но latch то появится. Посмотреть после компиляции - как он в проекте обзывается (если с именем регистра исходника не будет совпадать) - и описать этот регистр в констрейне. Да и при комбинационной схеме есть возможность описать задержки (как конкретно пишется - уже не помню, есть в описании команд, кажется от synopsys)
  14. давно не смотрел, но раньше всё отсутствующее в бесплатной версии указывалось на их сайте. вряд ли. Мой любой белорусский проходил, даже техподдержку давали на gmail. Правда, позже попросили перейти на корпоративный ящик. А вот у xilinx я на мой белорусский адрес так за несколько месяцев попыток не смог ничего бесплатного получить...
  15. ИМХо есть подводный камень - если при фронте клока ПЛИС изменяется мл. байт адреса, то в регистре будет метастабильность, которая устаканится только при следующем такте ПЛИС (в лучшем случае). Есть шанс, хотя и не частый, что 1-2 такта ПЛИС уйдут насмарку, и при задании врем. ограничений это нужно предусмотреть. большое спасибо! возможно - в данном случае - задать макс. допустимую задержку от выхода этого latch до того фронта клока, на котором должен уже быть выставлен действительный адрес для SRAM. М.б. через мультицикл это определить - но с учетом асинхронности записи мл. байта в регистр ПЛИС и клока ПЛИС - т.е. 1-2 такта ПЛИС учесть на переход в др. клоковый домен.