Author Topic: FPGA ?  (Read 9650 times)

0 Members and 1 Guest are viewing this topic.

Online Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: FPGA ?
« Reply #50 on: April 18, 2018, 05:15:10 am »
That reply from hamster_nz sums it up nicely. You want to work up to the final design in incremental steps so you have something that works most of the time and when it stops working you can have a easier time pinpointing what broke.

I wouldn't say running it using CUDA or similar GPU acceleration would help translating the design to a FPGA since the two work fairly differently. And you can get pretty quick compile times inside of HDL simulators. They also do incremental compiles so a small change in one module would just take a second to compile. Tho the simulation part might take a bit of time if you wanted to run the FPGA for long enough to actually get audio to listen to out of it since it. Usualy you only run the FPGA for a few 1000 clock cycles jsut to test the functionality of the design and that's pretty much instant on a modern PC.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA ?
« Reply #51 on: April 18, 2018, 12:01:22 pm »
Another good thing to try is High Level Synthesis (like Vivado HLS). It allows you to develop your code in C/C++ and then run it through the tool so it would generate HDL code for the IP core that performs your algorithm. For data processing algorithms this is not a bad approach, but you've got to know how to wire up that core (typically data processing algorithms use AXI Stream interface to accept data points one at a time).

Offline JanJansenTopic starter

  • Frequent Contributor
  • **
  • Posts: 380
  • Country: nl
Re: FPGA ?
« Reply #52 on: April 18, 2018, 02:02:26 pm »
Another good thing to try is High Level Synthesis (like Vivado HLS). It allows you to develop your code in C/C++ and then run it through the tool so it would generate HDL code for the IP core that performs your algorithm. For data processing algorithms this is not a bad approach, but you've got to know how to wire up that core (typically data processing algorithms use AXI Stream interface to accept data points one at a time).

A C code to FPGA code converter application ?, how nice, its all i need, how good is it ?
aliexpress parachute
 

Offline JanJansenTopic starter

  • Frequent Contributor
  • **
  • Posts: 380
  • Country: nl
Re: FPGA ?
« Reply #53 on: April 18, 2018, 02:06:03 pm »
I dont understand how can you make a sinewave with gates ?

In a software way...

Code: [Select]
static unsigned int index; // Where we are in the lookup table, * 2^22
static unsigned int dds_step;   // How far we advance the index each cycle
static short int lookup_table[1024] = {... sine values ... };

void update_sine(void)
{
   dac_set_output(lookup_table[index>>22]);
   index += dds_step;
}

Converted to H/W that looks like a 32-bit accumulator to hold "index", a 1024 entry 16-bit memory block to hold "lookup_table", and an adder to add 'dds_step' to 'index'.

By changing the value of 'dds_step' you change how quickly you advance through the lookup table, and hence the frequency of the sine wave coming out of the DAC.

This code looks like normal microcontroller C code.
I made a few synthesizers already.
aliexpress parachute
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: FPGA ?
« Reply #54 on: April 18, 2018, 02:10:34 pm »
To use look-up tables properly for signal synthesis, you should use fractional indices and some kind of interpolation (at least cubic in my experience) to get decent audio quality.

Note that there are other ways of generatiing basic waveforms such as sine/triangle that are iterative, don't need look-up tables and will get you less distortion (unless of course you can use huge look-up tables).
 

Offline daveshah

  • Supporter
  • ****
  • Posts: 356
  • Country: at
    • Projects
Re: FPGA ?
« Reply #55 on: April 18, 2018, 02:48:40 pm »
At some point going into FPGA development it may be worth looking into formal verification, which once you get your ahead around can be  easier and quicker (and of course safer) than simulation. Yosys is free and open source and the SymbiYosys tool makes the formal verification flow very easy. The only caveat is currently only Verilog is supported (without the third party Verific frontend).

Dan Gisselquist of ZipCPU has an excellent blog where he introduces formal verification using Yosys with real world examples: http://zipcpu.com
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA ?
« Reply #56 on: April 18, 2018, 03:40:47 pm »
A C code to FPGA code converter application ?, how nice, its all i need, how good is it ?
Check out Vivado HLS. There are few restrictions on the code - most important are no dynamic memory allocations and no I/O (both file IO and console) are allowed, but other than that just about any code is good enough. Google for "UG902 - Vivado Design Suite User Guide: High-Level Synthesis" if you want to know more (be prepared for a long read!).

Online Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: FPGA ?
« Reply #57 on: April 18, 2018, 04:19:22 pm »
Yeah there are some tools that allows you to covert C code into running on a FPGA, but this does NOT remove the need to know a HDL language and general FPGA workflows.

The C code that you put in has to be written with the FPGA in mind and needs some knowledge on how the whole thing works. Otherwise you can end up filling a giant FPGA completely full using just a few lines of code or have code that runs a lot slower than it should.

