Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi,

Two things.

1) You don't need the OFFSET=OUT spec with our IP. It turns out there is an extra clock in the wait states for read cycles, so you really have 18 ns to get the data to the OMAP, not 8.

2) Check this FPGA overviewwiki page. In particular, the options for shift register extraction and the IOB packing should help. You can also modify the synthesis optimizations to try to meet the OFFSET=IN specs first.

Do you have your own IP core interfacing to the EMIF? If you do you may need some pipelining to meet timing. If it is the base project, maybe you could zip it up and post it or something for me to take a look?

The OFFSET requirements are tied to the delay timing requirements for the EMIFA bus. They were derived from the OMAP-L138 datasheet, but I think are the same for the 1808.

-Mike

The paths that are failing are from the pads to the EMIF module, I don't have any code connecting there.

Also, the Industrial I/O project that I started with selected a -3 device.
You're shipping with -2 devices, so I changed to that.
The slack is less negative when the project is -3, but still fails.

Your EMIF wiki page shows the requirements for a read cycle.
Isn't the OFFSET = IN constraint for async writes? Figure 11 or 13 (see attachments)?
These all look like multicycle paths to me.

Sorry about the -3 vs -2 issue. We will correct that on our next release. However, several designs have been validated and close using -2 speedgrade (you should be able to confirm that with the reference project, I think) using ISE 13.2 as well as 14.3. If you can't get the reference project to build, then there must be a settings issue, as that should build and close with the -2 speedgrade.

With response to the OFFSET=IN:

The OFFSET=IN spec is basically from the clock-to-pad specs on the output bus lines of the OMAP-L138 EMIFA. See the specs in 5.10.6 of the OMAP-L138 Specification from TI. They call for a 7 ns MAX clock to pad, and a minimum 1 ns hold time. That is where the constraint came from.

The reason why I am not saying, "yeah it's multicycle" is because the EMIFA_iface module (which you have the source for) is registering the following signals:

- edi
- ea(5 downto 0), routed to the sub devices
- chip select decodes (based on the upper ea bits)
- a "pulsed" read strobe (rising edge detected oe, useful for FIFO advances, etc.)
- a "pulsed" write strobe (falling edge detected we)

We did this to force IOB register packing (where we could) as the data valid window from the OMAP-L138 is pretty awful. We also did this to ensure a known number of clock states so that our downstream cores did not have to deal knowing the async timing of the bus. One might argue that was not a great plan, and you're free to do something different.

I don't have the timing diagrams drawn up for a write cycle handy (need to find them), so I don't know how sensitive the core-level register write logic is to a slip of the chip select decode, the write strobe (which is used quite a bit for advancing FIFOs, etc), and the data. E.G., if you slip the generated write strobe by a clock, you will be applying data latched from the edi 1 cycle later than originally designed for. Is that OK? Maybe, but I would need to look at the timing and the wait states to ensure that the bus was still valid at that time.

I guess what I am saying is, "it may be fine and you can multicycle them, but we have not done that analysis here to guarantee operation in that configuration".

Most often, we have found the problem with OFFSET_IN is that the XST is seeing a 2-3 register pipeline (meant to be the IOB register followed by a pipeline register to support moving the signal across the chip) and saying "hay, I can just drop a shift register in there instead" and ripping up the pipelining we were shooting for. It then has to route the input (with a 4 ns valid time) through the IOB to a LUT implemented shift register, which is extremely difficult to achieve on a busy design. This is why I mentioned the optimizations in the prior post, what do you have the minimum shift register extraction set to?

-Mike

Thanks Mike,
In Synthesis Properties, HDL Options, I have:
-shreg_extract = unchecked
-shreg_min_size = 3

I see that IOB FFs are being used (unless the signal was trimmed).
I also see that output and io pins are set to slow slew, even though there is nothing in the ucf or properties about that - must be a default.

If shift register extraction was happening anyway, is there a report that would indicate that?

If you have it disabled, then it won't happen. Try leaving it enabled and seeting min size to 5.

The other thing that could be done is to use a DCM on the EMIFA clock, which will allow you to deskew any delays in the clock routing.

If you are willing to send me your project, I might get some time to take a quick peek.... but it may not be right away....

-Mike

I tried:
-shreg_extract = checked
-shreg_min_size = 5
No difference.

There is a DCM on i_ema_clk already.
Should there be a phase shift?

I sent you my project by email.
Let me know if you don't get it.
Our email is not working right today.

Thanks,
Emmett

Did not receive it.