REGISTER | LOGIN
Breaking News
Slideshow

10 Ways To Program Your FPGA

6/10/2016 09:47 AM EDT
21 comments
Page 1 / 10 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
KarlS01
User Rank
Author
We still need to do logic design and fully interconnect blocks
KarlS01   9/8/2016 4:39:18 PM
NO RATINGS
"As with HDL, HLS has limitations when using C-based approaches, just like with traditional HDL you have to work with a subset of the language"

It probably is not  possible to go directly from a program application to hardware at the RTL level because software compilers and operating systems do not have hardware counterparts.

Also the way that data is processed is totally different.  Data flows in hardware, but software has to move the data to where it can be processed.

The control flow graph or syntax tree or what ever shows the events/conditions(Boolean logic) that control the data processing steps in the software can be used to design the HW data-flow and control logic that takes the same inputs and generates the same results.

Similarly the inputs used for calls to produce the return value of calls can be used to define HW.

Trying to map SW to HW is foolhardy else it would have been done after all these years.

Extract the Boolean logic of the SW then design HW.  Programmers say the syntax tree is immutable therefore immutable hardware can be designed to the same Boolean logic.

 

ckachris
User Rank
Author
OpenCL
ckachris   6/30/2016 9:18:55 AM
NO RATINGS
Great article!

Since OpenCL is currently supported by the major FPGA vendors (xilinx and altera), I believe that this will be the mainstream language to program FPGA in the near future.  

 

Loutvi
User Rank
Rookie
Clash : Haskell to HDL
Loutvi   6/23/2016 7:28:43 AM
NO RATINGS
1 saves
Another interesting approach  leveraging functional language Haskell is the Clash tool from the University of Twente (Netherlands) which is recently trying to get its way to industry through the newly created spin-off called QBay Logic:

http://www.clash-lang.org/
http://qbaylogic.com/

"CλaSH (pronounced 'clash') is a functional hardware description language that borrows both its syntax and semantics from the functional programming language Haskell. It provides a familiar structural design approach to both combinational and synchronous sequential circuits. The CλaSH compiler transforms these high-level descriptions to low-level synthesizable VHDL, Verilog, or SystemVerilog."

 

fasdf
User Rank
Author
link to full example
fasdf   6/16/2016 11:04:14 AM
NO RATINGS
Adam, can you add a link to the full MyHDL example in the article?

http://myhdl.org/docs/examples/stopwatch/

 

KarlS01
User Rank
Author
Re: New languages
KarlS01   6/15/2016 10:55:38 AM
NO RATINGS
@Olaf:  I think we are on the same page design wise, but I don't like dealing with a lot of tools and languages. 

Embedded systems are usually C based and FPGA synthesis is HDL based so I choose a C based OOP and may run C code and the FPGA model together..

