Уважаемые коллеги! Если надо с РC (Win7) передавать данные c/на ПЛИС (у нас CYCLONE IV E) то правильно ли будет со стороны РС использовать обмен с RS-232, а со стороны ПЛИС (она на DE2-115) - UART (SoPC Builder ready)? Можно ли использовать JTAG UART, даёт ли это какие-либо преимущества? Заранее спасибо.

Я в своих проектах связываюсь с РС (Win7) через UART. Со стороны компа RS-232 или RS-485, со стороны плис UART+формирователь уровней (уарт из и SoPC Builder, и Qsys). Cyclon III, DE0.
JTAG UART использовать для связи с РС со своим ПО теоретически можно, но нужно ковыряться в нём. Дешевле (быстрее поднять) использовать просто uart. JTAG UART я использую только для отладки: в BSP редакторе указал поток для stdout - JTAG UART, в нужных местах программы делаю printf("log message"), на компе запускаю терминал (что-то типа nios2-trminal) и вижу логи, ероры и прочую служебную информацию. А как без nios2-trminal связаться с компом - гуглвпомощь.

Для связи можно использовать всё что угодно UART, USB FIFO, ethernet. Как бы тут всё зависит от того, что вы хотите передавать, как быстро и как просто должна быть построена реализация. По описаниями DE2-115 у вас простор для творчества.
А JTAG UART лучше оставить для отладки. Потому что обмен с платой по любому протоколу всё равно придется отлаживать.

какая, предпологаемая, скорость передачи данных?

Плюсы не надо преобразователя уровней УАРТ - РС232
недостатки, без среды разработки и жетага данные не получите.

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

Я предлагаю несколько другой вариант.
Возьмите любой маленький микроконтроллер. Что-то с 8-ю выводами... И от него с одной стороны - UART или USB, а с другой - SPI.
Так вот, UART - это байт ориентированный канал передачи данных. Все байты одинаковые, начало или конец пакета данных не определены... И над ним, сверху придется надстраивать протокол. Надо будет формировать пакеты, контрольные суммы, запросы-перезапросы и т.д. Все это делать в ПЛИС - долго и занудно, да и ресурса сожрет много. А вот в микроконтроллере сделаете за полчаса не напрягаясь. А со стороны SPI можно будет сформировать сигнал, стобирующий пакет. И сигнал "Ошибка", когда при приеме пакет пришел неправильный и его не надо обрабатывать... И при таком подходе практически весь дорогой ресурс ПЛИС сохранится...
Можно например взять DLP2232 и там есть возможность получить с одной стороны USB, а с другой - SPI... Но обработки пакетов там нет...

У человека есть уже кит DE2-115, ему нет надобности мастерить что-либо руками. На сколько знаю там на борту есть RS-232 чего на небольших скоростях должно хватить.

Странно, я же русским по белому написал, что данные обычно передаются пакетами... Кто в ПЛИСе будет пакеты делать? ТС явно новичек. Так ему что, в ПЛИС еще процессор запихнуть надо? Ему это пока сложно. А взять самый дешевый стартовый набор и соединить его с имеющимся китом - дело 10-ти минут...
Вот Вы и объясните это мне, что и зачем Вы предлагаете конкретно... Без вот этого "ему нет надобности мастерить "... Речь шла не о том, есть ли там RS или его нет, речь шла о передаче данных... А данные передаются либо медленно и занудно символьными кодами и 0A+0D - это начало пакета... И дальше все остальное в символьных кодах... Но при этом и перекодировка, и контрольные суммы должны быть... Либо передача данных идет в нех-кодах но тогда либо бит-стаффинги, либо байт-стаффинги. И передачей данных занимается отдельный контроллер, что я и предлагаю...

Простите что вмешиваюсь, просто с этим китом имел дело, там НИОС воткнуть -3 минуты. Заоодно пора привыкать, что встроенные АРМ ядра скоро будут почти во всех ПЛИС. НИОС - очень хороший старт для этого, хотя его надежность лично для меня под сомнением. По теме - рекомендую SLIP (байт стаффинг) - минимум оверхэда и все понятно

да я только позавчера писал в ПЛИС автомат который принимает пакет данных адрес + данные + контрольная сумма. За полвечера сделал с отладкой. Не надо делать сложные автоматы, если нужно просто передавать-принимать данные.

И еще один момент если ТС говорит о жетаг-уарте, скорее всего речь идет уже о проце в плисе...

и второй момент, голая плис к компу - немного неудобная система, какой то контроллер интерфейсный все же нужен...

Я смутно помню, что из Ниос можно работать с файлами хоста напрямую через тот же JTAG-UART.
Или через что-то ещё более системное, через что прога грузится и идёт отладка, только в настройках BSP где-то следует включить HostFS.
Судя по молчанию ТС, проблему он давно решил, но я бы лично СОМ-порты и пр. самопись исключил бы.
Ниос принял данные через fopen()/fread() -- поклал в ОЗУ, толкнул обработку, в обратную сторону не трудней, только постоянный бластер требуется для связи, ну и как при любом другом соединении. Только скорость не ахти, хотя с последним разогнанным в 4 раза бластером вдруг и ахти уже ?