FPGA Test Equipment

Question

I mostly have desktop software development background. Trying to learn hardware design.

Question: The question is mostly for developers (mostly individual contractors) who develop for any expensive equipments.

So suppose I am developing some firmware in VHDL/verilog for some client. Do you always need the "specified" hardware to test it? (That "specific", so if I have altera board, what about development for xilinx?) I mean usually for small projects with microcontrollers, you can buy them since they are not that expensive, but when you develop for fpgas, how does the development and testing stages work? I suppose the delay propagations and other things different from each one board or chip to another, which need to be accounted in your code.

Can someone please share how the procedure, especially when they dont have the equipment for which its going to be developed? Do you buy it or client provides it, or is it small changes just on the IDE level in software, which you can change from datasheets?

p.s: Not related but I am thinking of buying Altera DE1-SoC board. So if you have any better suggestions than this board, please let me know too. (Non Academic, sub $500, intermediate board, so i can grow and still use it)

Answer 1

Generally FPGA designs start out similar to ASIC designs - it's all in the simulator. You can get far better visibility for debugging in a simulator than you can ever get in hardware. You do need to build testbenches and functional models, though, which takes time. For complex implementations it's a requirement as you will never work out all the bugs by just testing on the hardware. Once the design is thoroughly debugged in the simulator, then you can drop it onto the board. Note that for very large designs on very large FPGAs, the synthesis and place and route can take a very long time. One design I worked on a year ago or so took up about 40% of a Virtex 6 HXT 565 and took about 7 hours to complete place and route. This is not something you want to have to do on a regular basis for small changes.

Generally any delays on the board are either too small (far less than a clock period) and can be ignored or they are unknowns that will need to be tuned and compensated for with some sort of active training routine as they will vary even within one batch of boards.

The FPGAs themselves are extensively tested (hence the very high cost) so that the delay variations are known to be within specified limits, and your design should not be dependent on the delay of an individual to-spec chip. If it is, then you have bigger problems and you need to either remove the dependence or find a way to compensate for it. For example, see the CERN time to digital core - it is highly dependent on routing and has its own calibration routine to characterize the delays that is run on a regular basis to correct for long-term and temperature-dependent variations.

It is possible to test code for one FPGA on a different FPGA. If the code does not interact with the outside world, then you can generally put it on any FPGA you wish. If you write vendor-independent code (avoid core generators for RAMs and ROMs, instead infer everything in pure HDL), then it is even possible to test code intended for production on a Xilinx FPGA on an Altera FPGA. Note that this does not work if you need to use FPGA specific features such as high speed transceivers.

If you are designing to interact with hardware, then you're going to need the hardware and the client should provide it unless it is also your job to build it. It will also be necessary to have some hardware debugging tools such as a mixed signal oscilloscope and logic analyser so you can check hardware interfaces to make sure they're doing what you intend.

Answer 2

It depends on the kind of work you're doing. Some FPGA designs have massive amounts of effor in the functional logic, none of which really depends very much on critical timing or device-specific hardware. For that you'd usually use a simulator and develop/test things on a PC without going near any hardware.

As a basic rule with FPGAs, if you design properly with some basic concepts about clocking, etc, and you provide proper timing constraints to the tools, then the design will work when you load it into the hardware.

Other designs have much more difficult timing or are close enough to the limits of what the FPGAs are capable of doing to need a much more device-dependent style of work, which might involve development boards for a specific FPGA, or just getting a prototype built and working with that.

In general FPGA compilations are hugely, hugely slower than software compilation, so any general form of 'burn and crash' development will driving you completely insane fairly quickly, and you should do as little of it as possible.

For all but the most trivial designs, every minute you put into functional simulation and correctly specifying timing constraints is worth an hour of loading things into hardware and poking around with scope/logic analyser trying to decide if they're working properly.

I have piles and piles of dev boards - sometimes getting them is a good way to get hold of a decent reference design schematic which you can't get without buying the board - but I find they're often massively complex (because they tend to showcase the capabilities of the chip) and might be a bit overwhelming to a newcomer to the field. I can't comment on the specific one you mention.