Graphics Library

Proposal Details

  • Who Updates: DanielKho, <Add YourName>
  • Date Proposed: 2015-01-03
  • Date Last Updated:
  • Priority:
  • Complexity:
  • Focus:

Current Situation

Currently there is no built-in graphics library in VHDL. Software programming languages such as C/C++/Java etc. became popular, in large part due to them having easy-to-use graphics libraries (graphics.h for example). To better serve our future market, and flow with existing trends, VHDL also needs a graphics library to allow hardware designers to easily implement graphics features directly on hardware, rather than relying on software to do the job. Current trends and the market keeps demanding for more features and lower power consumption, and one really good way to meet these demands is to move software code to hardware. As many would concur, a hardware design of the same feature set always performs better than its software counterpart (including C-based HLS), even when both of these have been optimised by their designers. Perhaps the only thing stopping us from implementing everything in hardware is the huge effort and time needed for such work. At present, it is simply easier and faster to implement graphics using software - there is always a graphics library to start with.

If we have a VHDL graphics library, people will start looking at implementing graphics on hardware as the amount of time and effort needed for graphics work would be roughly equivalent to if it were done using a software library.

Requirement

[In progress...]

Specify a portable graphics library, which provides graphics API functions to hardware designers. The API should provide only high-level features, such as graphics widgets (buttons, text boxes, combo boxes, etc), and possibly other graphics functions such as scaling and zooming. The library does not provide low-level (pixel-level) implementations regarding interfacing with some graphics vendor's chips, though it could provide an interface where the user can specify such protocols, possibly hooking up with a vendor's TLM/BFM.

Implementation details

Code Examples

Use Cases

Arguments FOR

Arguments AGAINST

General Comments

Supporters

Add your signature here to indicate your support for the proposal

-- DanielKho - 2015-01-03

Topic revision: r2 - 2020-02-17 - 15:34:56 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback