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)
Best Answer
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.