- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Id have thought these steps apply to all algorithm development.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page