Author Topic: Learning FPGAs: wrong approach?  (Read 54671 times)

0 Members and 1 Guest are viewing this topic.

Offline westfwTopic starter

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Learning FPGAs: wrong approach?
« on: June 15, 2017, 01:02:51 am »
Off in another thread:
Quote
  Do you know if there's any document which would describe the structure of the UDB in details?
(UDBs are the little FPGA-like block in a Cypress PSoC microcontroller.  But this question is generic to all FPGAs, CLPDs, and similar devices.)

So I (a software engineer with an EE degree from pre-FPGA times) have looked at various FPGAs at various times, and there always seems to be a hump that I have trouble getting over.   And I'm wondering if that's because of where I start - with the datasheet that describes the internal structure of the device.   Usually they go on about product terms and LUTs and output macrocells and so on.  And I know what each of those are (more or less) and how they work as individual pieces, but I lose the thread when I try to figure out how they might be combined to build larger structures.  (I mean, in principle I can build a UART out of shift registers, and I know how to build a shift register from a PAL, but...)

But that's completely the wrong approach, isn't it?
For the most part, if you're designing with an FPGA or CPLD, you should be designing at a MUCH higher level, with Verilog or VHDL or some schematic-entry tool.  And the tools knows about the resources available on a give chip, and will combine them appropriately or tell you to get a bigger chip with more macrocells (or something.)  Yeah, I can probably eliminate the 512byte FIFO from the chip that only has 320 bytes of embedded RAM, and at some point knowing a bit about the internals can help me optimize my thinking ("there's not penalty for adding extra terms to THAT equation.")  But otherwise ... it's like when you think about designing a SW algorithm, reading up on the multiple internal buses of your microcontroller is not the best starting point...

Am I getting closer?
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: de
Re: Learning FPGAs: wrong approach?
« Reply #1 on: June 15, 2017, 01:35:46 am »
I would just read a verilog tutorial.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #2 on: June 15, 2017, 01:43:32 am »
To star, both Altera and Xilinx are the top dogs here.  They both can be programmed in VHDL and Verilog.  I personally prefer Verilog since it is simpler language and you can still do all you want in Altera's Quartus.

Altera's Quartus allows you to enter visually gates, flipflops, ram, fifo, anything you like graphically and wire them together graphically as if it were a digital schematic.  This includes Verilog code you have written whose inputs and outputs would be represented in quartus as a block device with ins and outs.  On you schematic in Quartus, you then wire these function blocks to IO pins, have a selected chip for the project & compile.  Then, you chosen FPGA will be created and programmed doing what you laid out.  The compiler will also create a report telling you how much of the FPGA gates, memory & IO pins you used.  Also, how fast the clock can function.

Now, as for the USART, a simple set of DFF can serial shift data in to make a serial decoder, but, if you want there are pre-made blocks, to do this, or, even public domain Verilog/VHDL blocks which already conform to standard RS-232 standards which you can add anywhere in your Quartus schematic layout which eventually becomes your chip.  Dont worry about the size of what you are doing for these smaller functions like gates and serial decoders and even small dual port rams or fifos, I doubt you will fill even a % on the smallest FPGA.

Learning to read the data sheets on these devices helps so you understand when they say the IC has total 256kbit ram + 50k logic gates & how many IOs at what speed and voltage.

Also, look on youtube for tutorial videos for Quartus so you can see some examples of a user creating a device.  I cant speak for the quality or complexity of such videos, so search for beginner, try watching a few at 2x speed, if something looks interesting, restart the video at 1x speed.

Best of luck.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #3 on: June 15, 2017, 01:59:38 am »
Oh, 1 additional thing, Quartus II Web edition is free and you can play with it without any programmer or IC, it's fully functional.

When Youtubing, searching Quartus Tutorial, look for schematic entry & how to create things like ram.
Don't worry about Quartus version numbers, it's basically the same thing from version 9 and up.  Only a little different visual improvements.

https://www.youtube.com/results?search_query=quartus+tutorial

