This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > FPGA Technical Tutorials > FPGA-Based Prototyping Methodology > What can FPGA-based prototyping do for us? > What can’t FPGA-based prototyping do for us?

TABLE OF CONTENTS

Xilinx FPGA FPGA Forum

What can’t FPGA-based prototyping do for us?

FONT SIZE : AAA

We started this chapter with the aim of giving a balanced view of the benefits and limitations of FPGA-based prototyping, so it is only right that we should highlight here some weaknesses to balance against the previously stated strengths.

An FPGA-based prototype is not a simulator

First and foremost, an FPGA prototype is not an RTL simulator. If our aim is to write some RTL and then implement it in an FPGA as soon as possible in order to see if it works, then we should think again about what is being bypassed. A simulator has two basic components; think of them as the engine and the dashboard. The engine has the job of stimulating the model and recording the results. The dashboard allows us to examine those results. We might run the simulator in small increments and make adjustments via our dashboard, we might use some very sophisticated stimulus – but that’s pretty much what a simulator does. Can an FPGA-based prototype do the same thing? The answer is no. 

It is true that the FPGA is a much faster engine for running the RTL “model,” but when we add in the effort to setup that model (i.e., the main content of this book) then the speed benefit is soon swamped. On top of that, the dashboard part of the simulator offers complete control of the stimulus and visibility of the results. We shall consider ways to instrument an FPGA in order to gain some visibility into the design’s functionality, but even the most instrumented design offers only a fraction of the information that is readily available in an RTL simulator dashboard. The simulator is therefore a much better environment for repetitively writing and evaluating RTL code and so we should always wait until the simulation is mostly finished and the RTL is fairly mature before passing it over to the FPGA-based prototyping team. We consider this hand-over point in more detail in chapter 4. 

An FPGA-based prototype is not ESL

As we described in our introduction, electronic system-level (ESL) or algorithmic tools such as Synopsys’s Innovator or Synphony, allow designs to be entered in SystemC or to be built from a library of pre-defined models. We then simulate these designs in the same tools and explore their system-level behavior including running software and making hardware-software trade-offs at an early stage of the project. 

To use FPGA-based prototyping we need RTL, therefore it is not the best place to explore algorithms or architectures, which are not often expressed in RTL. The strength of FPGA-based prototyping for software is when the RTL is mature enough to allow the hardware platform to be built and then software can run in a more accurate and real-world environment. There are those who have blue-sky ideas and write a small amount of RTL for running in an FPGA for a feasibility study, as mentioned previously in section 2.3. This is a minor but important use of FPGA- based prototyping, but is not to be confused with running a system-level or algorithmic exploration of a whole SoC. 

Continuity is the key

Good engineers always choose the right tool for the job, but there should always be a way to hand over work-in-progress for others to continue. We should be able to pass designs from ESL simulations into FPGA-based prototypes with as little work as possible. Some ESL tools also have an implementation path to silicon using high- level synthesis (HLS), which generates RTL for inclusion in the overall SoC project. An FPGA-based prototype can take that RTL and run it on a board with cycle accuracy but once again, we should wait until the RTL is relatively stable, which will be after completion of the project’s hardware-software partitioning and architectural exploration phase. 

In chapter 13, we shall explore ways that FPGA-based prototypes can be linked into ESL and RTL simulations. The prototype can supplement those simulations but cannot really replace them and so we will focus in this book on what FPGA-based prototyping can do really well. 


  • XCR3384XL-12PQG208I

    Manufacturer:Xilinx

  • CPLD CoolRunner XPLA3 Family 9K Gates 384 Macro Cells 83MHz 0.35um Technology 3.3V 208-Pin PQFP
  • Product Categories: CPLDs (Complex Programmable Logic Devices)

    Lifecycle:Active Active

    RoHS:

  • XCR3384XL-12TQG144I

    Manufacturer:Xilinx

  • CPLD CoolRunner XPLA3 Family 9K Gates 384 Macro Cells 83MHz 0.35um Technology 3.3V 144-Pin TQFP
  • Product Categories: CPLDs

    Lifecycle:Active Active

    RoHS:

  • XC4VLX25-10FFG668CS2

    Manufacturer:Xilinx

  • FPGA Virtex-4 LX Family 24192 Cells 90nm Technology 1.2V 668-Pin FCBGA
  • Product Categories:

    Lifecycle:Obsolete -

    RoHS:

  • XC4VLX25-10SFG363C

    Manufacturer:Xilinx

  • FPGA Virtex-4 LX Family 24192 Cells 90nm Technology 1.2V 363-Pin FCBGA
  • Product Categories: Embedded - FPGAs (Field Programmable Gate Array)

    Lifecycle:Active Active

    RoHS:

  • XC3S200A-4FTG256I

    Manufacturer:Xilinx

  • FPGA Spartan-3A Family 200K Gates 4032 Cells 667MHz 90nm Technology 1.2V 256-Pin FTBGA
  • Product Categories: FPGAs

    Lifecycle:Active Active

    RoHS:

Need Help?

Support

If you have any questions about the product and related issues, Please contact us.