topor_topor

нуда, ненадо учитывать ограничения PCB дизайнера - пусть крутиться как хочет потом..... Одно скажу точно, если вы пытаетесь построить корректно работающий SPI на высоких частотах, и у вас нет STA тайминг констрейна (SDC) со значением мин\макс внешних задержек - работать будет не всегда.... Это станет понятно, когда россчитать эти самые задержки и их возможный технологический розбросс, к чему я вас и пытаюсь подвести. Даже при 10нс SPI.CLK это уже не так просто. Это + детектор фронта.

"МК набил фифо записи как командами чтения, так и записи, ..." - а ПЛИС при этом чё с этим ФИФО делает? Ждёт его заполнения? По какому событию определяет заполнение? Или ПЛИС одновременно его и читает (судя по схеме)? А что если перехлеснётся ПЛИС с МК? так тут-же и написано: SCK, SSEL and MOSI пропускается через 2-х битовый shift registers. Это и есть тот самый синхронизатор на 2-х тригерах, о котором я и говорил вначале.

1) "если мы точно знаем," - в этом-то и дело. Как-бы их узнать..... 2) Как гарантировать стабильность задержки, тем более если она как вы сказали пару тактов? Вы вообще когда нибудь прощитывали эти величины и их розбросс для разных материалов платы? 3) Выдавать раньше на пару тактов можна (введя пустые биты между адресом и данными), но кто сказал что задержка на плате как-то кратна тактовой частоте SPI.CLK? что, длинной провода MISO будете данные относительно клока подстраивать на стороне МК? Это как-то не хорошо... Розводчик шипко ругаться будет однако.... Да и тулзы для росчёта таких задержек надо где-то взять.... 1) Как эта схемка исключает чтение из адреса ФИФО в который идёт одновременно запись? По-моему - никак. Прочтётся мусор. 2) при полном асинхронизме клоков записи и чтения, данные перепутаються (вы думаете что читаете текущее, а реально это предыдущее напр.).

1) двухклоковых фифо, PLL и ресинхронизаторы - это способы как связать асинхронные клок домены. 2) ресинхронизаторы убирают метастабильность. Гдето тут была ветка про метастабильность и способы её подавления - стоит почитать. В т.ч. и при помощи ФИФО. http://electronix.ru/forum/index.php?showtopic=93650 3) Что вы будуте делать с ФИФО когда адрес чтения совпадёт с адресом записи? Это не проблема. МК привяжет асинхронное прерывание к своему клоку. http://electronix.ru/redirect.php?http://w...8Boston_CDC.pdf Читать п.5.8.2 - Ваш случай. похоже тут не тупая задержка нужна, а надо 7 раз клок чтения передёрнуть, чтобы rdempty получить.... ----- Не тратьте время - выкинте все ФИФО, привяжите SPI к клоку ПЛИС и спокойно работайте. ================================================================================ Т.е. в вашем случае - конвеер. Чтобы прочитать данные надо выдать команду чтения, а потом какую-то другую, чтобы забрать данные. Ну для вычетки массива - вариант, а для роботы с одиночными командами - только затраты на 2-е повторение.... Не всегда гут. Может лутше SPI.CLK в 2 раза понизить? 100МГц на SPI.CLK означает что у вас есть полтакта (5нс) на все задержки распространения сигнала от [МК -to -FPGA.PAD- to - внутренний флоп FPGA ].... Какая величина задержки на плате (при дорожке 10см напр)? Какое минимальное её значение, а какое максимальное (это критично для сетап-холд таймингов)? Какой реальный розбросс задержек на плате (skew)? Какое сетап\холд требование для MISO на МК? А что если внутренняя частота меньше SPI.CLK? Хватит на ресинхронизацию и на обработку команды? ---------- Ну это на засыпку... :) А ваше решение с конвеером в принципе хорошее. Но лутше всётаки отработать за одну команду команду.

Вот это как-то не очень понятно. О каких 40 тактах речь? даём команду записи. Последний бит приходит на 40-м клоке. Где есчё 40 беруться для интерпретации? Или вы предлагаете передавать фрейм из 40 бит + есчё дофига тактов клока на его интерпретацию? Вы правы. 1) Строить SPI при тактировании от внешнего клока надо только тогда, когда тактовый клок со стороны ПЛИС почти равен скорости SPI клока или меньше. 2) Правда на 100 МГц хана наступает и в вашем случае - при задани коректных STA констрейнов (как учесть например, что задержка на плате меняется от мин значения к макс, какие эти значения получаються, итд...) Да и связать асинхронные клок домены (SPI - остальная часть ПЛИС) тоже непросто.....

