в том то и дело что осциллографом там все проверено МНОГОКРАТНО. На всех выводах присутствуют сигналы .... на всякий подтянул к питанию шину данных .... в зависимости что на экране - линии данных D0 D6 есть сигналы или просто 0
Вид для печати
лучей как раз 4 и еще лог.анализатор на 16 каналов - к сожалению , только на работе .
Я уже многократно убеждался в отсутствии "контактов где они нужны" и КЗ между ножками CPLD.
Все идет к тому, что напишу простой скрипт для "JTAG Live Studio" на Python , который проверит эту связку "CPLD+RAM" .... я им уже баловался - моргал светодиодами на другой платке с Xilinx....
Есть у меня сомнения по поводу того, что Quatrus "оптимизирует" что-то и выкидывает нужное из кода.
Я настройки не менял особо там - только неиспользуемые пины в 3ее состояние перевел и на TTL уровни.
Я не автор и не могу судить как этот проект работает в реале в CPLD. По-этому и надоедаю автору и "со-авторам" с вопросами системного характреа. А по электронике я сам разберусь (с КЗ и обрывами и конфликтами на шинах - уже много десятков лет этим занимаюсь)) ).
Я очень ценю помощь отвечающих в этом топике!!! Это помогает найти ИСТИНУ))
(безотносительно обсуждаемого железа - не лучшее решение для неиспользуемых пинов.)
ну а исходник на что, его надо вдумчиво курить)
да и функционал скандаблера не бог весть какой сложный: в пределах одной входной видеостроки на одну запись в память приходится два чтения, на один входной строчный синхроимпульс генерится два выходных - вот эту картинку и стоит для начала снять анализатором (необязательно при этом заводить все адреса, достаточно нескольких младших разрядов для оценки правильности работы счетчиков)
- - - Добавлено - - -
да и схему с макетки срисовать не лишним будет (само-реверс-инжиниринг, как метод отладки. иногда приводит к неожиданным результатам))
так это же Ваши исходники я использую из этой темы)))
- - - Добавлено - - -
вот оба , Вами выложенные в теме ...
Вложение 79066Вложение 79067
- - - Добавлено - - -
схемы НЕТ как таковой)) две макетки - на них 2 чипа соединные проводами)))
Это не про код базового модуля, а как раз про побочные штуки внутри проекта, меня интересовал .qsf и финальный .pin - дело ж в каких-то мелочах..
qsf вроде без вопросов, да и в коде, по сути, нету изменений кроме ряды константных выходов, хотя для макета я бы не тянул отдельные провода к A17, A18 и CS, а занулил бы - это припаять проще, чем к ПЛИСке )
Память в DIP32, то есть на в reverse-корпусе, тут тоже не ошибиться. На 22й ноге всегда 0 ?
Вот схема этих проводов и интересует, ошибку ж ищем)Цитата:
схемы НЕТ как таковой)) две макетки - на них 2 чипа соединные проводами)))
Я тоже сталкивался с тем, что доказявая по своему клубку проводов себе (и не только себе), что все правильно, вдруг обнаруживается какой-нибудь нежданчик.
я же многократно говорил, что в программе ТорJtag ВСЕ ЛИНИИ С CPLD дрыгал и смотрел на ОЗУ!!! на соотвествующем пине....на CS всегда "0"))) Я подключал все пины от ОЗУ к CPLD как для этого случая - программно полностью управлять ОЗУ из строннего софта по JTAG Boundary-Scan technology. Надежно и удобно. А еще можно прошивать таким образом ПЗУ ВНУТРИ СХЕМЫ ( что я и делал с основной ПЗУ - правда не быстро - 2часа для 512к)
Ничего не остается как снова пройтись в режиме JTAG с тестером ну или на работе распаяю пины с шины данных и управления ОЗУ(для логического анализатора) или скриптом на Pythone все-таки напишу тест для ОЗУ.
Не совсем понял , что Вы имели ввиду но память находиться ПОД CPLD - место надо экономить на макетке и линии короче будут))) По-идее на макетке весь Синклер можно засунуть под CPLD на переходной плате - у меня под основной CPLD 2 ОЗУ корпуса расположены очень удобно))) Правда много макроячеек съедает ручное назанчение пинов на CPLD (((( Я изза этого не смог Карабас нано весь впихнуть в 216 макроячеек (на авторасстановке все влазит)