Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21586 Discussions

Probability successful in FPGA if done in modelsim!!

Altera_Forum
Honored Contributor II
1,470 Views

How 's the porbability to run successfully a project on real FPGA if I have verified it in simulation using Modelsim?  

And what makes the difference between modelsim and FPGA in case if it run on modelsim but doesn't run in FPGA? 

The same questions if the simulation is simulink. 

By your experiments, give me some opinion, 

I just want some orientation information for my self-studying. 

Thanks,
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
539 Views

almost 100% success if you know the proper design methodology. 

Differences occur for various reasons, e.g.: 

 

Improper simulation coverage or stimuli 

Your simulation must be automated to remove human error 

 

overflow/underflow of buffers 

 

timing violations 

 

wrong startup logic and stuck state machines or stuck handshake signals 

 

wrong operating temperature 

 

undriven inputs during development. 

 

and the list goes on... 

 

occasionally device or ips or your compiler are to blame
0 Kudos
Altera_Forum
Honored Contributor II
539 Views

What kaz said. Plus heres my list of ways to make it work as well as possible from the start: 

 

1. Make an algorithm in Matlab 

2. Architect the algorithm so you can match the algorithm architecture in simulink to the architecture on the FPGA. (eg fixed point, data flow etc) 

3. Run test vectors. 

4. Convert algorthm to HDL. Make sure you use good design practice (all synchronous - any clock domain crossings done with FIFOs where possible, or at least double register) 

5. Create a self checking test bench that uses the same input as the simulink model, or even better, use the simulink model as the testbench (you can use modelsim co-simulation with simulink). Do black box testing to ensure HDL results match the simulink model. Also during testing, make sure you hammer the design with all edge and corner cases and a random scattering in between, plus stress the control inputs with random control (assuming you have thinks like memory bandwidth and contention to take into account). 

 

Only when you've done this, can you try and compile the design. (but of course, you were constantly checking your modules through the synthesisor to make sure they met the FMax you need) 

 

6. Compile the design with timing constraints. Iterate until it fits. 

(7. If you have the resources, use the simulink model as the testbench again with the real hardware running for black box testing) 

8. Use a real input source, and check the design. 

 

Using these steps should help minimise any design problems. Then you can look at actual hardware faults at the end.
0 Kudos
Altera_Forum
Honored Contributor II
539 Views

 

--- Quote Start ---  

What kaz said. Plus heres my list of ways to make it work as well as possible from the start: 

 

1. Make an algorithm in Matlab 

2. Architect the algorithm so you can match the algorithm architecture in simulink to the architecture on the FPGA. (eg fixed point, data flow etc) 

3. Run test vectors. 

4. Convert algorthm to HDL. Make sure you use good design practice (all synchronous - any clock domain crossings done with FIFOs where possible, or at least double register) 

5. Create a self checking test bench that uses the same input as the simulink model, or even better, use the simulink model as the testbench (you can use modelsim co-simulation with simulink). Do black box testing to ensure HDL results match the simulink model. Also during testing, make sure you hammer the design with all edge and corner cases and a random scattering in between, plus stress the control inputs with random control (assuming you have thinks like memory bandwidth and contention to take into account). 

 

Only when you've done this, can you try and compile the design. (but of course, you were constantly checking your modules through the synthesisor to make sure they met the FMax you need) 

 

6. Compile the design with timing constraints. Iterate until it fits. 

(7. If you have the resources, use the simulink model as the testbench again with the real hardware running for black box testing) 

8. Use a real input source, and check the design. 

 

Using these steps should help minimise any design problems. Then you can look at actual hardware faults at the end. 

--- Quote End ---  

 

 

@ Tricky, Thanks for your valuable information, 

I'm wondering about these steps, are they specified to some sort of algorithms such as DSP, or image processing. Or it's more general method do an algorithm?
0 Kudos
Altera_Forum
Honored Contributor II
539 Views

Id have thought these steps apply to all algorithm development.

0 Kudos
Altera_Forum
Honored Contributor II
539 Views

At risk of stating the obvious, your code must be RTL and may only use the subset of the language that is supported by your synthesis tool. Code written for simulation without regard for synthesis will generally not work in an FPGA.

0 Kudos
Reply