I have a compiled (binary) bitstream file which I just want to emulate in software.
Linux, Mac, Windows.. anything goes. I know it will probably take a long time but I don't really care how long it takes. Anyway, I do NOT want to load the code to a real FPGA and run it.
Is there a software that can be used to achieve that goal?
You can't.
FPGA simulators only work on HDL code. Once a design has been built into a bitstream, that file can only be used to program an FPGA.
Related
I want to use AT command with separate coding in esp32 at Arduino IDE. However, if you flash AT command firmware and upload another code from Arduinoide, the existing at command will not be available. Is there a way to use it together?
What you're asking doesn't make any sense. The ESP32 can run a single program that's stored in its flash memory. It's not capable of running two firmware images at the same time. If it's running the AT firmware, it's not running an Arduino program, and vice versa.
You also do not need to talk to the AT firmware from an Arduino program running on the ESP32; the Arduino program is capable of directly doing much more than the AT firmware offers.
You might possibly be able to build a single firmware image that included both the AT firmware and an Arduino program, but it would be a great deal of work and would likely never work well if at all. Most of the AT firmware is released as compiled binaries, not source, so you would have little chance of customizing it or making it work in a hybrid environment.
You'd be much better off to reconsider why you think you need to do this and find a better solution.
I am currently learning about using PIC18F4550 for my project. Is there any way that I can load the program into the PIC without using ICSP or PICKit? At the first time of using the PIC, can we use USB to load the program into the PIC?
I had this question myself,
To program a PIC, many devices can be used. Microchips website gives couple of options . However, The PICKit can program and also do hardware debugging for PIC controllers. There is ICD3 which gives access to more in-depth analysis. There are many more third-party programmers for the PIC controller.
One of these programmers are needed for programming a PIC for the first time. your PIC can be initially programmed with bootloader code. Once you load bootloader you no longer need any programmer. You can send your Hex files over USB or UART and PIC will program itself with this new hex Code. ezbl from microchip has way to do it with USB but it only works with PIC24/dsPIC33
Microchip has very good documentation on bootloader AN851.
You can try the simple PIC programmer found on this page. It works with PICpgm, which is freeware. I've used this software before and it should work great with the 4550.
http://tomeko.net/misc.php
http://picpgm.picprojects.net/
I'm new to fpga programming, and I'm wondering how to make my fpga design distributable. Here's the scenario I have in mind. I have a network of computers, each deployed with an fpga based peripheral. I want to update the fpga design on the peripherals periodically. How do I accomplish this without spending a fortune on software licenses?
I have a small dev kit for an fpga that shipped with an executable to load example design files (it was an Altera fpga FYI). Does anyone know how I would create such an executable?
Some specifics:
My fpgas are Xilinx Spartan 6Es. I'm using Xilinx ISE for fpga development. The host computers are running debian linux.
Thanks for any and all advice!
If youre dealing with Altera: one computer would have the software tools and licenses needed to synthesize the project. Assuming all the FPGAs are the same model on each station/node, Quartus will generate an .sof file which you can copy and open from station to station. All you would need to do is download the Altera programmer tool (I believe you can download it separately from Quartus II) on each station which is free. Then upload the .sof to the board using the programmer, where you can permanently store it on the fpga prom using a technique similar to the following:
https://m.youtube.com/watch?v=ZrMe8JS7Ktk
However if you have Xilinx and Altera mix, Xilinx has .bit/xdl files, and uses another tool (impact) to upload their bitstreams. They can't be converted to and from bit and sof. So it's recommended that you probably stick to one make (Xilinx or Altera) and model based on your plans.
It looks like what you are looking for is how to make your FPGA's field upgradable. Assuming your FPGA is loading from an external memory such as an SPI flash chip, then you need to modify your design so that it is capable of writing to the SPI chip (or whatever) itself. This is most simply done by putting a register in your design which maps to the individual pins on the flash chip, and then "bit bang" the register from a connected computer. Assuming your FPGAs feed data into your own software running on the computer, then you would modify this software to have the functionality of manipulating this register to reflash the flash device. Obviously, if this goes wrong you bricked your device until it can be flashed again with the JTAG, but it provides a way for all the devices to get updated in the systems they operate without needing to buy a JTAG cable for every single station.
If you have Ethernet on your board you can use the remote programming tool from fpga-cores.
Then you can remote login to the network and program the FPGAs or mail the new config file to you customer and they run the programmer. This is how we remotely updates our boards.
Spartan 6 is supported. As a bonus you can also do some remote debugging with the remote logic analyzer.
Everything is free for non commercial use.
I have some crucial data written decades ago by an ancient 16bit DOS application.
There are no docs, no source, and no information about the author. Just the 16 bit exe.
I guess it's time for me to learn how to decompile stuff, since it seems the only way to restore file format.
I've tried OllyDbg, it looks really great, but it can't 16 bit.
So, is there a disassembler/debugger capable of working with such executables?
Thanks.
UPD: I know DOSbox, the app runs in it all right. The problem is, I don't need to run it, I need to understand the file format in which it writes data. Or maybe I don't know something about DOSbox and it can run as a debugger/decompiler as well? Or do you mean starting some old 16bit DOS debugger/decompiler in DOSbox? The latter sounds like an idea, but could you please name a decent DOS debugger, then?
disassembling tool:
use IDA Freeware https://www.hex-rays.com/products/ida/support/download_freeware.shtml
you won't find any better tool for reversing - even for old dos programs :)
most other tools are only capable of doing disassembling for 32bit and don't reach in any way the analyze features of IDA - its the gold standard tool of reverse engineering
debugger:
dosbox got its own builtin debugger (reachable through the "debug" command on command line)
but you need to build your own version of dosbox with activated debugger (oder better heavy-debug) see: http://www.vogons.org/viewtopic.php?t=3944
or if you got a ida licence with the sdk there is an dosbox<->ida-debugger plugin available
currently linux only https://github.com/wjp/idados
file format:
do you know what the file contains (what do you want from the file)
very complex information or "just" some lists of values?
maybe its better to start here with an hex-editor (http://mh-nexus.de/de/hxd/) and known result-values to compare
what program uses the data currently (or only the program itself)? maybe its possible to understand how the data is read in this program?
program itself:
how large is the exe?
console program or a big super gfx power app?
real 16bit or 32bit with dos-extender?
a single exe or overlays(dos-dlls)?
can you give access to the executable?
your turn
You're looking for IDA. It's the de-facto disassembler for pretty much anything.
You can get more help on this at https://reverseengineering.stackexchange.com/
You do not necessarily need to disassemble a program in order to figure out the format in which it writes data.
Perhaps you can do differential analysis on it. Change some inputs to the program, have it write the data, and watch how the file changes.
I have some vintage hardware devices here which can dump their NVRAM settings over MIDI in a binary format (in one case, a single SysEx message with a binary blob in it). If I wanted to know what the format is, I'd make small, systematic changes to the settings, and perform dumps, then see what bits in the binary data are changing.
You really are probably best off attacking the data, rather than the program.
Dosbox is probably a thing to try.
You might also look at http://hte.sourceforge.net/ .
My boss has given a code for testing PCI express on an Altera board. The code consist of several c code files having instructions such as reading Bios, setting some registers, writing to buffers etc.
My job at present is to see the functionality of the code by running it.
I am new to FPGA and I am unable to understand what tools, compilers etc will I use for compiling it for the FPGA.
Since it is a C code so I am sure I cannot use the same environment as that of Verilog/VHDL. Can I get some hints as to what compilers are available for compiling C code for testing various interfaces of an FPGA?
Thanks and regards
H
If the FPGA board is just connected through a standard PCIexpress interface, it isn't that hard to create a Linux driver to simply access a couple of registers. This might even be easier to do than getting some old DOS-based drivers to work.
I did some work on this in a pre-project to my masters thesis some years ago - if you're interested, it's available here: http://loejer.dk/files/FORK,%20pdf.zip
It sounds like the intent is that you connect the PCI-E card to a normal computer with a PCI-E slot, then run the test software on the host computer, so it will talk to the board via PCI-E, and exercise the board from the host, collect data on the host, and so on.
Such code will almost certainly be quite non-portable. You'll probably need to ask what system it's for (or examine the code to find hints -- e.g., if it starts with #include <windows.h> that's a pretty fair indication that it's for Windows).
The OS it's written for will give at least an 80% (or so) clue about what compiler to use -- if it's for Windows, chances are pretty good that it's intended for Microsoft's compiler. If it's for Linux, there's an even better chance that it's for gcc/g++. If it's for MacOS, it's probably for g++, but if it's really new, might target Clang.