Transition from ASIC to FPGA

Hi All,

I've been working on ASICs for quite a while and now Iam required to move to FPGA domain. I'd be glad if someone could give some suggestions on what I should know, where to start how easy or difficulty is it going to be. I'd like to know if anyone has had such experience and would like to knopw their vies regarding the same.

Thanks.

Reply to
From_ASIC_2_FPGA
Loading thread data ...

ASIC_2_FPGA,

If you have been designing your ASIC by writing a HDL, like VHDL, or verilog, then there is little you need to change.

Generally, a hardware description language is intended to abstract the hardware to make the process easier.

However, just as a good ASIC engineer will optimize their code to synthesize efficiently into a standard cell library, so a good FPGA engineer will recognize that some constructs are not efficient for the FPGA resources, and try to modify the coding style (usually by guessing, changing, and checking -- or by asking others about specific coding styles, or reading the application notes, and examining code written by others).

Generally, since one stage of logic in the FPGA has a lot more functionality than one stage in an ASIC, people try to code such that they have few levels of logic between the registers so that they meet their speed requirements.

Constraints in synthesis is always a challenge, so when you get your code functionally correct, then apply as few as possible constraints to get your timing met. The more constraints you add that do not improve the timing, the worse the result will be in general. Take out any constraints that are not doing what was intended, and try another constraint.

If you were used to short delays, and very fast clocks in the ASIC, you will need to realize that due to the large size of the FPGA, the delays are generally all larger, and clock speed is less (550 MHz in the fastest V5 speed grade).

If you were designing custom ASIC, then conversion will be a real challenge, as hardly anyone uses the schematic flow for FPGA any longer (some of us are old enough to remember it).

Choicer of tools, features, options, etc. are all important. For example, if you had been using Synopsis DC, then redirecting it to synthesize FPGA logic is as simple as a click on a box.

Austin

Reply to
Austin Lesea

Hi Austin,

I've been using Verilog HDL, so I have no issues as far as RTL coding or Verification is concerned. I am more concerned about the rest of things like the synthesis,P&R. As you pointed out , application of constraints for synthesis, selecting the speed grade etc..

I'd like to in general if a beginner is asked to work on FPGA, how would he be guided..

Thanks. Thanks fr your response.

Reply to
From_ASIC_2_FPGA

Excellent advice from Austin Lesea. You may also enjoy 'The Art of High Performance FPGA Design' [

formatting link
] although this is not necessarily the best methodology if good enough is good enough. And you may draw some inspiration from this gallery:
formatting link
.

Jan Gray

Reply to
Jan Gray

Hi Buddy ,

Just this link its very useful.

formatting link

Advantages of FPGA-Based Accelerators vs. ASICs

DeCypher's use of FPGA based logic permits our design staff to avoid the risks and tradeoffs encountered in ASIC design. Since FPGAs can be rewired "on-the-fly" during in-field use, each algorithm is implemented as a separate "logic configuration file". Each algorithm can run in a single clock cycle (two in some case) at very high speed because each is separately optimized without on-chip constraints imposed by any other algorithm. We control the chip clockrate according to the performance obtainable with each algorithm, independent of any other algorithm. Similarly, the entire on-chip logical resources of the FPGA can be devoted to maximizing the packing density of a particular algorithm's processing cell independent of other algorithms'. FPGAs do not force a rigid predefined limit on the number of cells per chip.

Switching FPGA wiring between algorithms is brief, and is transparent to the user. Each algorithm's "logic cell" (also called a "processing element" or PE) is as small as possible, maximizing the opportunity for on-chip parallelism. And, new unanticipated algorithms may be easily added to DeCypher by distribution of new data files, as simply as a software update is installed on a conventional computer. In short, FPGAs permit the system designer to dodge the early design tradeoffs associated with fully custom chips. It is not necessary to predict (at significant risk of error) the course of the bioinformatics state-of-the-art early in the product life cycle.

With Regards,

Sparkle

Reply to
curiousjyo111

Hi ,

Really nice information provided by Austin.

Just check this link for more info.

formatting link

With Regards,

Sparkle

Reply to
curiousjyo111

Hi ASIC_2_FPGA,

With respect to coding style I have a few strong suggestions:

(apologies in advance for shouting)

- DON'T DO CLOCK GATING

- DON'T DO RIPPLE CLOCKS

- REGISTERS ARE FREE

- CLOCK-ENABLES ARE FREE

