In the Embedded world your standard Embedded microprocessor/DSP has all the peripherals preset and connected to the computation logic, although this is changing these days (see Cypress for their PSoC Mixed Signal Arrays). Additionally, these peripherals can also asynchronously interrupt the microprocessor when they need servicing. All the appropriate connections and signaling to the peripheral are taken care of on silicon and access to these peripherals is typically via memory mapped registers.
In the FPGA world this onus is entirely upon the designer, the designer essentially builds the desired functionality off simple logic blocks. This in turn means that independent blocks of logic will be “executing” in parallel. Thus if the FPGA interfaces to SDRAM memory and an I2C device then the designer has to build the modules to interface to these. These modules in turn will be running in parallel. If there is data exchange between the two then this needs to be synchronized correctly. State machines are a very typical design pattern used for many such designs. The design of these modules is not too different to modular design in software. Systems can be partitioned into blocks with known interfaces, these independent blocks are then connected via a high-level module.
There are a set of protocols and tools one has to get used to much like in software development. The inherent nature of FPGA’s makes the steps somewhat different to typical development on microprocessors. To get a handle on working with FPGA’s one has to first get used to the tools and the typical design flow. To this end I wanted to start slowly without adding too much so I decided that this first project was going to be very simple. Additionally, since I am also learning VHDL I decided that this additional complication is an unnecessary distraction for this first run. Quartus II provides one very good escape from this: Schematic Capture. This allows us to capture the full design graphically. This is a useful feature, at least for the beginner, that the Xilinx tools lack. Also I believe that the typical modus operandi for using schematic capture is to do most of your modules in the HDL of your choice (these can be converted to schematic symbols) and then do the top-level connect of all via schematic capture.
So without much ado let us get started. In this project/tutorial I hope to go over the basic design flow. First, however, this (ODSW1010) short online introduction to FPGA design is worth sitting through. In this first project we will create a module with 1 input and 1 output. The input is a switch the output is an LED. We will turn on the LED when the switch is pressed and leave it on, we will do the opposite on the next key press and so on. You will need close reference to the board schematic to see how and where your peripherals are connected. Typically you will also need to reference the appropriate peripheral datasheet for additional information. I find that Digi-key is a great resource for this, locate the part and you will find the datasheet too (as an example here is the link to the DE2-70).
I decided that, on the DE2-70, I was going to connect KEY0 to LEDG0 (see silkscreen markings of the same name on the board). These translate to KEY0 and LED19 on the schematic which further translate to pins T29 and W27 on the Cyclone II, respectively (see pages 7, 11 and 21 of the DE2-70 schematic, Rev 1.0). We will input this information during pin assignment in Quartus II. Now I don’t want folks to get daunted by this as there are a lot of pins to map out because the manufacturer (TerasIC) has made available the full peripheral IO mapping as a csv file which can be directly imported into Quartus II (the file is called DE2_70_pin_assignments.csv located under DE2_70_SYSTEM_cd_v1.1\DE2_70_tutorials\design_files in the v1.1 of the DE2-70 CD).
OK let us start. Open Quartus II (I am using v8.0) and select “Open New Project Wizard”.
Quartus II New Project Wizard
On page 1 of the wizard select a project path and input a project name. Keep the top-level design entity name the same as the project name for now. There is more information about this in the Quartus II online tutorial I had mentioned in an earlier posting.
Quartus II New Project Wizard Page 1
Leave the default settings on page 2 of the wizard. On page 3 of the wizard select the FPGA device we will be working with. On my DE2-70 it is the EP2C70F896C6N. Refer to the Cyclone II datasheet as to what these markings mean.
Quartus II Wizard Page 3
Leave the default settings for page 4 of the wizard. Page 5 of the wizard gives a summary of the settings selected, select “Finish” to continue.
Now the first thing we will do is assign the pins. To do this go to Assignments menu and select Pins. This will open the Pin Planner. All we will do is assign sensible names to the pins of interest. To do this go to the bottom pane of the Pin Planner and copy what you see below.
Quartus II Pin Planner
Let us now capture the design. To do this open the File menu and select new, then select “Block Diagram/Schematic Capture”.
Schematic Capture
As per our design goals I decided that the simplest option will be to use a T flip-flop with KEY0 driving the clock input. In the Schematic Capture window select the “Symbols” tool and then expand the library and select the edge-triggered T flip-flop.
Insert T flip-flop
Now complete the rest of the design by selecting the symbol tool and add the components. The final design is shown below. Note that the two boxes showing the PIN_??? designation will only show up after the compilation phase so after the capture go ahead and compile. Notice now that the Schematic Capture Window shows the design with the actual pins connected.
Final Design
Now let us download the design and run it. In the Tools menu select Programmer. If this is your first time doing this then you will have to select “Hardware setup …” to select USB-Blaster as the means for programming. Then highlight MyFirstProject.sof and hit Start. The design should be downloaded. Now test it out.
Our digital design process is incomplete. Typically, in most cases the designer first performs a simulation to verify the design before fully taking it to the next stage of download and verification on hardware. This involves creating stimuli for the design and then setting up the simulation for either a functional simulation (faster) or a full timing based simulation. In our case, this is a very simple design so we will skip this and add this step in the future.
This is all for this lengthy post. In the following posts we will add more steps such as simulation and learn to use other tools, such as SignalTap II. Attached is this project as a Quartus II project archive. Follow this link to learn how to restore it. You will need to recompile it since I have not included the output files.
Download MyFirstProject
Popularity: 20% [?]
To Add Comments You First Need to Register or Login. Delia Hardware