PDA

View Full Version : Help: Windows didn't assign Bar0 to PCie (address mapping is not correct)



binpersonal
May 6th, 2012, 03:25 PM
Dear all,

We changed the Altera Cyclone PCIe DDR2 reference design to our needs. However, it doesn't work. The address mapping is not correct, it doesn't agree to address assignments in Qsys.

In WinDriver, Bar0 doesn't appear, only Bar2 appears under "Memory" tab (see Attached Figure). But the address range of Bar2 is not correct either, and the reading and writing were not correct when we write then read from Bar2.

Anyone can give any suggestions? Why it didn't have bar0 as assigned in Qsys?

The Windows operating system is Windows XP.

I attached the figures of Qsys block diagram, Qsys address map and IP Complier.

Thank you very much!

dwh@ovro.caltech.edu
May 6th, 2012, 04:02 PM
Look at your "Address Map" image. BAR0 has the 256MB DDR mapped from 0x1000_0000 to 0x1FFF_FFFF, and it has the onchip RAM mapped lower in that are, so the BAR region needs to be 2 x 256MB = 512MB.

Many computers will not boot with such large BAR regions. In your case, the BIOS probably did not enable that region.

Start by trying to use a smaller BAR.

The Qsys PCIe bridge is missing a function that most PCI bridges normally have, which is the ability to independently set the BAR size, and the base address of where that BAR maps to. Using this feature, you can normally take a 1MB BAR, and move it anywhere in the PCIe device address map, eg., in your case you would be able to look at the DDR 1MB at a time. This is sufficient for simple testing. Since the final application should use DMA, the use of small BAR regions is not an issue.

Start with a small BAR - even if you think this is not the right solution - since using the small BAR will show you whether or not this is really your problem.

Cheers,
Dave

binpersonal
May 6th, 2012, 04:16 PM
Thanks, can the bar region be as large as 256 MB or more?

We use "system"-> "assign base address" menu, the DDR now is mapped to 0x0000_0000 to 0x0fff_ffff, the on-chip memory now is mapped to 0x1000_0000 to 0x1003_ffff.

But it still doesn't work. Bar0 still does not appear.




Look at your "Address Map" image. BAR0 has the 256MB DDR mapped from 0x1000_0000 to 0x1FFF_FFFF, and it has the onchip RAM mapped lower in that are, so the BAR region needs to be 2 x 256MB = 512MB.

Many computers will not boot with such large BAR regions. In your case, the BIOS probably did not enable that region.

Start by trying to use a smaller BAR.

The Qsys PCIe bridge is missing a function that most PCI bridges normally have, which is the ability to independently set the BAR size, and the base address of where that BAR maps to. Using this feature, you can normally take a 1MB BAR, and move it anywhere in the PCIe device address map, eg., in your case you would be able to look at the DDR 1MB at a time. This is sufficient for simple testing. Since the final application should use DMA, the use of small BAR regions is not an issue.

Start with a small BAR - even if you think this is not the right solution - since using the small BAR will show you whether or not this is really your problem.

Cheers,
Dave

dwh@ovro.caltech.edu
May 6th, 2012, 05:14 PM
can the bar region be as large as 256 MB or more?


The PCIe spec will not stop you, but your particular hardware might. My EliteBook will not boot with a BAR of 256MB.



We use "system"-> "assign base address" menu, the DDR now is mapped to 0x0000_0000 to 0x0fff_ffff, the on-chip memory now is mapped to 0x1000_0000 to 0x1003_ffff.
But it still doesn't work. Bar0 still does not appear.

Because you did not change the BAR size by doing this. Look at the report on the Qsys GUI. Look at the synthesis report.

Look at this document here:

http://www.alteraforum.com/forum/showthread.php?t=35678

It has some comments.

To try and isolate this problem, start with just the on-chip RAM in the BAR at a base address of zero. You can use the "Address Map" tab to re-assign the addresses.

