3

FPGA designs may contain RTL along with IP blocks. These IP blocks most likely shall be from the vendor of the FPGA. Examples of such IP blocks are instantiating dual clock FIFOs, floating point and fixed point maths blocks so we can precisely set the latency e.t.c, low level primitives e.g device I/O buffers e.t.c. Such things cannot be inferred from the RTL code.

It may happen that development is usually carried out on a certain platform e.g Altera Quartus targetting Cyclone V. However, it may be that the final design for whatever reason has to be implemented in a completely different device e.g Microsemi Igloo 2.

What is the proper method to create portable designs in this case?

In theory the proper method will require:

  1. A design where files exist for the two versions of IP blocks from the two vendors. A wrapper can be used to instantiate one of the two IP blocks during simulation and synthesis.

  2. The synthesis tool to determine which files to use and which to exclude as it synthesizes the design. Thus, Quartus shall only use files that are relevant to it and Libero only use those relevant to it.

  3. The simulation tool can be set to compile and simulate design using one of the two vendors' IP.

An assumption made here is IP blocks with similar functions exist from both vendors.

quantum231
  • 11,218
  • 24
  • 99
  • 192
  • You would be surprised how much can be inferred in HDL. For example: https://www.intel.com/content/www/us/en/programmable/quartushelp/14.1/mergedProjects/hdl/vhdl/vhdl_pro_ram_inferred.htm – user110971 Dec 04 '18 at 20:53
  • Your TAG says VHDL but your question does not mention this. Is this meant for VHDL only or also for Verilog? – Oldfart Dec 04 '18 at 20:59
  • 1
    You are right, I changed it to HDL so it applies to both VHDL and Verilog. – quantum231 Dec 04 '18 at 21:00
  • I agree that a lot can be inferred from VHDL. However, it may not be possible to infer everything we want in the design. – quantum231 Dec 04 '18 at 21:01
  • There is one important distinction to be made. If you are designing a general-purpose hardware with few restrictions on timing and speed, any RTL form is portable. But if you are using FPGA at the verge of its performance capabilities (DDRx or fast serial communication), these functions will heavily depend on dedicated hardware blocks, and different vendors will put various hints and specific constraints to make their compilers to infer these IP blocks efficiently. So the portability will obviously suffer. – Ale..chenski Dec 18 '18 at 20:59

1 Answers1

2

HDL portability, like portability of software, is an unattainable ideal. Every synthesizer has different strategies and different bugs, and vendor specific libraries will come into play. However, it's worth striving for, as actual portability is like actual immortality...you'll never get there, but closer is always better.

Synthesizers can infer latches, and they usually do it in the same way--triggered by a block with a sensitivity list. The primary rule of portable RTL is to write processes that trigger from common clocks. If it's clear from your RTL where the latches are, it should be clear to the synthesizer.

Combinatorial logic can be included in your latching processes to allow the synthesizer freedom to use it at input or output. Keep it outside the latching process if you want to make sure that a specific internal value is latched.

In general, don't partition combinatorial blocks if you don't have to...the compiler may find optimizations you won't. However, if there's a clear and obvious architectural choice (such as a highly optimized algorithm), you might wish to impose that structure implicitly. Further, unusually large blocks of combinatorial logic may send some synthesizers down a rabbit hole; repartitioning could give it guidance.

Cristobol Polychronopolis
  • 9,622
  • 9
  • 17