No more gate-level simulation. for Cyclone V !!!

[Luis Cupido]

Hello,

I'm dealing with some fast state machines and gate-level-timing
simulation of some components has been very helpful.

Now using a Cyclone V I found that I can't do timing gate-level timing
simulation, quartus does not generate the SDF file, the *.sdo file.

Altera/Intel says this on the documentation regarding simulation:

"Gate-level timing simulation is supported only for the Arria II
GX/GZ,Cyclone IV, MAXII, MAX V, and Stratix IV device families.
Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?

Any help ?
Thanks.

Luis C.

 

[KJ]

On Thursday, April 2, 2020 at 7:50:55 AM UTC-4, Luis Cupido wrote:

Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?

Static timing analysis does not give you the same info as a gate level simulation. Static timing analysis is a far better way to verify your design for correctness compared with gate level sim.

Kevin Jennings

 

[Rick C]

On Friday, April 3, 2020 at 12:34:09 PM UTC-4, KJ wrote:

On Thursday, April 2, 2020 at 7:50:55 AM UTC-4, Luis Cupido wrote:
Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?


Static timing analysis does not give you the same info as a gate level simulation. Static timing analysis is a far better way to verify your design for correctness compared with gate level sim.

One big problem with static timing analysis is that it doesn't have a means of verifying the timing constraints. You analyze your design, construct the timing constraints, but there is no way to even check for typing errors.

So if any of the constraints are too lax, your design will pass analysis, but can fail on the bench and there is no way to find the bug. Then a timing simulation can save the day.

But in general, static timing analysis is a much more comprehensive way to verify timing. It is not so easy to get information on how to fix the problem, but at least it points you to the problem.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[HT-Lab]

On 03/04/2020 17:34, KJ wrote:

On Thursday, April 2, 2020 at 7:50:55 AM UTC-4, Luis Cupido wrote:
Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?


Static timing analysis does not give you the same info as a gate level simulation. Static timing analysis is a far better way to verify your design for correctness compared with gate level sim.

Kevin Jennings

That is not the issue, the issue is that Intel has decided to remove one
of the tools we use to check our design.

Obviously if static timing fails nobody will run gatelevel simulation,
however, if static passes and your design does not work (has happen to
me and I am sure to others) then gatelevel simulation provide a valuable
and easy to method to see where signals are "going red". Gatelevel is
also useful to see what happens before reset is asserted.

Given that all other vendors provide gatelevel timing I failed to see
why Intel in their great wisdom has decided to remove this feature for
one(?) of its family.

Hans
www.ht-lab.com

 

[Rick C]

On Friday, April 3, 2020 at 3:49:34 PM UTC-4, HT-Lab wrote:

On 03/04/2020 17:34, KJ wrote:
On Thursday, April 2, 2020 at 7:50:55 AM UTC-4, Luis Cupido wrote:
Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?


Static timing analysis does not give you the same info as a gate level simulation. Static timing analysis is a far better way to verify your design for correctness compared with gate level sim.

Kevin Jennings

That is not the issue, the issue is that Intel has decided to remove one
of the tools we use to check our design.

Obviously if static timing fails nobody will run gatelevel simulation,
however, if static passes and your design does not work (has happen to
me and I am sure to others) then gatelevel simulation provide a valuable
and easy to method to see where signals are "going red". Gatelevel is
also useful to see what happens before reset is asserted.

Given that all other vendors provide gatelevel timing I failed to see
why Intel in their great wisdom has decided to remove this feature for
one(?) of its family.

Maybe it's just me, but I hate saying "Intel" rather than Altera.

--

Rick C.

+ Get 2,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[HT-Lab]

On 03/04/2020 21:01, Rick C wrote:

On Friday, April 3, 2020 at 3:49:34 PM UTC-4, HT-Lab wrote:
On 03/04/2020 17:34, KJ wrote:
On Thursday, April 2, 2020 at 7:50:55 AM UTC-4, Luis Cupido wrote:
Use Timing Analyzer static timing analysis rather than gate-level timing
simulation."

I don't even know how to interpret the last sentence, how
does the Timing analyzer give me the same info / graphical view of the
timings of the critical signals and buses that I'm trying to view ?


Static timing analysis does not give you the same info as a gate level simulation. Static timing analysis is a far better way to verify your design for correctness compared with gate level sim.

Kevin Jennings

That is not the issue, the issue is that Intel has decided to remove one
of the tools we use to check our design.

Obviously if static timing fails nobody will run gatelevel simulation,
however, if static passes and your design does not work (has happen to
me and I am sure to others) then gatelevel simulation provide a valuable
and easy to method to see where signals are "going red". Gatelevel is
also useful to see what happens before reset is asserted.

