The first big difference is that at the end of the suggested flow you have waveform file that you can use for other needs too (and other tools too)…
Also – while working with PTPX with RTL VCD you must make sure that only Flip-Flops are mapped between RTL to netlist. Usually more than Flip-Flops are mapped, and since the RTL simulation is zero delay simulation, the propagation is not done well (and the results are not accurate). It is mostly critical and problematic around adders and multipliers, but not only.
The suggested flow can overcome partial design – RTL which contain stubs or other testbench that replace part of the RTL. You can’t overcome this in PTPX.
In general – you must be PTPX expert to be able to run with RTL VCD, and it is not accurate. In the SpringSoft flow anyone can generate netlist VCD/SAIF, and no need to be an expert to run it on PTPX.
Another issue – PTPX runs in this mode taking too much time. While generating GTL waveform in the new flow took about 1 hour, and the total power estimation was 2 hours, using this on PTPX (when it can be done) took more than 24 hours.
An interesting idea and really helpful. What would be the differences of this flow compared to the flow when RTL VCD along with gate-level netlist is loaded into Primetime PX and tool propagates RTL activities into gate nodes?
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.