For the occasions that you find yourself with a netlist file and you don’t know where it came from or what version it is, etc. this post is about how you can interpret the netlist file (ie. convert it into something readable).
Today I found myself with two netlists and I needed to know if they were the same. Yes of course you can try comparing the two files with a program such as Beyond Compare, but if the netlists were compiled on separate dates, you will have trouble recognizing this from the raw binary data. The best thing to do in this case is to convert the netlists to EDIF files, a readable, text file version of the netlist. Another option is to convert the netlists into VHDL or Verilog code. Here is how you can do this:
To convert a netlist (.ngc) to an EDIF file (.edf)
- Get a command window open by typing “cmd” in the Start->Run menu option in Windows. If you use Linux, open up a terminal window.
- Use the “cd” command to move to the folder in which you keep your netlist.
- Type “ngc2edif infilename.ngc outfilename.edf” where infilename and outfilename correspond to the input and output filenames respectively.
- Open the .edf file with any text editor to view the netlist.
To reverse engineer a netlist with ISE versions older than 6.1i
- Convert the netlist to an EDIF file using the above instructions.
- Type “edif2ngd filename.edf filename.ngd” to convert the EDIF file into an NGD file (Xilinx Native Generic Database file).
- To convert the netlist into VHDL type “ngd2vhdl filename.ngd filename.vhd“.
- To convert the netlist into Verilog type “ngd2ver filename.ngd filename.v“.
To reverse engineer a netlist with ISE versions 6.1i and up
- To convert the netlist into VHDL type “netgen -ofmt vhdl filename.ngc“. Netgen will create a filename.vhd file.
- To convert the netlist into Verilog type “netgen -ofmt verilog filename.ngc“. Netgen will create a filename.v file.
Now you should have all the tools you need to read an NGC netlist file.
Back in 2009 I did a presentation on why companies needed to be using FPGAs in their high frequency trading:
1. Stop competing in the arms race
Profits for being first to the game are over. Hardware will advance more quickly than you can develop strategies to run on it. Don’t compete in the arms race unless you can buy out Xilinx or Altera.
2. Stop focusing on speed of execution
Trying to get your order out faster than anyone else is a crowded game. Find intelligent strategies rather than fast and stupid strategies. Use FPGAs for what they are good at: fast parallel number crunching. Focus on processing market data to find trade opportunities, not on crunching protocols to save 2 microseconds.
3. Leverage existing hardware
Don’t waste your time developing your own custom hardware. The kind of hardware used in high frequency trading costs too much money to develop and involves too much risk (ironically). But the main problem is the development lead time which means that by the time you can trade on it you can buy something else which is cheaper and faster.
4. Use more data
The next profits will come from FPGA trading platforms that process data streams coming from everywhere and everything. Bring together data from a multitude of sources that are not yet being looked at and find the intercorrelations that can only be exploited by the speed of an FPGA.
Not long ago I discovered GitHub, the social coding website. Basically its a place where you can share your code and manage open source projects online. I think it’s mainly used by non-HDL programmers but the concept is not language specific so I figured it would be a good place to share FPGA designs. Gradually I will bring all the source code of all our tutorials onto GitHub so that people can more easily share it, modify it and contribute to it.
To start things off, I’ve uploaded the most popular project (at this time): Microblaze 16×2 LCD Driver.
Here’s the GitHub repository: Microblaze 16×2 LCD Driver on GitHub
Here’s how it’s organized:
- Each project will have its own repository.
- The first folder within the repository will be the name of the hardware platform (eg. ML505, XUPV5, XUPV2P, etc).
- The second folder will be the name of the software and the version number (eg. edk10-1, ise10-1, etc).
- After that, we will use the same folder structure as used by the software used, whether it be EDK, ISE or whatever.
As a new GitHub user, I admit that this might not be the best layout and I’m open to suggestions so by all means let me know in the comments if you see any problems with this.
Here’s what I want you to do:
- Get on GitHub if you are not already.
- Share FPGA developer projects with your friends and colleagues.
- Contribute to FPGA developer projects. What can you contribute?
- If you make a project work on a different hardware platform, add your code to the repository.
- If you make a project work in a different version of EDK/ISE/etc, add your code to the repository.
- If you can improve on a project, fork it and start a new one.
In general, I want you to share, learn and enjoy!