consistancy in synthesis/ simulation model

Hi, This is regarding synthesis of code on ISE 7.

II have a design that I want to run on spartan 3, 400K gate FPGA. It has taken 65% of total slices. The synthesis, and PAR options are set to default, no high effort levels are set.

The issue is every time I do the place and route the Post place and route simulation results are different. One of the two state machines hangup. I'm not getting the possible reason for this.

Could you please help me in solving this?

Thanks and Regards, Srikanth

Reply to
Srikanth BJ
Loading thread data ...

Take a look at the timing analysis report that pops out of the place and route. Odds are that you're violating the timing in the simulation in one of two ways:

- Clock(s) are running faster in simulation than the place and route report says is acceptable (i.e. sim runs at 50 MHz, but the timing report says that the best it can do is 10 MHz)

- Setup times on input pins are being violated. Again the timing report out of place and route will tell you what the setup time for each pin is relative to whatever clock signal it is referenced to. If your simulation model does not adhere to this (i.e. maybe inputs are changing just prior to the rising edge of the clock) than you won't simulate correctly.

Bottom line is to do timing analysis first and then make sure that the simulation model that surrounds the design does not violate those timing constraints.

KJ

Reply to
KJ

I'm implementing a manchester decoder. There are two asynchronous inputs. To decode the data, we sample this data using a local clock(16MHz, synthesys report mentions maximum clock around 40MHz). Therefore setup time may or may not be met. I suppose in actual hardware, if setup/hold time requirements are not met, the FF would remain in same state, and it will change state in next clock cycle when timing requirements are met. Please correct me if I'm wrong.

Thanks and Regards, Srikanth

Reply to
Srikanth BJ

If setup times are not met then you don't know if the FF will change, stay the same or even go metastable for a bit. The general approach to synchronizing async input to a clock is to bring the async signals into a FF then feed that FF output into a second FF. The output of the second FF is the only thing that then gets used further on down in the design.

Since you have two async inputs, if one of them is some form of clock that the other signal is referenced to then you would need to bring them in, do the required clocking between the two and then transfer the remaining signal into your local clock domain.

But, since you're still in the 'simulation' world though you don't have metastability as an issue. But the post route simulation model does model the required setup delays and clock to output delays so if you 'violate' timing by having inputs change at the wrong time relative to the local clock then the post-route simulation model will just sit there for an extra local clock cycle which would end up making the pre and post-route simulations be off by a clock cycle.

There is no 'solution' to this problem though. Since the inputs to the design are asynchronous to the local clock any supposedly equivalent simulation model that attempts to model actual delays (i.e. the post-route model or the actual device itself on a board) will differ from a model that does not attempt to model those delays (i.e. the original design source). That's a big reason why post-route simulations are not quite as useful as one would hope for.

One possible kludge would be to artificially synchronize those async inputs to your local clock before bringing them into your design. This assumes that the local clock is visible outside the design you're testing. If you do that, then you should be able to get a perfect match between pre and post-route simulation. Like I said though it's a kludge. Complete functional simulation and static timing analysis are the tools of the trade, post-route sim is an attempt to give the warm fuzzies because of inadequate or incorrect static timing analysis or incomplete testbench coverage.

KJ

Reply to
KJ

That is what I do. I just assume the synchronizer will work because it always has and because the proof is not covered by digital tools anyway.

A post-route sim is a final check-off item to prove that synthesis and my design rules have worked for at least one case. I keep it out of the edit, sim, edit loop because it is slow to run, adds little to timing or functional coverage, and rarely fails.

It is more efficient to work on coverage at full speed. An interesting measurement is to sim the clock frequency outside the specified range to see if there are any logical limits built into the design.

-- Mike Treseler

Reply to
Mike Treseler

I agree. To the extent that one has high quality functional test coverage and has performed static timing analysis, post-route sim 'should be' just a formality final check-off item, something that needs to be done but doesn't provide much value (because of the above mentioned 'high quality....')

If you don't have that high quality test coverage or don't properly perform static timing analysis in the first place then post-route sim's value might increase dramatically but is still inferior to just doing the 'high quality...' work in the first place.

Yep, start it up on Friday afternoon and see if it has completed on Monday morning.

Tons more efficient ('mucho kilograms' for those outside the US)

Yep, and more specifically not just a single out of range frequency but run it at several different frequencies both in and out of the design range to catch those logical limits that you don't quite realize are in there.

KJ

Reply to
KJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.