This document provides specifications for a System on Chip (SoC) design containing a Memory Interface Block (MIB) and a Universal Asynchronous Receiver and Transmitter (UART) interface. It includes block diagrams, I/O descriptions, state machines, and verification simulations for the top level design and all internal blocks. The top level interacts with a provided TramelBlaze microcontroller core and contains the MIB and UART blocks. The MIB allows the TramelBlaze to interface with an off-chip memory. The UART block contains independently designed transmit and receive engines that have been verified to successfully transmit and receive serial data to and from a terminal via the UART interface. Revision 4.0
Traditional vs. SoC FPGA Design Flow A Video Pipeline Case StudyAltera Corporation
This presentation compares the impact of traditional FPGA engineering design flow to one employed with an SoC FPGA. The two approaches will be contrasted in terms of their impacts on system architecture design, debugging, risk mitigation, system integration, bring-up, feature enhancements, design obsolescence, and engineering effort. A case study is presented that explores these impacts within a video pipeline development effort.
Lectio Divina Dominical III de Cuaresma Ciclo ACristonautas
TEXTO BIBLICO: Juan 4, 5-42
«El agua que yo daré brotará en él como un manantial de vida eterna»
Para descargar: www.fundacionpane.com y/o www.cristonautas.com
Ensuring Distributed Accountability in the CloudSuraj Mehta
Ensuring distributed accountability for data sharing in the cloud is in short nothing
but a novel highly decentralized information accountability framework to keep track
of the actual usage of the users' data in the cloud. Cloud computing enables highly
ecient services that are easily consumed over the internet.
Traditional vs. SoC FPGA Design Flow A Video Pipeline Case StudyAltera Corporation
This presentation compares the impact of traditional FPGA engineering design flow to one employed with an SoC FPGA. The two approaches will be contrasted in terms of their impacts on system architecture design, debugging, risk mitigation, system integration, bring-up, feature enhancements, design obsolescence, and engineering effort. A case study is presented that explores these impacts within a video pipeline development effort.
Lectio Divina Dominical III de Cuaresma Ciclo ACristonautas
TEXTO BIBLICO: Juan 4, 5-42
«El agua que yo daré brotará en él como un manantial de vida eterna»
Para descargar: www.fundacionpane.com y/o www.cristonautas.com
Ensuring Distributed Accountability in the CloudSuraj Mehta
Ensuring distributed accountability for data sharing in the cloud is in short nothing
but a novel highly decentralized information accountability framework to keep track
of the actual usage of the users' data in the cloud. Cloud computing enables highly
ecient services that are easily consumed over the internet.
A Mobile and Web application for time measurement intended to get an accurate picture of the productive time in a production environment in order to reveal the root causes behind ineffective/idle time and to eliminate non-added activities/tasks .
Technical Key-words : Ionic 2, Angular 2, PouchDB, CouchDB ,
DB Replication Protocol, Django, Python NvD3 charts .
1. CSULB
COLLEGE OF ENGINEERING
Department of Computer Engineering and Computer Science
FINAL Project
Final System on Chip Specification
MIB, UART, & TramelBlaze
CECS 460: System on Chip Design
Submitted by:
Phuong Nguyen
(013132325)
on December 16, 2016
Submitted to:
Mr. John Tramel
CECS Faculty
2. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 2
This document contains information proprietary to the
CSULB student that created the file - any reuse without
adequate approval and documentation is prohibited.
In submitting this file for class work at CSULB
I am confirming that this is my work and the work
of no one else.
In the event, other code sources are utilized I will
document which portion of code and who is the author.
In submitting this project, I acknowledge that plagiarism
in student project work is subject to dismissal from the class.
10. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 10
1. Introduction
This Chip Specification document is intended to describe every detail of the Memory
Interface Block (MIB) and Full Universal Asynchronous Receiver and Transmitter (UART)
Interface implemented by the preparer. In Revision 2.0, the Transmit Engine was interfaced to
the TramelBlaze, which was provided by Mr. John Tramel. Revision 3.0 built on top of the
Transmit Engine with the implementation of the Receive Engine. The two engines instantiated
together created the Full UART, which proved capable of receiving and transmitting data from/to
a Serial Terminal. In this final revision, a Memory Interface Block was implemented to grant the
TramelBlaze the ability to access the on-board Micron memory of the Nexys 4.
1.1. Purpose
The purpose of this document is to describe the details of the MIB and Full UART. First,
this document will elaborate on the chip‟s top level specifications with block diagrams, dataflow
descriptions, and details on the system‟s I/O ports. Secondly, this document will elaborate on the
details of each externally and internally developed block. The details will include their purposes,
Block Diagrams, I/O, State Machines (if necessary) and Register Map. With each internally
developed block, verification will be provided through the use of ISim‟s simulations. Lastly the
document provides a Chip Level Verification and Chip Level Test to prove the competence of
the MIB and the Full UART by exercising their functionalities.
11. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 11
2. External Documents
These documents were used in the development of the design. They were used to assist in
understanding the TramelBlaze and its interfaces but also assisted in creating the actual interface
and the Programmable Read-Only Memory (PROM) of the system.
2.1. PicoBlaze
The PicoBlaze is a cost-effective fully embedded 8-bit RISC microcontroller that
provided the basis of how the TramelBlaze was developed. Because of the identical instruction
set and architecture of the two microcontrollers, the PicoBlaze‟s user‟s guide proved helpful in
understanding and developing the ROM of the TramelBlaze.
2.1.1. Architecture
Figure 1: PicoBlaze/TramelBlaze Architecture
Understanding the connections between different components of the TramelBlaze
provided a vast amount of information on how the data flows. Especially with the development
of Read-Only Memory (ROM), having a schematic to detail the pathway of data provided
tremendous insight on how to properly develop the ROM.
12. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 12
2.1.2. Instruction Set
Program Control
JUMP aaa
JUMP Z, aaa
JUMP C, aaa
JUMP NC, aaa
CALL aaa
CALL Z, aaa
CALL C, aaa
CALL NC, aaa
RETURN
RETURN Z
RETURN NZ
RETURN C
RETURN NC
Arithmetic
ADD sX, kk | (sX, sY)
ADDCY sX, kk | (sX, sY)
SUB sX, kk | (sX, sY)
SUBCY sX, kk | (sX, sY)
COMPARE sX, kk | (sX,
sY)
Logical
LOAD sX, kk | (sX, sY)
AND sX, kk | (sX, sY)
OR sX, kk | (sX, sY)
XOR sX, kk | (sX, sY)
TEST sX, kk | (sX, sY)
Shift and Rotate
SR0 sX
SR1 sX
SRX sX
SRA sX
RR sX
SL0 sX
SL1 sX
SLX sX
SLA sX
RL sX
Interrupt
RETURNI ENABLE
RETURNI DISABLE
ENABLE INTERRUPT
DISABLE INTERRUPT
Storage
STORE sX, ss | (sX,
(sY))
FETCH sX, ss | (sX,
(sY))
Input/output
INPUT sX, pp | (sX, sY)
OUTPUT sX, pp | (sX, sY)
Table 1: PicoBlaze Instruction Set
Table 1 list out every instruction available to use for the PicoBlaze; in general, the
TramelBlaze utilizes the same instruction set, so ROM development will be similar to that of the
PicoBlaze.
Figure 2: Input and Output Timing Diagram
Figure 2 shows the timing diagrams behind the INPUT and OUTPUT instructions. These
are instructions are crucial in making the UART work properly as the UART utilizes these two
instructions to communicate with the TramelBlaze.
13. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 13
Instruction Description Function Zero Carry
ADD sX, kk Add sX with literal kk sX ← sX + kk ? ?
CALL aaa Unconditionally call subroutine at aaa TOS ← PC
PC ← aaa
- -
COMP sX, kk Compare sX with literal kk, Set CARRY and
ZERO flags as appropriate.
If sX=kk, ZERO ← 1
If sX<kk, CARRY ← 1
? ?
ENINT Enable interrupt input INTERRUPT_ENABLE ← 1 - -
FETCH sX, ss Read scratchpad RAM location ss into
register sX
sX ← RAM[ss] - -
INPUT sX, pp Read value on input port location pp into
register sX
PORT_ID ← pp
sX ← IN_PORT
- -
JUMP aaa Unconditionally jump to aaa PC ← aaa - -
JUMPZ aaa If ZERO flag set, jump to aaa If ZERO=1, PC ← aaa - -
LOAD sX, kk Load register sX with literal kk sX ← kk - -
OUTPUT sX, pp Write register sX to output port location
pp
PORT_ID ← pp
OUT_PORT ← sX
- -
RETEN Return from interrupt service routine. PC ← TOS
ZERO ← Preserved ZERO
CARRY ← Preserved CARRY
INTERRUPT_ENABLE ← 1
? ?
RETURN Unconditionally return from subroutine PC ← TOS+1 - -
STORE sX, (sY) Write register sX to scratchpad RAM
location pointed to by register sY
RAM[(sY)] ← sX - -
Table 2: Instructions used by Design
In the development of this design, many of the TramelBlaze‟s instructions were used to
create the ROM. Table 2 goes into detail with every instruction used in the development of the
UART.
14. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 14
2.2. Nexys 4 Data Sheet
The datasheet provided all the essential information on the hardware of the Nexys 4. This
consisted of the 100MHz Crystal Oscillator, UART connections, basic I/O connections and
interface information for the Micron Memory.
2.2.1. UART Connection
Figure 3: Nexys 4 UART Interface
The figure above was taken directly from the Data Sheet and showed the connections
between the Micro-USB and the Nexys 4 board. Though the diagram shows a FT2232 driver
between the Nexys 4 Chip and USB, it was unnecessary in this application as JTAG was not
being utilized. Hence, the diagram showed that port C4 is used to received data from the Micro-
USB and D4 is used to transmit data to the Micro-USB.
15. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 15
2.2.2. Basic I/O connection
Figure 4: Nexys 4 I/O Interface
This figure shows the connection of the LEDs, switches, and buttons and their interfaces.
It provided information on the voltages required to provide a logic 1 or logic 0 on both the
switches and buttons.
16. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 16
2.2.3. Cellular RAM Interface
Figure 5: Nexys 4 Cellular RAM Interface
This figure provides information on how to connect the required signals to the Cellular
RAM. Along with this figure, a table was also provided to show the ports for both the address
bus and data bus. This was essential in the instantiation between the project and the 8Mbyte
RAM.
2.3. ASCII Table
Figure 6: ASCII Table
An ASCII Table assisted in developing every interface. It provided a quick and easy way
to translate the given ASCII values into understandable character.
17. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 17
2.4. Spartan-6 Libraries Guide for HDL Designs
The Spartan-6 Libraries Guide provided essential information to complete the design for
the MIB and TSI. Particularly, this document provided details on the IBUFG, IBUF, OBUF,
IOBUF, include the Instantiation Templates and Logic Tables. This provided the foundation in
completing the TSI.
Buffer Description
IBUFG is used to connect incoming clocks to
the Core. This can only be driven by the global
clock pin; in the case of the Nexys 4, would be
pin E3.
IBUF is a simple buffer used to connect any
input from the top level to the design‟s core.
OBUF is a simple buffer used to drive output
signals to the FPGA from the core.
IOBUF allows the design to utilize
bidirectional pins on the FPGA board. T
controls the direction of the data flow as seen
in the truth table below.
T I IO O
1 X Z IO
0 1 1 1
0 0 0 0
Table 3: Buffers used in TSI
18. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 18
2.5. Micron MT458MW16BGX Data Sheet
The Nexys 4 utilizes a cellular RAM from Micron called the MT458MW16BGX. The
data sheet provided information on how to access the memory through signals. The signals
allowed the Nexys to read and write to memory based on the times provided by this data sheet.
Provided in Figure 7, are the timing diagrams for both the read and write. The datasheet also
provides the timing of each of the signals labeled by the figure.
Figure 7: Timing Diagrams for Reading and Writing
19. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 19
3. Requirements
3.1. Interface Requirements
This design must be able to utilize three main components, the TramelBlaze, the UART,
and the MIB. These components must be instantiated together to create the core. And any signals
from the core must interact with a Technology Specific Instantiation (TSI) before it interacts
with the FPGA. The core must utilize the MIB by taking in characters from the Receive Engine
of the UART, and storing them into the on-board Micron Memory. Once an asterisk is received
by the design, the Tramelblaze must take whatever was stored into the Micron memory and
output all the characters onto the Serial Terminal via Transmit Engine. Along with the outputting
of the memory data, a banner must be implemented to interface the Serial Terminal.
The Requirements from previous revisions must be implemented as well. The on-board
switches must be able to control the Baud Rate and the options for the UART parity.
Baud Switches Baud Rate Bit Time Nexys 4 Count
0000 300 0.003333333 333333
0001 1200 0.000833333 83333
0010 2400 0.000416667 41667
0011 4800 0.000208333 20833
0100 9600 0.000104167 10417
0101 19200 5.20833E-05 5208
0110 38400 2.60417E-05 2604
0111 57600 1.73611E-05 1736
1000 115200 8.68056E-06 868
1001 230400 4.34028E-06 434
1010 460800 2.17014E-06 217
1011 921600 1.08507E-06 109
Table 4: Baud Rate Truth Table
The logic table below describes the operations of each switch. The MSB will control
whether the transmit engine will send 7 bits or 8 bits. The second bit will enable or disable the
parity bit. And the LSB will control whether the parity will be even or odd.
Bits and Parity Switches Bits Sent Parity Options
000 7 Disabled
001 7 Disabled
010 7 Enabled/Even
011 7 Enabled/Odd
100 8 Disabled
101 8 Disabled
110 8 Enabled/Even
111 8 Enabled/Odd
Table 5: Parity Truth Table
20. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 20
3.2. Physical Requirements
SW7 SW6 SW5 SW4 SW3 SW2 SW1 SW0
N/A 8bits/7bits Parity En oHeL Baud 3 Baud 2 Baud 1 Baud 0
Table 6: Design Switch Interface
The table above shows the interface of the first byte of switches provided by the Nexys 4.
The values in every port change the UART‟s configurations.
BTNU BTND BTNC BTNL BTNR
N/A N/A Global Reset N/A N/A
Table 7: Design Button Interface
Only one of the buttons will be utilized and it will be used to reset the system entirely.
Because it is a reset, it does not require a debounce as crucial data is not being passed through
once it is pressed.
LD4 LD3 LD2 LD1 LD0
Overflow Framing Error Parity Error Transmit Ready Receive Ready
Table 8: Design LED Interface
In addition to the switches and buttons implemented in Transmit Engine, Revision 3.0
requires LEDs to turn on if the given line is asserted.
Overflow: Occurs when the Receive Engine is done receiving all the necessary bits but
Receive Ready is still asserted.
Framing Error: Occurs when the Receive Engine is done receiving the expected number
of bits but the last bit is not asserted.
Parity Error: Occurs when the generated parity and received parity do not match.
Transmit Ready: This is asserted when the Transmit Engine is done transmitting its
data.
Receive Ready: This is asserted when the Receive Engine has received the expected
number of bits based on Parity Options.
21. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 21
4. Top Level Design
4.1. Description
The Top Level is responsible for connection two things, the Core and the TSI. The Core
consists of the design itself, while the TSI contains all references to the target technology
libraries. Any communication from the core‟s I/O‟s must pass through the TSI before interacting
with the FPGA.
Figure 8: Design Top Module
23. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 23
4.4. Data Flow Description
The previous revisions of this design have verified the functionalities of both the
Transmit Engine and Receive Engine of the UART. The Transmit Engine was verified when the
statement “CSULB CECS 460 <CR><LF>” was consistently printed onto a Serial Terminal.
Next the Receive Engine was verified when it was able to take in a user inputted character and
transmit directly to the terminal. Typically known as an echo, the design was also able to detect
parity errors, framing errors, and overflow errors in case the transmission of data from one
machine to the next was not correct. Additionally, the TramelBlaze was able to service the
correct engine based on the Port ID‟s.
In this revision, a MIB was created to give the TramelBlaze access to the on-board
Micron Memory. Alongside with the Full UART, the TramelBlaze should be able to take in data
from the Serial Terminal and write those characters into a location in memory. Once an asterisk
is received by the Receive Engine, the data in the memory will then be read by the TramelBlaze
and outputted to the Serial Terminal.
4.5. I/O
4.5.1. Signal Names
Signal From To Description
c_clk TSI Core 100MHz Crystal Oscillator
c_reset TSI Core System Reset
c_switches TSI Core Baud Rate and Parity Options
c_Tx Core TSI Transmit Line out to USB
c_Rx TSI Core Receive Line in from USB
c_mem_addr Core TSI Points to a location in Micron Memory
c_status Core TSI Detects data errors, and Engine readiness
c_CE Core TSI Chip Enable for Micron Memory
c_WE Core TSI Write Enable for Micron Memory
c_OE Core TSI Output Enable for Micron Memory
c_ADV Core TSI Address Valid
c_CRE Core TSI Control Register Enable
c_UB Core TSI Upper 6 bits of Micron Memory Address
c_LB Core TSI Lower 16 bits of Micron Memory Address
c_mem_clk TSI Core Cell Ram Clock
MIB_I Core TSI Data from MIB to Micron Memory
MIB_O TSI Core Data from Micron Memory to MIB
T Core TSI IOBUF Selector
Table 9: Top Level Signal Names
24. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 24
4.5.2. Pin Assignment
Input Signals Assignment Output Signals Assignment
clk_in E3 Tx_Out D4
reset E16 ADV_n T13
Rx_In C4 CE_n L18
Parity_ops [2] V6 LB_n J15
Parity_ops [1] V7 UB_n J13
Parity_ops [0] R5 OE_n H14
Baud_Selector [3] R6 WE_n R11
Baud_Selector [2] R7 CRE J14
Baud_Selector [1] U8 mem_clk T15
Baud_Selector [0] U9 Status [7] U6
Status [6] U7
Status [5] T4
Status [4] T5
Status [3] T6
Status [2] R8
Status [1] V9
Status [0] T8
Table 10: Top Level Pin Assignments
Address Bus Data Bus
m_address[22]: U13 m_address[13]: U16 m_address[4]: H16 MIB_IO[1]: P17 MIB_IO[6]: T18
m_address[21]: M16 m_address[12]: P14 m_address[3]: J17 MIB_IO[1]: N17 MIB_IO[5]: R17
m_address[20]: T10 m_address[11]: V12 m_address[2]: H15 MIB_IO[1]: P18 MIB_IO[4]: U18
m_address[19]: U17 m_address[10]: V14 m_address[1]: H17 MIB_IO[1]: M17 MIB_IO[3]: R13
m_address[18]: V17 m_address[9]: U14 m_address[0]: J18 MIB_IO[1]: M18 MIB_IO[2]: U12
m_address[17]: M13 m_address[8]: V16 MIB_IO[1]: G17 MIB_IO[1]: T11
m_address[16]: N16 m_address[7]: N15 MIB_IO[9]: G18 MIB_IO[0]: R12
m_address[15]: N14 m_address[6]: K13 MIB_IO[8]: F18
m_address[14]: R15 m_address[5]: K15 MIB_IO[7]: R18
Table 11: Memory Address and Bidirectional Data Ports
4.5.3. Electrical Characteristics
Switches
o 1.8V are considered Logical 1
o 0V are considered Logical 0
Buttons
o 3.3V are considered Logical 1
o 0V are considered Logical 0
25. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 25
4.6. Clocks
The Nexys 4 is powered by a 100MHz crystal oscillator which is connected to pin E3.
Every single flop in the project will utilize this clock.
4.7. Resets
The project will utilize a HIGH active reset, this HIGH active reset will be fed into an
Asynchronous In, Synchronous Out (AISO) module that ensure that every flop will be reset
synchronously.
26. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 26
4.8. Software
;Programmers: Tony Le and Phuong Nguyen
;Last Updated: December 9, 2016
;Description: .tba file for interacting with memory
; Will receive an input and output the same value
; As well as saving the data to memory
;PORT_ID Function Reference
;0000 R/W data
;0001 Read status bits
;0011 Write to Address Register 0
;0012 Write to Address Register 1
;0013 Write to Data Out Register
;0014 Read Data In Register
;0015 Perform Memory Read
;0016 Perform Memory Write
ZEROS EQU 0000
ONE EQU 0001
FLAG_BITS EQU 0003
BOTH_FLAGS EQU 0003
RX_FLAG EQU 0001
TX_FLAG EQU 0002
ASTERICK EQU 002A
BACKSPACE EQU 0008
SPACE EQU 0020
CR EQU 000D
LF EQU 000A
C EQU 0043
E EQU 0045
H EQU 0048
I EQU 0049
L EQU 004C
O EQU 004F
W EQU 0057
;REGISTERS
BAN_FLAG EQU R0
ADDR_CHECK EQU R0
STATUS EQU R1
DATA EQU R2
FLAG EQU R4
ADDR_7UB EQU R5
ADDR_16LB EQU R6
COUNTER_UB EQU R7
COUNTER_LB EQU R8
PROM_FLAG EQU R9
SCRATCH EQU RA
DEL_FLAG EQU RB
MEM_DATA EQU RC
BAN_DATA EQU RC
NEWLINE EQU RD
NL_FLAG EQU RE
BANNER EQU RF
27. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 27
START LOAD R0, ONE ;INITIALIZE VALUES
LOAD DATA, ZEROS
LOAD FLAG, ZEROS
LOAD ADDR_7UB, ZEROS
LOAD ADDR_16LB, ZEROS
LOAD COUNTER_UB, ZEROS
LOAD COUNTER_LB, ZEROS
LOAD SCRATCH, BACKSPACE ;store values for delete
STORE SCRATCH, 0000
LOAD SCRATCH, SPACE
STORE SCRATCH, 0001
LOAD SCRATCH, BACKSPACE
STORE RA, 0002
LOAD SCRATCH, ZEROS
;Load Backspace characters into scratch
LOAD NEWLINE, CR
STORE NEWLINE, 0010
LOAD NEWLINE, LF
STORE NEWLINE, 0011
LOAD NEWLINE, 0010
;Load 'I WILL ECHO' into scratch
LOAD BANNER, I
STORE BANNER, 0020
LOAD BANNER, SPACE
STORE BANNER, 0021
LOAD BANNER, W
STORE BANNER, 0022
LOAD BANNER, I
STORE BANNER, 0023
LOAD BANNER, L
STORE BANNER, 0024
LOAD BANNER, L
STORE BANNER, 0025
LOAD BANNER, SPACE
STORE BANNER, 0026
LOAD BANNER, E
STORE BANNER, 0027
LOAD BANNER, C
STORE BANNER, 0028
LOAD BANNER, H
STORE BANNER, 0029
LOAD BANNER, O
STORE BANNER, 002A
LOAD BANNER, CR
STORE BANNER, 002B
LOAD BANNER, LF
STORE BANNER, 002C
LOAD BANNER, 0020
LOAD FLAG, ONE
ENINT
28. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 28
MAIN ADD R0, ZEROS ;MAIN LOOP
JUMP MAIN
ADDRESS 0300
ISR INPUT STATUS, 0001 ;Input Status Flags
AND STATUS, FLAG_BITS ;Mask Status
COMP STATUS, BOTH_FLAGS ;If Both are HIGH -- Jump
JUMPZ BOTH
COMP STATUS, RX_FLAG ;If Rx Flag is HIGH -- Jump
JUMPZ RX
COMP STATUS, TX_FLAG ;If Tx Flag is HIGH -- Jump
JUMPZ TX
RETEN
BOTH COMP DEL_FLAG, ONE
JUMPZ DEL ;If Delete Flag is HIGH -- Jump
COMP NL_FLAG, ONE
JUMPZ NLCHECK ;If New Line Flag is HIGH -- Jump
COMP PROM_FLAG, ONE
JUMPZ CHECK_Z ;If Prompt Flag is HIGH -- Jump
INPUT DATA, 0000
COMP DATA, 007F
JUMPNZ PROM_COMP ;If DATA is NOT Backspace -- Jump
LOAD DEL_FLAG, ONE ;Assert DEL_FLAG
COMP ADDR_16LB, ZEROS
JUMPNZ DEC_MEM ;If Lower Addr is NOT 0000 -- Jump
COMP ADDR_7UB, ZEROS
JUMPZ DEL ;If Upper Address is 0000 -- Jump
SUB ADDR_7UB, ONE ;Else Decrement Upper Address
DEC_MEM SUB ADDR_16LB, ONE ;Decrement Lower Address
JUMP DEL ;Unconditional Jump to DEL
PROM_COMP COMP DATA, ASTERICK
JUMPNZ ECHO ;If NOT "*" input -- Jump
LOAD PROM_FLAG, ONE ;Else Set Prompt Flag
LOAD NL_FLAG, ONE ; and New Line Flag
JUMP NLCHECK ;Unconditional Jump to NLCHECK
ECHO OUTPUT ADDR_7UB, 0011 ;Output Upper Address to MICRON
OUTPUT ADDR_16LB, 0012 ;Output Lower Address to MICRON
OUTPUT DATA, 0013 ;Write Data Out Register
OUTPUT DATA, 0016 ;Perform Memory Write
OUTPUT DATA, 0000 ;Output Received Data to S/T
LOAD FLAG, ZEROS ;Clear FLAG
COMP ADDR_16LB, FFFF
JUMPNZ DONT_IUB ;If Lower Addr is NOT FFFF -- Jump
ADD ADDR_7UB, ONE ;Else increment Upper Address
DONT_IUB ADD ADDR_16LB, ONE ;Increment Lower Adddress
RETEN
RX INPUT DATA, 0000 ;Input Data
COMP DATA, 007F
JUMPNZ CONT ;If DATA is NOT 007F -- Jump
29. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 29
LOAD DEL_FLAG, ONE ;Assert DEL_FLAG
COMP ADDR_16LB, ZEROS
JUMPNZ DEC_MEM2 ;If Lower Address -- Jump
COMP ADDR_7UB, ZEROS
JUMPZ DEL ;If Upper Address -- Jump
SUB ADDR_7UB, ONE ;Else Decrement Upper Address
DEC_MEM2 SUB ADDR_16LB, ONE ;Decrement Lower Address
CONT COMP DATA, ASTERICK
JUMPNZ CONT2 ;If NOT "*" -- Jump
LOAD PROM_FLAG, ONE ;Assert PROMPT FLAG
CONT2 LOAD FLAG, ONE ;Assert FLAG
OUTPUT ADDR_7UB, 0011 ;Output Upper Address
OUTPUT ADDR_16LB, 0012 ;Output Lower Address
OUTPUT DATA, 0013 ;Write to Data Register
OUTPUT DATA, 0016 ;Perform Memory Write
COMP ADDR_16LB, FFFF
JUMPNZ DONT_IUB2 ;If Upper Addr is NOT FFFF -- Jump
ADD ADDR_7UB, ONE ;Else Increment Upper Address
DONT_IUB2 ADD ADDR_16LB, ONE ;Increment Lower Address
JUMP RETURN ;Unconditional Jump to RETURN
TX COMP BAN_FLAG, ONE
JUMPZ BAN_OUT ;If Banner Flag -- Jump
COMP DEL_FLAG, ONE
JUMPZ DEL ;If DEL Flag -- Jump
COMP NL_FLAG, ONE
JUMPZ NLCHECK ;If New Line Flag -- Jump
COMP PROM_FLAG, ONE
JUMPZ CHECK_Z ;If Prompt Flag -- Jump
COMP FLAG, ZEROS
JUMPZ RETURN ;If FLAG is 0000 -- Jump
OUTPUT DATA, 0000 ;Else Output DATA
LOAD FLAG, ZEROS ;Clear FLAG
JUMP RETURN
BAN_OUT FETCH BAN_DATA, BANNER ;Fetch Banner ASCII Values
OUTPUT BAN_DATA, 0000 ;Output to S/T
ADD BANNER, ONE ;Increment Banner Address
COMP BANNER, 002D
JUMPNZ RETURN ;If Banner Address is 002D -- Jump
LOAD BAN_FLAG, ZEROS ;Clear Banner FLAG
RETEN
DEL FETCH DATA, SCRATCH ;Fetch DATA ASCII Values
OUTPUT DATA, 0000 ;Output DATA to S/T
ADD SCRATCH, ONE ;Increment SCRATCH Address
COMP SCRATCH, 0003
JUMPNZ RETURN ;If Scratch is 0003 -- Jump
LOAD SCRATCH, ZEROS ;Reload Scratch with 0000
LOAD DEL_FLAG, ZEROS ;Clear DEL_FLAG FLAG
RETEN
30. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 30
NLCHECK COMP NL_FLAG, ONE
JUMPNZ CHECK_Z ;If NOT New Line Flag -- Jump
FETCH DATA, NEWLINE ;Fetch NEWLINE Values
OUTPUT DATA, 0000 ;Output Values to S/T
ADD NEWLINE, ONE ;Increment NEWLINE Address
COMP NEWLINE, 0012
JUMPZ NL_RESET ;If NEWLINE is 0012 -- Jump
RETEN
CHECK_Z COMP ADDR_7UB, 0000
JUMPNZ PROMPT ;If COUNTER_UB is NOT 0000 -- Jump
COMP ADDR_16LB, 0000
JUMPNZ PROMPT ;If COUNTER_LB is NOT 0000 -- Jump
LOAD PROM_FLAG, ZEROS
RETEN
PROMPT COMP PROM_FLAG, ONE
JUMPNZ RETURN ;If Prompt Flag is NOT HIGH -- Jump
OUTPUT COUNTER_UB, 0011 ;Output Upper to MICRON
OUTPUT COUNTER_LB, 0012 ;Output Lower to MICRON
INPUT MEM_DATA, 0015 ;Perform Memory Read
SCHECK INPUT STATUS, 0001 ;Check Status
AND STATUS, 0002 ;Mask Tx Ready
COMP STATUS, 0002
JUMPNZ SCHECK ;If Tx Rdy is NOT HIGH -- Jump
INPUT MEM_DATA, 0014 ;Else input data
OUTPUT MEM_DATA, 0000 ;Output Data to S/T
INC_MEM COMP COUNTER_LB, FFFF
JUMPNZ DONT_ICUB ;If Lower is not full -- Jump
ADD COUNTER_UB, ONE ;Else Increment Upper
DONT_ICUB ADD COUNTER_LB, ONE ;Increment Lower
COMP COUNTER_UB, ADDR_7UB
JUMPNZ RETURN ;If addr, count NOT equal -- Jump
COMP COUNTER_LB, ADDR_16LB
JUMPNZ RETURN ;If addr, count NOT equal -- Jump
LOAD ADDR_7UB, ZEROS ;Clear Addresses and Counters
LOAD ADDR_16LB, ZEROS
LOAD COUNTER_UB, ZEROS
LOAD COUNTER_LB, ZEROS
LOAD PROM_FLAG, ZEROS
LOAD NL_FLAG, ONE ;Set New Line Flag
RETEN
NL_RESET LOAD NEWLINE, 0010 ;Load Flag
LOAD NL_FLAG, ZEROS ;Clear Flag
RETEN
RETURN RETEN
ADDRESS 0FFE
JUMP ISR
END
31. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 31
5. Externally Developed Blocks
5.1. Asynchronous In, Synchronous Out (AISO)
Description
This block ensures the reset to every
block‟s reset is synchronous to each other
hence the name. The reset of this block is
directly connected to a button (BTNC), which
when asserted will synchronously reset every
module.
I/O
Signal I/O Connected to
clk_in Input 100MHz Crystal Oscillator
reset Input BTNC
sync Output Every Block‟s Reset
Table 12: AISO I/O
Register Map
Register Usage Description
flop [1:0] Synchronize Upon reset, sends a single pulse to all modules
Table 13: AISO Register Map
Source Code: Appendix A17
Figure 10: AISO Block Diagram
32. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 32
5.2. TramelBlaze
Description
The TramelBlaze is a 16-bit soft-
core microcontroller that emulates the
PicoBlaze. The TramelBlaze provides the
instantiation for a ROM, which it will read
from and perform actions based on the
instructions provided by the ROM. In this
application, the TramelBlaze utilize every
port in order to receive ASCII values and
to transmit ASCII values to a Serial
Terminal. The READ_STROBE and
WRITE_STROBE will be outputted to
UART which will help the UART
determine whether to use the Transmit or
Receive Engine during a specific operation.
I/O
Signal I/O Connected to
IN_PORT [15:0] Input UART
CLK Input 100MHz Crystal Oscillator
INTERRUPT Input RS Flop
RESET Input AISO
OUT_PORT [15:0] Output UART
PORT_ID [15:0] Output UART & In_Sel MUX
INTERRUPT_ACK Output RS Flop
READ_STROBE Output UART
WRITE_STROBE Output UART
Table 14: TramelBlaze I/O
Register Map
Register Usage Description
R[15:0] PROM Functions individually in TramelBlaze PROM
Table 15: TramelBlaze Register Map
Figure 11: TramelBlaze Block Diagram
33. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 33
6. Internally Developed Blocks
6.1. Core
Description
Implemented in Revision 4.0, the Core compiles the processor and its interfaces in one
large instantiation. Any signals that interacts with the Core in any way must go through the TSI
first. In this design, the Core consists of the externally developed TramelBlaze, and internally
developed Full UART and MIB, these modules interact as seen in Figure 12. Aside from the
main components, the core also instantiates some accessory components as well, such as the
AISO to provide a synchronous reset to all modules, and a Pulse Maker and RS Flop to handle
the TramelBlaze‟s interrupts.
Figure 12: Core Top Module & Core Interface Interactions
34. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 34
I/O
All Inputs and Outputs state in this table are connected to the TSI before interacting with
other components of the FPGA.
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I On-board Button – BTNC
Rx_In 1 I USB
mem_data_in 16 I Micron Memory
Baud_Sel 4 I On-board switches
Parity_ops 3 I On-board switches
mem_addr 23 O Micron Memory
mem_data_out 16 O Micron Memory
IOBUF_T_LoE 1 O TSI
CE_LoE 1 O Micron Memory
WE_LoE 1 O Micron Memory
OE_LoE 1 O Micron Memory
ADV_LoE 1 O Micron Memory
CRE_HiE 1 O Micron Memory
UB_LoE 1 O Micron Memory
LB_LoE 1 O Micron Memory
Tx_Out 1 O USB
status 8 O On-board LEDs
mem_clk 1 O Micron Memory
Table 16: Core I/O
Source Code: Appendix A2
35. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 35
6.1.1. Memory Interface Block (MIB)
Description
The MIB consists of two major components, the state machine and the control flops. The
state machine sends the appropriate signals based on what it has receives in terms of Port ID. The
state machine allows the signals to be one of three configurations, IDLE, MEMREAD, and
MEMWRITE, and these states control the signals CE#, WE#, OE#, and T. With the signals
being sent, the control flops of the state machine manage the memory addresses and the data
coming to and from the Micron Memory. From this point, the TramelBlaze‟s ROM controls the
timing in when to send the memory address location and went to send or receive data.
Figure 13: MIB Top Module
36. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 36
I/O
Signal Size (bits) I/O Connected to
clk 1 I 100MHz Crystal Oscillator
reset 1 I AISO
Read 1 I TramelBlaze
Write 1 I TramelBlaze
Port_ID 16 I TramelBlaze
mem_data_in 16 I Micron Memory
TB_outport 16 I TramelBlaze
CE_LoE 1 O Micron Memory
WE_LoE 1 O Micron Memory
OE_LoE 1 O Micron Memory
IOBUF_T_LoE 1 O TSI
ADV_LoE 1 O Micron Memory
CRE_HiE 1 O Micron Memory
UB_LoE 1 O Micron Memory
LB_LoE 1 O Micron Memory
mem_addr 23 O Micron Memory
mem_data_out 16 O Micron Memory
TB_inport 16 O TramelBlaze
Table 17: MIB I/O
Register Map
Register Module Description
CE_LoE MIB Chip Enable Signal for Micron Memory
WE_LoE MIB Write Enable Signal for Micron Memory
OE_LoE MIB Output Enable Signal for Micron Memory
IOBUF_T_LoE MIB Controller for IOBUF in TSI
ADV_LoE MIB Address Valid Signal for Micron Memory
CRE_HiE MIB Control Register Enable Signal for Micron Memory
UB_LoE MIB Upper Byte Signal for Micron Memory
LB_LoE MIB Lower Byte Signal for Micron Memory
mem_addr MIB Memory Address location
mem_data_out MIB Data sent to Micron Memory
TB_inport MIB Data sent to TramelBlaze
state MIB State of MIB state machine
next_state MIB Next state of MIB state machine
WCLK MIB Counter to stay in write state for 130ns
RCLK MIB Counter to stay in read state for 130ns
nCE_LoE MIB Next state of Chip Enable
nWE_LoE MIB Next state of Write Enable
nOE_LoE MIB Next state of Output Enable
nIOBUF_T_LoE MIB Next state of T
37. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 37
nADV_LoE MIB Next state of Address Valid
nCRE_HiE MIB Next state of Control Register Enable
nUB_LoE MIB Next state of Upper Byte
nLB_LoE MIB Next state of Lower Byte
WA_R0 MIB Register to store and send Upper Byte
WA_R1 MIB Register to store and send Lower Byte
WD_R MIB Register to store and send character to Micron Memory
RD_R MIB Register to store and receive character from Micron Memory
Table 18: MIB Register Map
State Machine
Figure 14: MIB State Machine
This state machine is representative how the MIB‟s state machine works. Both WClk and
RClk are used to stay in that state for at 120ns.
Source Code: Appendix A3
Verification
Figure 15: MIB Verification
This verification was created by connecting the project to a module cell ram that
simulates the working behavior of the Micron Memory. At the bottom, the registers are taking
the correct data, especially when an asterisk (ASCII value: 2A) is received. The values are then
seen taken to the TramelBlaze and outputted onto the Transmit line.
38. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 38
6.1.2. Universal Asynchronous Receiver and Transmitter (UART)
Description
The UART consists of three components, the Transmit Engine and Baud Rate Decoder
from Revision 2.0, and the Receive Engine developed in Revision 3.0. The Transmit Engine is
responsible for shifting data out to the Transmit Line of the USB, while the Receive Engine is
responsible for shifting data into its register before outputting them to the TramelBlaze to be
processed. Both these Engines require a Baud Rate which is provided by a user inputted 4-bit
value that will translate to appropriate values that dictate the speed of transmitting and receiving
data.
An Interrupt signal is also implemented in the UART to cause the TramelBlaze to enter
the Interrupt Service Routine. The Interrupt signal named UART_Interrupt is asserted whenever
either the Transmit Engine or the Receive Engine are ready to work.
Figure 16: UART Top Module
40. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 40
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
Port_ID 16 I TramelBlaze
Data_in 8 I TramelBlaze
Rate_Sel 4 I Baud Rate Decoder
Parity_ops 3 I On-Board Switches
write_strobe 1 I TramelBlaze
read_strobe 1 I TramelBlaze
Rx_In 1 I USB
Rx_Out 10 O TramelBlaze
Status 8 O TramelBlaze & On-Board LEDs
UART_Interrupt 1 O Pulse Maker
Tx_Out 1 O USB
Table 19: UART I/O
Source Code: Appendix A4
41. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 41
6.1.2.1. Transmit Engine
Description
The Transmit Engine is comprised of five major components, the Transmit Bit Time
Counter, the Transmit Bit Counter, the Transmit Controller, the Bit Decoder and the Transmit
Shift Register. On a Transmit Engine level, these individual components work together in
achieving the goal of shifting data out to the Transmit Line. The first component, the Bit Time
Counter determines the speed at which the Engine can shift out data; the speed is ultimately
determined by the value provided by the Baud Rate Decoder of the UART. Next, the bit count
ensures that the Engine will only shift out 11 bits of data. The Bit Decoder takes in Data values
received by the Controller and determine the values that enter the 10th
and 9th
bit of the shift
register based on the Parity Options. The Shift Register concatenates the values from the Parity
Selector and Controller with 0 and 1, before shifting those values out from the LSB to MSB. All
of the previously mentioned components are controlled by the Controller. The Controller
consists of three flops that send signals to the Bit Time Counter, Bit Count, Shift Register and
UART Interrupt.
Figure 18: Transmit Engine Top Module
43. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 43
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
ld_in 1 I Write Strobe & Port ID
Baud_Rate 19 I Baud Rate Decoder
Data_in 8 I TramelBlaze
Parity_ops 3 I On-Board Switches
Tx_Rdy 1 I UART Interrupt
Tx_Out 1 I USB
Table 20: Transmit Engine I/O
Register Map
Register Module Description
count [18:0] Time_Counter Baud Rate Counter
count [3:0] Bit_Count Fixed number on how many times shift register can shift
Tx_Rdy Controller Acknowledge that Transmission is Ready
Load_D1 Controller Delays data to reach DoIt and Shift Register for one clock period
DoIt Controller Allows Bit Count and Bit Time Counter to increment
D_out [7:0] Controller Takes in Data from TramelBlaze
bit_10_9 Bit Decoder Determines what bit 10 and 9 of shift register will do
register [10:0] Shift Register Prepare data to be shifted out to a designated pin
SD0 Shift Register Takes in Data from TramelBlaze
Table 21: Transmit Engine Register Map
Source Code: Appendix A5
Verification
Figure 20: Transmit Engine Verification
The Transmit Engine is able to shift out data through the Tx_out line in accordance to the
requirements. This was done by giving the Transmit Engine different values, different Baud
Rates, and different Parity options to ensure that It was shifting out data properly.
44. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 44
Components
Transmit Bit Count
Description
The Transmit Bit Count holds the
responsibility of ensuring that the shift register
shifts out only 11 bits a time during transmission.
This is achieved through creating a flop that will
increment every time the Transmit Bit Time
Counter and Controller sends the appropriate
signals.
In Revision 3.0, the bit count had to be
changed to 12 in order to accommodate for the lack
of a STOP bit when both Eight and Parity Enable
options were selected.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
DOIT 1 I Tx Controller
BTU 1 I Tx Bit Time Counter
DONE 1 O Tx Controller
Table 22: Transmit Bit Count I/O
Source Code: Appendix A6
Verification
Figure 22: Transmit Bit Count Verification
The Test Bench shows that as soon as the value equals to 11, DONE is asserted to signify
that every bit has been shifted out.
Figure 21: Transmit Bit Count Module
45. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 45
Transmit Bit Time Counter
Description
The Transmit Bit Counter controls the
speed at which the system runs at. A Baud
Rate value is inputted into the module and it
will increment to that value as long as the
Controller allows it to. Given that the value
equates the Baud Rate value, it will assert its
signal, BTU, and reset the count back to 0.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
DOIT 1 I Tx Controller
Baud_Rate 19 I Global Input
BTU_Out 1 O Tx Shift Register & Bit Count
Table 23: Bit Time Counter I/O
Source Code: Appendix A7
Verification
Figure 24: Bit Time Counter Verification
The Test Bench shows that as soon as count is equal to 109, BTU_out is asserted for one
clock cycle before the count is reset to 0.
Figure 23: Transmit Bit Time Counter Module
46. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 46
Transmit Controller
Description
The Transmit Controller comprises of
two RS flops and two D flop. A Tx_Rdy RS flop
that tells the processor that the Engine is ready to
be utilized. A delay D flop to stall the load to the
Shift Register. A DoIt RS Flop that allows the
two counters to count. And an 8-bit load register
that take in data from the TramelBlaze and
transmit them to the Bit Decoder and Transmit
Shift Register.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
done 1 I Tx Bit Count
load 1 I Write Strobe & Port ID
Out_Port 8 I TramelBlaze
Tx_rdy 1 O Pulse Maker
Load_D1 1 O Transmit Shift Register
DoIt 1 O Tx Bit Count & Bit Time Counter
D_out 8 O Tx Shift Register & Bit Decoder
Table 24: Transmit Controller I/O
Source Code: Appendix A8
Verification
Figure 26: Transmit Controller Verification
This Test Bench shows the verification of the three flops. It shows that upon reset, Tx_rdy
remains high contrary to the Load_D1 and DoIt signal. When the load signal is asserted, Tx_rdy
goes low while the other two go high, and Out_Port takes up the test value. When done is
asserted, all flops go back to their original state.
Figure 25: Transmit Controller Module
47. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 47
Bit Decoder
Description
The Bit Decoder determines the
values that will be placed in the 10th
and 9th
bit location of the Transmit Shift Register.
This is entirely based on the values of the
Eight, Parity Enable, and oHeL lines which
are taken directly from the Nexys 4‟s on-
board switches. Table 25 provides the True
Table logic for the decoder.
Eight Parity oHeL 10 9
0 0 0 1 1
0 0 1 1 1
0 1 0 1 ^Data [6:0]
0 1 1 1 ~^Data [6:0]
1 0 0 1 Data [7]
1 0 1 1 Data [7]
1 1 0 ^Data [7:0] Data [7]
1 1 1 ~^ Data [7:0] Data [7]
Table 25: Bit Decoder Truth Table
I/O
Signal Size (bits) I/O Connected to
Reg8_in 8 I Tx Controller
bits_parity_oHeL 3 I On-board Switches
bit_10_9 2 O Tx Shift Register
Table 26: Bit Decoder I/O
Source Code: Appendix A9
Verification
Figure 28: Bit Decoder Verification
This Test Bench proves how the different options work with the same data of 8H‟9E.
Figure 27: Bit Decoder Module
48. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 48
Transmit Shift Register
Description
The Transmit Shift Register is responsible
for taking in data from the Controller and Bit
Decoder and shifting it out based on the speed of
the Baud Rate. While shifting data out to the USB
line, it shifts in 1‟s to signify the inactive behavior
of the Engine when data is not being transmitted.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
load 1 I Tx Controller
shift_en 1 I Tx Bit Time Counter
S_Data_in 1 I 1‟b1
D_in 11 I Bit Decoder, Tx Controller, 2‟b01
SD0 1 O USB
Table 27: Transmit Shift Register I/O
Source Code: Appendix A10
Verification
Figure 30: Transmit Shift Register Verification
This Test Bench shows the signal load allowing sample data 11‟b555 loading into
register. It also shows how register is shifting data out to SD0 while being filled in with 1‟s.
Figure 29: Transmit Shift Register Module
49. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 49
6.1.2.2. Receive Engine
Description
Like the Transmit Engine, the Receive Engine comprises of five major components, the
Receive Bit Time Counter, State Machine, Receive Bit Count, Receive Controller, and Receive
Shift Register. Individually, there are many components that are almost identical to those of the
Transmit Engine, but every component was modified to allow this part of the design to receive
data rather than to transmit data. The first component, the State Machine, determines when the
Receive Engine will work. It is also used to detect the Start Bit of the Transmitter to allow the
Engine to manipulate values that run into the Bit Time Counter and Bit Count. Next, the Bit
Time Counter, controls the speed at which the Receive Engine operates at. The speed is
determined entirely by the Baud Rate Decoder of the UART. Additionally, whenever the State
Machine detects a Start bit, the value of the Baud Rate will temporarily be divided by 2 to
calibrate the Engine in a way that allows it to pick up values at the halfway mark of every bit.
The Receive Bit Count is essentially the same as the Transmit Bit Count, but rather than be given
a fixed value of how many bits to count, it entirely depends on whether the Transmitter is
sending seven or eight bits and whether there will be a parity sent or not. The Receive Controller
takes care of two responsibilities, the first is to send a signal to let the processor know it is ready
to receive values and the second is to take the value received and to check for errors. Lastly, the
Receive Shift Register is similar to the Transmit Shift Register, except that it will output two; a
ten-bit value sent to the controller to check for errors, and an eight-bit value that will be sent
straight to the TramelBlaze for processing.
Figure 31: Receive Engine Top Module
51. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 51
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
Rx_In 1 I USB
Eight 1 I On-Board Switches
Parity_En 1 I On-Board Switches
oHeL 1 I On-Board Switches
read_strobe 1 I TramelBlaze
Rate 19 I Baud Rate Decoder
Port_ID 16 I TramelBlaze
Rx_Rdy 1 O UART Interrupt
Parity_Err 1 O On-Board LED
Frame_Err 1 O On-Board LED
Overflow 1 O On-Board LED
Rx_Data_TB 8 O TramelBlaze
Table 28: Receive Engine I/O
Register Map
Register Module Description
count [18:0] Rx Time Counter Baud Rate Counter
Start State Machine Detection of a Start bit
DOIT State Machine Allows Counter to count
State [1:0] State Machine Current position in receiving
next_state [1:0] State Machine Holds value of next state
next_Start State Machine Holds value of next Start
next_DOIT State Machine Holds value of next DOIT
count [3:0] Rx Bit Count Fixed number on how many times shift register can shift
bits [3:0] Rx Bit Count Based on Parity Options, determines compare value
Rx_Rdy Rx Controller Signify readiness to take in data
Parity_Err Rx Controller If asserted, generate Parity does not match received
Frame_Err Rx Controller Stop Bit not detected
Overflow Rx Controller Too much information
F_Check Rx Controller Holds last value received by Shift Register
Data_Ctrl [9:0] Rx Shift Register Data sent to Rx Controller
Data_TB [7:0] Rx Shift Register Data sent to TramelBlaze
Data_Out [9:0] Rx Shift Register Raw Data shifted from Transmitter
Table 29: Receive Engine Register Map
Source Code: Appendix A11
52. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 52
Verification
Figure 33: Receive Engine Verification
Testing the Receive Engine required using the ROM from the previous Revision and
Transmit Engine to feed the Transmit line into the Receive line. This was done to simulate data
entering and being processed by the Receive Engine. This Test Bench demonstrates a working
Receive Engine that is able to accurately detect when the Start bit occurs. Simultaneously, it able
to properly shift in the Transmit line data and re-map the data according to where it needs to be
sent off to.
53. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 53
Components
Receive Shift Register
Description
The Receive Shift Register is responsible for
taking in the data from the Rx Line and shifting them
into a register. Because of the Eight and Parity Enable
switch, the register values need to be re-mapped
accordingly. The raw value is copied into two separate
registers, Data_Ctrl and Data_TB. Data_Ctrl is the data
sent to the Controller that consists of every bit of
information to calculate any errors. Data_TB is the data
sent to the TramelBlaze, and this consists of only the
ASCII value that was sent. This data is extracted using a
combinational block that will shift the value further and
fill the unnecessary information with 0‟s.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
BTU 1 I Rx Bit Time Counter
Start 1 I State Machine
Rx_In 1 I USB
Eight 1 I On-board Switches
Parity_En 1 I On-board Switches
Data_Ctrl 10 O Rx Controller
Data_TB 8 O TramelBlaze
Table 30: Receive Shift Register I/O
Source Code: Appendix A12
Verification
Figure 35: Receive Shift Register Verification
The Verification shows when Shift Enable is asserted, Data_Out takes in Rx_In value at
every positive edge of the clock. The data is also shifted according in Data_Ctrl and Data_TB.
Figure 34: Receive Shift Register Module
54. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 54
State Machine
Description
The Receive Engine State Machine determines
the state of the signal it is receiving. In Figure 30, it is
illustrated to show how the data in this machine flows.
The Start bit is most significant bit of information the
State Machine needs to detect. It allows the Engine to
enter the second state and allows itself to prepare for the
on-coming data. Once this bit has been detected, the
State Machine allows the counters to count and begins
collection. Once the Bit Count has received the
necessary number of bits, it will return to the IDLE state
and it will wait for the next Start bit.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
Rx_Line 1 I USB
BTU 1 I Rx Bit Time Counter
DONE 1 I Rx Bit Count
Start 1 O Rx Bit Time Counter
DOIT 1 O Rx Bit Time Counter & Rx Bit
Count
Table 31: Receive State Machine I/O
State Machine
Figure 36: Receive State Machine Module
Figure 37: Receive State Machine
55. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 55
Source Code: Appendix A13
Verification
Figure 38: Receive State Machine Verification
Figure 31‟s Test bench demonstrates the State machine at work. During the correct states,
Start and DOIT are on at the appropriate times. As this was a rough test, the States continue to
cycle through one another because Rx_Line is consistently low, while BTU is consistently high.
56. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 56
Receive Controller
Description
The Receive Controller consists of multiple RS
flops, all with a different purpose. The first flop sends out
a signal called Rx_Rdy which is asserted whenever the
Engine is done receiving data from the Transmitter. When
active, this signal asserts the interrupt to the TramelBlaze.
Next, the Parity_Err flop is a signal sent to one of the
Nexys 4‟s on-board LEDs. The LED turns on whenever
the generated parity does not match the received parity,
which indicates that there is an error in the transmission.
Next, the Frame_Err flop sends a signal to the LEDs
whenever the Stop bit is not detected after a transmission.
Lastly, the Overflow flop sends a signal to the LEDs
whenever a Stop bit has occurred but there is still more
data coming in. These signals allow any user to be able to
detect the errors that may occur during the transmission of
data to the Receive Engine.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
DONE 1 I Rx Bit Count
Clear 1 I Read Strobe & Port ID
Eight 1 I On-board Switches
Parity_En 1 I On-board Switches
Even 1 I On-board Switches
D_In 10 I Shift Register
Rx_Rdy 1 O TramelBlaze
Parity_Err 1 O On-board LEDs
Frame_Err 1 O On-board LEDs
Overflow 1 O On-board LEDs
Table 32: Receive Controller I/O
Source Code: Appendix A14
Figure 39: Receive Controller Module
57. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 57
Verification
Rx_Rdy Signal
Figure 40: Receive Ready Signal Verification
The Rx_Rdy signal is an RS flop which takes in two inputs to set and reset the value.
Whenever DONE is asserted, the Rx_Rdy signal goes high, but the Clear signal has priority over
DONE, which causes it to stay low as long as Clear is high.
Parity Error Signal
Figure 41: Parity Error Verification (working)
In this first test, the module was given a test signal of 10‟B11_1001_0011 at 8-bits and
odd parity enabled. It was able to pass the test with no issues as the test signal was correct.
Figure 42: Parity Error Verification (not working)
To test whether the Parity Error signal worked, the same signal was sent in this test but
rather than sending an odd parity, an even parity was requested. Because it was the same signal,
the Parity Error signal went high, as the Generated Parity did not match up with the Received
Parity.
58. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 58
Framing Error Signal
Figure 43: Framing Error Verification (working)
Framing Error tested whether a Stop bit was detected or not. The same example from
Parity Error was run through the Framing Portion, and it detected no framing error because the
two most significant bits were 1‟s
Figure 44: Framing Error Verification (not working)
To ensure Framing Error was in working condition, the two most significant bits were
changed to 0‟s to simulate the nonoccurrence of a Stop bit. Once the flop detected this, the Error
was asserted.
Overflow Signal
Figure 45: Overflow Error Verification (working)
Overflow occurs whenever DONE and Rx_Rdy are both asserted at the same time, as
neither of them are not asserted at this time. Overflow does not occur.
Figure 46: Overflow Error Verification (not working)
Once both are them are asserted at the same time, an Overflow does occur as the Test
Bench demonstrates.
59. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 59
Receive Bit Count
Description
The Receive Bit Count behaves similarly to the
Transmit Bit Count, where it counts the number of bits to
ensure that the Engine is picking up the correctly number of
bits. But in addition to this, the Engine is also tasked with the
responsibility of changing the compared values due to the
difference in how many bit needs to received based on the
Eight and Parity Enable options. Table 33 shows the truth
table behind how it many needs to be detected.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
DOIT 1 I State Machine
BTU 1 I Rx Bit Time Counter
Eight 1 I On-board Switches
Parity_En 1 I On-board Switches
DONE 1 O State Machine & Rx Controller
Table 33: Receive Bit Count I/O
Table 34: Receive Bit Count Truth Table
Source Code: Appendix A15
Verification
Figure 48: Receive Bit Count Verification
This Test Bench shows the Bit Count working with an option of 8-bits. It matches the
truth table above and allows the Receive Engine to sample 10 bits before asserting.
Eight Parity Bits
0 0 9
0 1 10
1 0 10
1 1 11
Figure 47: Receive Bit Count Module
60. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 60
Receive Bit Time Counter
Description
The Receive Bit Time Counter is
similar to the Transmit Bit Time Counter,
where it determines the speed at which the
Engine runs based off of the value inputted
by the Baud Rate Decoder. The difference
between the two Bit Time Counters is that
the Receive Engine does not hold the same
value whenever it receives a bit. Whenever
the Engine detects a Start Bit, the value of
the Baud Rate will temporarily be divided
by two so that the Receive Engine can
sample the transmitted data at the half way
mark of every bit. This allows the Engine
to accurately pick up data and allows room
for any sort of drift.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
reset 1 I AISO
DOIT 1 I State Machine
Start 1 I State Machine
Baud_Rate 19 I Baud Rate Decoder
BTU 1 O Tx Bit Count, State Machine & Tx
Shift Register
Table 35: Receive Bit Time Counter I/O
Source Code: Appendix A16
Verification
Figure 50: Receive Bit Time Counter Verification
This Test Bench shows the change in Baud Rate when the Start signal goes high. As soon
as Start is asserted, Rate changes immediately.
Figure 49: Receive Bit Time Counter Module
61. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 61
6.1.3. Baud Rate Decoder
Description
The Baud Rate Decoder is a 4-bit
Decoder that determines the speed at which the
Transmit and Receive Engine run at.
I/O
Signal Size (bits) I/O Connected to
Rate_Sel 4 I R6, R7, U8, U9
Baud_Rate 19 O Transmit Engine
Table 36: Baud Rate Decoder I/O
Register Map
Register Usage Description
Baud_Rate
[18:0]
Constant Change the constant that Bit Time Counter compares to
Table 37: Baud Rate Decoder Register Map
Source Code: Appendix A17
Verification
Figure 52: Baud Rate Decoder Verification
The Baud Rate Decoder proves that it is working properly by associating the correct
value with the correct switch orientation.
Figure 51: Baud Rate Decoder Module
62. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 62
6.1.4. Pulse Maker
Description
This block generates a one clock period
pulse whenever a signal is asserted. With two D
flops inside, it is able to take the signal and generate
a one clock period pulse to the output. In this
application, The D_in input will take in an interrupt
signal from the UART and it will set the Interrupt
through the pulse and sent it over to an RS flop,
which manages the interrupt of the TramelBlaze.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
D_in 1 I UART
reset 1 I AISO
pulse 1 O RS Flop (S)
Table 38: Pulse Maker I/O
Register Map
Register Usage Description
flop [1:0] Pulse Create a one clock cycle pulse when flop [1:0] = [0, 1]
Table 39: Pulse Maker Register Map
Source Code: Appendix A19
Verification
Figure 54: Pulse Maker Verification
This Test bench proves that the Pulse Maker is working properly, it is only sends a one
clock period pulse regardless of how long the signal may be.
Figure 53: Pulse Maker Module
63. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 63
6.1.5. RS Flop
Description
The RS Flop module exactly models how an RS Flop
works. Through the S input, the RS Flop is connected to the
Pulse Maker, which sets D_out high whenever this input is
asserted. On the contrary, the R input is connected to the
TramelBlaze‟s Interrupt Acknowledge, which when asserted
will clear the value of D_out and cause it to go to low.
This module is also used to manage the Transmit
Ready and Receive ready before they enter the Pulse Maker.
I/O
Signal Size (bits) I/O Connected to
clk_in 1 I 100MHz Crystal Oscillator
R 1 I TramelBlaze
Reset 1 I AISO
S 1 I Pulse Maker
D_out 1 O TramelBlaze
Table 40: RS Flop I/O
Register Map
Register Usage Description
D_Out Interrupt Send interrupt when S is asserted
Table 41: RS Flop Register Map
Source Code: Appendix A20
Verification
Figure 56: RS Flop Verification
This Test Bench shows a working RS Flop. It is set high whenever S is asserted but R
will deassert the value while also having priority over S.
Figure 55: RS Flop Module
64. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 64
6.2. Technology Specific Instantiation (TSI)
Description
The TSI is a newly developed block in Revision 4.0, that combined with the Core
provides a more organized and chip specific design. With the TSI, the design is improved by
providing easier access to I/O cells that are more specific towards the chip‟s design. In this
design, the usage of an IOBUF was necessary to be able to access the memory through a
bidirectional wire. Without this type of buffer, the design would not be able to access the
memory as it does.
Figure 57: TSI Top Module
65. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 65
I/O
Signal Size (bits) I/O Connected to
clkI 1 I 100MHz Crystal Oscillator
resetI 1 I On-board Buttons -- BTNC
switchesI 7 I On-board Switches
clk 1 O Core
reset 1 O Core
Switches 7 O Core
Tx 1 I UART
Rx_I 1 I UART
Tx_O 1 O USB
Rx 1 O USB
MEM_A 23 I MIB
status 8 I UART
mem_clk 1 I Always Logic „0‟
CE 1 I MIB State Machine
WE 1 I MIB State Machine
OE 1 I MIB State Machine
ADV 1 I Always Logic „0‟
CRE 1 I Always Logic „0‟
UB 1 I Always Logic „0‟
LB 1 I Always Logic „0‟
MEM_A_O 23 O Micron Memory
statusO 8 O On-board LEDs
mem_clk_O 1 O Micron Memory
CE_O 1 O Micron Memory
WE_O 1 O Micron Memory
OE_O 1 O Micron Memory
ADV_O 1 O Micron Memory
CRE_O 1 O Micron Memory
UB_O 1 O Micron Memory
LB_O 1 O Micron Memory
MIB_T 1 I MIB State Machine
MIB_I 16 I MIB
MIB_O 16 O MIB
MIB_IO 16 IO Micron Memory
Table 42: TSI I/O
Source Code: Appendix A21
66. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 66
7. Chip Level Verification
7.1. Revision 2.0: Transmit Engine
Figure 58: Transmit Engine w/ TramelBlaze Verification
Figure 50‟s waveform demonstrates a simulation of the Transmit Engine with key signals
passing through it. The most important signal to note is the Tx_Line which shows the data
entering the Transmit Engine being shifted out serially to a receiver.
Figure 59: Transmit Engine with TramelBlaze Serial Terminal Output
When loaded up onto the Nexys 4 board and connected to RealTerm, the results were as
seen in Figure 51. This shows a consistent transmission to the Serial Terminal as long as the
Engine and Serial Terminal agree upon the Parity options and number of bits being sent.
67. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 67
7.2. Revision 3.0: Receive Engine
Figure 60: Receive Engine w/ Transmit Engine Feed Verification
Once the Transmit Engine was verified, the Receive Engine could be tested. Figure 52,
taken from the Receive Engine verification demonstrates the working behavior of the Receive
Engine. As seen in the Figure 53, by taking the Transmit Line and feeding it into the Receive
Line, the system simulated how data would flow into the Receive Engine, as if they were user
inputs. This was done with the Transmit Engine ROM; it was consistently sending out the string
“CSULB CECS 460<CR><LF>” into the Receive Engine, so that it could show how data flows
through the it. The values of Data_TB matches with the value of Reg_out and this provides
enough evidence to say that the Receive Engine is working properly.
Figure 61: Test connection between Transmit Engine and Receive Engine
68. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 68
Figure 62: Full UART and TramelBlaze Serial Terminal Output
After ensure that both the Transmit Engine and Receive Engine were working properly as
individuals, a new ROM was developed in order to utilized both engines. Once the ROM was
properly developed, the design was connected to the Serial Terminal to test its capabilities. In
this test, every option was tested to ensure absolute completeness of the design. The figure above
shows four statements that was typed in by the preparer. Each statement consisted of different
switch options to fully test the UART‟s functionalities. Through these tests, the UART was able
to accurately print each statement and its Parity Options without fault. This was also done at the
fastest Baud Rate to ensure the design was exercised at its fullest potential.
69. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 69
7.3. Revision 4.0: Memory Interface Block
Figure 63: MIB with Cell Ram Verification
Verifying that the MIB worked required different methods than the ones used to verify
the UART. First, the MIB had to be connected to a Cell RAM module provided by Micron in
order to simulate it. This was critical in properly designing the MIB so that it meets the timing
required to partake in certain read‟s and write‟s. After this was complete and data was seen to be
stored in the Cell RAM as seen in Figure 64, it was apparent that the system was able to access
the Micron Memory. After ensuring that the MIB was working correctly, another ROM had to be
created to utilize all the tools that the MIB provided. Once this was complete, clearing any
lingering bugs was done with ease.
Figure 64: Memory Address and Data
70. Prepared by:
Phuong Nguyen
Date:
December 14, 2016
Document Name:
Final Specification
Revision:
4.0
Nguyen 70
8. Chip Level Test
Figure 65: Chip Level Test with MIB, Full UART, and TramelBlaze
After ensure MIB‟s test benches were working properly, it was appropriate to begin
testing it using the Full UART and serial terminal. Like the previous revisions, a new ROM had
to be developed in order to accommodate for the additional functionalities of the MIB. To save
time, only one parity option was used throughout the entire development process, 8 bits/No
Parity. The other parity options were already confirmed to be working in the previous revision,
when testing the Receive Engine. This test was solely focused on the usability of the MIB. At the
top the banner “I WILL ECHO<CR><LF>” appears whenever reset is pressed. After that, the
user is able to input character into the serial terminal, exactly like in the previous revision, except
the system has the added functionalities of being able to backspace properly, and stores each
character into a location in the on-board memory. Whenever a “*” is pressed, memory then
dumps out the stored data, and simply prints whatever the user had inputted. This is clearly
shown in the next two statements in the figure above.