This is some great stuff, thanks for all the feedback - seriously. My VHDL experience is probably about 2/3 online tutorials, and they were all behavioural. The main aim of the articles are for me to learn.

The point about documentation is valid. However, as I've has no training at all in this, I'd be writing a document that basically has no value. After this project has come to it's conclusion, I'll probably go try again using processes/methods learned.

Thanks again for the feedback :)

Learning by doing is cool.

You don't have to do it the conventional way.

It's just that from my perspective, I can only focus on the future problems. I am too traumatized from the HW experience! I almost rewrote a couple of my points again just now.:)

You are documenting via your blog in a sense. It has value. It is a high level representation of your plans for the project.

Hey - author here. I'm not wanting to learn industry practices, it's a hobby project. May look into things like that later, though. The other article parts have the disclaimer that says I have no idea what I'm doing ;) Cheers for the feedback :)

Uh oh. I didn't realize you were actually on HN. Apologies if my other spiel seems too harsh.

Perhaps the better sounding term would be "engineering practices" rather than "industry practices". If it's a hobby, you still want to get a good result out of your effort. That principle in industry still applies to the hobbyist IMO.

The signal names issue that alain94040 mentioned was just an example of one problem with the code.

Assuming the desired result is to get running on an fpga, I think you need to take a step back for a second and look at the target environment you want to run on and plan out how it will all work.

Hah, don't worry - I didn't think it was harsh. I've had no training/edu in HDL whatsoever, so this was a deep dive - I expected to be told I'm doing wrong!

The end result is on FPGA, yes. Still a long way before that works. And I'll make sure any massive screwups are documented in next parts, those are the best parts (and, probably most valuable) to write about :)

Thanks for the advice! I've been synthesizing a bit, fixing a few issues that at least didnt present when building for the simulator. I've yet to run it actually on hardware, though - that part will be fun. Webpack does still come with the schematic viewer, which is really neat.

Cheers for the tips. I'll eventually move to Verilog, but as others point out, I think it's good to walk before I run. Regarding pipelining, I'm getting right on it - and the iterative benchmarking is something I plan to do. Thanks again :)

Also, feel free to contribute to the Verilog tutorial I started for software engineers, it's on WikiBooks at https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...

VHDL is dead in the industry(). While VHDL is slightly better for teaching, why not learn directly what everyone else uses? Also, because VHDL is such a pain to support for CAD tools, more tools support Verilog only, or support VHDL as a second-class citizen.

() my european friends hate me each time I say that, but it's true.

Yeah I was taught in VHDL but my prof acknowledged that it's mainly because it's better as an educational tool. He argued that it's easier to go from VHDL to Verilog after learning the strict practices, and that it leads to just better programming practices in the industry

yes! I've not implemented conditional jump to an immediate offset yet, so you need the branch target in a register.

Hey folks, writer here. Thanks for the great comments! Part 2 is already up talking interrupts (same blog) and i'll be cheating even more when the SD card interface comes online.