Given that all other vendors provide gatelevel timing I failed to see
why Intel in their great wisdom has decided to remove this feature for
one(?) of its family.

Maybe it's just me, but I hate saying "Intel" rather than Altera.

I have the same, occasionally I still say Actel instead of
MicroSemi...eh...MicroChip. I don't think we have to take this so
seriously as long after MicroSemi bought Actel you could still find
"Actel" all over their documentation.

Hans
www.ht-lab.com

 

On Friday, April 3, 2020 at 8:49:34 PM UTC+1, HT-Lab wrote:

Given that all other vendors provide gatelevel timing I failed to see
why Intel in their great wisdom has decided to remove this feature for
one(?) of its family.

I came across this a few years ago and I seem to remember that it was all families from Cyclone V onwards so not just one family. Don't know if this has changed since then.

Also from reading docs at that time Altera docs indicated the reason for not supporting timing sim was because designs were getting so complex timing sim takes too long to be viable and so would be dropped. Interestingly when I checked the Xilinx docs at that time timing simulation was still supported and their docs indicated because designs where becoming more complex that timing sim was recommended!! The polar opposite to Altera.

As I said that was a few years ago. I was working on a project where we had to do timing sim because it was part of the development process. That project switched to Xilinx devices just because of this issue.

I haven't needed to do timing sim since so I don't know if much has changed since then.

 

[gtwrek]

In article <3a4c3990-b99a-436f-b083-c37b9431651c@googlegroups.com>,
<pault.eg@googlemail.com> wrote:

On Friday, April 3, 2020 at 8:49:34 PM UTC+1, HT-Lab wrote:


Given that all other vendors provide gatelevel timing I failed to see
why Intel in their great wisdom has decided to remove this feature for
one(?) of its family.


I came across this a few years ago and I seem to remember that it was all
families from Cyclone V onwards so not just one family. Don't know if
this has changed since then.

Also from reading docs at that time Altera docs indicated the reason for
not supporting timing sim was because designs were getting so complex
timing sim takes too long to be viable and so would be dropped.
Interestingly when I checked the Xilinx docs at that time timing
simulation was still supported and their docs indicated because designs
where becoming more complex that timing sim was recommended!! The polar
opposite to Altera.

As I said that was a few years ago. I was working on a project where we
had to do timing sim because it was part of the development process.
That project switched to Xilinx devices just because of this issue.

I haven't needed to do timing sim since so I don't know if much has
changed since then.

That's interesting the Altera took that tact. I wonder how much effort
it really is to maintain the SDF generation - surely it's a solved
problem?

On the other hand, I do find the need for SDF annotating, gate-level
simulations as a waste of time, with better ways of accomplishing
the same goals. I've not run a full timing simulation in probably
over 20 years... In fact, even the need for gate-level simulations
at all, is remote - like once a year or so - and these are almost
universally to confirm/debug a vendor RTL/netlist mismatch...

So, I sortof understand Altera's thought process. But I do know
there's certainly a vocal group of folks who insist gate-level sims
(with or without timing) is a sign-off requirement. And Altera
brushing off those folks doesn't seem like a wise move..

Regards,
Mark

 

[KJ]

On Wednesday, April 15, 2020 at 1:06:52 PM UTC-4, gtwrek wrote:

In article <3a4c3990-b99a-436f-b083-c37b9431651c@googlegroups.com>,
pault.eg@googlemail.com> wrote:
On Friday, April 3, 2020 at 8:49:34 PM UTC+1, HT-Lab wrote:

On the other hand, I do find the need for SDF annotating, gate-level
simulations as a waste of time, with better ways of accomplishing
the same goals. I've not run a full timing simulation in probably
over 20 years... In fact, even the need for gate-level simulations
at all, is remote - like once a year or so - and these are almost
universally to confirm/debug a vendor RTL/netlist mismatch...

Agreed. In fact, the last couple of times I remember running a gate level sim was to show a demonstrate an incorrect synthesis implementation...to Altera. But to do that I only had to run the sim for a couple of clock cycles or so. In at least one of the cases, I modified the design to bring out an external signal to a pin so that it could be directly observed to be incorrect. The testbench was an instantiation of the source design in parallel with the gate level sim.

Altera is correct from the viewpoint that running a gate level sim as a substitute for timing analysis is a waste of time and resources. However, from the viewpoint of having a way to validate correct synthesis (whether this is done routinely as part of company's design process or is an exception case) the gate level sim has usage.

Kevin Jennings