OpenCores
URL https://opencores.org/ocsvn/wbuart32/wbuart32/trunk

Subversion Repositories wbuart32

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /wbuart32
    from Rev 12 to Rev 13
    ↔ Reverse comparison
  •

Rev 12 → Rev 13

/trunk/README.md
4,22 → 4,24
good to me also, having had ~~perfect~~_ (a good) _understanding of ~~all~~
things from the very first, to write_ ... my own UART core.
 
- This Verilog core contains two UART modules, one for transmit and one for receive. Each can be configured via one 32-bit word for just about any baud rate, one or two stop bits, five through eight data bits, and odd, even, mark, or space parity. If you are looking for an example Verilog UART module containing all these features, then you've just found it.
- This Verilog core contains two UART modules, [one for transmit](rtl/txuart.v) and [one for receive](rtl/rxuart.v). Each can be configured via one 32-bit word for just about any baud rate, one or two stop bits, five through eight data bits, and odd, even, mark, or space parity. If you are looking for an example Verilog UART module containing all these features, then you have just found it.
 
- The module goes beyond simple transmit and receive, however, to also include a fairly generic synchronous FIFO. For those looking for a fairly simple FIFO, you've also just found it.
- The module goes beyond simple transmit and receive, however, to also include a fairly generic [synchronous FIFO](rtl/ufifo.v). For those looking for a fairly simple FIFO, whether for your UART capability or something else, you've also just found it.
 
- If you are looking for a wishbone--enabled peripheral, this module offers two configuration methods: one that can be included in another, larger, wishbone module, and another wish is complete in its own right--together with FIFO and a FIFO status register.
- If you are looking for a wishbone--enabled peripheral, this module offers two configuration methods: [one](rtl/wbuart-insert.v) that can be included in another, larger, wishbone module, and [another](rtl/wbuart.v) which is complete in its own right--together with an integrated FIFO and a FIFO status register.
 
- If you are familiar with other UART setup protocols, you'll find this one even easier to setup. Unlike the 16550 serial port, this serial port can be set up by just writing to and setting a single 32--bit register. Once set, either at startup or by writing the the port, and your UART is fully configured. Changes will take place on the next byte to be transmitted.
- If you are familiar with other UART setup protocols, you'll find this one even easier to setup. For example, unlike the 16550 serial port, this serial port can be set up by just writing to and setting a single 32--bit register. Once set, either at startup or by writing the the port afterwards, and your UART is fully configured. Changes will take place on the next byte to be transmitted (or received).
 
- If you would rather test your own UART transmitter and/or receiver, this core contains within it a Verilator enabled UART simulator which can be used in test-benches of your own UART implementation to know if you've done it right or not.
- If you would rather test your own UART transmitter and/or receiver, this core contains within it a Verilator enabled [UART simulator](bench/cpp/uartsim.cpp) which can be used in test-benches of your own UART implementation to know if you've done it right or not.
 
- Finally, the test benches within bench/verilog of this directory can be used as very simple test benches to test for UART functionality on a board with only two pins (clock and output UART), or three pins (adding the input UART). Thus, if you are just trying to start up a project and need a demonstration that will prove if your UART will work, you can find such a demonstration project in this code. Further, two of those test benches will also create VCD files that can be inspected via gtkwave, so you can get a feel for how the whole works.
- Finally, the test benches within [bench/verilog](bench/verilog) of this directory can be used as very simple test benches to test for UART functionality on a board with only two pins (clock and output UART), or three pins (adding the input UART). Thus, if you are just trying to start up a project and need a demonstration that will prove if your UART will work, you can find several such a demonstration projects in this code. Further, two of those test benches will also create VCD files that can be inspected via gtkwave, so you can get a feel for how the whole thing works.
 
