FPGA tips - one for micro users

Hi all, I've just written a report called "Single Top FPGA Tips". May be of interest for micro users who want to get started using FPGAs...

formatting link

I tried to think of the best tip that I could give to a microntroller designer who has just started with FPGAs. That one is Single Top Tip #3. I hope that is useful! Kind regards, Anthony Burch

Reply to
Tony Burch
Loading thread data ...

Nice. I've been doing FPGA stuff coming from the micro/software side and the "think Hardware" resonated with me.

Andrew

Reply to
andrew queisser

How can you have 'Single Top tips' ? If it is single, there is just one, and it is surely a Single Top Tip, and if there are half a dozen, or ten, they are not single any more ??

-jg

Reply to
Jim Granville

Anthony,

You've hit on many topics that cause beginers problems, but I would add some more "meat" to the document. Show VHDL or Verilog examples of right and wrong ways of doing things. Your document points out good things, but doesn't really provide any answers.

The Design Warrior's Guide to FPGAs by Clive "Max" Maxfield provides the same info, but gives examples.

Eric

Reply to
Eric

Thanks Andrew! Yes, when first seeing VHDL or Verilog for the first time, some guys from the micro/software side think "OK, this looks a bit like C or other code". As you know, it's important to be aware straight away that the code is actually a "description of a circuit" rather than an instruction sequence.

Anthony

Reply to
Tony Burch

Hey Jim, that's a fair comment:) My idea was to consider each type of person, with different levels of experience. Then write a "single top tip" for each person. For example, I considered that if I was talking to an absolute beginner, what single tip would I give them. And if I was talking to a "Microntroller designer who has just started with FPGAs", what single tip could I offer them, and so on. So I imagined 6 different people at 6 different places.

Kind regards, Anthony

formatting link

Reply to
Tony Burch

Thanks Eric for your suggestions & recommendation. I'll check out Clive's book. I'll make some changes for Revision 1.1 of this tips document but I will probably also write another report that is more focused on providing good/bad design examples rather than just tips.

Kind regards, Anthony

formatting link

Reply to
Tony Burch

Partway through my "learning verilog" projects, it occurred to me that I could have expressed myself better with a schematic for one of the blocks, if only it were faster to type in.

Reply to
DJ Delorie

The "learn about synchronous design" tip resonates with me - simply because *no-one should be allowed near digital logic unless they know about synchronous design* ;). Ever!

Same applies to software too, but hey, one crusade at a time...

Steve

formatting link

Reply to
Steve at fivetrees

I agree that sometimes a description can be done quicker in a schematic. And, it has the benefit of being self-documenting - at least for smaller circuits.

The nice thing about HDLs is that text files - unlike schematic databases - aren't proprietary. And, except for the unix/windows end of line differences, text files are portable.

Reply to
Paul Urbanus

As someone who's been doing FPGA design since the XC3000 was state of the ard, I like tip #6: Perform functional and Timing Simulation to verify the performance of your design.

I once had a client come to me in a panic because their customer expected a deliverable in a few days. My client had hired an old-timer with no FPGA experience to do the design. Their development cycle was:

  1. Edit FPGA code
  2. Place and route
  3. Download and test code
  4. Code no-workey. Back to step 1.
  5. Repeat 1-4 until in panic mode.

When I asked about their simulation results, developer's response was, "We don't have time to simulate!"

Of course, my reply was, "No, you don't have time NOT to simulate."

After about a day of simulation, the problem was solved. Turned out to be a number of small things. The developer was a competent person and had written a fair amount of code.

Developing code without simulating is like writing software without a debugger. It can be done, but it takes longer and isn't near as much fun.

If, however, simulation is not employed, then the equivalent of the software development 'printf' statement is to connect appropriate internal signals to test points.

However, one has to be careful about that, as adding extra nodes to some nets can cause unexpected problems unless the synthesis tool settings are set correctly.

With Xilinx anyway, one can get a free license to use the ModelSim-XE simulator. For a beginning FPGA designer, this should be all that is needed. IIRC, there isn't a limit on the size of the design that can be simulated using the non-paid XE license. However, at certain circuit size points, the simulation S-L-O-W-S W--A--Y D---O---W---N

Reply to
Paul Urbanus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.