Commit 189f3595 authored by goekce's avatar goekce
Browse files

questions from students

parent 681c1d6b
Pipeline #16100 passed with stages
in 2 minutes and 26 seconds
......@@ -44,3 +44,10 @@ problem-set-11.md
example-state-machine.md
example-adc-reading.md
```
```{toctree}
:maxdepth: 1
:caption: 'Unsorted'
questions-from-students.md
```
# Questions from students
## Makefiles
> You use makefiles in your projects. What are they for?
These files are used to synthesize or simulate the design by using commands on the shell without firing up the GUI. In other words they contain recipes to build your project.
You find more info on [make in Sean Kross' book The Unix Workbench](https://seankross.com/the-unix-workbench/working-with-unix.html#make). Makefiles can not only used for compiling code but also to describing frequently used steps in a project.
> Why do you use them? The GUI is easier to use after all.
I use them because these save me the mouse clicks for recurring tasks during the design process like synthesizing the design and programming the FPGA.
Alternatively you could also use [a program that records your mouse actions and repeat them](https://sourceforge.net/projects/minimousemacro/). Still it is more reliable and less error prone to use commands. Additionally you can add the programming capabilities of your shell like Bash or Powershell to add further automation, e.g., synthesizing a project with fifty different configurations and select one with the best results.
## Delivering only necessary files
> You recommend us to upload only the necessary files to a repository. Why?
These necessary files are typically called *source* files. For example your HDL files are source files but the bitstream and logs are *generated* files.
You should only upload source files if another developer (including your future you) will continue working on a project later. When you are working professionally you could be working in a team or your project will be used by someone else. Uploading unnecessary files will clutter developer's view and could waste developer's time in unnecessary searching tasks. For example assume that there are 10 files in a project directory, but only one of them is an actual source file, and a colleague of you who took over your project tries to introduce themselves to the project. They will first think that all of the files could influence the design and will start browsing them. This is unnecessary.
## Including building & usage instructions in the project
> I uploaded my project to a repository. Why do you want us to write instructions how to compile the project and use it?
If you deliver a project it should contain instructions to build the project. This will ease the job for the user. Imagine you bought a new shelf from a home improvement store. The building instructions will ease your job. Usage instructions are helpful too.
> The building instructions should typically include a build script. Why?
Surely you could also describe how to synthesize your project in the GUI. Writing the commands to create a bitstream are much shorter and less error prone.
> How can I do that?
After your are done your project you can create a script file that opens your project and generates the bitstream using commands. For example here are excerpts from my makefile that generates scripts to open a project and generate a bitstream in Vivado:
```{literalinclude} projects/vsyn.mk
:start-at: syn.tcl
:end-at: write_bitstream
```
`$(PROJ)` is the filename of your Vivado project. `> $@` and `>> $@` are part of Unix shell and makefile syntax and they write these lines to `syn.tcl`. They should not be included in your synthesis script file.
Similarly the following excerpt programs the bitstream.
```{literalinclude} projects/vsyn.mk
:start-at: program.tcl
:end-at: close_hw_manager
```
You can execute a script file with Vivado using `vivado -mode batch -source SCRIPT.tcl`.
So an idea could be to put these scripts in your repository and write in the instructions that the user should run first `vivado -mode batch -source syn.tcl` and then `vivado -mode batch -source program.tcl`.
## Language choice
> Why do you prefer Systemverilog over VHDL? A friend recommended me VHDL which supposed to be more popular in Europe.
The advancements in hardware description languages typically lag behind compared to the software languages. For example, as of 2022 the [latest Systemverilog standard is from 2017](https://ieeexplore.ieee.org/search/searchresult.jsp?queryText=IEEE%20Standard%20for%20SystemVerilog--Unified%20Hardware%20Design,%20Specification,%20and%20Verification%20Language&returnFacets=ALL&returnType=SEARCH&matchPubs=true&sortType=newest) and [the latest VHDL standard is from 2019](https://ieeexplore.ieee.org/search/searchresult.jsp?queryText=IEEE%20Standard%20for%20VHDL%20Language%20Reference%20Manual&returnFacets=ALL&returnType=SEARCH&matchPubs=true&sortType=newest). [These standards are not implemented in Vivado though](https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/Introduction?tocId=fmPYmh_GQ6tv1yfGJtHDTA) and Vivado supports Systemverilog 2012 and VHDL 2008.
In my opinion Systemverilog includes more convenient language features which I find beneficial especially for beginners.
......@@ -89,3 +89,5 @@ Xilinx
μA
μs
parameterizable
makefiles
Powershell
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment