FPGA prototyping: Difference between revisions

Revision as of 16:44, 9 August 2018

Revision as of 19:10, 7 October 2018

Line 1:

{{Further|Field-programmable gate array}}{{multiple issues|

{{original research|date=September 2012}}

{{refimprove|date=September 2012}}

}}

'''FPGAField-programmable gate array prototyping''', (field-programmable gate array'''FPGA prototyping''') sometimes, also referred to as FPGA-based prototyping, [[Application-specific integrated circuit|ASIC]] prototyping, or [[System- on- a- chip|SoCsystem-on-chip]] (SoC) prototyping, is the method to [[prototype]] SoCsystem-on-chip and ASIC[[application-specific integrated circuit]] designdesigns on [[FPGAField-programmable gate array|FPGAs]] for hardware [[verification and validation|verification]] and early [[software development]].

Verification methods for [[computer hardware|hardware]] design as well as early [[software]] and [[firmware]] co-design have become mainstream. Prototyping SoC and ASIC designdesigns with one or more FPGAs and [[electronic design automation]] software has become a good method to do this.

==Why Prototypingprototyping is Importantimportant==

#Running a SoC design on FPGA prototype is a reliable way to ensure that it is functionally correct. This is compared to designers only relying on [[Electronic circuit simulation|software simulations]] to verify that their hardware design is sound. About a third of all current SoC designs are fault-free during first silicon pass, with nearly half of all re-spins caused by functional logic errors.<ref name ="soc">http://www.soccentral.com/results.asp?CatID=596&EntryID=30794</ref> A single prototyping platform can provide verification for hardware, firmware, and application software design functionality before the first silicon pass.<ref>{{Cite web|url=http://www.tayden.com/publications/Nanometer%20Prototyping.pdf|title=Nanometer prototyping|last=Rittman|first=Danny|date=2006-01-05|website=Tayden Design|archive-url=|archive-date=|dead-url=|access-date=2018-10-07}}</ref>

#[[Time to market|Time-to-Market]] (TTM) period is shrinkingreduced from FPGA prototyping: In today's technological driven society, new products are introduced rapidly, and failing to have a product ready at a given [[market window,]] can cost a company a considerable amount of [[revenue]].<ref name="reason">{{Cite web|url=http://www.design-reuse.com/articles/13550/fpga-prototyping-to-structured-asic-production-to-reduce-cost-risk-ttm.html|title=FPGA Prototyping to Structured ASIC Production to Reduce Cost, Risk & TTM|website=Design And Reuse|access-date=2018-10-07}}</ref> If a product is released too late of a market window, then the product could be [[Obsolescence|rendered useless]], costing the company its investment capital in the product. After the design process, FPGAs are ready for production, while [[Standard cell|standard cell ASICs]] take more than six months to reach production.<ref name = reason/>

#Development Cost: Development cost of 90-nm ASIC/SoC design tape-out is around $20 million, with a mask set costing over $1 million alone.<ref name= soc/> Development costs of 45-nm designs are expected to top $40 million. With increasing cost of mask sets, and the continuous decrease of IC size, minimizing the number of re-spins is vital to the development process.

==Design for Prototyping==

