From: ratemonotonic on
Hi All,

I am new to FPGA development , I have encountered a timing closure
problem and would appreciate some advice from experienced xilinx guys.

My problem is as follows -

My system has three major modules -

1) Microblaze - interfaced with an external Flash and SDRAM.(using EMC
IP core).
2) Ethernet Interface - using EMC agian this time inteface with an
external SMSC MAC/Phy controller - asynchronously.
3) Our internal radio modem IP - Interfaced with microblaze using an
FSL bus.

When I integrated only the ethernet module with microblaze it works
very well and I can interface with a PCs ehternet port and communicate
reliably. I have seen the external bus transactions on a Logic ana and
it is fine.

when I integrated our modem IP in the FPGA. The ehternet post breaks ,
the externla bus transaction are exactly the same , but I cannot read
and write to the external Ehternet MAC Phy chip registers properly
even though the Logic analyser doesnt show any change.

By changing some timing constriants now we have a working model with
both modules working. But any further changes breaks every thing ( The
flash and SDRAM inteface as well). Obviously we are right on the edge.

How would you tackle such a situation? Any work around?

Thanks
Rate



From: Jon Beniston on

> How would you tackle such a situation? Any work around?

Buy a faster FPGA if possible.

Cheers,
Jon
From: KJ on
On Apr 18, 7:08 am, ratemonotonic <niladri1...(a)gmail.com> wrote:
> Hi All,
>
> I am new to FPGA development , I have encountered a timing closure
> problem and would appreciate some advice from experienced xilinx guys.
>
> My problem is as follows -
>
<snip>
> when I integrated our modem IP in the FPGA. The ehternet post breaks ,
> the externla bus transaction are exactly the same , but I cannot read
> and write to the external Ehternet MAC Phy chip registers properly
> even though the Logic analyser doesnt show any change.
>
> By changing some timing constriants now we have a working model with
> both modules working. But any further changes breaks every thing ( The
> flash and SDRAM inteface as well). Obviously we are right on the edge.
>
> How would you tackle such a situation? Any work around?
>

You mention that you changed 'some timing constraints' but never said
that you have successfully completed static timing analysis. Timing
constraints are not just something to change on a whim, they come
about because of the timing requirements of the devices to which your
design is connected.

So I would suggest
1. Complete a full static timing analysis.
2. Fix any paths that are reported as failures.
3. Are there multiple clocks? If so, how are the inevitable clock
domain crossings handled?

Kevin Jennings