Once you can confirm that you can boot windows, you can increase the size of the BAR (the offset of the on-chip RAM) until it breaks. Then you will know the limits for your particular hardware setup.

Cheers,
Dave

binpersonal
May 6th, 2012, 05:23 PM
Thank you, Dave,

We actually got rid of the DDR2 once and has on-chip memory and SGDMA at Qsys. But it didn't seem to help and Bar0 sill didn't appear at the WinDriver memory tab. There was nothing under WinDriver memory tab.

Could you diagnose this problem?



The PCIe spec will not stop you, but your particular hardware might. My EliteBook will not boot with a BAR of 256MB.



Because you did not change the BAR size by doing this. Look at the report on the Qsys GUI. Look at the synthesis report.

Look at this document here:

http://www.alteraforum.com/forum/showthread.php?t=35678

It has some comments.

To try and isolate this problem, start with just the on-chip RAM in the BAR at a base address of zero. You can use the "Address Map" tab to re-assign the addresses.

Once you can confirm that you can boot windows, you can increase the size of the BAR (the offset of the on-chip RAM) until it breaks. Then you will know the limits for your particular hardware setup.

Cheers,
Dave

dwh@ovro.caltech.edu
May 6th, 2012, 07:08 PM
Could you diagnose this problem?

Go through the tutorial I wrote in the thread I pointed you to.

The examples in the document are for x8 and x1, and there is a x4 PCIe in the example code. The boards are the Stratix IV GX Development kit and the Cyclone IV GX Transceiver Starter kit. There's enough detail in there for you to create a design for your specific board.

Under code/pci_debug is a tool for accessing the BARs under Linux. You can use it to read/write to the on-chip RAM, and then later, when you add a DDR controller to the design, use it for accessing DDR.

Cheers,
Dave

dwh@ovro.caltech.edu
May 6th, 2012, 07:29 PM
The Windows operating system is Windows XP.


Could this be a 32-bit vs 64-bit issue? What is the processor you are using?

Perhaps try setting BAR0 as 32-bit to see if it makes a difference.

To test Linux, download a bootable CD-ROM and boot from that, or install Ubuntu via Wubi (which sticks a file onto your windows drive).

Cheers,
Dave

dwh@ovro.caltech.edu
May 6th, 2012, 07:44 PM
Bar0 sill didn't appear at the WinDriver memory tab. There was nothing under WinDriver memory tab.
Ignore WinDriver to start with. Use PCITree to see if the BIOS programmed the 64-bit BAR0 correctly.

Who knows if your copy of WinDriver is setup to allocation 64-bit BARs? Read the documentation and see.

Cheers,
Dave

binpersonal
May 6th, 2012, 07:52 PM
Dave, thank you for so many valuable suggestions.


Ignore WinDriver to start with. Use PCITree to see if the BIOS programmed the 64-bit BAR0 correctly.

Who knows if your copy of WinDriver is setup to allocation 64-bit BARs? Read the documentation and see.

Cheers,
Dave

dwh@ovro.caltech.edu
May 6th, 2012, 07:54 PM
thank you for so many valuable suggestions.

Hopefully one of them gives you some insight as to what is happening.

Cheers,
Dave

binpersonal
May 11th, 2012, 02:18 PM
Thanks, Dave.

Then how to use Qsys to connect to large memory chip (DDR II)?

If I assign large Bar size covering the whole address of DDR II, computer will not boot.

What to do to make large memory chip to work with PCIe?

Thank you very much!



The PCIe spec will not stop you, but your particular hardware might. My EliteBook will not boot with a BAR of 256MB.



Because you did not change the BAR size by doing this. Look at the report on the Qsys GUI. Look at the synthesis report.

Look at this document here:

http://www.alteraforum.com/forum/showthread.php?t=35678

It has some comments.

To try and isolate this problem, start with just the on-chip RAM in the BAR at a base address of zero. You can use the "Address Map" tab to re-assign the addresses.

