--- Quote Start ---
I feel a bit like an idiot asking more of you but ...
--- Quote End ---
Don't feel bad. The tools are complicated and the official documentation and examples often suck ...
--- Quote Start ---
I did get stuck in your directions very close to the end at the "Source Contraints" step. I found the .tcl file, but I'm not sure how to source it
--- Quote End ---
The word 'source' is Tcl programming terminology.
In Quartus, you click the mouse in the Tcl console window (View->Utility Windows->Tcl console), and at the tcl prompt you type
tcl> source $TUTORIAL/hdl/s4gxdk/share/scripts/constraints.tcl
--- Quote Start ---
I assume once I do that successfully the following line of code will work, but at the moment it does not for me.
--- Quote End ---
Let me know if it doesn't.
--- Quote Start ---
I also tried your autogeneration thing, but quartus 12.1 threw a bit of a fit.
--- Quote End ---
If you have trouble sourcing the constraints file, I'll re-run the test on 12.1 and fix the problem.
--- Quote Start ---
I would rather step through it instead of auto-generating though, so I'm more interested in what you meant about those constraints.
--- Quote End ---
Excellent attitude! :)
--- Quote Start ---
Everything I've seen always has a DMA block connected to the pcie block. Since my data transfers are relatively basic, I was wondering if that was really necessary (I've read DMA has a large overhead, and so is not efficent for small amounts of data).
--- Quote End ---
It depends on what and when you consider programming the DMA controller 'overhead'.
The naive way to think of using a DMA controller is that you use the processor to write the DMA controller registers to setup the transfer, and then wait for the interrupt to indicate the DMA transfer is done. That is overhead.
The more typical way to use a DMA controller is that you use the processor to setup a scatter-gather buffer of "things to do", and then enable the DMA controller to do them completely independent of the CPU. The CPU may or may not have to service ISRs, depending on what your scatter-gather buffer is doing, eg., reading a temperature sensor and DMAing the result to a 7-segment display can be done completely independent of the CPU.
Anyway, that'll give you an idea of why a DMA controller might be useful.
With respect to PCIe transactions, the most efficient transactions are always implemented by a bus master issuing burst transactions. An x86 CPU or NIOS II CPU will not generate those sorts of transactions, so you use a DMA controller.
--- Quote Start ---
From a curiosity standpoint, is there a way to configure this thing without having to use the host PC? Isn't there a way to find the PCIe addresses without just finding it on the host PC? I thought my idea of polling the physical addresses wasn't the worst thing...
--- Quote End ---
You need a PCIe end-point to configure the PCIe address map. The PCIe end-point is generally the source of the PCIe reference clock and in the old-days of PCI, it was where the interrupt lines routed and the bus arbiter lived. You can do this with an FPGA, but that is not how the development boards are wired.
--- Quote Start ---
And as a more general question, is the purpose of this whole thing to have something like a PCIe block that just has a more basic interface (tx/rx) kind of thing to be used in other designs?
--- Quote End ---
Which "whole thing" are you talking about? The Qsys PCIe block? The purpose of that block is "a black box that can speak PCIe" :)
The alternative is implementing TLP packet parsing ... refer to the PCIe spec ...
Cheers,
Dave
Honored Contributor
