Sopc Help

where are your failing paths? Adding the pipelines should already help, but in some cases it can be the design inside your component that can be the problem.

Do you have the same problem with less masters in your SOPC design?

I'll test that.

But I also have a question: Some of my write masters get a buffer full. Fifo dept is 258 and there should be enough of time to write them to the SDRAM. If i assing a GO to 2 components at the same time the arbiter can handle that ... right or not?

I think you should use some signaltap probes to see what is happening and why your masters are frozen for so long.

One possible explanation could be that you have two masters trying to access different portions of memory at the same time, and the arbitrator is letting each one access one word at a time. In that case you loose all the latency cycles from the DRAM on each access.

The master interface has some features to speed up the access, such as bursts and/or pipelined transfers with arbitrator lock. You should look into those, to let your masters access several words in a row and avoid most of the lost latency cycles.

Yes, i have 2 images to be stored at the same time.

(2 camera's -> 1 memory).

The arbiter integer are standard 1 (as in the picture).

And i enabled a burst of 32 while the template FIFO is 256.

Is a burst of 32 enough ?

And what does a burst of 32 means? That the master has 32 clk cycles acces to the slave or that 32 data transfer occur to the slave?

Like u said, the slave needs some cycle to set the adress.

Another Question:

If u use the write - MM Master like follows:

(FIFO is filled by camera at 48MHz : 1 byte every clk)

(SDRAM works on clk of 144MHz)

U send : GO, Adress = 0x000000000 , Number of Bytes = 640 decimal

What will happen?

I can think of some things.

- FIFO will run empty and the component will have no data to transmit.

But will the write controller freeze?

Redesigned the SOPC for 1 camera -> 1 Write MM-Template

Spec of MM Template :

- FIFO = 256

- Burst Enabled and 8

--- Quote Start ---

where are your failing paths?

--- Quote End ---

--- Quote Start ---

Do you have the same problem with less masters in your SOPC design?

--- Quote End ---

Setup paths within the SOPC with slack of -1.953

Lots of them.

--- Quote Start ---

Setup paths within the SOPC with slack of -1.953

Lots of them.

--- Quote End ---

Either you are using a too high clk frequency

or you have a bad create_clock command in the TimeQuest sdc file.

Some suggestions:

- If the SDRAM controller you are using does not support burst then don't enable bursting in the masters.

- Increase the arbitration share of each master to allow multiple back to back transfers from each master to access the SDRAM

- Increase the data width of the master to match your memory controller width

--- Quote Start ---

Either you are using a too high clk frequency

or you have a bad create_clock command in the TimeQuest sdc file.

--- Quote End ---

Fmax is about 132MHz but that is when i remove all the others VHDL and only generate a Sopc with one Write master and one SDRAM controller.

The second option could be a problem. I don't have much experience with

SDC file or asserting constraints. I followed TimeQuest User Guide by Ryan Scoville. do i need a diffrent ip.sdc for the sopc? Here is my SDC-File for main design:

# **************************************************************#  Time Information# **************************************************************
set_time_format -unit ns -decimal_places 3
 # **************************************************************#  Create Clock# **************************************************************
create_clock -name {FPGA_CLK1} -period 20.833 -waveform { 0.000 10.416 } 
create_clock -name {FPGA_CLK2} -period 20.833 -waveform { 0.000 10.416 } 
create_clock -name {PIX_CLK} -period 20.833 -waveform { 0.000 10.416 } 
 # **************************************************************#  Create Generated Clock# **************************************************************
derive_pll_clocks
 # **************************************************************#  Set Clock Latency# **************************************************************
 # **************************************************************#  Set Clock Uncertainty# **************************************************************
derive_clock_uncertainty

FPGA_CLK_1 and _2 are 48MHz input clk's that go straight to a PLL each. They generate a freq of 48MHz and 144MHz.

The generated CLK 144MHz i use for the SOPC gives failing paths (setup)

--- Quote Start ---

Some suggestions:

- If the SDRAM controller you are using does not support burst then don't enable bursting in the masters.

--- Quote End ---

It does. It supports a burst of 1,2,4,8. I set every burst on 8.

--- Quote Start ---

- Increase the arbitration share of each master to allow multiple back to back transfers from each master to access the SDRAM

- Increase the data width of the master to match your memory controller width

--- Quote End ---

I'll try them, but i was trying to avoid the last suggestion because then i need to make the code a little more complex.

If i increase arbitration shares, that will have no affect on the slack.

or am i wrong?

Aditional info:

FPGA : Cyclone III EP3C10F256C8N

SDRAM : IS42S16400B

If more info is required plz ask.

Thx for the reply's.

Did some tests,

With 1 write master MM to SDRAM controller fmax 132MHz

I Added one -> 2 Write masters to SDRAM controller fmax 115MHz