You will find basic schematic entry and how to add verilog code as well as plenty of stuff, like simulation.  (Note that simulation has slightly changes over quartus versions over the years, for these, look at the latest Quartus versions on how to do that.)
« Last Edit: June 15, 2017, 02:03:27 am by BrianHG »
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Learning FPGAs: wrong approach?
« Reply #4 on: June 15, 2017, 06:44:22 am »
I wouldn't study the cells of a FPGA too long if you want to get started. It's what turns out to be the least common dominator, and they just put a lot of them on 1 chip so it can be flexible to use.

What is most important to remember from a cell:

- Each cell has a LUT. Most entry level devices are 4-bit wide LUTs. This is what actually encodes the logic you programmed.
- Each cell has 1 flip flop. I.e. 1 bit of high-speed of 'memory'. This is rarely used for memory as such, but more for state information.

Then there are a ton of switches to route signals. Most FPGA's also contain a adder block in each cell, as it tends that those are often used.
FPGA's also have hard logic these days, which you could implement with cells - but as they are so often used the vendors have baked them on the chip. Most common options are hardware multipliers and embedded SRAM blocks. More advanced FPGA's even integrate complete ARM cortex CPU's or DDR controllers onchip at fixed locations.

Programming is best done in a high level language. Although you could do it graphically - I wouldn't recommended. It's too tedious after a short while.

I started out with VHDL and still doing that today. It's much more strongly typed opposed to Verilog which is loosely typed. Pick your poison.

In HDL you should describe how signals should behave and change at (clock) events. In VHDL processes you can actually write rather high level code, complete with functions and other abstractions. VHDL is actually a typical programming language in that respect: you can also write non-synthesizable code (useful for test benches for example).

I think one important tricks to understand is how statements are synthesized to hardware. RTL viewer is your friend. Usually if you write more complex statements, more hardware is being added. If you try to do more computation in 1 go, combinational paths will be longer and thus the maximum clock frequency of the design will go down.

This is actually no different than MCU design. You'll also look at the assembly. You'll also worry about execution times and sizes.
« Last Edit: June 15, 2017, 08:56:14 am by hans »
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Learning FPGAs: wrong approach?
« Reply #5 on: June 15, 2017, 07:55:14 am »
I agree that looking in too much detail at the underlying hardware structure of the FPGA isn't useful, beyond the high level parameters that tell you how much logic resource you have available.

For example, if an FPGA is sold with 10,000 logic cells, that means roughly 10,000 bits that can be registered and stored. The look-up tables associated with them mean you can have, to a good first approximation, any logical relationship between one set of bits and another that you like.

FPGAs also include 'hard' logic blocks, like dual-port RAM, multipliers and PLLs. These are useful, and you should definitely learn how to instantiate, configure and use them, but there are other things that are worth learning first and getting to grips with.

Don't use schematic entry to design your logic. Seriously. It's fine for academic purposes as a way to introduce the basic concept of a configurable system, but it's not portable, doesn't scale, takes much longer to do non-trivial designs, and is difficult to maintain. Walk away before you even start, and instead, learn VHDL (my preference) or Verilog.

By far the most important things to get your head around are:

- writing 'code' for an FPGA is not like writing code for a microprocessor. It's NOT a sequence of instructions to be executed one after the other, even if it occasionally looks as though it might be. Each process you create describes a piece of hardware which exists in parallel with all the others you've defined, and is always carrying out its prescribed function independently. Nothing at all inherently happens sequentially. If you want different things to happen on consecutive clock edges, you need to make sure something changes on one edge which can then be read and taken into account on the next edge.

- always, always, always be aware of when signals get updated, and when they are required to be valid with respect to other signals. Get to grips on day one with the concept of a clock domain. After lunch (but still on day one), read up on metastability, how it happens, and how to stop it becoming a problem in your design. Be in no doubt whatsoever that FPGA vendors and their tool chains do NOT solve this problem for you, but they do give you everything you need to solve it yourself.

I make a big deal of this because it's a ridiculously easy way to mess up a design, in a way which is not obvious to look at, and which causes occasional (or perhaps frequent) errors that make a board unreliable. Avoid a world of hurt later on by taking clock relationships seriously right from the very start.