What these C code converter tools are useful for is when the FPGA needs to be programed to do a very complex task as they essentially provide an extra layer of abstraction. Very useful for things like hardware video decoders/encoders that are already complicated to understand in C code. But if you are able to break your problem down into a bunch of D flipflops and computational logic then its easier and more efficient to simply express it in the actual HDL language.

Lucky for you that a lot of audio DSP operations are mostly just putting the samples trough some math equations in a certain order and this is easy to convert into HDL code. That is provided you can get the math to work with fixed point numbers since floating point is not very FPGA friendly due to the complex logic needed to do math with it. Since these things are often used for DSP work means that a lot of FPGA vendors might have some ready to go modules of common DSP functions. These might be things like FIR and IIR filters, NCO signal generators, upsamplers/downsamplers, FFT etc...

Also FPGAs are not always better than CPUs. They are a bit like GPUs in a PC where they are great at doing a simple(but possibly also very long) task over and over on a lot of data. While they are not very good at complex tasks that involve making a lot of decisions and taking different routes trough the procedure all the time. As an example a FPGA can implement a SD card interface pretty nicely where you can give it commands like "Write 0x55 0x45 0x45... to sector 465", it has to do the same thing every time to execute that. But if you wanted to do something like "Append decimal 1234 onto file log.csv" then you are going to have a hell of a time teaching a FPGA to do it and use a lot of resources(Both inside the chip and in hours of your work). Such a task involves first finding the FAT32 filesystem on the card, then navigating to the directory, then finding the log.csv in a file table, allocating a new sector to that file, writing the data to that sector, updating the file table entry and finally closing the file. This is very easy to do with a CPU however so in such a case you would be best off to include one in the design where the "Write sector" functionality would be left in the FPGA while the filesystem is handled by the CPU that gives commands to the FPGA on what sectors to read and write. In this case you use a external microcontroler that's connected to the FPGA over some sort of bus or you build a softcore CPU inside the FPGA(Some FPGAs even have built in CPUs) and run compiled C code on that.

One neat trick when using an external MCU/CPU with a FPGA is to use a MCU that has support for external SRAM memory (A lot of decent ARM MCUs have this). If you connect these external memory pins to the FPGA then you can have the FPGA act like its a SRAM chip, except that these memory locations are actually reading/writing to hardware registers inside the FPGA. As a result you can build peripherals inside the FPGA and memory map them into the MCU so that they are used just like the built in peripherals. This makes the FPGA sort of like a south bridge in a PC or a sort of coprocessor.
« Last Edit: April 18, 2018, 04:21:14 pm by Berni »
 
The following users thanked this post: JanJansen

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA ?
« Reply #58 on: April 18, 2018, 05:31:12 pm »
The C code that you put in has to be written with the FPGA in mind and needs some knowledge on how the whole thing works. Otherwise you can end up filling a giant FPGA completely full using just a few lines of code or have code that runs a lot slower than it should.
It's the same thing with a regular C code. Unless you know what you're doing, you can write horrendously inefficient C code just as well. Which is why I've referenced a user guide for HLS which describes how to write C code to achieve best results. One thing I like about HLS is that it allows to effortlessly pipeline your processing to increase throughput at expense of more resources used. All it takes is a single #pragma directive in the code.

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: FPGA ?
« Reply #59 on: April 18, 2018, 06:18:13 pm »
Why not just write the HDL directly in the first place? Trying to shoehorn C in there seems like an extra step and a waste of time.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA ?
« Reply #60 on: April 18, 2018, 06:34:15 pm »
Why not just write the HDL directly in the first place? Trying to shoehorn C in there seems like an extra step and a waste of time.
Because it's much easier to develop your data-processing algorithm in C as you can use regular debugger to debug the code to confirm it's doing what it needs to do using regular C toolset and a testbench written in C. And then you can do a co-simulation of generated HDL code against your C code testbench to confirm that generated code works just as well. Just try it out and you will see the benefits yourself! There is nothing to "shoehorn" and there are no extra steps. I take C programming over HDL code any day!

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: FPGA ?
« Reply #61 on: April 18, 2018, 07:36:18 pm »
Why not just write the HDL directly in the first place? Trying to shoehorn C in there seems like an extra step and a waste of time.
Because it's much easier to develop your data-processing algorithm in C as you can use regular debugger to debug the code to confirm it's doing what it needs to do using regular C toolset and a testbench written in C.

Matlab is way better tool than plain C toolset, especially if your HDL project is signal processing.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA ?
« Reply #62 on: April 18, 2018, 07:38:24 pm »
Matlab is way better tool than plain C toolset, especially if your HDL project is signal processing.
As long as you already know it and got the money to buy a license. While learning C is free and much more useful in the long run ;)

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: FPGA ?
« Reply #63 on: April 18, 2018, 09:09:14 pm »
Oh, I remembered that there was a video of my Music Box project on YouTube. It doesn't have MIDI, but it does play a tune (skip towards the end).



All of the HDL is here:

http://hamsterworks.co.nz/mediawiki/index.php/Synth_Envelope

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf