Author Topic: FPGA Design Methodology?  (Read 1812 times)

0 Members and 1 Guest are viewing this topic.

Offline james_s

  • Super Contributor
  • ***
  • Posts: 7045
  • Country: us
Re: FPGA Design Methodology?
« Reply #25 on: April 18, 2018, 03:57:55 pm »
Oops, yes, stupid brain. I definitely meant simulator, it would be pretty hard to get much done with an FPGA without using the synthesizer.

Offline Berni

  • Super Contributor
  • ***
  • Posts: 1709
  • Country: si
Re: FPGA Design Methodology?
« Reply #26 on: April 18, 2018, 04:54:43 pm »
My decision between simulating or running on real hardware also depends on the design.

Simple designs that don't involve really wide buses can be easily debugged in hardware by preparing 16 spare IO pins and connecting them to a logic analyzer or use the built in logic analyzer inside the FPGA. Both Altera and Xilinix provide a nice one that you just tell what signals you want and it stuffs the entire softcore logic analyzer into the FPGA behind your back.

But if you are developing something more complex like maybe a memory mapped CAN bus controller or your own softcore CPU or something then simulation is well worth it. The extra time taken to set it up and write a testbench can save you a TON of time later in the form of much faster compile times and ability to look at any signal you want. It also depends how easy it is to make a test bench.

For example if you are making that CAN bus controller you might need the testbench to emulate another CAN device on the bus that your controller can talk to. That's obviously a lot of work, but you can do a trick and simply instantiate two or more of your CAN controllers that you are developing and connect them to the same bus to have them talk to each other.

Most HDL simulation tools also don't have protocol decoding in the waveform viewer. But what you can do is implement a simple protocol decode inside the testbench and have it output the decoded data as a bus that you then add to your waveform view, or alternatively you can print the data to the console. This part can then be reused to have the testbench run an automated test to check if correct data came trough and say PASS if it did.

Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo