When learning any hardware for the first time, one invariably runs into peculiarities that are so foreign and frustrating that they discourage the learner (especially the self-taught learner) from progressing further.
Many a development board has been left collecting dust for months -- or set aside forever -- in favor of a more approachable piece of hardware that is less powerful but easier to use. For this reason, most people best master difficult-to-learn hardware in a university or professional setting. In these environs, the user is forced to use a particular piece of hardware, but at the same time has access to resources and mentors that are simply not available to the average do-it-yourself electronics enthusiast.
In the case of FPGAs, the home-learner can read all the books and cruise all the online forums out there, but -- inevitably -- he will run across an issue specific to FPGAs that is so counter-intuitive that he stops having fun and starts being frustrated.
This FPGA will rue the day it crossed me!
My job is to give that DIY user access to adequate resources that he or she can use to learn complicated hardware -- in this case, FPGAs. But how can I possibly deal with the frequent and varied peculiarities that seem to arise when learning programmable logic? The short answer is "I can't!" The long answer is that, by assuming the user is familiar with MCUs, I can use that assumed knowledge as a basis for comparison in teaching the fundamental concepts of FPGA programming.
In my Digital Logic class in college, for example, our first assignment with VHDL was to write a simple circuit that used a couple of switches as inputs and modified the state of some corresponding LED outputs accordingly. Because of my experience with MCUs and C programming, I could not get my head around the idea that I was "writing a circuit." I understood the digital logic I was being taught, but when it was put into a code format I was still thinking sequentially. Where was the "while(1)" loop at the end? This code was going to run off into the weeds!
I sat in my first lab completely frustrated until the teaching assistant pointed to my code and said, "When it's uploaded to the board, everything in this code is happening all at once." Thinking sequentially was my first "chute," my error in understanding, and my TA's statement was my first "ladder," a way of thinking that allowed me to gain a real understanding as to what was going on inside my code.
So now I'm trying to put ladders in place along the learning path before the user even hits the chutes. Portions of VHDL code that are reliant on a clock signal, for example, can be very hard for a new user to understand. Having MCU experience might even come as a detriment, because the user already has a bias as to how things are "supposed" to go. How do I even explain a constraint file to an MCU user if she can't initially visualize the connections between the constraints and the hardware description language (HDL) representation? I need to dispel biased ideas before they can become frustrations so the student can understand FPGAs as painlessly as possible.
Everyone has a different experience when learning FPGAs. When you were learning, at what point did you become hopelessly stuck? What "peculiarities" of FPGAs really made you bang your head on your keyboard? And, when you did finally get it? What was the trick? What did you read or hear that finally gave you a ladder and made the idea "click"?
Max Maxfield 1/28/2013 10:02:10 AM User Rank Blogger
Re: Change of perspective
My head is a jumble of ideas. On the one hand I've been thinking about the best way to explain FPGA concepts to younger folks. One way to do thsi would be to provide a simple schematic entry mechanizm that allows you to capture a design as a circuit of logic gates and registers, and then explain that this design gets loaded into the FPGA.
The problem with this is that we no longer design at the level of gates and registers -- we capture our designs at a higher level of abstraction (RTL or higher) --then we feed theses descriptions into synthesis -- and the gate/register-level netlist is the output from synthesis.
Like I say, my head is a jumble of ideas abouit how best to explain this -- but I do think that sketching a curcuit out on a piece of paper -- even if it's at the level of functional blocks being connected together -- helps convey the fact that each blog will be "doing it's thing" independently of the other blocks (that is, all of the blocks will be active and doing things at the same time)
I think the 7400 series implementation vision that you are speaking about is a very good starting point for FPGA world newcomers. It make me think in the ever-present schematic vs HDL debate.
Since joining the APP community, I've noted that most of the people here comes to FPGA design from the classic soft-programming paradigm (MCUs, processors, operative systems...). In fact, I believe that this is the general situation out there.
I was involved in physical microelectronic design when I first met a FPGA. More precisely, I was used to think in terms of electrical signals flowing throughout metal wires and reaching custom CMOS gates that I was developing: even a simple NAND, OR... logic gate supposed a pretty high level abstraction for me!!!
Nowadays, I still need to work in schematics capture mode in order to understand what is really going on in my designs. My HDL skills are very limited, and I should admit that programming in VHDL or Verilog is still a pain for me...
My "personal ladder" is to visualize the HDL components as black boxes in a hierachical schematic design. Then, I fill the boxes with primitives, code snippets or already available IP cores, and I only write new HDL code when strictly necessary.
Maybe this is not the most convenient way of getting the work done, but I strongly believe that becoming aware of that we are really "wiring" hardware block components when using a FPGA is a key point in order to cope with the issues of a first approach to this technology.
World is at the fast lane of dynamism and technology is a key part to this change. I think programming either hardware descriptive or software abstraction level both still have same method of coding but differentiation lies in syntax and few other stuffs.
What's FPGA? It's method of programming for logic device and field programmable gate array only taking care of the complexity part of it. In embedded system, simulation, modeling and/or formalization are essentials part - their goals are to ensure system correctness properties vis -a-viz reliability and integrity to their real life behaviours. Meanwhile, VHDL is just another coding of Verilog coined as Verilog Hardware Descriptive Language ( VHDL) is a traditional C concept of coding.
Even if you have worked on any real time operating system kernel like uCos II, this also C concept but difference is archicture of the processor RTOS running on, this makes RTOS coding more time and memory management inclined. Yes, IF, THEN and CASE ... and perhaps FSM.
@Max, It was a gradual demise, so many modifications over the 5 years it was running.
The keys finally started to give up life and chips sockets became erratic.
The Acorn BBC B came onto the scene, and my children wanted the posh BBC instead of the funny old puter dad made. It languished in a box in the workshop until some heavy weight rested on one end of the PCB at which point pcb cracked in half.
I salvage all the TTL chips and Roms but that was it.
I think the Science Museum has a board still.
It was a joy to use, as you could put a scope on any bit and see the waveforms and timing.
If you or anyone wants copies of the schematics of the Ohio Scientific version and the additional boards, I can scan them into the PC send them to you. Roms are available on the Net and I have some development roms that may not be on the net.
I will set a time limit that by this time next year I will have an FPGA version running?
Max Maxfield 1/25/2013 3:31:17 PM User Rank Blogger
Re: Change of perspective
@Crusty: I think that came out around 1978/79 -- I was at university then and didn't have any time (or money) free -- but looking back I wish I had built one of those -- I really wish you hadn;t lost yours ... what happened to it?
@Max, As a young lad I used to get the electronics hobbyist magazine "Practical Electronics" in the UK.
Practical Electronics. Did you follow the series on the UK101? It was an English copy of the Ohio Scientific single board 6502 computer all 74 TTL logic, it had built in Basic (early Microsoft with bugs). I built one while working at the London Underground Research Labs, 4K of static ram it cost me £300 and basically Kick started my electronics professional career. It took a deal of talking to get the wife to agree to that expenditure.
I still have the roms and the circuit diagrams though the single board departed life long ago. When I have got a bit more HDL control under my belt I intend to fully transfer the circuits to an FPGA . I might even worry you all by writing a reto blog on raising the past to life again?
I seem to remember my department head, getting upset and making one as well. He was not to be upstaged by his bench technician.
Max Maxfield 1/25/2013 2:54:12 PM User Rank Blogger
Re: Change of perspective
@matthew180: I know just what you mean, although my background was a bit different. As a young lad I used to get the electronics hobbyist magazine "Practical Electronics" in the UK, in addition to transister-level projects there were a lot of simple 7400-series TTL projects, so I was used to thinking in terms of hardware before I went to university.
At university I learned to program in FORTRAN and BASIC (I learned Pascal and C "on the job" after I'd graduated). When I was first exposed to a hardware description language and software/logic simulation (this was long before Verilog and VHDL) -- it all made perfect sense to me -- it mapped onto th eway I already thought the world worked.
matthew180 1/25/2013 2:38:18 PM User Rank Beginner
Change of perspective
I'm not sure I had a moment where things "clicked", but I certainly had a moment where changing my perspective allowed me to really accomplish my goals. That moment happened when I started thinking about how I would design my circuit using 74LS logic instead of HDL.
I was coming from a programmer's perspective sure, but I also know some electronics and have worked with microcontrollers, TTL logic, etc. before, so at least I knew I was not "programming". However, HDL constructs like IF THEN, CASE, etc. can be very misleading for a person coming from a software discipline. Understanding what you are describing is critical to getting things working, and using the classic 74-series logic chips is a great way to visualize your circuit and understand what you are doing.
Using this mental model also helps you wrap your head around the parallel nature of hardware and FPGAs. If you put two chips on a breadboard, wire them up and apply power, it is natural to look at them and understand that they will both be operating at the same time, instead of one waiting for the other to do something. Circuit boards are two-dimensional with wires running all over the place, "code" on the other hand is a one-dimensional linear list that establishes a mental model of a sequence. I think HDL's biggest problem is the presentation (not that I have a better idea at this point, I'm just making an observation).
Getting out of the theory and theory-heavy books, and on to texts that give practical working examples helped me a lot too. I'm a hands-on self-taught learner, so to much math or theory and I glaze over. Show me a formula and I'll shrug and move on. Show me that formula implemented in code or HDL, now I can understand it and use it. And as for Moore or Mealy... Don't care. Neither ever helped me get my FSM working.
FPGAs are becoming increasingly common in the hobbyist world based on the merits of customization and speed and the advantages associated with the concept of open-source.
Using a Papilio FPGA Development Board, the team built an AVR8-based soft-controller, running on the Papilio, that could handle the kind of data processing and buffering required for the project, while still being able to write code in the Arduino domain.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