With Altera's Quartus II toolchain you'll be happy to see that it fully supports SDC constraints, floorplanning, ECO without doing a full P&R, full TCL scripting, either from command line or GUI, incremental compilation and other comfort-enhancing features.

The Xilinx toolchain does pretty much all of the above, except that it doesn't support SDC but uses its own proprietary format for setting timing constraints, and as far as I know does not support scripting.

No clock tree synthesis is required for FPGA's. Everything's pre-buffered.

Both toolchains are available on Windows, Linux and Solaris.

Today's FPGA's are pretty good in terms of performance (but never good enough), so normally you start coding for the slowest speed grade, and only once you find out that after careful tweaking of your logic and placement you cannot meet timing you will switch to a faster speed grade.

Also, you will find that you will not need to simulate as much as you used to do. Run into a bug? Find it through JTAG, fix it, shoot a new bitstream into the device, and try again.

Hope this helps,

Ben

Reply to
Ben Twijnstra

The Xilinx EDK supports TCL scripts. EDK has multiple hooks into its implementation flow where it allows you to specify a TCL routine to run. It also allows the TCL routine to query EDK about the design. You can use it for design rule checks on parameter settings, you can use it to create a core level constraint file, etc.

We have used it to generate custom constraint files based on how the parameters are set at the EDK level.

Personally, I find FPGAs much less stressful than ASICs. My first ASIC was an FFT optimized vector processor chip. After we had handed the design off to the vendor, but before we had the parts back, they let it slip that it was the biggest part they had made to date. I did not sleep well for a while after that.

You still want to spend lots of time with simulations, but I focus my simulations on unit testing the cores I use with bus functional models. I have some simulations that are running code on the PowerPC, but when it comes time to test things running with Linux on the PowerPC, it is MUCH quicker to just try it on real hardware.

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

Hi Jan, Thanks for the reply, the link was very informative.

Hi Ben, Hi John

Thank you for responses..

I have a quiestion, when we design the architecture or do RTL coding, we think of the number of gates(in case of ASIC) the design would constitute and I suppose LUT is a basic building block of FPGA, is it as important in case of FPGA to know the number of LUT levels. What effect would it have if Iam not sure how many LUTs of an FPGA will be required, when I design something.

Thanks.

Reply to
From_ASIC_2_FPGA

All,

Thanks to those who made a nice comment about my post.

(You will note I did not say anything about X vs. A.)

I feel that the question is vendor agnostic: right now the question is about what is different?, not "who should I be using?" It doesn't help at all to recite a litany of features of a tool that they have never even seen, for a design flow that they have never used!

So, to answer more questions ---

"I am more concerned about the rest of things like the synthesis,P&R.

As you pointed out , application of constraints for synthesis, selecting the speed grade etc.."

Synthesis is done by the synthesis tools. As has been often posted here, the quality of the synthesis depends on many things, and you will have to match your style, to your favorite tool (or if you do not have a favorite, pick a few, and try them). I feel that since coding style is often unique to each coder/application, the results are also highly variable.

Place and route is done by the FPGA vendor's tool, after synthesis, and the results are such that you don't get to play here much at all.

For everyone, there are absolute constraints, and relative constrains, which will get you in more trouble than they are worth (generally). Often a designer will have no placement constrains, nor pin constraints, and see what happens. If they don't like the result, they may start first by locating the IO bus pins in a preferred logical way, and move on from there (you quickly realize IO comes in 'banks', and that keeping IO in banks that are adjacent for the same function is a smart move).

WARNING: (Potential) Marketing Message*: If you are doing very high end work, then the ONLY tool out there is PlanAhead, which Xilinx owns now, for FPGA. It allows general area constraints, and nailing down inside IO locations of your function blocks and your IO pin locations outside. :End of WARNING!

*Message does contain truthful statements about capabilities, however.

Constraints is all something that will be specific to your synthesis tool, and how well you can speak its constraint language. Unfortunately, there is little standardization here (everyone likes to be just a tiny bit different).

Speed grade is easy: choose the slowest, work as hard as you can, and only go to the next faster grade if there is no way to make your design meet timing. Speed grades cost more money, so this is a naturally regulating design issue.

And, we all have to begin somewhere. Xilinx does offer classes, both introductory and advanced, across a wide range of topics.

formatting link

I am told by one of my compatriots that his classes that he teaches at a local university are often attended by ex-ASIC designers, being interested in getting educated about use of FPGAs.

I am sure that you have universities and colleges in your area that offer such classes. The key is that you need to be sure that they are using a FPGA for their lab part of the course, and the course is current to the technology.

