olegras

Попробуйте так: даете клоковому сигналу жесткий констрейн. P&R выдаст отрицательный slack, вот там и посмотрите что именно не вписывается в нужный тайминг...

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

Да ладно Вам, конечно правильнее. Я же написал "почти"... По поводу внешней памяти - если важнее количество параллельных блоков - внешняя память поможет. Если важнее скорость - внешняя память может стать узким местом.

Без описания Вашего алгоритма, параметров "входного массива", что такое "на процессорах - совсем плохо " и др. - подсказать что-то конкретное довольно сложно. Судя по всему можно добиться выполнения одного шага алгоритма за один такт (если например получится разбить 3 обращения к массиву на чтение - на 1 обращение к 3 массивам). Расчитывайте на такты в сотни МГц. В любом случае задача полностью "подходит для реализации на плис". По поводу сколько одновременно выполняющихся таких "алгоритмов" врядли Вам кто-то поможет (см. выше). Можно поступить примерно так: В среде разработки выбрать "самую навороченную FPGA", реализовать алгоритм и посмотреть сколько он занимает емкости камня в процентах от общей емкости. А если мало - поставить несколько FPGA (т.к. все алгоритмы параллельны). Кстати, самые навороченные FPGA стоят тысячи долларов... Пока набирал текст - XVR уже ответил, получилось почти одно и тоже...

UG383. Spartan-6 FPGA Block RAM Resources User Guide: То есть возможное увеличение размера bit файла в зависимости от количества использованных 9 Kb block RAM - нормальная ситуация.

Когда-то делал эксперименты с автоматами. Хотел узнать разницу между асинхронно-синхронным и чисто синхронным автоматом. Описывал одни и те же автоматы двумя способами. Состояний на 10-15. После синтеза результаты были одинаковые. Это было хорошо видно в RTL вьюере. Выводы были такими, что в варианте с одним процессом мы описываем логику (ту, что на входах триггеров) и сами триггеры в одном процессе. В варианте с двумя - ту же логику описываем в асинхронном процессе, триггеры - в синхронном. И все. То есть разница только в способе представления/описания автомата. Сейчас работаю в 14-м ISE, у которого RTL вьюер паршивее, чем можно представить в страшном сне...

Похоже, что так и есть. Проект на S6 с ПЗУ на BRAM и без них имеют разный размер. Причем если нету BRAM то от количества задействованной логики (по крайней мере ~ от 1% до 30%) размер не меняется.

Я бы все же состояние s31 явно бы описал. А входные rdy, miosio, miso у Вас асинхронные относительно clk?

А зачем вообще нужны режимы с частью непередаваемых данных? Может это и не спортивно, но как вариант: Превратить хитроумный узел в тупое устройство. DSP всегда считывает с ПЛИС одну и ту же последовательность А1 - А8/А1 - А8... А использует те данные, которые ему нужны.

Тем более что диагностический блок - это тоже автомат?.. :rolleyes:

Он имел ввиду что обе выполнятся

Мне кажется это не совсем тот случай. if/else это все таки взаимоиключающее условие. Один провод с двумя возможными состояниями (а не с одним). Два провода - четыре состояния (а не два).

А меня еще интересует: есть у меня автомат на 57 состояний. Синтезатор имплементирует его по "one-hot", т.е. кодирует 57 битным словом, в котором каждому состоянию соответствует только одна 1, остальные 0. С одной стороны как бы понятно как будет работать вся логика по выходам такого автомата. С другой стороны - а если на выходе автомата появятся две, три единицы? Есть ли гарантия того что так не произойдет?

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

Уважаемый ТС. Не поленитесь - перечитайте эту тему с самого начала. Посчитайте, сколько раз Вам намекали на ресет. Обидно блин...

Все таки проверьте напряжение ресета.

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

В моем даташите в названии lan8710ai-ezk.pdf, а по тексту lan8710i (без a). Не досмотрел, извиняюсь. Но в Вашем - наличие pull-up'ов показано в таблице 2.1 в графе buffer type (PU), а в таблице 2.9 раскрывается что PU это internal pull-up. Так вот в табл. 2.1 как раз все mode - PU.

Datasheet на трансивер lan8710ai. Стр. 71. Table 7.10 nINT/TXER/TXD4 Pull-up TXEN Pull-down RXD0/MODE0 Pull-up RXD1/MODE1 Pull-up RXD2/RMIISEL Pull-down RXD3/PHYAD2 Pull-down RXER/RXD4/PHYAD0 Pull-down RXCLK/PHYAD1 Pull-down COL/CRS_DV/MODE2 Pull-up CRS Pull-down LED1/REGOFF Pull-down LED2/nINTSEL Pull-up MDIO Pull-up nRST Pull-up Это копи-паст из таблицы этого pdf

10К на ногах по схеме - это не похоже на pull-down. С учетом внутренних pull-up'ов (Datasheet, Table 7.10), думаю что посде старта будет "All capable. Auto-negotiation enabled" По умолчанию (после аппаратного ресета) этот ресет снят От скорости в коде управления физикой по MII ничего не меняется. Меняется от дуплекса (коллизия и все такое). То есть, насколько я помню, отличие поведения физики от скорости только в том, что при приеме пакета по RXD - при 100 преамбула приходит полностью, при 10 приходит только SFD (хотя передавать преамбулу полностью надо в любом случае). По крайней мере 3 или 4 опробованных трансивера от разных производителей вели себя именно так. Если правильно построить приемную часть (т.е. ждать SFD после поднятия RXDV), то установленную скорость можно даже не анализировать. Ну если ее не надо например выводить на дисплей...

Вот эту часть кода (включая .ucf) хотя бы можете выложить? Содержимое ROM и сторона ПК пока не нужны.

Хорошо. Видимо я не смог объяснить что от Вас требуется. Зайдем с другой стороны. Вы не могли бы выложить свой код?

В этом проекте ничего не передавая на трансивер, проверьте уровни на всех его управляющих ногах (кабель Ethernet отключите). Потом перевключите плату (без прошивки ПЛИС) и замерьте эти же ноги. Отпишитесь.

Ну здесь действительно можно обойтись без процессора. Но дополнительно устройство должно (как минимум, при работе в реальных условиях): - уметь отвечать на ARP ПК; - если предполагается, что сеть может быть и полудуплекс - уметь выполнять процедуру разрешения коллизии (эта процедура описана не помно в каком RFC и хорошо ложится на конечный автомат); - иметь возможность как-то вводить IP и МАС адреса сторон (например УАРТ + ГиперТерминал); - обязательно учитывать необходимость IPG (минимальный интервал между пакетами); - учитывать, что в сети (если она составная) может оказаться что размер Вашего пакета надо будет динамически уменьшать (об этом устройство узнает в пришедшем пакете ICMP); - учитывать, что в сети UDP пакет может потеряться (и это законно). Ну если с ходу - пока все. Потом можно будет прикрутить ICMP, чтобы с ПК пинговать (если надо). Все это возможно реализовать в автомате. Но сначала - трансивер. Или он у Вас уже заработал?

То есть: Со стороны ПК - с фиксированных IP и МАС адресов ПК, по фиксированным UDP портам на устройство периодически поступают пакеты из фиксированного набора ("команд"). И только. Со стороны устройства - с фиксированных IP и МАС адресов устройства, по фиксированным UDP портам на ПК непрерывно (почти непрерывно) поступают пакеты. И толко. Так?