REGISTER | LOGIN
Breaking News
News & Analysis

Microsoft Eyes Expanding FPGA Role

Network chips not keeping pace
10/23/2014 02:30 PM EDT
12 comments
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 2   >   >>
nsiret
User Rank
Author
Re: Tools suck
nsiret   10/26/2014 1:11:14 PM
NO RATINGS
Cx is not yet widely known so not many people can share their experience. I'll publish more feedbacks and testimonies on our website in the next weeks. In fact @rick, we waited until Cx and ngDesign fit in quality, and were adapted to the ASIC/FPGA markets, before starting to promote it.

betajet
User Rank
Author
Re: Tools suck
betajet   10/25/2014 5:35:25 PM
NO RATINGS
Karl asked: So what is the reason why P&R should be in the loop?

1.  I mistrust Verilog simulators.  I'd rather run my design in the actual hardware or a development board.

2.  When I'm doing FPGA design, I'm usually designing hardware/software systems.  I like to use the software I'm designing to provide the execution environment for the FPGA I'm designing.  That way I don't need to write a separate "test bench", which would take a lot of work and become a project by itself for some of my FPGAs.  The software gives me the execution environment for free.

3.  I loathe writing "test benches".  I'd rather write device-level software that will be used in the actual product.

4.  I'm generally working alone.  It's a very bad idea for the designer of an FPGA to also write its test bench.  It's much better to have someone else do it to provide better coverage.

5.  I like to find out as early as possible if I'm going to have timing or routing problems.  I don't want to redesign logic I thought was OK and have to add pipeline stages at the last minute to fix problems.

6.  It's really hard to tell if logic synthesis is doing a good job.  Sure, you could look at automatically-generated schematics, but they're pretty much useless once your design become non-trivial.  So my approach is to synthesize often so I can see right away if the synthesized logic is using an unexpectedly large (or small) number of FPGA cells and other blocks.

7.  Logic synthesis generates lots of warnings, most of them false alarms.  (My experience here is with XST.)  I want to see those warnings as early as possible, because some of them may be important.  I use a "sed" script and "diff" to see if warnings have changed from previous synthesis runs.

KarlS01
User Rank
Author
Re: Tools suck
KarlS01   10/25/2014 5:02:13 PM
NO RATINGS
So what is the reason why P&R should be in the loop?  MMDV

betajet
User Rank
Author
Re: Tools suck
betajet   10/25/2014 2:39:46 PM
NO RATINGS
Karl wrote: The time consuming syntheis/P&R steps are before bit stream creation so seems to me that tools should focus on logic design/simulation so bit stream creation is after logic design and would not be in the design loop.

There's no reason in principle why synthesis and P&R should be slow.  There are many known ways to speed them up, but since the bitstream formats (and therefore the internal architectural details needed to do P&R) are secret nobody can develop the new software except the FPGA vendors.  They have no incentive to speed them up, because they have no competition for their tools and any extra time spent on FPGA software increases overhead.

Microprocessor and microcontroller manufacturers have discovered that you can minimize software development overhead using free-as-in-freedom software.  This lets those IC vendors concentrate on what they do well -- designing and manufacturing ICs -- leaving compilers and operating systems to people who can do it better and cheaper.  FPGA vendors haven't discovered this yet.

JMO/YMMV

KarlS01
User Rank
Author
Re: Tools suck
KarlS01   10/25/2014 10:34:23 AM
NO RATINGS
@betajet:  The time consuming syntheis/P&R steps are before bit stream creation so seems to me that tools should focus on logic design/simulation so bit stream creation is after logic design and would not be in the design loop. 

In my day we drew second level{simplified) logic diagrams designed logicdrew waveforms, and then did physical design(wired modules together).  Later he concept of synthesis was so appealing that everyone forgot to design first.  You know, it's like writing object code first then trying to figure out the source code.

There is a LI group "Agile IC Methodology" that may look at an iterative approach (Problem is very little activity).  I am suggesting  to use Boolean and assignment expressions for input and simulate the logic all in the C# Visual Studio IDE.  Application code classes can be included so the whole SoC is in one environment.  After it works logically, then do physical design once.

As a way to program an FPGA in C, parse the source and extract the control flow and generate micro code for data flow control.
  1. Use one embedded memory for control.
  2. a second for variable/pointer storage.
  3. and a third for a call stack.

Dual port memories are accessed in parallel and hold the outputs so no FF registers.  Add an ALU, compatator, and multiplier at a cost of about 200 LUTs to run C w/o  CPU.

External memory and FIFOs for transient data can be added as needed.

A model that runs if/else, loops, and function calls is running with simple examples.  Switch is not done yet.

 

 

rick merritt
User Rank
Author
Re: Tools suck
rick merritt   10/24/2014 2:38:57 PM
NO RATINGS
Anyone have experience to share using Cx? Or any other options?

betajet
User Rank
Author
Re: Tools suck
betajet   10/24/2014 1:30:54 PM
NO RATINGS
Rick wrote: for the FPGA world to capitalize on this kind of opportunity, they also have to develop better C language tools.

IMO the best thing for FPGA users would be for FPGA vendors to open up their bitstream formats so the free-as-in-freedom world can work its magic.  Users can complain all they like about VHDL and Verilog (in whichever order), but the reality is that V+V are the only game in town as long as FPGAs are closed to outside tools.  There are a number of companies adding new layers on top of VHDL and Verilog, which can be effective in some problem domains.  But they don't address the fundamental problems.

Languages and tools for FPGAs have been a problem for a long time.  For example, see this 2007 EE Times article: "FPGA tool bottleneck stalls HPC" [www.eetimes.com/document.asp?doc_id=1165139].

KarlS01
User Rank
Author
Re: Tools suck
KarlS01   10/24/2014 10:14:06 AM
NO RATINGS
It is not only the tools, the design process that places and routes nd optimizes every thing as if it is in the critical path.  The old rule of thumb that 15% of the paths account for 85% of the problems implies that micro-code control could be used.  The critical paths are mostly in the data flow anyway. 

When registers are added to increase fmax that means more cycles of latency and short simple logic parhs result.  This leads to using micro code for control.

Before super scalar RISC the CPU cycle was usually limited by the ALU and setting the condition code register.  The cycle control logic was sometimes a problem because of the complexity.

Several generations of IBM computers have used micro-code control, so it is tried and true.  Embedded memory with access time less than half the FPGA fmax period makes micro code an option and also makes function changes a matter of loading memory.

As far as C based tools,  the source code can be parsed and compiled directly to micro code so the execution time of the CPU/ISA is eliminated. 

The CPU/FPGA coprocessor is not the answer especially for general purpose.  Micro code for general purpose and custom DSP like algorithms can process data without putting raw data into mem ory and reading it back out for processing is a better approach.

There is also thr "memory wall" problem with shared memory.  GPUs are given independent blocks of data in local memory for parallel processing.  No shared memory.

Matthieu Wipliez
User Rank
Author
Re: Tools suck
Matthieu Wipliez   10/24/2014 4:06:22 AM
NO RATINGS
1 saves
Exactly, if we want FPGAs to succeed in that space, we have to remove another bottleneck: design time! And it's certainly not gonna happen if people are required to learn VHDL/Verilog...

Now C is a very good language in my opinion, it is just not suited for designing hardware for many reasons. So you can either cripple the language with vendor-specific extensions, pragmas, macros, and whatnot, still call it "C/C++", and hope nobody notices (this is what almost all High Level Synthesis vendors do).

Or you can create a new, elegant C-based language for hardware called Cx (more info at cx-lang.org), which is easy to use and allows any software or hardware engineer to design hardware. And we've built an IDE for that language, which helps you to verify the code as you're writing it. Examples of code are available on our Github repository.

rick merritt
User Rank
Author
Tools suck
rick merritt   10/23/2014 8:42:38 PM
NO RATINGS
BTW, for the FPGA world to capitalize on this kind of opportunity, they also have to develop better C language tools.

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