FPGA vendors (usually) have free software packages that support the smaller devices, and perhaps have a few less features, but are excellent learning platforms.

WARNING! (Potential) Marketing Message: For example, Spartan 3 and 3E have sold tens of thousands of student boards to university programs around the world, making them one of the most successful teaching platforms, ever. The cost is on par with most college textbooks.

formatting link
:End of WARNING!

Austin

Reply to
Austin Lesea

Hi Austin Thanks for providing your views. I'd be glad if I could get some views on my question related to the LUT

Thanks.

Reply to
From_ASIC_2_FPGA

Thanks for the warning, but... isn't Synplify Premier addressing the same market? That product's roots in their Amplify offering started years before PlanAhead was available.

Is PlanAhead in a different market than Synplify Premier?

- John_H

Reply to
John_H

Basically, this is a trial-and-error approach where your knowledge about LUT usage increases as you synthesize and fit little tidbits of code. If you're designing for low-cost FPGAs the rule is fairly simply that you have a netlist that consists of 4-input, 1-output functions that contains some boolean equation, optionally followed by a flipflop. The average ratio between LUT delay and wire delay on average in modern FPGAs is about 25/75 for a sizeable design - and that's just the only thing that's certain in FPGA design.

Thus, numbers of 4 and 16 are important in FPGA-land - they determine whether you're going through 1, 2 or 3 logic levels in terms of combinatorial logic.

Best regards,

Ben

Reply to
Ben Twijnstra

Hello everyone,

Please excuse me, but I'd happy to see response related to the doubt/ queries I have. Iam lost in this discussion of PlanAhead..Synplify..Marketing etc.

Thanks in advance, for your co-operation.

Reply to
From_ASIC_2_FPGA

Thanks for the reply Ben, Could you please tell me what you mean,when you say "this is a trial-and-error approach where your knowledge about LUT usage increases as you synthesize and fit little tidbits of code"

Reply to
From_ASIC_2_FPGA

That sounds like The Knowledge. To quote the same piece,

[
formatting link
]

The Knowledge

If you want to be a cab driver in London, you first must earn The Knowledge. Students study for many months to memorize the thousands of little streets in London and learn the best routes from place to place. And they go out every day on scooters to scout around and validate their book learning.

Similarly, if you want to be a great FPGA-optimized core designer, you have to acquire The (Device) Knowledge. You have to know what the LUTs, registers, slices, CLBs, block RAMs, DLLs, etc. can and can't do. You have to learn exactly how much local, intermediate, and long routing is available per bit height of the logic in your datapath and how wide the input and output buses to the block RAMs are. You have to learn about carry chain tricks, clock inversions, GSR nets, "bonus" CLB and routing resources, TBUFs, and so forth.

You also need to know the limitations of the tools. What device features PAR can and can't utilize. How to make PAR obey your placement and timing constraints, and what things it can't handle. And how to "push on the rope" of your synthesis tools to make them emit what you already know you want.

The Knowledge isn't in any book, alas. Yes, you can read the 'street maps', e.g. the datasheets and app notes, but that only goes so far. You have to get out on your 'scooter' and explore, e.g. crank up your tools and design some test circuits, and then open up the timing analyzer and the FPGA editor and pour over what came out, what the latencies (logic and routing) tend to be, etc.

--
So you have to pick up the tools and try some things.  (The first thing I do 
with every new device and tool release is build a quick verilog counter 
 Click to see the full signature
Reply to
Jan Gray

Thanks to all for their time and valuable suggestions

Reply to
From_ASIC_2_FPGA

What people are suggesting is simply "try it". The tools you need are only a free download away. Implementing tiny toy examples and seeing how small RTL changes affects the synthesized result's resource usage and fMAX, together careful reading of the device user guide, is really the best way to build up the needed intuition. It will give you a much better understanding of FPGA than any canned beginner's guide would ever be able to.

Regards and good luck, Tommy

Reply to
Tommy Thorn

Gated clock , clock muxes and ripple clocks are no longer a problem for modern synthesis tools. Precision and Synplicity can easily convert these structures to FPGA efficient logic (gate signal reconnected to FF-EN input). If fact ASIC prototying is such a big market (Dataquest 2005 study stated that 30% of all ASICs are prototyped on FPGA) that I suspect support will continue to increase. For example, Precision not only support gates clocks and SDC constraining you can also use Synopsys Designware components (not all) in your design without having any RTL for it.

Hans

formatting link

Reply to
HT-Lab

This is what I refer to as "wax on, wax off"

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

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.