==Design-for-Prototyping<ref>{{cite web|url=http://www.newelectronics.co.uk/electronics-technology/prototyping-system-designs-on-fpgas/32395/ | title=Prototyping system designs on fpgas| publisher=New Electronics | date= 2011-03-22|accessdate= 2011-03-22}}</ref>==

'''Design for Prototyping'''<ref>{{cite web|url=http://www.newelectronics.co.uk/electronics-technology/prototyping-system-designs-on-fpgas/32395/|title=Prototyping System Designs on FPGAs|last=|first=|date=2011-03-22|website=|publisher=New Electronics|archive-url=|archive-date=|dead-url=|accessdate=2011-03-22}}</ref> ('''DFP''') refers to designing systems that are amenable to [[prototyping]]. Many of the obstacles facing development teams who adopt FPGA prototypes can be distilled down to three "laws":

* SoCs are larger than FPGAs

* SoCs are faster than FPGAs

* SoC designs are FPGA-hostile

Putting a SoC design into an FPGA prototype requires careful planning in order to accomplish prototyping goals with minimal effort. To ease the development of the prototype, best practices called, Design-for-Prototyping (or DFP), influences both the [[System on a chip#Design flow|SoC design]] style and the project procedures applied by design teams. Procedural recommendations include adding DFP conventions to RTL coding standards, employing a prototype compatible simulation environment, and instituting a system debug strategy jointly with the software team.

==Partitioning Issues==

Line 27 ⟶ 29:

===Balance FPGA Resources While Creating Design Partitions<ref name = Aldec/>===

When creating circuit partitions, engineers should first observe the available resources the FPGA offers, since the design will be placed onto the FPGA fabric The architecture of each FPGA is dependent on the manufacturer, but the main goal in design partitioning is to have an even balance of FPGA resource utilization. Various FPGA resources include Look-Up-Tables[[Lookup table|lookup tables]] (LUTs), [[D Flipflip-Flopsflops]], block [[Random-access memory|RAMs]], [[Digital signal processor|digital signal processors]] (DSPs), clock buffers, etc. Prior to balancing the design partitions, it is also valuable to the user to perform global logic optimization to remove any redundant or unused logic. A typical problem that arises with creating balanced partitions is that it may lead to timing or resource conflict if the cut is on many signal lines. To have a fully optimized partitioning strategy, the engineer must consider issues such as timing/power constraints and placement and routing while still maintaining a balanced partition amongst the FPGAs. Strictly focusing on a single issue during a partition may create several issues in another.

===Placing and Routing Partitions===

In order to achieve optimal place and routing for partitioned designs, the engineer must focus on FPGA pin count and inter-FPGA signals. After partitioning the design into separate FPGAs, the number of inter-FPGA signals must not to exceed the pin count on the FPGA.<ref>http://www.fpga-faq.com/FAQ_Pages/prototyping.pdf</ref> This is very difficult to avoid when circuit designs are immense, thus signals must utilize strategies such as time-division-multiplexing (TDM) which multiple signals can be transferred over a single line.<ref>http://www.inetdaemon.com/tutorials/telecom/t-carrier/time-division_multiplexing.shtml</ref> These multiple signals, called sub-channels, take turns being transferred over the line over a time slot. When the TDM ratio is high, the bus clock frequency has to be reduced to accommodate time slots for each sub-channel. By reducing the clock frequency the throughput of the system is hindered.<ref name=Aldec/>

===Timing Requirements<ref name= Aldec/>===

System designs usually encompass[[Clock more___domain thancrossing|encompass several clock domains]] with signals traversing separate domains.<ref name="Aldec" /> On-board [[Clock generator|clock oscillators]] and global clock lines usually mitigate these issues, but sometimes these resources may be limited or not fulfill all design requirements. Internal clocks should be implemented within FPGA devices since clock line and clock buffers connections are limited between FPGAs. Internal clocked designs which are partitioned across multiple FPGAs should replicate the clock generator within the FPGA, ensuring a low clock skew between inter-FPGA signals. In addition, any gated clock logic should be transformed to clock enables to reduce skew while operating at high clock frequencies.

Clock domains crossings should not be partitioned onto separate FPGAs. Signals passing through the crossing should be kept internal to a single FPGA, since the added delay time between FPGAs can cause problems in a different ___domain. It is also recommended that signals routed between FPGAs be clocked into registers.

Line 46 ⟶ 48:

Certus brings enhanced RTL-level visibility to FPGA-based debugging. It uses a highly efficient multi-stage concentrator as the basis for its observation network to reduce the number of LUTs required per signal to increase the number of signals that can be probed in a given space. The ability to view any combination of signals is unique to Certus and breaks through one of the most critical prototyping bottlenecks.<ref>{{cite web|url=http://www.tek.com/document/whitepaper/break-through-your-asic-prototyping-bottlenecks | title=Break Through Your ASIC Prototyping Bottlenecks| date= 2012-10-23|accessdate=2012-10-30}}</ref>

EXOSTIV uses large external storage and gigabit transceivers to extract deep traces from FPGA running at speed. The improvement lays in its ability to see large traces in time as a continuous stream or in bursts. This enables exploring extended debugging scenarios that can't be reached by traditional embedded instrumentation techniques. The solution claims saving both the FPGA I/O resources and the FPGA memory at the expense of gigabit transceivers, for an improvement of a factor of 100,000 and more on visibility.<ref>{{cite web|url=http://www.exostivlabs.com/why-exostiv/ | title=Why EXOSTIV?| date= 2015-10-14|accessdate=2015-11-25}}</ref>

==See also==