Once you can confirm that you can boot windows, you can increase the size of the BAR (the offset of the on-chip RAM) until it breaks. Then you will know the limits for your particular hardware setup.

Cheers,
Dave

dwh@ovro.caltech.edu
May 11th, 2012, 04:32 PM
Then how to use Qsys to connect to large memory chip (DDR II)?

If I assign large Bar size covering the whole address of DDR II, computer will not boot.

What to do to make large memory chip to work with PCIe?


You need to use slight-of-hand and indirection :)

You need to think of the memory map of your board as being independent/separate to the memory map of your x86 host. If you want to move results between your Qsys memory map and your x86 host memory, then you use DMA. The DMA controller needs to be able to see both PCIe addresses and Qsys addresses to be efficient.

If you use the x86 host to directly read and write to your Qsys system, it will not be very efficient (low data rate). Typically you use (slow) x86 transactions to setup the DMA controller, and then let it perform efficient transfers.

Cheers,
Dave

binpersonal
May 11th, 2012, 05:03 PM
but will it reduce BAR0 size? I just concern if my computer can boot.
Do you mean using DMA can reduce BAR0 size if the x86 host memory is still connected to Qsys ?



You need to use slight-of-hand and indirection :)

You need to think of the memory map of your board as being independent/separate to the memory map of your x86 host. If you want to move results between your Qsys memory map and your x86 host memory, then you use DMA. The DMA controller needs to be able to see both PCIe addresses and Qsys addresses to be efficient.

If you use the x86 host to directly read and write to your Qsys system, it will not be very efficient (low data rate). Typically you use (slow) x86 transactions to setup the DMA controller, and then let it perform efficient transfers.

Cheers,
Dave

dwh@ovro.caltech.edu
May 12th, 2012, 02:51 PM
but will it reduce BAR0 size? I just concern if my computer can boot.
Do you mean using DMA can reduce BAR0 size if the x86 host memory is still connected to Qsys ?

The BAR size will be reduced to whatever the common set of control registers requires.

Consider the following simple case. Lets say I have a DMA controller that has the following registers; 64-bit PCIe address, 32-bit Avalon (Qsys) address, direction (PCIe-to-Avalon or Avalon-to-PCIe), length in bytes, a control register and a status register. You need 7 32-bit registers to describe this. The minimum practical BAR size is about 256-bytes, but its more typical to use a page of the host memory, i.e., 4kB or 8kB.

You can program the DMA controller to move a block of data to or from any PCIe address (which includes the host memory) to an Avalon address, which includes your DDR memory.

Note how the host does not need to see the Avalon DDR memory, it is the DMA controller that needs to see those addresses.

Cheers,
Dave

binpersonal
May 12th, 2012, 03:06 PM
Thank you! Dave,

Do you mean DDR2 is not connected to PCIe Hard IP, it is only connected to DMA? What is the differences between PCIe address and Avalon address? Isn't PCIe address also Avalon address since it often uses Avalon MM interface?

Also, do you have examples/more detailed documents about this?

Thank you very much!



The BAR size will be reduced to whatever the common set of control registers requires.

Consider the following simple case. Lets say I have a DMA controller that has the following registers; 64-bit PCIe address, 32-bit Avalon (Qsys) address, direction (PCIe-to-Avalon or Avalon-to-PCIe), length in bytes, a control register and a status register. You need 7 32-bit registers to describe this. The minimum practical BAR size is about 256-bytes, but its more typical to use a page of the host memory, i.e., 4kB or 8kB.

You can program the DMA controller to move a block of data to or from any PCIe address (which includes the host memory) to an Avalon address, which includes your DDR memory.

Note how the host does not need to see the Avalon DDR memory, it is the DMA controller that needs to see those addresses.

Cheers,
Dave

dwh@ovro.caltech.edu
May 13th, 2012, 03:36 AM
Do you mean DDR2 is not connected to PCIe Hard IP, it is only connected to DMA?
DDR2 and DMA and the Qsys PCIe bridge would be connected to a Qsys system. However, its the operation of a PCIe-to-Qsys bridge that you need to understand.



