TR Forums

SecretSquirrel wrote:

just brew it! wrote:

During debugging you need to look at signals internal to the chip that don't make it out to the external pins. The tools allow you to compile a "soft" logic analyzer right into the FPGA, which then talks to your workstation to display the waveforms. The downside is adding or moving "probes" takes half an hour because you need to recompile the entire design!

What is it called in the Altera world? Xilinix calls theirs ChipScope. Very handy.

SignalTap II.

So... we're progressing. Two steps forward, one step back. We're hoping to take a shot within the next week at loading everything onto our real hardware (as opposed to the Altera eval/dev boards we've been using to date).

My piece of the design appears to be producing correct output, but is struggling to achieve our target frame rate of 60Hz; this seems to be due to contention with other parts of the system for access to DRAM. The "real" target hardware has ~50% more DRAM bandwidth than the development cards, and a decision was made this week to reduce the resolution of one of the video inputs (which will reduce bandwidth requirements a bit), so I'm not worried about the frame rate issue at this point... I've got bigger fish to fry!

It is quite gratifying to see the FPGA logic compiled from my VHDL code producing an image on a monitor...

just brew it! wrote:

It is quite gratifying to see the FPGA logic compiled from my VHDL code producing an image on a monitor...

Kinda like the first time you made an LED blink with a micro controller....

I agree though. The first time I saw video on the screen from an Open Graphics board board, I felt the same way. I think this is what separates the theoretical types from the applied types, regardless of your field. Theoretical guys get that feeling when the figure out the answer. Applied guys get that feeling when they make the answer work.

Congrats.

--SS

SecretSquirrel wrote:

Theoretical guys get that feeling when the figure out the answer. Applied guys get that feeling when they make the answer work.

I think that's a very good way of putting it. I also got to see this at a pretty extreme scale back when I used to work at Fermilab many years ago. You had the accelerator people who ran experiments on the Tevatron accelerator; then you had the theoretical people who ran simulations on custom supercomputers. Totally different worlds. I worked with the theoretical physics folks, but my own job was firmly on the "applied" side of the fence since I was part of the team that built and maintained their custom supercomputers (I was responsible for maintaining the system software and support libraries, and also wrote most of the hardware diagnostics).

Related question:

I'm having some trouble finding a text book that has a good coverage of both general Digital Electronics (binary numbers, boolean logic, logic gates, K-maps, ...) *and* VHDL. Most of them seem to focus on one or the other, with a little bit of the other thrown in for good measure. Does anyone have any recommendations?

Stargazer wrote:

Related question:

I'm having some trouble finding a text book that has a good coverage of both general Digital Electronics (binary numbers, boolean logic, logic gates, K-maps, ...) *and* VHDL. Most of them seem to focus on one or the other, with a little bit of the other thrown in for good measure. Does anyone have any recommendations?

An understanding of digital logic design is a prerequisite for VHDL, and is a fairly broad topic in its own right. IMO having a single text for both would be like having a single mathematics text that has an in-depth coverage of both Algebra and Calculus. I'm not saying it *can't* exist, but it seems like an awful lot of material to cover in a single book.

You might try Digital Design and Computer Architecture by Harris & Harris. While I don't know the textbook personally, it's the current assigned text in the course I took some years ago, and the description sounds like it's close to what you're looking for. You'll note that they don't introduce HDLs until after covering combinational and sequential logic. IMO Verilog/VHDL are rather arcane and introducing them earlier would not help at all conceptually. You want to learn the hardware structures first, on an abstract level, and then you learn how to describe them in an HDL.

As a side note, the VHDL texts I read while coming up the learning curve taught me the language constructs, but did not do a very good job of preparing me for the reality of writing code for synthesis. There's a lot of stuff that'll compile and simulate just fine, but becomes problematic when you try to put it into a physical FPGA. IMO if you're serious about learning how to do this stuff, there's no substitute for getting an eval card or developer's kit and loading your design into physical hardware.

just brew it! wrote:

Stargazer wrote:

Related question:

I'm having some trouble finding a text book that has a good coverage of both general Digital Electronics (binary numbers, boolean logic, logic gates, K-maps, ...) *and* VHDL. Most of them seem to focus on one or the other, with a little bit of the other thrown in for good measure. Does anyone have any recommendations?

An understanding of digital logic design is a prerequisite for VHDL, and is a fairly broad topic in its own right. IMO having a single text for both would be like having a single mathematics text that has an in-depth coverage of both Algebra and Calculus. I'm not saying it *can't* exist, but it seems like an awful lot of material to cover in a single book.

That's true, but if you combine them both in the same book, you can structure things in a way so that you cover certain VHDL parts in connection to those parts in the DE course. For instance, you could cover combinatorial logic, and then how to do this in VHDL. This has some benefits.

You could of course not have a very comprehensive coverage of VHDL in such a book, but you could at least cover the basics (the problem is that most books tend to be *too* basic).

Also, students are notoriously cheap, and sometimes balk at having to get more than one book.

mako wrote:

You might try Digital Design and Computer Architecture by Harris & Harris. While I don't know the textbook personally, it's the current assigned text in the course I took some years ago, and the description sounds like it's close to what you're looking for. You'll note that they don't introduce HDLs until after covering combinational and sequential logic. IMO Verilog/VHDL are rather arcane and introducing them earlier would not help at all conceptually. You want to learn the hardware structures first, on an abstract level, and then you learn how to describe them in an HDL.

Thanks, I'll take a look at it! A quick glance at the table of contents makes it seem interesting at least.

just brew it! wrote:

As a side note, the VHDL texts I read while coming up the learning curve taught me the language constructs, but did not do a very good job of preparing me for the reality of writing code for synthesis. There's a lot of stuff that'll compile and simulate just fine, but becomes problematic when you try to put it into a physical FPGA. IMO if you're serious about learning how to do this stuff, there's no substitute for getting an eval card or developer's kit and loading your design into physical hardware.

Agreed. Practical experience is *very* useful in situations like this.

6 microseconds in the life of an FPGA (click for full-size image):

I miss seeing those images. Quite a lot of fun to see/dissect.

just brew it! wrote:

6 microseconds in the life of an FPGA (click for full-size image):

Now that's what I call a timing diagram! Brought back some scary memories of undergrad trying to get the FPGA working right

just brew it! wrote:

As a side note, the VHDL texts I read while coming up the learning curve taught me the language constructs, but did not do a very good job of preparing me for the reality of writing code for synthesis. There's a lot of stuff that'll compile and simulate just fine, but becomes problematic when you try to put it into a physical FPGA. IMO if you're serious about learning how to do this stuff, there's no substitute for getting an eval card or developer's kit and loading your design into physical hardware.

My final project for my digital class had a file that would not synthesize with the rest of the code...my professor could not figure it out, I could not figure it out, and I lost points because of it But I still did well in the course...so there's that...

BTW, I know this is late to the party in terms of learning VHDL and Verilog, but having worked a with both, what you really need to learn is digital logic. Presto! You know 80-90% of both languages! The other 10-20% is exactly what you mentioned in this post, getting it to synthesize.

For larger projects, IMO a good working knowledge of modular top-down software design is important too. Although you're writing code that gets translated into digital logic, you're effectively writing software too.

Another challenge has been getting our hardware guys to make proper use of version control systems (Subversion) for their VHDL code. I think this comes fairly naturally to people who've been doing software for years, but not so much for EEs, especially if they haven't worked with a source code management system before.

just brew it! wrote:

For larger projects, IMO a good working knowledge of modular top-down software design is important too. Although you're writing code that gets translated into digital logic, you're effectively writing software too.

Another challenge has been getting our hardware guys to make proper use of version control systems (Subversion) for their VHDL code. I think this comes fairly naturally to people who've been doing software for years, but not so much for EEs, especially if they haven't worked with a source code management system before.

Even for smaller projects, modular design is important. It greatly enhances testability, even more so than in software, IMHO. For example, I'm in the middle of putting together a a PWM fan controller and temperature sensor peripheral for a work project. It's not a big design at all, perhaps a couple thousand lines of code -- mainly because I'm looking at 16 PWM units and 16 1-wire temperature interfaces. However, the design is entirely modular. One, it makes it easy to make 16 of something, and two, I can test each individual block and make sure it works in isolation. Yes, the situation is exactly the same with software libraries, but for some reason, just like version control seems more natural to software folks, building and testing modular designs seems to be more natural for hardware types -- at least in my experience.

--SS

Running 3 simultaneous Quartus II compilations on a system with 8 GB of RAM causes things to go all spastic as it starts hitting the swap file HARD. Unfortunately, this system's motherboard is maxed out at 8 GB.

Time to upgrade to something with a motherboard that can use 32 GB...

64 GiB should be easy enough with X79 and Sandy Bridge-E.

32GB
install server hyper-v or equiv.
use an ssd for host.

Just me....

DrDillyBar wrote:

32GB
install server hyper-v or equiv.
use an ssd for host.

Just me....

Definitely a SSD plus a RAID-1.

Hyper-V is a non-starter, as I run Linux as my base OS; there will be a Win7 VM though for those "gotta have Windows" situations that arise from time to time.

Damn, wished I had seen this thread a bit earlier. I actually LOVE writing VHDL - resp. designing RTL (Register Transfer Logic) - and consider myself not too shabby at it, sadly my work offers such projects only from time to time. So i hope my input is still somewhat useful and not too late for you/somebody.

just brew it! wrote:

As a side note, the VHDL texts I read while coming up the learning curve taught me the language constructs, but did not do a very good job of preparing me for the reality of writing code for synthesis.

THIS. The first problem regarding most VHDL-Courses/books is that it is treated as a programming language, which it is not. It's a hardware description language. A good developer needs not just to know the language, but also the capabilities of the target device (FPGA) or design library (ASIC), and testing/verification of course. Basically you have to know how a certain language construct you use, e.g., a FSM or datapath, will actually get synthesized, and how to verify functionality in simulation and hardware. "Knowing VHDL" then becomes: deriving RTL-synthesisable VHDL-code for a given algorithm.

The second and third problems are 'style' and 'abstraction levels' - hardly any books or courses teach you how to properly style and document code and how to modularize it so it stays manageable and in easier to grasp code-chunks. It's not just 'what' you write, but also 'how' you write it, e.g., a cleanly written, well structured FSM controlling some datapath can already be a work of art; which is apparently hard, for they are quite rare to find in the 'wild'.

Enough of the ranting, here's the best book I found that actually addresses these problems - mostly the first - at least as good as any single book can:
RTL Hardware Design Using VHDL - Coding for Efficiency, Portability, and Scalability - Pong P. Chu
It's worth every cent as it actually teaches some methodologies. So far as I can tell most of the other books mentioned so far are mostly along the lines of: ok, here are some VHDL constructs and some/a lot of examples; have fun. To get to know your design-target(s) and tools there is no other way but to dig through your providers documentation, sorry. But if you have done it once, it becomes easier for the next one as there are lots of similarities.

Here's one other link list with lots of good stuff and some more learning texts/FAQs:
http://tams-www.informatik.uni-hamburg.de/vhdl/

This is all I can think of right now, feel free to ask more questions.

Thanks for the book recommendation and links. I'm off of the FPGA project for now (it's on hold waiting to see if there's funding for the next phase), but there is a chance I will be doing more FPGA work again in the future.