Here's an example to spoil your day. Suppose you have an FPGA design which is a simple square wave generator, and the period of the square wave needs to be programmable.

Generating the wave is easy. You create a counter, clocked from some master reference clock (call it FCLK), which counts up from 0 to some programmed value CLK_PERIOD, and when it matches, you toggle the output and zero the counter.

CLK_PERIOD needs to be set, let's say via an SPI interface. So, you create a simple SPI slave, which can be written by an external microcontroller. That SPI slave is clocked by an external pin (SCK). The new value of CLK_PERIOD is updated when the last active edge of SCK is received.

Now consider what happens just at that moment. Let's suppose CLK_PERIOD is changed from 0x7F to 0x80.

On every edge of FCLK, the value of CLK_PERIOD is being read. That's fine if all the bits in CLK_PERIOD are actually valid at that instant. But what if SCK and FCLK have just the wrong phase relationship, so at the time the counter is being compared with it, some bits have their new values and some have the old value? And what if a bit is just on the point of changing, which makes the comparator metastable?

At best, you get a single cycle with the wrong period, ie. neither the old value nor the new one. At worst, your counter runs off into the weeds and it takes 2^n clocks before the output starts toggling again (where 'n' is the number of bits in your counter).

The logic of your code might be completely fine. Functional simulation will never show a problem. But once every few seconds, minutes or hours, your real hardware will malfunction.

Ways to solve this problem include:

- make FCLK fast enough that SCK can be sampled as though it's an asynchronous signal, ie. don't use it as a clock at all, but instead, look for changes of state in SCK in a process that's driven from FCLK.

- use a dual-port RAM as a FIFO. Push setting changes into the FIFO from the SCK side, and read them out in the FCLK domain. The vendor's FIFO logic includes robust features for crossing clock domains. (Typically, this involves converting addresses to and from Gray codes, but you never see this in your own code as it's done for you when you instantiate a FIFO).
 
The following users thanked this post: hans, marshallh, Yansi, Joeri_VH

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Learning FPGAs: wrong approach?
« Reply #6 on: June 15, 2017, 09:34:34 am »
There are a few things that are worth thinking about. Or maybe it is just rambling.

FPGAs are not CPUs
CPUs hold this state in RAM and legislatures, and change this state slowly, at best only a few words at a time. FPGAs can change a lot of state all the time if you let them. If you code for FPGAs as though they are CPUs, then you will miss the point of FPGAs

A design for an FPGA is static - for the most part you can't add more state information at 'runtime' - you do not have the FPGA equivalent of "malloc()" or "new" to add more logic. Instead try to think of your data flowing through your designs, much like how signals flow through a circuit.

Overthinking and Overdesigning
For the most part, FPGAs are just chips with inputs, outputs and clocks. Your job is to get the output pins to change as required by the inputs and the passage of time (as measured by the clocks). Your design does this by keeping track of information in a hidden, internal state vector, which evolves from cycle to cycle.

The simpler and more concise your description how this happens, the better the end result will be.

It is easy to overthink the problem, esp for a newbie. Ask yourself often "is this the simplest way to do this?".

As a general rule deeply nested HDL code with lots of IF statements is bad. If you do this, you are missing something about the problem and should see if you can decompose the problem more.

A simple design is easier to debug than a complex one.

Structure or behavioral code
Learn the distinction between structural and behavioral design. Your design is made up of little bits that behave in a specific way, connected together to make your design. Try to keep these aspects of your designs as separate as much as possible, at least while you are starting out.

Structural is like designing a schematic or PCB - how things are connected. Graphical tools work good at this, and this works well when using IP blocks, But HDL code isn't too good at this - it gets too verbose

Behavioral is like making the 'model' describing how an OpAmp works or other complex component works. This is somewhat hard to do graphically, but works well when using HDL code.

If you try to describe how things are connected and how they behave at the same time, it doesn't work well in either code or in graphical tools. Avoid this ugly middle ground!

