3
\$\begingroup\$

As much as IP tends to make things easier, I would like to find was to learn more about protocols and interfaces by doing everything myself (I understand the difficulty of the task, and I have resources to aid me as in professors and books). From what I understand though, it is near impossible (without reverse engineering) to use any hardware features on an FPGA without IP. I have poked around online and found next to nothing on the subject as people seem complacent on using IP. Essentially I'm trying to find more open source HDL resources as there is a lack of it at the moment.

Edit: to be more concise, is it possible to work around manufacturers' IP to program fpgas?

\$\endgroup\$
  • 4
    \$\begingroup\$ Do you have a question? \$\endgroup\$ – Eugene Sh. Feb 28 '17 at 15:45
  • \$\begingroup\$ Sorry, I may have forgot to explicitly ask one in my ramblings or deleted it by accident. I'll edit it and add it at the bottom \$\endgroup\$ – bit0fun Feb 28 '17 at 15:47
  • \$\begingroup\$ Apparently it wold be impossible to use the hard and the semi-hard (firm) IPs present on the FPGAs. \$\endgroup\$ – Eugene Sh. Feb 28 '17 at 15:51
  • \$\begingroup\$ It is unclear what OP is asking. One thing is "how to program FPGA" in the sense of "how to fuse-in interconnect information", another thing is how to use hardware primitives as ser-des and block RAMs, and third thing is whether one can make their own large macro blocks as PCIe or USB SIE. \$\endgroup\$ – Ale..chenski Feb 28 '17 at 20:50
  • \$\begingroup\$ My apologies on not clarifying. In your list, I'm more looking at the second and third item. \$\endgroup\$ – bit0fun Feb 28 '17 at 20:52
9
\$\begingroup\$

There may be a misunderstanding about what 'IP' means.

It's possible to program the fabric of an FPGA, that is the programmable LUTs and things, from the ground up. However, the bits and gates and tables in a Xilinx and an Altera are different, and are different from family to family, so it's like assembly coding a micro, they all have different low level machine code. I don't think anybody does that, at least, not commercially.

It's generally easier to use VHDL and write AND and OR and vector ADD assignments, and let the mapper turn that into LUT entries. I wouldn't call that 'IP', I'd call that compilation. When your VDHL that implies NAND gates and latches hits an Altera compiler, or a Xilinx compiler, as the fabric is different, the LUT tables will be programmed differently, but the low level function that you've described in the VHDL gets implemented the same.

If you want to use the specific hardware that Xilinx and Altera provide, like the dual port RAMs, or the 48x24 multiplier accumulator, then you need to use vendor-specific primitives. But, you have full control over how you connect to them. I still wouldn't call this IP.

