Electronics > Beginners
Online FPGA simulator?
rstofer:
--- Quote from: emece67 on February 12, 2019, 05:20:23 pm ---As I understand the FPGA design cycle, it is heavily based upon simulation, so it is a bad idea, IMHO, not to learn to use the simulator from the very begining.
--- End quote ---
In earlier times with Xilinx ISE, the simulator wasn't free. The IDE was free, the synthesis and place/route tools were free but not the simulator. As a result, I have never used the simulator.
Now the simulator is free in Vivado but I still don't use it. I liken simulation to single stepping through pages of assembly code - a colossal waste of time. Yes, it could be useful for small pieces of a project (perhaps observing the ALU or not, see below) but I'm not convinced it brings anything to the dance when the actual circuit fails about a million cycles into booting the OS. And the OS is KNOWN to work...
The new Internal Logic Analyzer of Vivado, OTOH, can be quite handy because I can trigger it just before where I expect a problem. Getting the constraints file correct can be a bit of a challenge but much of it is automated.
I can also arrange for an address breakpoint that will change the CPU mode from Run to Single Step and pause. Now I can single step in the area where I expect to find a problem.
There are a lot of ways to debug projects, FPGAs or otherwise, and all have a place. That's why I want a board with lots of LEDs and 7-segment displays.
A long time back I was messing with the design of an ALU for the PDP 11/45. That thing is complicated! So, I coded it up on an FPGA and I connected the inputs and outputs (data and flags) to a long shift register. That allowed me to insert test vectors and grab the results. I used another processor (Blackfin) to handle the data transfer while grabbing vectors from an NFS server. And that's the way you test an ALU. With a Raspberry Pi it might be even easier since it could handle the transfer and contain the files. Handling the transfer on a typical Linux box seems daunting.
KE5FX:
--- Quote from: emece67 on February 12, 2019, 05:20:23 pm ---Hi,
Digilent has some breadboardable dev boards that, depending on budget, of course, may be affordable.
As others have said, use the simulator supplied with the vendor tool, otherwise, simulating vendor suplied cores will be not so easy.
As I understand the FPGA design cycle, it is heavily based upon simulation, so it is a bad idea, IMHO, not to learn to use the simulator from the very begining. Synchronous design and static time analysis ensure, to a high degree, that the real circuit will behave as the simulated one.
Unfortunately, the web if full of blatantly useless tutorials, courses & examples from experts that totally refuse to use simulators and disown the synchronous design.
Regards.
--- End quote ---
Wasting a lot of time with simulators and expecting it to improve your ability to get things done with FPGAs in real-world hardware projects is like wasting a lot of time alone with porn and expecting it to improve your sex life.
Buy a board, hook up a scope, and do some probing. And yes, keep it synchronous. 8)
ataradov:
There are issues that can only be realistically debugged in a simulator. And keeping it synchronous is not always an option.
Simulators are useful tools and there is no financial penalty in trying it.
emece67:
.
jmelson:
--- Quote from: KE5FX on February 12, 2019, 10:05:26 pm ---
Wasting a lot of time with simulators and expecting it to improve your ability to get things done with FPGAs in real-world hardware projects is like wasting a lot of time alone with porn and expecting it to improve your sex life.
--- End quote ---
Well, you can actually test a lot of things internal to a module of HDL code with a few minutes of writing a testbench and then simulating the sequence you think might not work as intended. This can be MUCH faster than trying to instrument a physical board. ChipScope (Xilinx in-FPGA logic analyzer) takes up a lot of room on small FPGAs and has limited record depth. In really difficult cases, it can tell you what is going wrong between internal and external signals, but is a lot of hassle. Guessing where the issues might turn up and then checking those by simulation can save a lot of hard work.
--- Quote ---Buy a board, hook up a scope, and do some probing. And yes, keep it synchronous. 8)
--- End quote ---
Really, trying to debug an FPGA in a more complex system with just a scope can be very frustrating. And, of course, lacking synchronizers on inputs to the FPGA is something that will generally NOT be caught by simulation, but you need synchronizers on pretty much ALL inputs, so you should just check to make sure they are in the code.
Jon
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version