At one time, the biggest drawback to the files in these directories was that
there wasn't a version of this UART interface containing a FIFO. Well, no
more. Now there is a wbuart.v file that can be interacted with from a
wishbone/B4/pipeline bus, and it contains a FIFO with a parameterized length
that can extend up to 1023 entries.
more. Now there is a [wbuart.v](rtl/wbuart.v) file that can be
integrated into a wishbone/B4/pipeline bus. As mentioned above, this module
contains a FIFO with a parameterized length that can extend up to 1023 entries.
Indeed, recent changes have even added in optional hardware flow control, should
you wish to use it.
 
Thus this is a very simple and easy to use controller.
/trunk/bench/README.md
1,22 → 4,24
There are two bench testing directories, one for Verilator sources, and one for C++ simulation sources that will work with Verilator. The Verilog sources may or may not be used with Verilator. Indeed, they would work nicely as stand--alone top--level files that may be used to test whether or not the UART on a given board works.
There are two bench testing directories, [one for Verilator sources](verilog), and [one for C++ simulation sources](cpp) that will work with Verilator. The Verilog sources may or may not be used with Verilator. Indeed, they would work nicely as stand--alone top--level files that may be used to test whether or not the UART on a given board works.
/trunk/bench/verilog/README.md
1,14 → 1,15
This directory contains three basic configurations for testing your UART
and proving that it works:
- helloworld: Displays the familiar "Hello, World!" message over and over. Tests the transmit UART port.
- linetest: Reads a line of text, then parrots it back. Tests both receive and transmit UART.
- speechfifo: Recites the Gettysburg address over and over again. This can be used to test the transmit UART port, and particularly to test receivers to see if they can receive 1400+ characters at full speed without any problems.
- [helloworld](helloworld.v): Displays the familiar "Hello, World!" message over and over. Tests the transmit UART port.
- [echotest](echotest.v): Echoes any characters received directly back to the transmit port. Two versions of this exist: one that processes characters and regenerates them, and another that just connects the input port to the output port. These are good tests to be applied if you already know your transmit UART works. If the transmitter works, then this will help to verify that your receiver works. It's one fault is that it tends to support single character UART tests, hence the test below.
- [linetest](linetest.v): Reads a line of text, then parrots it back. Tests both receive and transmit UART.
- [speechfifo](speechfifo.v): Recites the [Gettysburg address](../cpp/speech.txt) over and over again. This can be used to test the transmit UART port, and particularly to test receivers to see if they can receive 1400+ characters at full speed without any problems.
 
Each of these configurations has a commented line defining OPT_STANDALONE within
it. If you uncomment this line, the configurations may be run as stand alone
configurations. (You will probably want to adjust the baud clock divider, to
be specific to the baud rate you wish to generate as well as the clock rate
you will be generating this from.)
it. This option will automatically be defined if built within Verilator,
allowing the Verilator simulation to set the serial port parameters. Otherwise,
you should be able to run these files as direct top level design files. (You
will probably want to adjust the baud clock divider if so, so that you can set
to the baud rate you wish to generate as well as the clock rate you will be
generating this from.)
 
