Hacker News Reader

Comment by WillFlux | Hacker News Reader

Original author here. I’ll do my best to answer any questions. Be gentle; this is my first time on the receiving end of Hacker News. :)

View on HN

Nice series! I've considered doing something similar due to the dearth of decent material on FPGA and hardware design on the internet though never quite got around to it...

For the sprites did you consider a part on dealing with multiple overlapping sprites? (I just skimmed, so apologies if you did this somewhere and I missed it!) There's at least two approaches here and I think it's an interesting thing to explore to discuss design trade-offs.

The two approaches I can see are:

1. Load the relevant line of each sprite into flops during the blank interval, when drawing determine which sprites produces a pixel for a given output pixel then apply ordering, taking into account transparent pixels to determine which one wins. You have a simultaneous read of all of the sprite flops each output pixel to do this

2. Pre-render all of the sprite pixels for a line into a memory buffer during the blanking interval. If you have multiple sprite pixels per cycle from memory and take advantage of that fact your FPGA can probably run at some multiple of the pixel clock (say 100 MHz vs the ~25 MHz pixel clock for 640x480) you do quite a lot in the blanking interval.

I reckon 2 wins when you're wanting more sprites per line and higher bit-depths per sprite pixel (8-bit 256 colour sprites vs 2/4/8 colour sprites).

I've got a ~60% complete version of 2, maybe I should follow you lead and finish it off and write about how it works.

Having now actually looked at the code looks like you did a version of 1, but as you've only got 1-bit pixels the combination stage is trivial (of the 8 sprites are any on, if so output a sprite pixel)?

I assume you’re talking about FPGA Ad Astra? https://projectf.io/posts/fpga-ad-astra/

The first sprites post, https://projectf.io/posts/hardware-sprites/ does include 4-bit sprites, but again no overlapping.

I am planning another sprite post with overlapping coloured sprites combined with a framebuffer background. I will probably use approach 2, as you describe, but with hardware design, I’ve found that the best algorithm can surprise you in practice.

I’d strongly encourage you to finish your write up and post it. As you say, there is a dearth of decent FPGA material, especially for hobbyists and those trying to learn hardware design.

You can do the pre-rendering on the previous line if you can spare two buffers. You just render into a buffer, then during the blanking interval latch it into a shift register. That gives you a lot more time to render.

You're right and I think I'm actually doing that on my 60% complete prototype. Haven't touched it for a couple of months and I've forgotten some of the details!

What’s your opinion about SystemVerilog? Can it be used as a higher level language compared to VHDL? Or it is still on same level?

SystemVerilog has several useful additions for FPGA engineers, but tool support has been slow to materialise. For the moment, I’ve kept to the few features that Xilinx Vivado and Yosys http://www.clifford.at/yosys/ are both happy with, such as enums, logic data type, and always_ff etc.

I’ve not used VHDL in anger, so can’t give you a useful opinion there.

Doing VHDL designs for a living here, using SystemVerilog once in a while when absolutely required. Take my words with a good pinch of salt!

SV is anyway a hardware description language, so you still think and code in terms of modules and signals (wires) to be connected. But if you want to create structures that use variables and have a more "procedural" style, I find that SV is more agile than VHDL for this specific purpose.

If you want real high level languages for hardware there are tools that provide synthesis from C/C++, Python and more software oriented languages.

> there are tools that provide synthesis from C/C++, Python and more software oriented languages

That sounds extremely interesting!

Beware, its much harder to get the correct hardware design useing these tools.

If that doesn't matter, then go for it!

I would imagine that.

A functional language like Haskell would probably be easier to compile to hardware.

I suggest increasing the text contrast on your site. It's barely readable on my screen as it is.

It’s something I’m looking into. The font seems to render thinner on some platforms, making it hard to read.

Do you have any learning materials recommendations for digital design and fpga programming?

Not the author, but regularly also get asked this question, and I usually recommend Digital Design and Computer Architecture, 2nd Ed [1]; supplemented with practical work on an FPGA.

[1] - https://www.elsevier.com/books/digital-design-and-computer-a...

Thanks

Alas, this is a surprisingly hard question to answer, at least for FPGA design.

Here are a few sites that helped me learn:

* https://www.fpga4fun.com

* http://fpgacpu.ca

* https://www.nandland.com/verilog/tutorials/index.html

* https://1bitsquared.com/pages/chat (Discord)

And a few interesting blogs:

* https://blackmesalabs.wordpress.com/

* https://tomverbeure.github.io

* http://labs.domipheus.com/blog/

None of the introductory FPGA books have impressed me, so I don’t have any recommendations there. Maybe some other HN readers will have some suggestions?

Thanks! I feel the best way to learn could be a set of labs of increasing difficulty with attached testbenches for simulation self-check This specialization https://www.coursera.org/specializations/fpga-design has something like that, but unfortunately it's fairly shallow

I bought several books but this is the found I found most accessible: "RTL Hardware Design Using VHDL" by Pong Chu https://ieeexplore.ieee.org/book/5237648

Any plans on making an actual GPU/accelerator? It looks like you already have the beginnings of one.

We’ll see :D

Forthcoming posts will cover simple 3D modelling with texturing and lighting in hardware. But that’s still a long way from a GPU.

Reply on news.ycombinator.com