ОК. Вижу Вы любитель проблем :) На канальном уровне всё просто - клок и данные. Захлопнул их в тригер и нет проблем... Предположим также что вы извернулись, и вам хватило тактов SPI фрейма на то, чтобы принять команду и декодировать её. И даже вы смогли правильно обконстрейнить всё для STA (и даже неизвестную задержку линии от МК к ПЛИС смогли правильно учесть...) Это не всем удаётся, ибо количество клоков ограничено числом бит в фрейме. Некоторые начинают тригера с negedge клоком использовать и прочую асинхронщину (типа заводить логику на ресеты...), а про тайминг констрейны в этом случае я вообще молчу..... Вот вам и асинхронщина началась. А дальше наверно надо и команду интерпретировать.... ПЛИС то от своего генератора работает и асинхронна к вашему SPI, который повешен на внешний клок. Надо как-то клок домены суметь вязывать.... --------- Поэтому-то я и рекомендую начинающим дурью не маяться - привязать все SPI сигналы к ПЛИС клоку и делать тревиальный синхронный цифровой дизайн. Зачем фифошки? Ну если очень хочется.... " сигнал прерывания (фифо чтения не пустое) будет привязан к клоку ПЛИС" - очень хорошо. МК предполагает что все прерывания вообще асинхронны (кнопку-то к прерыванию подключать вас не смущает?). "То есть мне нужно после получения прерывания выдержать паузу на МК и потом генерить клок от МК к ПЛИС, чтобы забирать данные из фифо чтения" - сразу забирайте. Зачем вам пауза? ПЛИС сначала фиксирует данные в ФИФО, а потом генерит прерывание.

синхронность понятие относительное.... У ПЛИС свой клок а у МК свой - всё асинхронно.

В деталях проблема не ясна но отвечу на что понял... 1) Вы работаете с SPI интерфейсом. Это значит что один конец мастер, а другой слейв. Сделайте МК мастером. Это значит что только он инициирует передачу данных. 2) Как сделать доступ в один и тот-же регистр и со стороны МК и со стороны ПЛИС по записи. -Придумайте протокол обмена по SPI: код команды, адрес, данные. -Когда МК даёт команду записи в регист, она принимается SPI декодером команд (в виде автомата) -Декодер команды останавливает ПЛИС и меняет регистр -Декодер команды перезапускает ПЛИС с новым значением 3) как сказать МК, что ПЛИС сменила значение регистра - по прерыванию - по SPI. В этом случае надо "завести" регистр состояния ПЛИС и читать его переодически командой SPI. Например, ПЛИС взводит бит состояния в 1 при последней записи в регистр, а при чтении регистра состояния этот бит автоматически обнуляется. 4) что от чего тактировать.... - проще всего SPI склок выдавать из МК (задайте нужную конфигурацию МК SPI) - ПЛИС должна иметь свой генератор клока выше частоты SPI клока - Все входные SPI сигналы в ПЛИС привязать к внутреннему клоку через ресинхронизаторы (2 тригера) - анализируя уровни SPI входов при помощи соответствующего автомата - декодировать SPI поток данных. Вот как-то так... --------------------- Есчё добавлю... SPI понятие розтяжимое.... Фактически надо говорить о СТЕКЕ протоколов. В этом случае SPI - это только описание доступа к каналу передачи (клок, данные) - канальный уровень Дальше идёт формат команды SPI (код команды, адрес, данные) Дальше интерпретатор команд (напр. чтение из регистра 1 выполняется со сбросом бита состояния, а регистра 2 без таких-же действий) - прикладной уровень

Кому интересно розвитие темы.... Установка разных значений битрейта COM порта действительно не влияет на битрейт со стороны FTDI.FIFO. В любом случае получается константа большой (максимально возможной для канала USB порт - FTDI) величины. Спасибо svss за ответы.

Странно, ибо с VCP драйвером - эмуляция СОМ порта должна быть 100%.... Возможно програмно и можно вычитывать СTS состояние, но при использовании FTDI.VCP драйвера оно не работает "по-чесному" как в реальном СОМ, а просто всегда поставлено в СTS=1 (чтобы обмануть программу и всегда розрешать писать в порт. по типу нульмодема). Хотелось-бы это подтвердить документально..... Чё-то описание особенностей роботы с FTDI.VCP драйвером не находил.... Да и странно отсутствие хендшейкинга.... Это понятно, но это со стороны железки (FIFO), а у меня проблемы на стороне программы. Программе тоже нужен хендшейк... При роботе с чесным ПС СОМ портом я всегда использовал хендшейкинг в программе..... Это конечно странно.... При работе с D2XX драйвером, программа может получать от него обратную связь через FT_GetStatus(), FT_GetModemStatus, и тем самым не переполнять все буфера. 1) Зачем при таком розкладе тогда вообще FT_GetModemStatus, FT_SetBaudRate, FT_SetFlowControl? 2) Что тогда задаёт FT_SetBaudRate если по Вашему "Скорости обмена тоже нет, сколько ни устанавливайте бодрейт"? 3) Вопрос в том, как работать со статусом модема в VCP драйвере? Собственно я даже умею получать состояние СTS, но оно почему-то константа.... К сожалению это о D2XX но не о VCP драйвере.... 4) Я так понял, что вы используете D2XX драйвер. Для гарантии непереполнения буферов, вы используете FT_GetStatus(). Правильно? А FT_GetModemStatus() пробовали (RTS\CTS)? ------------------ Кстати, неужели никто не пользуется хендшейкингом при написании Win софта при роботе с FTDI? А где и как Вы видете какой битрейт установился?

Мне тоже на хендшейк похоже, вот и спрашиваю как его правильно использовать... Хоть скорость "приёмника" и большая, но программа должна быть правильно написана - с хендшейком, особенно потому, что "COM-портовский битрейт" в USB имеет довольно специфическую реализацию из-за разных принципов передачи. 2) Пишу на Tcl, поэтому и терминологические отличия (в часности команда Open). Можна сказать что использовал FT_SetFlowControl(...) для розрешения аппаратного (RTS\CTS) хендшейка. Но CTS=1 как я не старался. Вам удавалось видеть чтобы CTS=0 когда нибудь? 3) "приоритет конфигураций" - Что будет главнее, если все три варианта противоречиво заданы (напр. разный битрейт указан, то какой установиться)? Переформулирую: FTDIPORT.INF - это прямо настройки в драйвере -> win XP settings в окошке свойств порта-> FT_SetFlowControl(...) прямо из программы. 4) FT245 это USB FIFO, но со стороны win XP - это COM порт, а значит должен работать и в режиме аппаратного хендшейка со стороны программы. Или при работе с FT245 VCP драйвером хендшейк не предусмотрен или какой-то особенный? RXF/TXE - это хендшейк на стороне FIFO.

Добрый день, Уважаемые знатоки, помогите решить вопрос с програмированием FTDI FT245R (USB-FIFO). Конфигурация такая: - На стороне ПС: win XP +VCP драйвер (COM порт) - На другом конце - железка, которая забирает данные с FT245R.FIFO на большой скорости (всё чё приходит до >3MB\sek), согласно протоколу - Передаю данные побайтно (с промежуточной печатью на экран между посылками) ПРОБЛЕМА: Всё работает хорошо, но недолго - после передачи N байт (разное количество, типично около 300), скорость передачи уменьшается до 1 байта за 4 сек приблизительно. Данные приходят во внешнюю железку неправильные (неправильно интерпретируються) Пробовал менять настройки COM (и разный хендшейкинг, и разную скорость, и разные настройки буферов...) - не помогает. ERROR's порт не возвращает, CTS=1 всегда. ВОПРОС: 1) Кто сталкивался с подобным? Где можно прочитать по теме... 2) Пробовал задать маленький выходной буфер (64 байта) и получить CTS=0 забив его байтами, но не выходит - CTS=1 всегда. Кто знает как использовать правильно аппаратный хендшейк? Как сконфигурить порт для этого? 3) В win XP какой приоритет конфигураций COM порта (FTDIPORT.INF -> win XP settings -> опции команды OPEN)? Заранее благодарю

А в какую схему по Вашему синтезатор должен превратить эту строчку? Общий совет простой: ненадо насиловать синтезатор хитро-перевыподвертнутыми синтаксическими конструкциями. Розложите это на реализуемые в синтезе элементы: счётчики, регистры, суматоры и т.п. и проблемы появляться не будут (на Verilog програмировать нельзя, этож не С).

1) А чё за ошибки-то моделсим выдает? 2) Тригеры у вас описаны 100% правильно с асинхронным сбросом.... В вашем "технолоджи" я так понял есть 2 соответствующх тригера в которых входные данные подключены в "разном стиле": (sload=1, sdata=imax_start), и (просто d=imax_ready) А как при этом асинхронные ресеты этих-же тригеров подключены? 3) Регистр должен быть таким как описан в Верилоге, а не зависимым от места розположения :) Синхронный и асинхронный сбросы работают немного по-разному.... 4) А почему сделан вывод, что тригер стал вдруг с синхронным сбросом?

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