HDLs have blocks/modules. C is not modular(has no nmodules/classes.  OOP is modular(classes).

OOP has encapsulation of data and methods to maniipulate the data.

OOP has polymorphism so  derived classes can extend/modify functionality.

So what is needed to model an FPGA?  inputs/outputs, registers, memory, LUTs.

OOP has classes with get/set accessors for properties(input/output), types(registers), Arrays(memory), assignments, Boolean and arithmetic expressions(LUTs).

The similarities make it easy to do the same functions as an FPGA, the bonus is a free compiler/debugger/IDE.  And the compiler actually connects the blocks.

After the function is correct reformat the source text into Verilog for synthesis.

Kevin Neilson
User Rank
Author
Re: FPGA programming insight
Kevin Neilson   6/14/2016 5:34:35 PM
NO RATINGS
I see no fundamental reason why HDL sims should be slower than (cycle-accurate) C sims, especially if you are using 2-level Systemverilog data types.  The HLS vendors will tell you that their C models are much faster.  Here's why:

1.  They take the high-level model and generate extremely verbose HDL.

2.  The HDL in turn instantiates primitive models (e.g., UNISIMS), which are extremely verbose and slow and were designed to check static timing, not high-level functionality.

3.  They put all of this in their proprietary and not-so-good HDL simulator.

4.  The HDL sim is 100x slower.  Thus, the mantra, "HDL sims are slow!" 

5.  They put yet more resources are put into making C models, and none into improving the HDL flow.

Olof Kindgren
User Rank
Author
New languages
Olof Kindgren   6/14/2016 4:46:36 PM
NO RATINGS
I think it's very exciting to see a lot of new languages, but I'm not hoping for a single-language future, but for domain-specific languages, just as we see a whole flora of languages for different purposes on the software side. When I'm doing block-level design, I don't want to use a text-based language at all. I always draw blocks on paper anyway before implementing, so why not do this directly on the computer instead. This is where I'm hoping that IP-XACT or something similiar will have a stronger presence in the future, as it's supposed to be a vendor-neutral standard. If I'm doing algorithm designs, it could be great to have a HLS that allows me to quickly describe and simulate my code. The caveat here is that the HLS tools pushed by the FPGA vendors are vendor-specific, which means that once you've started using one vendor's tool, it will be expensive to switch. For control logic, I don't have any problems doing the design in VHDL or (System)verilog. SV is more advanced right now, but a bit big and clumsy. VHDL is gaining nice features in the new language revisions, but tools are slow to adopt. I've also used Migen, which is another Python-based language that is quite nice in some regards


The big problem currently with code generators is that they use verilog or VHDL as an intermediate format. Those languages were never designed for that, and the result is often a single file with tens of thousands of lines, which can be absolutely horrible if you need to debug the generated code. Once that happens, the quicker design phase can easiliy be outweighted by a more complicated debug phase, as the generated code often isn't meant to be read
.

A potential remedy for this would be to mimic what LLVM is doing, and define a intermediate representation language that is actually designed to be an intermediate representation. All new languages could then use this as an output format, and hopefully we can have code bases with mixed languages. This could also output verilog and VHDL to work with existing tools.

KarlS01
User Rank
Author
Re: FPGA programming insight
KarlS01   6/14/2016 9:42:33 AM
NO RATINGS
Yes, indeed FPGA or not designs evolve and there are multiple iteratons cost, performance, power, etc.

HDL simulation is tedious and time consuming, so languages have been created that focus on the "high level".   Classes/objects are very similar to the resources of an FPGA.

The FPGA resources are very simple.  Even the 6 input LUT is just a 64 bit ROM.  registers are one or more FFs, and IO pins are well, IO pins.

An OOP compiler ties things together quickly with incremental compile and interactive debug.

FPGA simulation can be done after synthesis, P & R, netlist generation, model build.

Does an yone want to talk about logic simulation in an OOP environment?

PS do you want to run it on the same platform with C code?

 

 

tb100
User Rank
Author
Re: FPGA programming insight
tb100   6/13/2016 7:41:29 PM
The Berkeley RISC-V CPU project was designed using Chisel. It supposedly allowed them to design a very complex 64 bit superscaler, out-of-order execution CPU core with very few lines of code, and made it easy to try multiple iterations of the design to quickly see what was most efficient.

KarlS01
User Rank
Author
High Level Languages, FPGA, and OOP
KarlS01   6/12/2016 2:16:52 PM
NO RATINGS
@Adam: "What interests me are two things, how long will it take befroe HLS offers performance equivelent to the best HDL coded approach and how do we verify HLS. That I can see as being very interesting. "
  1. The"best HDL handcoded approach" is vague/subjective and always somebody "knows"  they can do it better.  On top of that, the parameter priorities are not defined such as resouirces, cycles, fmax, response time.
  2. Synthesis takes HDL as input so who/how it was generated should not affect verification.
  3. So HDL is required to program  an FPGA.

We are getting back to Hardware DEFINITION Language.  If HDL were design languages HLS would not exist.

The question becomes "How to design" vs "program".  Logic design is the process of defining dataflow and control/Boolean logic.  The physical resources of an FPGA are pins, registers, memory, LUTS, and hard IP blocks.

The OOP capability needed is to construct logic/data blocks, easily connect the blocks, compile a model, debug that mode, and generate HDL.

 

 

Page 1 / 3   >   >>
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed