Dear all I have synthesized my VHDL-coded design in Quartus v17 and have the netlist (vho) file. But the problem is that after synthesis, my design data ports in the resulting netlist file has changed from signed to std_logic_vector. What's the problem? How can I resolve this issue? Thanks Reza
Reza M. S. wrote: > How can I resolve this issue? Don't do a Post-Whatever-Simulation. It's useless. Perform a behavioural simulation and use proper constraints. That's all you need. > How can I resolve this issue? Use std_logic in your ports. To use std_logic in ports is an unofficial industry standard.
Lothar M. wrote: > Don't do a Post-Whatever-Simulation. It's useless. Perform a behavioural > simulation and use proper constraints. That's all you need. Why should be be useless?
Mar. W. wrote: > Why should be be useless? A counterquestion: what should it be good for? Do a behavioural simulation AND add proper constraints to the design, that's enough.
Why do you think, Xilinx took effort in integrating this function into their design tools? The main idea behind this to compare various types of placement options and verify them. Of course this is done during automatic place and route when using timing driven placement and it works whenever the placer is intelligent enough to find a solutiuon. But as soon as a mixture of area and speed is required, this is all a matter of probabiliy how good it works. Also temperature issues do apply. During auto placement, the placer has to be pessimistic and stays far away from the possible desitiy and timing for those parts of the cirtuic which do not toggle permanently and stay cool enough. Third party tools make use of that netlist to resynthesize this. Also when you try to manipulate the FPGA with the FPGA editor on low level, you need this timing simulation.
Mar. W. wrote: > Why do you think, Xilinx took effort in integrating this function into > their design tools? Because users with design strategies from the last millennium wanted them to. > The main idea behind this to compare various types of placement options > and verify them. Thats of no interest when the design is reported as "fast enough". The only timing analysis one must do is the STA (static timing analysis). > Also when you try to manipulate the FPGA with the FPGA editor on low > level, you need this timing simulation. Why sould I dig around in the FPGAs layout at all? When this is the only way, then its the wrong way leading to a dead-end. Even with an "working" timing simulation there is not the slightest guarantee that you will find all the possible timing violations. Because you must no only run a "worst case simulation" and a "best case simulation". No you will have to run a "random timing simulation" also because thats what will happen in real life. So for me the summary is: In 99.99% of the designs you only need the STA together with correct constraints. When you are one of the 0.01% then an FPGA may be the wrong thing for the job.
In a processor based architecture, post synth can be useful Esp if there is ROM ( or RAM as well in some cases) that is to be tested. Idea is to ensure that initialisation values were integrated correctly for those memory instances and processor is able o fetch/perform action. If there is any indication that drives IO based on those initialisation values from HEX file, then post synth simulation can help for better confidence. Thanks, Amol
Post-Layout simulation is the only way to detect dynamical timing problems, caused by complex clocking or when non-hazard free logic has been implemented on interfaces to hard-macros. A static timing analysis will not help in such cases.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.