1) "Не бери дурного в голову, а тяжелого в руки" - вот никто и не брал..... 2) Опишите реализацию протокол доступа к асинхронной статической памяти "через обычный масив С" ну или хотя-бы просто тригер.... В RTL, для этого напр. нада кучу тригеров задействовать, а как в С - чесно говоря ума не приложу. 3) "не заморачиваемся на циклоаккуратность."... ну програмисту это может и можно но в RTL.... Это типа летим в соседнюю галактику, не заморачиваясь тем как сделаем антигравитационный двигвтель....

1) "имитация на Си процессов" - ну не знаю - не видал такого. Немогу оценить простоту трансляции такого С описания в verilog. 2) Если вы работаете в CatapultC - то типа теоритически он вам должен с математики сгенерить реализабельный verilog насколько я его знаю.... Какраз что вы и хотите - конвертит С в verilog. Ну как минимум для DSP алгоритмов. Неужели CatapultC не сгенерил RTL ? Поделитесь опитом работы с CatapultC... 3) Си на Асм таки переводят - компилятором...... Не вы первый програмист ум которого бударажит идея типа "конвертации" С в RTL (verilog). Mentor даже такой (и единственный) конвертер изобрёл - CatapultC. А практически - такое пока не работает, тем более в общем случае.... 4) Всётаки, посоветую сконцентрироваться на внятно-розжёвано-доходчивом традиционном техническом задании.

1) Я вас правильно понял, что у вас фактически есть С модель будущего устройства? Если да - то хорошо, верификаторы такое любят. Только надо её подключаемой к симулятору сделать. Verilog напр. может работать напрямую с чистым С. А есчё лутше сразу SystemVerilog референс модель делать. 2) Есть внятное описание - удивительно, но этого может и хватить. 3) Есть сложные циклограммы взаимодействия модулей - нарисуйте их в виде автоматов Мура\Мили - поможет 4) clock-gating в лутшем случае начинается на этапе RTL, а то и бекенда. 5) Что такое "псевдо-процессы" не очень понимаю. Математику лутше добить до уровня аппаратно реализуемых блочков - сумматоров, умножителей... Незабудьте указать розрядность и оптимизировать формулу под быстродействие. Да и simulink модель на таком уровне поможет сильно. 6) Что внутри вашей програмной модели - никого не интересует (см. п.1)). Читать С код (даже детализированный) чтобы что-то понять - тупик.

Заинтересовало сие чудо и меня... Кроме прикольной архитектуры обратил я внимание на такие вещи: 1) "С" компилятора чё-то негде скачать, а есть только асемблер. ОС тоже нету. Похоже и не скоро будут, т.к. архитектура не клеется со всеми наработками для традиционных процесоров (тут GCC переделкой не обойтись).... Поправте если не прав... 2) Розработчик утверждает что: "Откомпилированная программа может быть выполнена на любом количестве клеток. При этом возможно динамическое изменение их количества, что обеспечивает реализацию методологии постепенной деградации процессора при отказах его клеток." Возникае вопрос: реализована-ли в имеющихся ядрах система проверки работоспособности клетки (self checking), её автоматическое "блокирование" и таким образом переход выполнения откомпилированной программы на меньшем количестве клеток? Или надо вручную перепрошивать ПЗУ, перелинковать откомпиленую программу и.т.п. Чем это лутше традиционных процесоров? 3) Розработчик утверждает что: " увеличение производительности и сокращение энергопотребления в несколько раз (см. характеристики), так как позволяет реализовать эффективный вычислительный процесс;" Возникае вопрос: На сколько % уменьшают потребление "архитектурные клеточные навороты" и на сколько - простой gated clock? Мне кажется это соотношение где-то 5 к 95 соответственно. Есть ли смысл на энергопотреблении заострять внимание? Где хотя-бы результаты Power симуляций с VCD с gated clock и без, а также симуляции аналогичной по MIPS традиционной архитектуры и клеточной без gated clock в обоих и на одной технологии? А-то приведённые данные как-то сомнительны (сравнили пароход с паровозом: MCc0401100000 vs TMS320 ... ибо неизвестно что внутри TMS и какой в нём был критерий оптимизации) 4) Также интересно сравнить традиционный процессор и клеточный при тех-же MIPS по величине тактовой частоты и количеству тригеров.... Не могу утверждать, но кажеться мне у клеточного тригеров (и площадь) куда больше.... Не проще ли достичь MIPS простым ускорением, а не архитектурным усложнением? ---------- Написал не злорадства ради, а технической объективности для.... Без предъявления процессора который на рынке лутше других - доказать свою крутость сложно....

Точнее сказать, метастабильность моделируется в модели тригера, путём установки его выхода в Х при нарушении setup\hold. А симулятор да - непричём.

А извините, это до синтеза или после (с реальными задержками) неработает? Если после - то и не должно. Модель тригера так описана, что впадает в Х если setup\hold на входе невыполняется - другими словами моделирует метастабильность. Если Вы такое видите - то у Вас правильно созданный тест - показал проблему. Для того чтобы в симуляции показать правильную роботу Вашего синхронизатора, прийдётся задать исключение. А именно, заставить первый тригер в синхросхеме не выдавать Х при невыполнении setup\hold. Как это в Quartus сделать не подскажу, а обычно это можно сделать, отредактировав файл реальных задержек (SDF). Надо изменить вручную setup\hold проверки в первых тригерах синхросхем на 0.... Нивкоем случае не портите созданный тест (методом подачи входных воздействий по спаду напр.). Этим Вы просто закроете глаза на проблему, и пропустите пару мест в дизайне где нужно сознательно вставить синхронизатор. 1) Что-то мне подсказывает что в TimeQuest можно засунуть всё, для чего откуда либо получен нетлист и SDF.... TimeQuest к семействам не привязан. Создайте нетлист и SDF в любой версии софта. 2) Использование TimeQuest Вам не поможет решить проблемы с Clock Hold - TimeQuest просто STA анализатор, а "ошибки в разделе Clock Hold" - это проблемы физической реализации. Их надо фиксить (это просто). 3) Синхронизация сигналов не влияет на наличие Clock Hold. Эти виолейшины и в 100% синхронной схеме возможны.

Это про радиацию я так понял инфа? Никак ума не приложу, как некий встроенный периодически запускаемый тест спасает от радиоактивности? А если нейтрон ударит после теста? А если воздействие не нарушает структуры ОЗУ (при этом портятся текущие данные, а вновь записанные тестером читаються правильно)? А если сама схема тестера (тоже прошивочное ОЗУ междупрочим) всегда в ОК станет? Как дублирование ОЗУ спасёт тоже неясно - какое из 2-х правильное? Если есть внятная инфа по конкретным реализациям (от каких типов фейлов как защищать цифру) поделитесь плиз.

Золотые слова! Чё думать - трясти надо: // mode=1 - сдвиговый регистр // mode=0 - обычный регистр `define SCAN 1 always @ (posedge clk) begin if (mode == SCAN) reg[7:0] <= {reg[6:0], 1'b0} else reg[7:0] <= data_in[7:0]; end assign SERIAL_OUT = reg[7];

Похоже имелось ввиду "комбинаторных", а не "асинхронных "... А чего вдруг комбинаторика (а именно паралельные мультиплексоры) ухудшает тайминги на функциональной части схемы? Вы что, сделали такие же "скоростные констрейны" на этих мультиплексорах как и на функциональной части? Зачем? Задайте слабее - тут-же время некритично.... Опять же, предложенный вариант 2) не требует много комбинаторики....

1) Иногда детальный анализ ТЗ исключает необходимость решения искуственных проблем... Вы зачем-то хотите тестировать встроенную в ПЛИС блочною ОЗУ (не ОЗУ в которой конфигурация храниться). Зачем? Производитель её уже проверил при производстве. Она сделана фиксированной (структура не програмируется) и сломается врядли.... в отличии от "зашитой цифровой схемы" которая её тестирует.... Если это защита от радиации, то фиг Вам какие внутренние чекеры помогут - они ведь тоже в конфигурационной ОЗУ зашиты. Тут TMR + ECC надо, что исключает манипуляции с регистрами чекеров... 2) Ежели всётаки очень надо... И при условии что у вас есть достаточно времени на сбор данных то: включите все ваши регистры в один большой сдвиговый (в одном режиме это отдельные паралельные регистры, а вдругом - один большой двигающий). Сначала туда записывается результаты тестирования, а потом вы их медленно выдвигаете наружу. Никаких тяжёлых парралельных мультиплексоров и проблем с таймингами... Что значит "реконфигурируемый"? Это всмысле разные прошивки ПЛИС? Или это прошивка одна, но имеет несколько режимов? Или это RTL с параметрами который надо превращать в разные прошивки? В последнем случае, Вы должны либо сделать констрейны независимые от параметров RTL (что обычно и бывает), либо создать параметризованные констрейны. Рекомендую для тайминг констрейнов использовать SDC формат.