What is the differences between PCIe address and Avalon address? Isn't PCIe address also Avalon address since it often uses Avalon MM interface?
No, PCIe addresses and Qsys addresses are two completely separate address maps.

Consider the case of 4 identical FPGA boards plugged into a motherboard. Those four boards could be configured with identical Qsys systems, right? Their Qsys address maps are therefore identical. How can the PCIe address map be identical to the Qsys address map? It cannot.

In this case, how would each of the boards DMA into x86 memory? Well, the host would access each of the board's DMA controllers via registers mapped into a BAR. Each board would be uniquely mapped into the x86 address map by the BIOS. The Qsys source address on each board could be identical, but the PCIe destination address would be unique to each board.

Draw a picture of the address maps, and you'll see that a DMA controller is really a 'bridge' that can see the Qsys address map on one side, and the PCIe address map on the other.



Also, do you have examples/more detailed documents about this?
No. This is pretty standard for PCI development. However, its not exactly documented anywhere, its more like "that is just the way it is". Once you understand it, it makes sense.

Read the data sheet of the PLX PCI9054 PCI bridge, or read the PCI section of the Freescale MPC8349EA PowerQuicc II Pro processor documentation, and you'll see very similar descriptions of the operation of the PCI bridges.

Cheers,
Dave

binpersonal
May 13th, 2012, 07:40 AM
Thank you! Dave, another question:

How to have a "Qsys PCIe bridge"? because I can not find it in Qsys component library. what is the exact name? or do we need to build one ourselves?

Thank you very much!


DDR2 and DMA and the Qsys PCIe bridge would be connected to a Qsys system. However, its the operation of a PCIe-to-Qsys bridge that you need to understand.


Cheers,
Dave

dwh@ovro.caltech.edu
May 13th, 2012, 04:30 PM
How to have a "Qsys PCIe bridge"? because I can not find it in Qsys component library. what is the exact name? or do we need to build one ourselves?
I'm investigating the Altera IP at the moment:

http://www.alteraforum.com/forum/showthread.php?t=35678

The existing Qsys component does not implement a DMA controller as part of the bridge, so it does not meet the requirements for what I would consider to be a decent bridge. I need to complete the MegaWizard flow review and then some of the SOPC components on the Altera wiki. If none of them have features that meet my requirements, I'll create a design. I'll then document it and post it to the Altera wiki. I'm currently working on a board design, so might not get started on the bridge design for a little while (since it does not impact the board layout, just the resources used in the FPGA).

What exactly are the requirements of your design? Perhaps I or someone else on the forum can suggest a solution that will get you working now.

Cheers,
Dave

binpersonal
May 13th, 2012, 05:54 PM
Thank you, Dave.

We have a PCIe Hard IP, 128M 16 bit DDR2 SDRAM and 21K 64-bit on-chip memory.

Qsys assigns 256MB for the DDR2 SDRAM due to Avalon MM interface, plus on-chip memory, the total size of Bar0 exceeds 256 MB, and we can not make it work with WinDriver and our computer (Windows XP).

It seems the maximum size of Bar0 for our computer is 256 MB.

So we want to make both DDR2 SDRAM and on-chip memory working, we want to reduce the size of Bar0.




I'm investigating the Altera IP at the moment:

http://www.alteraforum.com/forum/showthread.php?t=35678

The existing Qsys component does not implement a DMA controller as part of the bridge, so it does not meet the requirements for what I would consider to be a decent bridge. I need to complete the MegaWizard flow review and then some of the SOPC components on the Altera wiki. If none of them have features that meet my requirements, I'll create a design. I'll then document it and post it to the Altera wiki. I'm currently working on a board design, so might not get started on the bridge design for a little while (since it does not impact the board layout, just the resources used in the FPGA).

What exactly are the requirements of your design? Perhaps I or someone else on the forum can suggest a solution that will get you working now.

Cheers,
Dave

dwh@ovro.caltech.edu
May 13th, 2012, 06:07 PM
We have a PCIe Hard IP, 128M 16 bit DDR2 SDRAM and 21K 64-bit on-chip memory.

Qsys assigns 256MB for the DDR2 SDRAM due to Avalon MM interface, plus on-chip memory, the total size of Bar0 exceeds 256 MB, and we can not make it work with WinDriver and our computer (Windows XP).

It seems the maximum size of Bar0 for our computer is 256 MB.

So we want to make both DDR2 SDRAM and on-chip memory working, we want to reduce the size of Bar0.

That tells me what the hardware is, but it does not tell me anything about why. Here's a few questions;

1) What FPGA do you have on the board?

2) Why does the FPGA have memory? What is it to be used for?

3) Why does the host CPU need to see that memory?

4) What is your data flow?

For example, in my application I have high-speed ADCs and signal processing logic in the FPGA. The FPGA results will be written to DDR3 RAM, and then those results DMAed to the host CPU. There is a few MB of data that needs to be transferred every ~20ms. However, those results can be queued, and transferred as a larger DMA transfer every 500ms.

The host CPU will run Linux, and a device driver will setup the DMA controllers on multiple boards to DMA their results into main memory. The main memory will contain scatter-gather DMA buffers. The data will be moved out of the buffers once the host has processed the results.

You need to come up with a similar data flow description for your system.

Cheers,
Dave

binpersonal
May 13th, 2012, 06:45 PM
1) It is Cyclone IV GX speed grade 7, I modified the design in
http://www.alterawiki.com/wiki/PCI_Express_in_Qsys_Example_Designs
changed the DDR2 to our 128 M 16 bit DDR2 SDRAM.

2) The memory is to be used for storing some parameters/commands for signal processing

3) There is a lot of RF data from ADCs for the FPGA to process, CPU needs to send commands/parameters, also obtains processed data storage in DDR2 SDRAM from PCIe. I don't know if CPU needs to see that memory or not, if it does not need to see that memory, how to realize ? to get the data from DDR2 SDRAM?

4) FPGA processes the ADC data,CPU sends commands/parameters, access data in on-chip memory or in DDR2 SDRAM. displays processed data for real-time (30frams/s) images on screen.



That tells me what the hardware is, but it does not tell me anything about why. Here's a few questions;

1) What FPGA do you have on the board?

2) Why does the FPGA have memory? What is it to be used for?

3) Why does the host CPU need to see that memory?

4) What is your data flow?

For example, in my application I have high-speed ADCs and signal processing logic in the FPGA. The FPGA results will be written to DDR3 RAM, and then those results DMAed to the host CPU. There is a few MB of data that needs to be transferred every ~20ms. However, those results can be queued, and transferred as a larger DMA transfer every 500ms.

The host CPU will run Linux, and a device driver will setup the DMA controllers on multiple boards to DMA their results into main memory. The main memory will contain scatter-gather DMA buffers. The data will be moved out of the buffers once the host has processed the results.

You need to come up with a similar data flow description for your system.

Cheers,
Dave

dwh@ovro.caltech.edu
May 14th, 2012, 03:20 AM
1) It is Cyclone IV GX speed grade 7, I modified the design in
http://www.alterawiki.com/wiki/PCI_Express_in_Qsys_Example_Designs
changed the DDR2 to our 128 M 16 bit DDR2 SDRAM.


Ok.



2) The memory is to be used for storing some parameters/commands for signal processing


Why use the DDR memory for this? It would make more sense to me to use on-chip memory for parameters that the DSP logic will be using. Of course, that assumes there are a few parameters.



3) There is a lot of RF data from ADCs for the FPGA to process


That data should be going directly into the DSP logic. What actually needs to be stored in the DDR? A power spectrum? A cross-correlation?