If you want to use a packaged FFT, down-sampling FIR filter, or Viterbi decoder, or the embedded ARM, provided for or licensed by the vendor for their architecture, whether it's a free (with the tools) or paid-for license, that's IP.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Nitpick: Some synthesis tools can infer certain primitives. For instance, Xilinx tools will try to infer block RAMs when possible. \$\endgroup\$ – duskwuff -inactive- Feb 28 '17 at 20:11
  • \$\begingroup\$ @duskwuff, as Neil rightfully qualified, block of RAM is not really an IP. It is technically not much different from a D-flop. It is just mapping of HDL into available hardware primitives. All modern tools recognize standard HDL constructions and map them optimally to available hardware. You can build a classic D-flop out of NAND gates explicitly in Verilog and it will be mapped to general LUTs, but what would be the point? \$\endgroup\$ – Ale..chenski Feb 28 '17 at 20:40
  • \$\begingroup\$ I don't believe that the format of configuration files and the bit-mapping for how to configure FPGA interconnect martix was ever disclosed to public, so the statement of possibility to do the config on your own has a very-very low likelihood. \$\endgroup\$ – Ale..chenski Feb 28 '17 at 20:57
  • \$\begingroup\$ @AliChen: There were several papers I've read where the research group was doing non-standard things with FPGA that to this day I can't do with vendor supplied tools. One that I remember was reconfiguring an FPGA on the fly so that a single FPGA on the board functions like 4 or more FPGAs (run circuits that can't fit on the chip). Another was one that implemented an evolutionary algorithm so the system rewrites the circuit on the fly as it is being trained. So at least some people have done it though if I were to guess I'd say they'd have signed NDAs for the necessary info \$\endgroup\$ – slebetman Mar 1 '17 at 7:26
  • \$\begingroup\$ @slebetman First thing you mentioned is dynamic reconfiguration, which is supported by Xilinx tooling. Second thing was working with much older Xilinx FPGAs (XC6216) that had a documented bitstream format. \$\endgroup\$ – duskwuff -inactive- Mar 1 '17 at 7:47
9
\$\begingroup\$

It is certainly possible to program (using and HDL) and do useful tasks on FPGAs without using any third party IP blocks - if that is what you meant. However you do still have to use the vendors synthesis tools.

Synchronous state machines etc written in appropriately structured VHDL easily synthesize onto the LUTs and flip flops and multiplexers in an FPGA cell and you can have these designs connect with the IO pins using a constraints file (which will be in a proprietary format).

The synthesis tools will recognise certain idioms in VHDL and map onto other resources on the chip automatically e.g. using global clock signals where appropriate and even mapping a pipelined arithmetical construct onto a DSP where appropriate.

On the other hand there are some resources on the chip for which you have to use vendor supplied macros for the synthesis tools to be able to map onto hardware. One example is if using a PLL to generate clocks of different phases.

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ There are 3rd party synthesis tools available. Implementation on the other hand has to use the vendor's tools (unless dealing with lattice ice40 clifford.at/icestorm) \$\endgroup\$ – ks0ze Feb 28 '17 at 19:12
4
\$\begingroup\$

You certainly can implement any interface protocol by yourself. How do you think these IPs were designed in first place?

All you need is to carefully study particular specifications, and implement all state machines in accord to documentation. Then you need to verify all your HDL constructions with test benches covering all corner cases. Then you need to place and route your logic in such a way that it meets necessary timing for required clocks. The provider of FPGA will provide automatic tools to do this job, but very frequently the placement of logic blocks can be tricky to achieve satisfactory timing, and great sophistication might be required to formulate proper timing constraints for the tool.

You will also need to design external environment to operate your interface under realistic conditions, either virtually (again, system/bus models,) or have physically operating environment, to validate functionality of your interface.

Of course, you can do it all alone, and it will take you just a couple of years to accomplish all these tasks for any modern packet-serialized interface. Or you can use fruits of labor of several years of seasoned engineers who already did this design, and wrapped their work in a form of configurable IP. You will only need a couple of weeks to understand external workings of it, and embed the IP into your design. But the IP will cost you. It is now your choice.

For efforts along the self-designing path you can start with OpenCores.org.

| improve this answer | |
\$\endgroup\$
4
\$\begingroup\$

Depends on what kind of IP you mean. Some IP is soft IP and is really no different from a design in HDL as it lives on the LUTs on the FPGA. This stuff you can implement on your own, but it can be very complex. Hard IP, in the other hand, exists as dedicated silicon outside of the FPGA LUTs. Usually this will involve mixed signal components, such as in a PLL or a high speed serializer or deserializer. Sometimes hard IP is purely digital, as in the case of a hard CPU core, PCIe interface, or Ethernet MAC. If the hard IP has mixed signal components, then it is impossible to replace with HDL alone. If the core is purely digital, then it may be more complex than would be feasible to replace.

Now, there are common FPGA primitives such as multipliers, LUTs, and block RAM that can actually be inferred with a bit of pure hdl instead of requiring an explicit instantiation. For things like block RAM and DSP slices, this can be a very reasonable approach.

| improve this answer | |
\$\endgroup\$
2
\$\begingroup\$

If you want to make something like a FIFO, then yes, you can roll your own.

Now if you want to use specific hardware primitives like BRAM, Multipliers, PLLs etc, then you will need to use the tools, libraries, IP and interfaces provided by the manufacturer.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ That's what I had suspected. Shame really \$\endgroup\$ – bit0fun Feb 28 '17 at 15:52
  • 1
    \$\begingroup\$ Why is that a shame? You wanted to implement these yourself - go on. Just make sure not to buy an FPGA with the proprietary hard IPs \$\endgroup\$ – Eugene Sh. Feb 28 '17 at 15:53
  • 2
    \$\begingroup\$ I think you've misunderstood what the primitives are - they're like microcontroller peripherals. They're a section of hardware that performs that function and can be wired into the rest of it. But they aren't usually called "IP", that's larger sections of code that perform high level tasks. \$\endgroup\$ – pjc50 Feb 28 '17 at 16:06
  • 1
    \$\begingroup\$ (generally it's impossible to use an FPGA at all without the manufacturers toolchain! The only exception is the lattice semi device that's been reverse engineered) \$\endgroup\$ – pjc50 Feb 28 '17 at 16:08
  • 1
    \$\begingroup\$ @pjc50, I would say primitives are more similar to the built in flash/registers/fpu/alu/etc. on an microcontroller, where they are the basic building blocks of the device. The peripherals would be more analogous to hard ip cores such as PCIe/Transceivers. And, just like you don't have direct access to the data pins of USB on a uC you don't have direct access to multi-gigabit transceivers pins on an FPGA \$\endgroup\$ – ks0ze Feb 28 '17 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.