another day
This commit is contained in:
parent
c141dd0ee6
commit
df40d6c91c
|
|
@ -0,0 +1 @@
|
|||
ivan-igorevich@DESKTOP-HGRRHPT.10852:1670842641
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
\documentclass[a4paper]{article}
|
||||
|
||||
\input{../common-preamble}
|
||||
\input{../bmstu-preamble}
|
||||
\input{../fancy-listings-preamble}
|
||||
\usepackage{icomma}
|
||||
|
||||
\numerationTop
|
||||
|
||||
\begin{document}
|
||||
\fontsize{14pt}{14pt}\selectfont % Вполне очевидно, что мы хотим 14й шрифт, все его хотят
|
||||
\thispagestyle{empty}
|
||||
\makeBMSTUHeader
|
||||
|
||||
\makeReportTitle{лабораторной}{1}{Исследование коллизий при множественном доступе к среде в
|
||||
беспроводных сетях передачи информации}{Беспроводные технологии в информационных системах}{}{C.С. Баскаков}
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\tableofcontents
|
||||
\newpage
|
||||
\pagestyle{fancy}
|
||||
\sloppy
|
||||
\section{Цель}
|
||||
Закрепление навыков работы с системой имитационного моделирования OMNeT++, построение имитационной модели беспроводной системы сбора данных и исследование ее характеристик при множественном доступе к среде передачи данных в условиях наличия коллизий.
|
||||
|
||||
\section{Задачи}
|
||||
\begin{enumerate}
|
||||
\item Повторить описанные действия с исходным проектом, чтобы убедиться в повторяемости результатов.
|
||||
\item В исходной имитационной модели системы заменить количество передатчиков $N_{TX}$, размер пакета $L_{app}$ и скорость передачи данных $R$ в соответствии с индивидуальным вариантом
|
||||
\item Провести имитационный эксперимент с модифицированной моделью системы для исследования пропускной способности и вероятности коллизий. Построить графики. Сравнить теоретические значения с результатами моделирования, убедиться в корректности полученных значений.
|
||||
\item Увеличить размер пакета $L_{app}$ и скорость передачи данных $R$ в 2 раза и повторить эксперимент. Сравнить полученный результат с предыдущими графиками и объяснить наблюдения.
|
||||
\end{enumerate}
|
||||
|
||||
\newpage
|
||||
\section{Выполнение работы}
|
||||
\subsection{Повторение моделирования}
|
||||
На рисунке \hrf{pic:src} представлены графики, полученные в результате имитационного моделирования и расчёта в Matlab. Полученные графики идентичны представленным в методическом материале, что говорит о корректности воспроизведения имитационного моделирования с исходными данными.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\begin{subfigure}[b]{0.32\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{pics/03-wtis-Lab-1-Nrx-500.pdf}
|
||||
\caption{Общее количество полученных пакетов}
|
||||
\label{pic:nrx}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}[b]{0.32\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{pics/03-wtis-Lab-1-Kapp-500.pdf}
|
||||
\caption{Общий коэффициент доставки пакетов}
|
||||
\label{pic:kapp}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}[b]{0.32\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{pics/03-wtis-Lab-1-Ke-500.pdf}
|
||||
\caption{Общий коэффициент энергопотребления}
|
||||
\label{pic:ke}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}[b]{0.32\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{pics/03-wtis-Lab-1-Ketx-500.pdf}
|
||||
\caption{Коэффициент энергопотребления передатчиков}
|
||||
\label{pic:ketx}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}[b]{0.32\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{pics/03-wtis-Lab-1-Kphy-500.pdf}
|
||||
\caption{Коэффициент надёжности доставки пакетов}
|
||||
\label{pic:kphy}
|
||||
\end{subfigure}
|
||||
\caption{Графики исходного проекта}
|
||||
\label{pic:src}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Индивидуальное задание}
|
||||
Для выполнения индивидуального задания был получен вариант № 10, параметры моделирования (значения переменных) которого представлены в таблице \hrf{tbl:var}.
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\begin{tabular}{|c|c|c|c|}
|
||||
\hline
|
||||
$N_{TX}$ (шт.) & $L_{app}$ (байт) & $R$ (кбит/с) & $k$ \\ [0.5ex]
|
||||
\hline
|
||||
30 & 50 & 1500 & 30 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Таблица значений для варианта}
|
||||
\label{tbl:var}
|
||||
\end{table}
|
||||
|
||||
Для выполнения имитационного моделирования необходимо задать диапазон изменения среднего периода передачи пакетов ($T_s$) таким образом, чтобы полный нормированный трафик $G$ был в диапазоне $[0,05; 1]$
|
||||
|
||||
Поскольку $G=\frac{N_{TX}}{T_s}*\tau$, где $\tau=\frac{8*L_{phy}}{R}$, а $L_{phy} = L_{app} + 63$, то $T_s= \frac{N_{TX}\tau}{G}$. Для $G = 0,05; T_s \approx 361,6$, а для $G = 1; T_s \approx 18,08$ мсек.
|
||||
|
||||
|
||||
\section{Выводы}
|
||||
|
||||
\end{document}
|
||||
48
03-FPGA.tex
48
03-FPGA.tex
|
|
@ -215,10 +215,56 @@ Gated Clock - ТИ, который модифицируется на логик
|
|||
|
||||
так бывает нужно, когда нужно, чтобы схема работала не на каждом такте. Это возможно сделать при помощи сигнала разрешения. Это часто нужно делать для формирования определённой скважности (переключений в дереве ТИ меньше и входные структуры триггеров переключаются реже, соответственно немного ниже потребление). 1. ФАПЧ. 2. clkctrl (фактически, это небольшой модуль, который контролирует вход на глобальную шину, позволяет делать мультиплексирование и разрешение). Так простой И вырезает нужные фронты (но проблемы сдвига фронта никуда не исчезают) если не использовать clkctrl.
|
||||
|
||||
\item Конфигурация сигналов сброса: Комб логика, которая используется как асинхронный сброс, должна быть синхронизирована (иначе комбинационная логика будет формировать глитчи и ресеты могут срабатывать не тогда, когда нужно). Кросс-доменные (тактовых доменов) сбросы необходимо синхронизировать.
|
||||
|
||||
\begin{frm}
|
||||
Синхронизация асинхронных сигналов. АС - это сигнал, изменяющийся без привязки к ТИ. То есть АС может нарушать (и часто нарушает) время установки и время удержания относительно ТИ. В этом случае триггер попадает в метастабильное состояние. При попадании в МСС триггер не принимает значение 0 или 1 и переходит в устойчивое состояние с задержкой больше, чем $T_{co}$. Время установки определяется большим числом факторов. Классическая схема подавления метастабильности заключается в двух последовательных триггерах. Три триггера возможно понадобится для высоких частот. Больше обычно применяется для схем подавления дребезга.
|
||||
|
||||
В фифошках счётчики обычно делают не в бинарных, а в коде Грея, где меняется только один разряд.
|
||||
\end{frm}
|
||||
|
||||
Времена снятия и установления нормируются только для снятия сброса, потому что триггер может выйти из сброса и среагировать на ТИ, а может нет.
|
||||
|
||||
СХЕМА у ВИКИ
|
||||
|
||||
преимущество в скорости, сброс второго триггера мгновенный. используется для синхронизации только снятия сброса.
|
||||
|
||||
В документации по проектированию возможно найти все эти правила, но там по входам всех триггеров ТИ инвертированы. Идея в том, что не важно, какая схема, так или иначе будет осуществлён сброс, если мы снимаем по переденму фронту, то сброс происходит близко к переднему фронту, а когда синхронизируем по заднему фронту, снятие произойдёт между фронтами всех остальных триггеров. Дело в задержке распространения сигнала. Если мы работаем локально 1-3 нс, если же сигнал сброса будет заведён на общие цепи ТИ, то задержка может доходить до 5нс, поэтому на скоростях выше 100МГц это может сформировать метастабильность.
|
||||
|
||||
Поэтому инверсию ТИ для триггеров синхронизации сброса нужно ставить только если мы сбрасываем локальную группу триггеров или на малой скорости.
|
||||
|
||||
\item Timing Closure говорит о том, что если сигнал значительно разветвляется (написано 30, но фактически, 300) то его тоже следует передавать по глобальной шине.
|
||||
|
||||
\item Non-synchronous design structure
|
||||
\begin{itemize}
|
||||
\item в проекте не должно быть комбинационных обратных связей
|
||||
\item В проекте не должно быть асинхронных РС-триггеров
|
||||
\item не нужно синхронихировать триггеры по уровня
|
||||
\item не должно быть цепей задержки
|
||||
\end{itemize}
|
||||
\item signal race например, когда одним сигналом разрешается и формируется выходной сигнал.
|
||||
\item Asynchronous clock domains. определяет правила передачи данных между разными доменами ТИ. Домен ТИ - это тригеры и связанная с ними комбинационная логика, которая тактируется одним ТИ.
|
||||
двойной триггер не спасёт. есть вариант реализовать протокол обмена (фронт детектор)
|
||||
|
||||
СХЕМА 2 у ВИКИ
|
||||
|
||||
нужно формировать однобитный строб. данные не должны меняться на 3 и 4 фронте. строб и данные меняются как показано на диаграмме, и когда мы их защёлкиваем на 3 или 4 такте, они будут точно неизменные.
|
||||
\begin{lstlisting}[style=VerilogStyle]
|
||||
input logic stb;
|
||||
input logic [7:0] din;
|
||||
input logic c2;
|
||||
|
||||
logic[2:0] stb_z;
|
||||
logic ena;
|
||||
|
||||
always_ff @(posedge c2) stb_z < {stb_z[1:0], stb};
|
||||
assign ena = ~stb_z[2] & stb_z[1];
|
||||
always_ff @(posedge c2) if (ena) dreg < din;
|
||||
|
||||
\end{lstlisting}
|
||||
\end{enumerate}
|
||||
|
||||
1. расширить разрядность памяти хранения до 32 бит и на запись и на чтение, чтобы на лампочках было видно.
|
||||
2. добавить регистр (помимо ктл и дивайдер) если там 0 то пусть работает как работало, а если 1, подключается режим моргающего жёлтого с длительностью которая берётся из грин ((грин+1)-0-(грин-1)-0)
|
||||
\newpage
|
||||
\appendix
|
||||
\setcounter{secnumdepth}{2}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
\documentclass[a4paper,fontsize=14bp]{article}
|
||||
|
||||
\input{../common-preamble}
|
||||
\input{../fancy-listings-preamble}
|
||||
\input{../bmstu-preamble}
|
||||
\setcounter{secnumdepth}{4}
|
||||
\numerationTop
|
||||
|
||||
\begin{document}
|
||||
\thispagestyle{empty}
|
||||
\makeBMSTUHeader
|
||||
|
||||
\makeReportTitle{лабораторной}{1}{Моделирование компонент систем на кристалле}{Проектирование цифровых устройств на \\ программируемых логических интегральных схемах (ПЛИС)}{}{С.В. Фёдоров}
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\tableofcontents
|
||||
\newpage
|
||||
\pagestyle{fancy}
|
||||
\section{Цель}
|
||||
Изучить методики моделирования компонент систем на кристалле с интерфейсами Avalon-MM. Освоить методику интеграции компонент в системы на кристалле.
|
||||
|
||||
\section{Задачи}
|
||||
Для достижения цели было описано несколько задач, каждая со своей целью.
|
||||
\begin{enumerate}
|
||||
\item \textbf{Создание простых тестбенчей.} Цель: получение навыков реализации тестбенчей, эмулирующих транзакции в соответствии со спецификацией Avalon-MM. Моделирование обмена с разрабатываемыми модулями систем на кристалле.
|
||||
\item \textbf{Создание простой системы на кристалле и интеграция пользовательских модулей.} Цель: получение базовых навыков конфигурации системы на кристалле на основе процессора NiosII в средстве Platform Designer. Подготовка проекта системы на кристалле для использования в следующих лабораторных работах.
|
||||
\item \textbf{Моделирование систем на кристалле в ModelSim.} Цель: Подготовка созданного проекта к моделированию. Изучение методики моделирования систем на кристалле в пакете ModelSim с процессором, исполняющим программный код из внутренней памяти SRAM.
|
||||
\item \textbf{Самостоятельная работа.}
|
||||
\end{enumerate}
|
||||
\section{Выполнение работы}
|
||||
По шагам из методического материала был создан проект в САПР Quartus Prime (доступен по \href{https://git.iovchinnikov.ru/ivan-igorevich/fpga-lab-2/commits/branch/simulation}{ссылке}). В начальном проекте «поезд проезжал через семафор» задолго до инициализации (переход сигнала \code{run} в высокий уровень), поэтому цикл прохода поезда в тестбенче всего проекта (\code{niosII_tb.sv}) был изменён и представлен в листинге \hrf{lst:main-train}.
|
||||
|
||||
\begin{lstlisting}[language=Verilog,style=VerilogStyle,caption={Изменённый основной цикл тестового стенда},label={lst:main-train}]
|
||||
initial begin
|
||||
train = 0;
|
||||
wait (niosii_inst_reset_bfm_reset_reset);
|
||||
forever begin
|
||||
repeat(22528) @(posedge niosii_inst_clk_bfm_clk_clk);
|
||||
train = 1;
|
||||
repeat(10) @(posedge niosii_inst_clk_bfm_clk_clk);
|
||||
train = 0;
|
||||
end
|
||||
end
|
||||
\end{lstlisting}
|
||||
|
||||
В результате моделирования была получена диаграмма работы (waveform), представленная на рисунке \hrf{pic:modelsim-before}.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{03-fpga-lab-02-beforeindividual.png}
|
||||
\caption{Диаграмма Modelsim}
|
||||
\label{pic:modelsim-before}
|
||||
\end{figure}
|
||||
|
||||
\section{Индивидуальное задание}
|
||||
В качестве индивидуальных были даны следующие задания:
|
||||
\begin{enumerate}
|
||||
\item расширить разрядность памяти хранения до 32 бит и на запись и на чтение, чтобы изменения были видны на светодиодах.
|
||||
\item добавить регистр (помимо \code{ctl} и \code{divider}). Если там 0, то схема должна работать без изменений, а если 1, должен подключаться режим мигающего жёлтого с длительностью, которая берётся из памяти (параметр зелёного цвета), то есть мигать циклически со следующей периодичностью:
|
||||
|
||||
\begin{tikztimingtable}
|
||||
length & 5D{green} 5D{green} 5D{green} 5D{green} 5D{green} 5D{green}\\
|
||||
yellow & 5L 5H 5L 5H 5L 5H \\
|
||||
\end{tikztimingtable}
|
||||
\end{enumerate}
|
||||
\section{Выводы}
|
||||
|
||||
\newpage
|
||||
\appendix
|
||||
\setcounter{secnumdepth}{4}
|
||||
\section{Приложения}
|
||||
\renewcommand{\thesubsection}{\Asbuk{subsection}}
|
||||
|
||||
\subsection{Исходные коды проекта}
|
||||
\label{appendix:src}
|
||||
|
||||
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
|
@ -457,7 +457,7 @@ N=30, R=50, L=125*8, $T_s$=1мин $P_x \leq 1\%$
|
|||
\end{itemize}
|
||||
|
||||
\subsection{В сетях без иерархии}
|
||||
Destination Sequence Distance Vector. Протокол построен на основе Беллмана-Форда - поиск кратчайших путей. Каждый узел содержит таблицу переходов к ближайшим узлам.
|
||||
\textbf{Destination Sequence Distance Vector}. Протокол построен на основе Беллмана-Форда - поиск кратчайших путей. Каждый узел содержит таблицу переходов к ближайшим узлам.
|
||||
например, сеть A-B-C-D
|
||||
|
||||
\begin{tabular}{|c|c|c|c|}
|
||||
|
|
@ -473,6 +473,36 @@ Destination Sequence Distance Vector. Протокол построен на о
|
|||
|
||||
Чем больше номер - тем свежее маршрут. В данном случае метрика - это скорость (количество переходов). Узлы должны оценивать надёжность соединения. Преимущество в том, что мы всегда знаем кому передать пакет (актуальный маршрут). Минус в том, что для того, чтобы информацию о маршруте собрать нужно потратить $n^2$ сообщений, где n - это число устройств. Подходит для маленьких сетей.
|
||||
|
||||
Вычисление всех маршрутов заранее - это проактивный подход. Есть подход реактивный - вычисление маршрута по факту запроса.
|
||||
|
||||
\textbf{AODV - AdHoc On-demand Distance Vector Routing.}
|
||||
|
||||
Когда отправителю нужно отправить данные, он формирует пакет Route Request и все устройства в его радиусе его получают. В запросе есть служебная информация, исключающая дублирование итд. Далее узел Д передаёт через конкретные узлы (кратчайший маршрут) ответный Route Response. До появления запросов никакие таблицы маршрутизации не строятся. Эффективность протокола зависит от числа узлов назначения. Протокол изначально разрабатывался для эпизодических сетей. Не подходит для больших сетей с устройствами на батарейном питании.
|
||||
|
||||
\subsection{Маршрутизация в сетях с иерархией}
|
||||
Выделяем некоторые устройства, которые становятся управляющими
|
||||
\textbf{LEACH - low energy adaptive clustering hierarchy}. Разделяем сеть на кластеры и выбираем головной узел кластера, подчинённые узлы передают пакеты своему головному узлу, который передаёт данные на шлюз. Сеть формируется в несколько этапов:
|
||||
\begin{itemize}
|
||||
\item выбираем головной узел (5\% узлов должны стать головными, выбирают узлы самостоятельно)
|
||||
\item выбираем кластеры
|
||||
\item остальные узлы принимают решение, к какому кластеру они относятся
|
||||
\item режим работы - каждый головной узел формирует расписание TDMA.
|
||||
\item головные узлы между собой тоже разделяют канал по CDMA.
|
||||
\item перевыбор головных узлов для усреднения расхода ресурсов.
|
||||
\end{itemize}
|
||||
Основной минус в предположении, что головные узлы всегда могут передать данные базовой станции, и что головные узлы распределятся примерно равномерно.
|
||||
|
||||
Если часто меняется сеть, иерархия работает плохо поскольку нужно переназначать адреса узлам, а это жнергозатратно (меньшая устойчивость к изменению топологии). Идея в том, что мы экономим на трафике за счёт того что мы выделяем маршрут по головным устройствам.
|
||||
|
||||
\subsection{Геометрическая маршрутизация}
|
||||
Распределённая сеть, где каждое устройство знает свои координаты и координаты своих соседей. Чтобы передать пакет, узел отправитель должен знать кооржинаты конечного узла получателя. Вычисляем расстояния до ближайших соседей.
|
||||
|
||||
\[d = \sqrt{(x_s-x_d)^2+{y_s-y_d}^2}\]
|
||||
|
||||
Таким образом мы понимаем, что нужно передавать узлу, который находится физически ближе к получателю. Решение очень масштабируемое из-за того что у нас почти нет служебного трафика и минимальное хранение.
|
||||
|
||||
Возникают проблемы аппаратурного характера и локальных минимумов (когда заходим в тупик). Проблема локального минимума может решаться поиском в глубину или ширину. Мы должны понимать как узнавать адрес узла назначения (неотъемлемая чать это некоторое хранилище координат в виде хэш-таблиц). Поиск по кратчайшему пути не всегда оптимальный путь. Поэтому часто используются не физические, а логические координаты более достоверно отражающие качество связи между устройствами.
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@
|
|||
\input{../common-preamble}
|
||||
\input{../bmstu-preamble}
|
||||
\input{../fancy-listings-preamble}
|
||||
\usepackage{icomma}
|
||||
|
||||
\numerationTop
|
||||
|
||||
|
|
@ -92,7 +91,7 @@
|
|||
|
||||
Для выполнения имитационного моделирования необходимо задать диапазон изменения среднего периода передачи пакетов ($T_s$) таким образом, чтобы полный нормированный трафик $G$ был в диапазоне $[0,05; 1]$
|
||||
|
||||
Поскольку $G=\frac{N_{TX}}{T_s}*\tau$, где $\tau=\frac{8*L_{phy}}{R}$, а $L_{phy} = L_{app} + 63$, то $T_s= \frac{N_{TX}\tau}{G}$. Для $G = 0,05; T_s \approx 361,6$, а для $G = 1; T_s \approx 18,08$ мсек.
|
||||
Поскольку $G=\frac{N_{TX}}{T_s}*\tau$, где $\tau=\frac{8*L_{phy}}{R}$, а $L_{phy} = L_{app} + 63$, то $T_s= \frac{N_{TX}\tau}{G}$. Для $G = 0,05; T_s \approx 361,6$ мсек, а для $G = 1; T_s \approx 18,08$ мсек. Для моделирования был выбран диапазон $T_s = [10; 400]$ мсек с шагом 20.
|
||||
|
||||
|
||||
\section{Выводы}
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
Loading…
Reference in New Issue