CPU needs to send commands/parameters

Again, this likely should go to on-chip RAM and registers.



also obtains processed data storage in DDR2 SDRAM from PCIe. I don't know if CPU needs to see that memory or not, if it does not need to see that memory, how to realize ? to get the data from DDR2 SDRAM?

You will never want to use the host CPU to transfer anything but a few simple parameters. The performance of a CPU issuing a write or read command to a PCIe device is slow. Its fine for setting up a few registers, or initializing a DMA controller, but its ultimately just slow.

You need to talk to a device driver developer. They will explain that devices that transfer data, eg., network cards, video cards, data processing cards, do not use the CPU for moving the data, they use a DMA controller on each of those respective cards.

You should design the hardware to match the requirements of the device driver developer.



4) FPGA processes the ADC data,CPU sends commands/parameters, access data in on-chip memory or in DDR2 SDRAM. displays processed data for real-time (30frams/s) images on screen.

30 frames per second of what? An HD image, or a 1024-point power spectrum? This data defines your sustained data rate from your board to the CPU. Calculate it. This is your design target!!!

If your data rate is low, perhaps a simple CPU-based read of that data will be sufficient. However, in most applications it would not be, or it would be a waste of CPU time, and DMA will be your only option. If you do need DMA, then you can discuss with your device driver developer whether or not the Altera DMA controller has sufficient functionality for your requirements.

For example, in the Qsys PCIe example I sent a link to, the PCIe bridge can be configured with a 1MB outgoing translation window. If your device driver developer can guarantee that the host data used for DMA is located in a single 1MB region, then you can just use that DMA controller directly.

Cheers,
Dave

binpersonal
May 14th, 2012, 06:58 AM
Dave,

The data rate is high, DDR2 SDRAM is necessary to storage large temporary data to ensure real-time, and it is designed by my supervisor, not me.

My task is to make both DDR2 and on-chip memory work, not to avoid the problem by getting rid of DDR2 SDRAM or on-chip memory.

Could you tell me where is the link of your example ?
" in the Qsys PCIe example I sent a link to, the PCIe bridge can be configured with a 1MB outgoing translation window."

Thank you very much!


Ok.



Why use the DDR memory for this? It would make more sense to me to use on-chip memory for parameters that the DSP logic will be using. Of course, that assumes there are a few parameters.



That data should be going directly into the DSP logic. What actually needs to be stored in the DDR? A power spectrum? A cross-correlation?


Again, this likely should go to on-chip RAM and registers.


You will never want to use the host CPU to transfer anything but a few simple parameters. The performance of a CPU issuing a write or read command to a PCIe device is slow. Its fine for setting up a few registers, or initializing a DMA controller, but its ultimately just slow.

You need to talk to a device driver developer. They will explain that devices that transfer data, eg., network cards, video cards, data processing cards, do not use the CPU for moving the data, they use a DMA controller on each of those respective cards.

You should design the hardware to match the requirements of the device driver developer.



30 frames per second of what? An HD image, or a 1024-point power spectrum? This data defines your sustained data rate from your board to the CPU. Calculate it. This is your design target!!!

If your data rate is low, perhaps a simple CPU-based read of that data will be sufficient. However, in most applications it would not be, or it would be a waste of CPU time, and DMA will be your only option. If you do need DMA, then you can discuss with your device driver developer whether or not the Altera DMA controller has sufficient functionality for your requirements.

For example, in the Qsys PCIe example I sent a link to, the PCIe bridge can be configured with a 1MB outgoing translation window. If your device driver developer can guarantee that the host data used for DMA is located in a single 1MB region, then you can just use that DMA controller directly.

Cheers,
Dave

dwh@ovro.caltech.edu
May 18th, 2012, 10:19 PM
The data rate is high, DDR2 SDRAM is necessary to storage large temporary data to ensure real-time


Then you have no choice but to use DMA. You cannot efficiently transfer data using the host CPU.