If you leave OPT_STANDALONE commented, these demo programs should work quite
nicely with a Verilator based simulation.
/trunk/bench/verilog/echotest.v
57,13 → 57,18
`define OPT_DUMBECHO
//
//
// Uncomment the next line if you want this program to work as a standalone
// (not verilated) RTL "program" to test your UART. You'll also need to set
// your setup condition properly, though. I recommend setting it to the
// ratio of your onboard clock to your desired baud rate. For more information
// about how to set this, please see the specification.
// One issue with the design is how to set the values of the setup register.
// (*This is a comment, not a verilator attribute ... ) Verilator needs to
// know/set those values in order to work. However, this design can also be
// used as a stand-alone top level configuration file. In this latter case,
// the setup register needs to be set internal to the file. Here, we use
// OPT_STANDALONE to distinguish between the two. If set, the file runs under
// (* Another comment still ...) Verilator and we need to get i_setup from the
// external environment. If not, it must be set internally.
//
`ifndef VERILATOR
`define OPT_STANDALONE
`endif
//
module echotest(i_clk,
`ifndef OPT_STANDALONE
101,7 → 106,7
//
// This code only applies if OPT_DUMBECHO is not defined.
`ifdef OPT_STANDALONE
wire [29:0] i_setup;
wire [30:0] i_setup;
assign i_setup = 31'd868; // 115200 Baud, if clk @ 100MHz
`endif
 
/trunk/bench/verilog/helloworld.v
40,13 → 40,18
////////////////////////////////////////////////////////////////////////////////
//
//
// Uncomment the next line if you want this program to work as a standalone
// (not verilated) RTL "program" to test your UART. You'll also need to set
// your setup condition properly, though. I recommend setting it to the
// ratio of your onboard clock to your desired baud rate. For more information
// about how to set this, please see the specification.
// One issue with the design is how to set the values of the setup register.
// (*This is a comment, not a verilator attribute ... ) Verilator needs to
// know/set those values in order to work. However, this design can also be
// used as a stand-alone top level configuration file. In this latter case,
// the setup register needs to be set internal to the file. Here, we use
// OPT_STANDALONE to distinguish between the two. If set, the file runs under
// (* Another comment still ...) Verilator and we need to get i_setup from the
// external environment. If not, it must be set internally.
//
//`define OPT_STANDALONE
`ifndef VERILATOR
`define OPT_STANDALONE
`endif
//
module helloworld(i_clk,
`ifndef OPT_STANDALONE
53,20 → 58,23
i_setup,
`endif
o_uart_tx);
//
input i_clk;
output wire o_uart_tx;
`ifndef OPT_STANDALONE
input [30:0] i_setup;
`endif
 
// If i_setup isnt set up as an input parameter, it needs to be set.
// We do so here, to a setting appropriate to create a 115200 Baud
// comms system from a 100MHz clock. This also sets us to an 8-bit
// data word, 1-stop bit, and no parity.
// Here we set i_setup to something appropriate to create a 115200 Baud
// UART system from a 100MHz clock. This also sets us to an 8-bit data
// word, 1-stop bit, and no parity. This will be overwritten by
// i_setup, but at least it gives us something to start with/from.
parameter INITIAL_UART_SETUP = 31'd868;
 
// The i_setup wires are input when run under Verilator, but need to
// be set internally if this is going to run as a standalone top level
// test configuration.
`ifdef OPT_STANDALONE
wire [30:0] i_setup;
assign i_setup = 31'd868; // 115200 Baud, if clk @ 100MHz
assign i_setup = INITIAL_UART_SETUP;
`else
input [30:0] i_setup;
`endif
 
reg pwr_reset;
/trunk/bench/verilog/linetest.v
41,13 → 41,18
////////////////////////////////////////////////////////////////////////////////
//
//
// Uncomment the next line if you want this program to work as a standalone
// (not verilated) RTL "program" to test your UART. You'll also need to set
// your setup condition properly, though. I recommend setting it to the
// ratio of your onboard clock to your desired baud rate. For more information
// about how to set this, please see the specification.
// One issue with the design is how to set the values of the setup register.
// (*This is a comment, not a verilator attribute ... ) Verilator needs to
// know/set those values in order to work. However, this design can also be
// used as a stand-alone top level configuration file. In this latter case,
// the setup register needs to be set internal to the file. Here, we use
// OPT_STANDALONE to distinguish between the two. If set, the file runs under
// (* Another comment still ...) Verilator and we need to get i_setup from the
// external environment. If not, it must be set internally.
//
// `define OPT_STANDALONE
`ifndef VERILATOR
`define OPT_STANDALONE
`endif
//
module linetest(i_clk,
`ifndef OPT_STANDALONE
66,7 → 71,7
// comms system from a 100MHz clock. This also sets us to an 8-bit
// data word, 1-stop bit, and no parity.
`ifdef OPT_STANDALONE
wire [29:0] i_setup;
wire [30:0] i_setup;
assign i_setup = 31'd868; // 115200 Baud, if clk @ 100MHz
`endif
 
/trunk/doc/gpl-3.0.pdf Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.