Different FPGAs from different vendors
If you ignore the more magical parts of an FPGA (e.g. PLLs), at the bottom of the heap are the FPGA's primitives. LUTs and FlipFlops, ALMs, Slices, whatever - these change between vendors and devices, but they are very simple and pretty generic.

You could build anything you want with enough four input LUTs and D-flipflops. It might not be most efficient, but you can do it. Likewise you can also build anything you like with a (impractically) wide enough RAM and an single address register (e.g. a 256x8 bit RAM can act as an 8-bit counter). For the most part, the different FPGA architectures have just decided to put a different stake in the ground along this continuum.

A design that is optimal for one FPGA architecture is usually pretty close to optimal for another - changing vendor or the part is not usually going to make your design much easier.

Loops
If you write software for a while you have the power of unbounded loops fixed in your head. You need to retrain yourself to achieve your design goal without them.

This is like learning to write non-blocking code, but taking it to the next level. Don't try to be cunning and fight it or work around it - you can't win. :)

Time
Time for FPGA designs is very different for time in software or electronics. Everything happens all at once (in parallel), and then things happen so slowly (you can only do so much in one clock cycle).

Much like the shift to when you start shifting from DC to doing AC designs in electronics, or working in with maths in the frequency domain, or moving to writing real-time software you didn't know how much you didn't know what time really means until you finally get to grips with it. Once you do understand it, you can't see how it could really be any other way.
« Last Edit: June 15, 2017, 09:36:18 am by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: soFPG

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #7 on: June 15, 2017, 09:56:31 am »
PLLs

