SimonRichter
Occasional ContributorJoined 5 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Debugging PCIe transfers on IVB iGPU
Hi, I'm trying to pull data from an FPGA card into the iGPU on an older IVB system. This machine has an 8086:0150 Host Controller as 0:00.0, and an 8086:0162 iGPU as 0:02.0; the FPGA is connected as 1:00.0. I have created a p2p dma_buf in Linux, exported that from my driver as a file descriptor, imported it on Vulkan, and am now trying to vkCopyImage data from the imported image to a texture, converting to Y0 layout in the process. I get no complaints from the validation layer, and adding a bunch of printk()s allowed me to validate that the GPP PTEs for the BAR are created, but no TLPs arrive. Checking the opposite direction with a read request to the 256M prefetchable range of the iGPU device 00000002 0100aaff e0000048 gives me back UR 0a000000 00002008 0100aa48 while for arbitrary memory addresses, e.g. 00000002 0100aaff 50000048 I get successful completion with some garbage data 4a000002 00000008 0100aa48 xxxxxxxx xxxxxxxx The UR seems to be generated by the root complex, which would suggest that I can't use address-routed TLPs between devices, which would also explain why I'm not seeing a TLP from the iGPU in my FPGA. Is that correct, or have I forgotten something? Simon1KViews0likes2CommentsRe: FPGA Programming Via USB instead of Programming Pod
Hi, you can use any JTAG adapter you want, or build your own, provided you don't use SignalTap or time-limited components -- these two features still require the Altera USB Blaster. For any other design, convert your file to SVF format, that lists the exact sequence of JTAG signals to initialize the FPGA in a readable format that can be interpreted e.g. by OpenOCD. Simon2.9KViews1like1CommentRe: Stratix V DDR3 simulation not working. All memory signals undefined.
Hi, I have a similar issue with a simulated UniPHY based CycloneV DDR3 controller. I've tracked it down to the the CSR port on the DDR3 block, which isn't reset properly, so its csr_waitrequest, csr_rdata and csr_rdata_valid signals remain undefined. The issue seems to be that the component instantiation_name_0002 (with "instantiation_name" replaced by the actual name) contains a signal csr_reset_n_ports_inv that is uninitialized and passed as the reset signal to the mm_interconnect_1 instance contained within it. It's obvious that this is an error, as that name exists only twice in the whole file, once as the signal definition and once where it is connected to an in port. Inserting a line csr_reset_n_ports_inv <= not csr_reset_n; somewhere in the architecture body fixed this. If the design connects both the CSR and the AVL ports to the same bus, this will make the entire bus appear as 'U' in simulation. Simon1KViews0likes0CommentsRe: Controlling output files when generating IP from the command line
Hi Adzim, sorry for the late reply, I'm swamped with other work right now. I'm using Quartus 20.1. Generating with the GUI allows me to deselect the additional files in the last wizard page, and then opens a separate dialog that allows me to deselect the examples, and then these files are not generated. These settings aren't saved in the retrieval info section, so regenerating non-interactively falls back to defaults. The scripts you mention generate the examples -- my goal is to stop these from being called during non-interactive generation to save time here. Simon1.4KViews0likes0CommentsRe: EMIF controller and DDR4
The initial configuration is done by the memory's sequencer block, from the IP settings, so in the simple case, you don't need to use this interface at all and you can disable it. U-Boot could use these registers during a memory test, and the operating system could use those registers to detect ECC errors at runtime, so if that is desired, you'd connect the interface to the soft CPU's data bus.1.3KViews1like0CommentsRe: Simulation: override warnings during compilation, and Intel rebranding breaking generated scripts
Hi Nurina, the one attached to my earlier post should work for that -- it compiles and simulates because I've used the workarounds I've described, and the scripts implementing those are included in the archive. Simon5.1KViews0likes0CommentsRe: Simulation: override warnings during compilation, and Intel rebranding breaking generated scripts
Hi Nurina, I wouldn't call this "solved" though: I have workarounds that allow me to continue by editing autogenerated files -- as you say, that isn't a good idea, but at least it unblocks my progress. I have ModelSim and Quartus installed from the same download archive (the 20.1.1.720 "full"), and no other versions of either are installed, so I can verify that this script has been generated with Quartus 20.1, and the libraries are also the ones included with Quartus 20.1 -- hence my assessment that the generated script is incorrect, as it checks for the wrong string in the version to assess whether the Quartus and ModelSim versions are compatible. The mismatch between the QIP and SPD files seems to be a regression from earlier Quartus versions: I have an older project that uses Quartus 16.1, and generated IP blocks there are added to the "work" library for both synthesis and simulation, so at some point between 16.1 and 20.1 a decision was made to add a -library tag in the QIP file to move the main component of the IP block into a library, but the same change wasn't made for SIP files. Simon5.2KViews0likes0CommentsRe: Simulation: override warnings during compilation, and Intel rebranding breaking generated scripts
Hi Nurina, I've made a quick demo project that shows the problem, with just a PLL and a DDIO as IP components. My simulation setup was really close to the quickstart tutorial already, and I've redone it in the test project to rule out errors here. The `sim.tcl` script included in the archive follows the layout of the template generated from the quickstart tutorial, the `sim.sh` just wraps generation and ModelSim invocation: ip-setup-simulation --output-directory=simulation --quartus-project=sim_test cd simulation vsim -batch -do ../sim.tcl Inconsistent names The name of the "doubler" component (the PLL in the test project) is doubler.doubler in synthesis, and requires a use clause, but work.doubler during simulation. I can work around that with pragmas, but that is far from ideal: -- synthesis read_comments_as_HDL on -- library doubler; -- use doubler.doubler; -- synthesis read_comments_as_HDL off to make the library import conditional on synthesis, and -- synthesis translate_off pll_inst : entity work.doubler -- synthesis translate_on -- synthesis read_comments_as_HDL on -- pll_inst : entity doubler.doubler -- synthesis read_comments_as_HDL off to use the imported name during synthesis, and the name inside `work` during simulation. The DDIO component is not affected, as it uses an older format and is never loaded into a separate namespace (I also need to explicitly compile that in my sim.tcl script, as no SPD file exists for this component, so it is ignored by ip-setup-simulation). Recompilation of shipped libraries The generated ModelSim setup script (simulation/mentor/msim_setup.tcl) has a conditional section that isn't supposed to be executed when using the ModelSim included with Quartus, which recompiles the shipped libraries. For the simple project, that isn't much of an issue (just takes longer), but for the project that uses DDR3 memory and transceivers, these are less optimized models, which increases simulation time. Removing the section between if ![ string match "*ModelSim ALTERA*" [ vsim -version ] ] { and the corresponding closing bracket from the generated msim_setup.tcl reduces both compilation time (dev_com becomes a no-op) and uses the shipped libraries. With the sim.sh script in the QAR file, this can be tested by deleting the "simulation" folder (to start with a clean slate) and invoking the script as rm -r simulation ./sim.sh f This applies a (crude) fix that deletes the conditional sections. My interpretation is that the ModelSim version included with Quartus is supposed to skip these sections always, but the branding update from "ALTERA" to "INTEL" broke this test. Extracting the library names can be skipped when using the "elab" command as defined by the msim_setup.tcl script -- that includes all necessary -L options, and I can work with that, thanks for the pointer to the quickstart that shows how to actually make this usable. Simon5.2KViews0likes0Comments