Reverse engineering the manufacturer's programming sequence of an FPGA

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.