it is designed by my supervisor, not me.


And is your supervisor aware of how to design PCI and PCIe systems and how to write Linux device drivers? Is he aware of the differences in address maps? Has he been reading these forum messages? (Please ask him to).



My task is to make both DDR2 and on-chip memory work, not to avoid the problem by getting rid of DDR2 SDRAM or on-chip memory.


I never indicated you had to get rid of it. However, it is unlikely you can ever have the host CPU see all memory on your board via a BAR. As I commented earlier, I have a 64-bit HP EliteBook with 16GB of RAM, and if I use a PCIe BAR of 256MB, that CPU will not boot. So, this issue is not solved by simply using a 64-bit host CPU, its only solved by avoiding it altogether, by using DMA between the Qsys address map and the PCIe address map.



Could you tell me where is the link of your example ?
" in the Qsys PCIe example I sent a link to, the PCIe bridge can be configured with a 1MB outgoing translation window."


Its part of the PCIe core configuration. The core gets configured with two 1MB outgoing translation windows, eg., see p8. This window can be used to access any location in the PCIe address map. Using the Qsys DMA controller, you can access two 1MB regions of the host memory. This is not as flexible as a Qsys-to-PCIe bridge with a DMA controller embedded inside it, however, since that component does not exist, you need to figure out whether you can live with the existing solution.

Cheers,
Dave

binpersonal
May 24th, 2012, 07:36 AM
Dave, p8 of which document? I can not find your information in page 1-8 of ug_pci_express.pdf

Thank you very much!




Its part of the PCIe core configuration. The core gets configured with two 1MB outgoing translation windows, eg., see p8. This window can be used to access any location in the PCIe address map. Using the Qsys DMA controller, you can access two 1MB regions of the host memory. This is not as flexible as a Qsys-to-PCIe bridge with a DMA controller embedded inside it, however, since that component does not exist, you need to figure out whether you can live with the existing solution.

Cheers,
Dave

dwh@ovro.caltech.edu
May 24th, 2012, 08:41 AM
Dave, p8 of which document? I can not find your information in page 1-8 of ug_pci_express.pdf
Wrong document. Earlier in this discussion I directed you to read the document I posted in this thread:

http://www.alteraforum.com/forum/showthread.php?t=35678

The Cyclone IV GX designs meet timing if you turn on multi-corner timing analysis. I'm still working through an Altera SR to get the Stratix IV GX design to meet timing.

Cheers,
Dave

GZoinker
May 25th, 2012, 03:27 AM
The Cyclone IV GX designs meet timing if you turn on multi-corner timing analysis.
Cheers,
Dave

I need to reply about this in that other thread but I have a design which is...

CycloneIV '7
Hard IP PCIe core
Avalon MM interface with Qsys design flow
A fair bit of custom logic, but a fairly simple Avalon interface
My logic drives DMA to the host memory using the address translation tables as above
125MHz core clock.

This doesn't meet timing (with a pcie core clock to pcie core clock path setup failure), although the PCIe user guide says this configuration should work in all '7 devices.

I raised an SR but a project archive doesn't include the *.qsys file, and as whoever handled the SR couldn't open the qsys project they simply marked the SR as closed. :eek:

I don't actually need the 125Mhz clock so am using the 62.5MHz option but could have had my fingers burnt here.


Nial.

dwh@ovro.caltech.edu
May 25th, 2012, 07:16 PM
Hi Nial,



This doesn't meet timing (with a pcie core clock to pcie core clock path setup failure), although the PCIe user guide says this configuration should
work in all '7 devices.


I've updated the PDF and zip file linked to in the original thread:

http://www.alteraforum.com/forum/showthread.php?p=147114

I edited the C4GXSK constraints.tcl script to use a -7 speed grade, and I can confirm that timing fails for that speed grade. I agree that this is inconsistent with the PCIe Compiler Users Guide. I still can't get the Stratix IV GX x8 design to meet timing either.

Cheers,
Dave