PLLs are bad beasts. They are only present in recent devices and they are usually vendor specific. E.g. Spartan2 (obsolete, but still good as it's 5V tolerant therefore very useful to design PCI-boards) and Spartan3 don't have PLLs, whereas Spartan6 devices include a few of them, but in order to use them you need to pass through their IP-wizards which automatically instantiate resources according to user's requirements. Nothing wrong with this, it simply means the approach is specific to Xinlinx (Altera, others ..)

I say it because from my point of view, everything is related to HDL at the RTL level is just 'HDL', I mean a couple of vhdl files plus constraints for a simulator.

I don't play with vendor tools until I have a workset. Instead I spend the 70% of the time on the simulator, where a few constraints are different from those required by the final target. This is the first thing one should learn as it's the main approach's rule, and it also means I can't simulate PLLs (neither it makes sense) until I move to the synthesizer, where the block is physically defined and properly instantiated.

On simulator I usually describe PLL block as a black box entity, with it's behavior is idealized by a function (I can write it in C, matlab, and pass it to the simulator through wrappers).

In other words, playing with HDL is a mashup between pure logic behavior and pspice. This is enough for a preliminary workset, then (the last 30% of your development time) you need to experiment and verify on the physical target if time-constraints are really all satisfied.
 

Online chris_leyson

  • Super Contributor
  • ***
  • Posts: 1541
  • Country: wales
Re: Learning FPGAs: wrong approach?
« Reply #8 on: June 15, 2017, 10:08:26 am »
Quote
writing 'code' for an FPGA is not like writing code for a microprocessor. It's NOT a sequence of instructions to be executed one after the other
Good advice from AndyC_772 it's an easy trap that new players can fall into. Always clock logic from a single clock source if you can and never ever use asynchronous logic. Use clock enable inputs to slow down a master clock if your logic needs a slower clock source. Always register or latch input signals to avoid metastability issues and if you need to cross clock boundaries then instantiate an asynchronous FIFO.
These days you don't need to do 'bare metal' design and you don't need to focus on the internal architecture of a particular FPGA family, it's all done with core generators now whereas back in the day with older generation silicon with limited resources you might have had to hand craft logic to save on resources.
« Last Edit: June 15, 2017, 10:35:10 am by chris_leyson »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: Learning FPGAs: wrong approach?
« Reply #9 on: June 15, 2017, 10:11:35 am »
Always remember that you are not writing code, you are building hardware.Think about how you would use logic ICs to do the job.
Even things that look like sequential code, specifically VHDL process blocks, express priority, not sequence.
You don't need to know anything about LUTs, Slices etc. until you're getting into advanced optimisation.
 
Start with a devboard that has a fairly big device. Even for simple designs, place & route will be faster - you can just ignore the stuff you won't be using.
You will be using state machines a lot, so need to understand them.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Learning FPGAs: wrong approach?
« Reply #10 on: June 15, 2017, 10:19:41 am »
legacy, it sounds as though you're making life difficult for yourself. Do you really not know which device - or at least, family of devices - a given design will target? And what do you have against PLLs? They're essential tools that have been present in every major device family for the last decade.

My preferred family is Altera Cyclone IV E. Older parts are functionally similar but less good in every quantifiable way. Cyclone V parts are bigger and more costly, and Cyclone 10 isn't yet readily available. I probably could switch to another vendor, but in the absence of a compelling reason to do so, it would be a lot of work for little or no benefit.

With that in mind, I usually start a new design along the following lines...

- how many I/O's do I need? Design the rest of the schematic, then see how many pins end up on the empty FPGA page. Add a few more for test points, and for the feature I'll find I need by the time the design is at rev C.

- create a dummy FPGA project in Quartus, with all the I/O pins defined with their correct direction and I/O standard (LVDS, 3.3V CMOS, 1.8V CMOS and so on).

- allocate the pin-out of the device, ensuring all the rules about which pins can go where are met. For example, on Cyclone IV E, LVDS pins can only go in a 2.5V bank, differential inputs must be at least a certain number of pads away from single-ended outputs, and so on.

- estimate the logic capacity requirement of the design. This is hard. Often I'll actually write a complete first draft of the code at this point, and hold off completing the PCB until it's done. It's amazing how many bugs get spotted and fixed at this stage.

- finish the PCB and send off for manufacturing

- simulate the VHDL in ModelSim. The Altera free version of this includes complete behavioural simulation models for all the hard IP blocks (memory, PLLs, DSP and so on), so I can simulate the entire system without having to worry about these. Yes, it's vendor specific, but so is my board, so I really don't care.

- debug the VHDL. This is probably the most coffee intensive part of the whole process, up to this point.

- write the SDC file. This takes over as the most coffee intensive part of the process.

- start writing test code for the main processor. Keep doing this until real hardware arrives.

- when real hardware arrives, plug it in and begin testing. By this point, I should already know that my FPGA will, to a good first approximation, work as intended. Minor changes and enhancements can be tested functionally on real hardware. More significant changes require a return to ModelSim.
« Last Edit: June 15, 2017, 10:23:44 am by AndyC_772 »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: Learning FPGAs: wrong approach?
« Reply #11 on: June 15, 2017, 10:29:20 am »
The first hardware you should use when starting out with FPGAs should ALWAYS be a devboard. Any devboard. Even better if it has an on-board programmer. Most manufacturers ( and some third parties) do very cheap boards for most FPGA families.

There are so many other things that can make it not work, that you really don't want to be wasting time messing around trying to figure out if it's a hardware, programming  or code  problem.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #12 on: June 15, 2017, 11:26:41 am »
They're essential tools that have been present in every major device family for the last decade.

Does Spartan2 have pll ? No!
Does Spartan3 have pll ? No!
Does Spartan6 have pll ? Yes!

Is Spartan2 5V tolerant? Yes!
Is Spartan3 5V tolerant? No!
Is Spartan6 5V tolerant? No!

Before babysitting people, understand what people needs.

 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: Learning FPGAs: wrong approach?
« Reply #13 on: June 15, 2017, 11:33:10 am »
They're essential tools that have been present in every major device family for the last decade.

Does Spartan2 have pll ? No!
Does Spartan3 have pll ? No!

Spartan 2&3 has DLLs, which serve the same purpose.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: hans, Someone

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #14 on: June 15, 2017, 02:37:47 pm »
I have used a simulator only once and it was a simple 4 bit counter.  I just had to try it...

If my primary state machine has, say, 100 states (which uses a 100 bit 1-HOT state vector) and controls a few dozen outputs that kick off other processes, I just can't see how the simulator is going to help.  It may be several thousand cycles in before I get to the part I want to see.  I may actually be using a logic analyzer at the FPGA level to analyze a hang in the Operating System.  Maybe something to do with booting the system from the Compact Flash.  There a lot of cycles before I get this far.  What sector did I read?  What did the data look like?  No, printf() is not a solution here!

So, I try to use a board with enough IO to feed a fairly wide logic analyzer.  Now I can create some kind of trigger that starts the capture just before the spot I am interested in and not have to wade through a bazillion nanoseconds of trace.

Bottom line:  I head straight to hardware.  This takes time because the system has to be fully synthesized, placed and routed.  It is probably not the most productive way to design FPGA projects but it works for me in my hobby world.

I don't have enough time with Vivado and a real project to know if the in-circuit logic analyzer will be a help.  From what I have seen, it is a really nice feature.  Once you become an uber-guru of the constraints file.  What a PITA!

I have seen designs where the code writes straight to the LUT.  All of the logic is specified around LUTS and DFFs.  I don't tend to understand it...

I write my VHDL as though I want to understand it several years later.  Just simple code, no tricky bits.  I let the toolchain worry about the details.  Again, this is not the high performance approach but it works for me.

 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: Learning FPGAs: wrong approach?
« Reply #15 on: June 15, 2017, 02:41:45 pm »
I'd agree that to get something happenning quickly & get a feel for things, avoiding simulation is probably a good start as it's yet another tool to learn before you see anything working.
You may or may not chose to use it later on - personally I've never used one.
You need to trade off the time setting it all up versus the savings in compile/program time not having to do place & route every iteration.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Learning FPGAs: wrong approach?
« Reply #16 on: June 15, 2017, 03:03:53 pm »
To star, both Altera and Xilinx are the top dogs here.  They both can be programmed in VHDL and Verilog.
and schematic capture as well. or Abel or  or AHDL.

As an FPGA designer you don;t deal with the 'guts' of the fpga. that is handled by the synthesizer and mapper.
simply make your schematic / code or mix thereof , click compile and blast it in the chip. done.
the tools come with extensive libraries with almost anything you can think of ( including whole cpu's and peripherals )
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Learning FPGAs: wrong approach?
« Reply #17 on: June 15, 2017, 03:37:13 pm »
the internal stuff gets important when optimizing your design, when you are a tight ass with low budget, or need every last MHz out of it

http://zipcpu.com/blog/2017/06/12/minimizing-luts.html

if you dont care about $ you can "program" fpgas in python, or even GO like javascript fed kids do these days https://reconfigure.io/ (on $3K dev board haha)
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 721
  • Country: au
Re: Learning FPGAs: wrong approach?
« Reply #18 on: June 15, 2017, 10:54:08 pm »
I like the Lattice ice40 fpgas. I believe they're the only one's where the "guts" meaning LUTs and inter-connect as well as bitstream format have actually been reverse engineered and documented by Clifford Wolf. If you want to tinker at that low-level, then the code is available as an example. I don't believe any of the other vendors - eg xilinx or altera document this stuff. In fact the opposite is true and they all encumbered by patent protections.

It helps that there's a lightweight and open-source verilog compiler and p&r available - sufficiently mature to synthesize the pico RISC-V core. From memory, I believe the toolchain even beats Lattice's proprietary toolchain - in terms of reduced lut counts and better timing.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #19 on: June 15, 2017, 11:26:07 pm »
I like the Digilent FPGA dev boards. They have a good selection and they're not too costly.

Don't worry about how the FPGA fabric works at first--you really don't need to know those low-level details as a beginner. Later, when you have more experience, you can explore the inner workings of the part.

Simulation is your friend. If something doesn't work in simulation, it's not likely to work on the chip. Learn how to write test benches at the same time you learn how to write Verilog or VHDL code. You'll save lots of time in the long run.

You probably already have a good grasp of state machines, but if not, bone up on them because you'll be using them a lot when working with FPGAs.

Start with simple projects, like a simple serial UART or SPI before trying to tackle something like HDMI.

Strive for simplicity. Complex designs are rarely the best designs.
Complexity is the number-one enemy of high-quality code.
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: Learning FPGAs: wrong approach?
« Reply #20 on: June 16, 2017, 12:50:49 am »
Off in another thread:
Quote
  Do you know if there's any document which would describe the structure of the UDB in details?
(UDBs are the little FPGA-like block in a Cypress PSoC microcontroller.  But this question is generic to all FPGAs, CLPDs, and similar devices.)

So I (a software engineer with an EE degree from pre-FPGA times) have looked at various FPGAs at various times, and there always seems to be a hump that I have trouble getting over.   And I'm wondering if that's because of where I start - with the datasheet that describes the internal structure of the device. 

Yah, not the best place, as you've figured out for yourself.

If you're old school I presume you shouldn't have any trouble with the actual logic design for what you want to do. So start there. Start with the familiar and work towards the unfamiliar.

Design your logic with discrete flip-flop, registers, gates, whatever you need - but don't reach for your dog eared TI 7400 logic guide, just invent your own parts as you need because you can have any part you want. With the magic of HDLs and FPGAs you can make, and interconnect, those parts inside the FPGA. Seventeen bit adder? No problem. Twenty-nine input 'and' gate? No problem. You get the idea.

Next step would be to learn one of the HDLs. My recommendation would be for Verilog, but in 30 seconds there will be 10 fan-boys coming along to tell you that I'm muddle-headed and VHDL is the only true way to the light. (If HDLs were church denominations VHDL would be the Calvinists and Verilog the Pentecostal Baptists; although I suspect some of the VHDL guys would quite like to find a Plymouth Brethren HDL.  :))

Once you've got the beginning of a grip on your chosen HDL, take the 'discrete' design you already made and implement the discrete parts you 'made up' in HDL, interconnect them in HDL, scribble a little HDL test-bed and hit the simulator.

In the process of doing this I think you'll find what I did, that you start thinking in HDL instead of flip-flops, gates, etc and you'll start to be able to do your design work directly in HDL.

The vendor tools for actual FPGAs can be quite a struggle to set up and get running with - not what you want at the 'hello world' stage. I'd recommend that if you're going Verilog that you grab the open source Icarus iverilog simulator and have a play with that and get yourself comfortable with some working results in simulation before you try and get them anywhere near an actual FPGA. If you want to go VHDL I'm sure someone can point you at some tools.

But otherwise ... it's like when you think about designing a SW algorithm, reading up on the multiple internal buses of your microcontroller is not the best starting point...

I'd prefer cache as the programming analogy. Some algorithms are going to suck unless you understand cache coherency, cache occupancy etc. You can always get something that works on any architecture, but getting it working well may mean tuning for the cache implementation on each architecture that you run it on.

Similarly, you can probably get a design in Verilog to work on any FPGA, but you may need to dig into the specific FPGA architecture to get it to work well, or take up a smaller capacity chip etc.

One area it is worth knowing the ins and outs of your particular FPGA is literally the ins and the outs. You can save quite a lot of grief by understanding how to use I/O cells to your advantage, and how to get the right clock into the right pin and distributed around inside the FPGA the right way.

As a software engineer you're going to have to keep reminding yourself that the HDL you're writing represents wires, gates and registers. It's all parallel and any temptation to fall back onto classic iterative programing habits will bite you in the backside. Every time your instincts tell you to write a for loop you're almost always looking for a Mealy/Moore state machine instead.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 
The following users thanked this post: chickenHeadKnob

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #21 on: June 16, 2017, 08:02:07 am »
if you dont care about $ you can "program" fpgas in python, or even GO like javascript fed kids do these days https://reconfigure.io/ (on $3K dev board haha)

LOL  :-DD :-DD :-DD
 

Offline jprozas

  • Newbie
  • Posts: 3
  • Country: es
Re: Learning FPGAs: wrong approach?
« Reply #22 on: June 16, 2017, 11:14:47 am »
This link is to learn digital design with FPGA (verilog) with open tools. (Spanish)

https://github.com/Obijuan/open-fpga-verilog-tutorial/wiki

Enviado desde mi Aquaris_A4.5 mediante Tapatalk
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #23 on: June 16, 2017, 02:27:09 pm »
if you dont care about $ you can "program" fpgas in python ...

You probably think you're joking, but human madness is already past that. Xilinx marketers take python very seriously, and even "scientists" from California University believe that python is the most efficient way to program FPGAs:

https://forums.xilinx.com/t5/Xcell-Daily-Blog/Best-Short-Paper-at-FCCM-2017-gets-30x-from-Python-based-PYNQ/ba-p/765899

https://arxiv.org/pdf/1705.05209.pdf
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #24 on: June 16, 2017, 02:37:52 pm »

You probably already have a good grasp of state machines, but if not, bone up on them because you'll be using them a lot when working with FPGAs.


A state machine is just a C switch statement inside the while(1) loop.  But, just ahead of the switch(), you need to define a default output state for every output signal you create.  Otherwise, you have to define the output state of every signal at every state.

Like this:
Code: [Select]

    process(Reset,Clk) is
    begin
        if Reset = '1' then
            state <= s0;
        elseif rising_edge(clk) then
            state <= NextState;
        end if;
    end process;


    process (state, FullEA, FetchOpnd, F, TAG, IA, CO, OFL, OVFLInd, COtemp, CSET, VSET,
                r_Button0, CCC, CondMet, BOSC_Flag, SavedSign, A_BUS(15), ShiftCount,
                SZ, ZR, DVDS, Result, Ones, OVR,
                CountShifts, ACC, IncludeEXT, EXTN, Rotate, AFR,
                BitCount, XIO_Device, XIO_Function, XIO_Modifier,
                DisplaySwitch,
                ConsoleXIOCmdBusy, ConsoleXIOCmdAck,
                PrinterXIOCmdAck, PrinterXIOCmdBusy,
                ReaderXIOCmdBusy, ReaderXIOCmdAck,
                DiskXIOCmdBusy, DiskXIOCmdAck,
                DiskReady, IAR,
                SingleStep, BreakPointActive, BreakPoint,
                PendingInterrupt, ReturnState_r, StartState) is
    begin
        A_BusCtrl <= A_BUS_NOP;
        ACC_Ctrl <= ACC_NOP;
        ACC_ShiftIn <= '0';
        Add <= '0';
        AFR_Ctrl <= AFR_NOP;
        BitCountCtrl <= BitCount_NOP;
        CI <= '0';
        CIn <= '0';
        CIX <= '0';
        CarryIndCtrl <= CARRY_IND_NOP;

        <and so on...>
       
        case state is
            when s0    => NextState <= s0a; -- use this to IPL
            when s0a  => if DiskReady = '0' then -- wait for disk to go not ready
                                      NextState <= s0b;
                                else
                                      NextState <= s0a;
                                end if;
            when s0b => if DiskReady = '1' and ColdstartHold = '0' then -- wait for disk to go ready and
                                                                                                     -- coldstart code to be copied

            <and so on>
 

There are two processes to create this FSM:  The first just changes the state according to the NextState value on every clock cycle.  In the case of a loop, the state may not actually change.  See the second process...

The second process does all the work and it is not clocked.  It is just a huge collection of combinatorial logic.

Here I defined default outputs for 10 signals (although they aren't shown in the snippet of FSM code).  In the real world, there are 49 of these default outputs and 117 states.

I didn't say anything about the 'sensitivity list' that starts out as
Code: [Select]
process (state, FullEA, FetchOpnd, F, TAG, IA, CO, OFL, OVFLInd, COtemp, CSET, VSET,

This sensitivity list tells the simulator which signals to monitor to decide to actually run the process.  If there are no changes to any signals in the list, the simulator won't evaluate the process.

This list is meaningless to synthesis but the synthesizer will whine if an input signal to the process is undeclared.  But it's just whine and snivel, the output works with or without the list.
« Last Edit: June 16, 2017, 02:44:42 pm by rstofer »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf