You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+9-5Lines changed: 9 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,9 @@ The Project F display controller makes it easy to add video output to FPGA proje
4
4
5
5
To get started take a look at the [demos](#demos) then read [modules](doc/modules.md) for the display controller interfaces and parameters. The design aims to be as generic as possible but does make use of Xilinx Series 7 specific features, such as SerDes. If you want advice on adapting this design to other FPGAs, then take a look at [porting](doc/porting.md).
6
6
7
-
For tutorials and further information visit [projectf.io](https://projectf.io).
7
+
For tutorials and further information, visit [projectf.io](https://projectf.io).
8
+
9
+
_NB. Pixel coordinates are now signed values and have been renamed; see module documentation for [display timings](doc/modules.md#display-timings)._
8
10
9
11
## Contents
10
12
@@ -33,6 +35,8 @@ Direct TMDS generation on FPGA requires high-frequency clocks (742.5 MHz for 720
33
35
34
36
The Black Mesa Labs (BML) Pmod is based on the Texas Instruments [TFP410](http://www.ti.com/product/TFP410). The Pmod is restricted to standard DVI features but allows even tiny FPGAs to support DVI signalling. As of February 2019, there is an unresolved issue when using a BML DVI Pmod with HDMI displays: some displays report a signal error and show nothing. This issue isn't confined to Project F but has also been reported by Black Mesa Labs themselves.
35
37
38
+
![](doc/display-pmods.jpg?raw=true"")
39
+
36
40
37
41
## Display Resolution Support
38
42
The following four display resolutions are tested and included by default (all at 60 Hz refresh rate):
@@ -86,7 +90,7 @@ Details on module interfaces can be found in the [modules](doc/modules.md) doc.
86
90
87
91
## Testing
88
92
89
-
If it isn't tested, it doesn't work. Project F tests its designs in simulation and on real hardware. For the display controller you can use the included [test benches](hdl/test) and [Python TMDS model](#tmds-encoder-model) to exercise the design.
93
+
If it isn't tested, it doesn't work. Project F tests its designs in simulation and on real hardware. For the display controller, you can use the included [test benches](hdl/test) and [Python TMDS model](#tmds-encoder-model) to exercise the design.
90
94
91
95
We haven't formally verified the design yet, but plan to do this for the display timings and TMDS encoder during 2019. If you're interested in learning more about formal verification, check out Clifford Wolf's [Formal Verification with SymbiYosys and Yosys-SMTBMC](http://www.clifford.at/papers/2017/smtbmc-sby/).
92
96
@@ -124,12 +128,12 @@ The following table shows utilization of the display-controller with the gradien
124
128
Interface LUT FF
125
129
-----------------------------
126
130
DVI on FPGA 278 86
127
-
DVI BML 3-bit 49 32
131
+
DVI BML 3-bit 86 32
128
132
DVI BML 24-bit TBC TBC
129
-
VGA 12-bit 67 32
133
+
VGA 12-bit 92 32
130
134
-----------------------------
131
135
Synthesized and implemented with Vivado 2019.1 using default options.
132
136
133
-
For comparison an Artix A35T has 20,800 LUT6 and 41,600 FF, while the tiny Spartan 7S6 has 3,752 LUT6 and 7,500 FF.
137
+
For comparison, an Artix A35T has 20,800 LUT6 and 41,600 FF, while the tiny Spartan 7S6 has 3,752 LUT6 and 7,500 FF.
134
138
135
139
NB. If you drive the "DVI on FPGA" display controller with a few fixed colours, such as the simple test bench, the optimizer removes a significant part of the design, resulting in misleadingly low utilization.
Copy file name to clipboardExpand all lines: doc/modules.md
+8-10Lines changed: 8 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,11 +77,11 @@ The [demo](/hdl/demo) modules include appropriate parameters for four standard p
77
77
78
78
79
79
## Display Timings
80
-
The display timings generator turns timing parameters into appropriately timed sync pulses and provides the current screen co-ordinates. Accurate timings depend on an accurate [pixel clock](#display-clocks). ([display_timings.v](/hdl/display_timings.v))
80
+
The display timings generator turns timing parameters into appropriately timed sync pulses and provides the current screen coordinates. Accurate timings depend on an accurate [pixel clock](#display-clocks). ([display_timings.v](/hdl/display_timings.v))
81
81
82
82
### Inputs
83
83
84
-
*`i_pixclk` - pixel clock
84
+
*`i_pix_clk` - pixel clock
85
85
*`i_rst` - reset (active high)
86
86
87
87
The pixel clock must be suitable for the timings given in the parameters (see display clocks, above).
@@ -92,18 +92,16 @@ The pixel clock must be suitable for the timings given in the parameters (see di
92
92
*`o_vs` - vertical sync
93
93
*`o_de` - display enable: high during active video
94
94
*`o_frame` - high for one tick at the start of each frame
95
-
*`o_h [15:0]` - horizontal beam position (including blanking)
96
-
*`o_v [15:0]` - vertical beam position (including blanking)
97
-
*`o_x [15:0]` - horizontal screen position (active pixels)
98
-
*`o_y [15:0]` - vertical screen position (active pixels)
95
+
*`o_sx [15:0]` - horizontal screen position (signed)
96
+
*`o_sy [15:0]` - vertical screen position (signed)
99
97
100
-
The positional outputs `(h,v)` and `(x,y)` allow you to determine the current pixel AKA "beam position". The values provided by `h` & `v `include the blanking interval, while `x` & `y` only include valid on-screen positions. For simple drawing or bitmap display you can use `(x,y)` and safely ignore `(h,v)`. However, if you're doing calculations in real time "racing the beam", then you'll want to perform actions in the blanking interval, which is where (h,v) comes in.
98
+
The current beam position is given by `(o_sx,o_sy)`. `o_sx` and `o_sy` are **signed** 16-bit values.
101
99
102
-
Project F considers blanking intervals to occur _before_active pixels. At the start of a frame (indicated by the `o_frame` signal), you have the blanking intervals in which to work before active pixel drawing occurs. The following sketch this for 1280x720p60 (other resolutions work in the same way):
100
+
When display enable (`o_de`) is high, these values provide the active drawing pixel and are always positive. During the blanking interval, one or both of `o_sx` and `o_sy` will be negative. This allows you to prepare for drawing, e.g. if you have a two cycle latency to retrieve a pixel's colour you can request the data for the first pixel of a line when `o_sx == -2`.
103
101
104
-
![](display-controller-hv-xy.jpg?raw=true"")
102
+
![](display-timings.jpg?raw=true"")
105
103
106
-
NB. `x` and `y` are 0 during the blanking interval.
104
+
At the start of a 1280x720p60 frame, `o_sx == -370` and `o_sy == -45`. Active drawing starts at `o_sx == 0` and `o_sy == 0` and the final coordinates are `o_sx == 1279` and `o_sy == 719`.
107
105
108
106
Horizontal and vertical sync may be active high or low depending on the display mode; this is controlled using the `H_POL` and `V_POL` parameters (below).
0 commit comments