pnp
New ContributorJoined 4 years ago
User Profile
New Contributor
User Widgets
Contributions
Re: Questa: Cannot checkout an uncounted license within a Windows Terminal Services guest session
Hi Wani, Thank you for your reply. I checked my email, including spam folder and didn't see anything. I also checked the private messages in this forum and confirmed the email address in my profile is correct. Not sure what happened. Best regards, PaulQuesta: Cannot checkout an uncounted license within a Windows Terminal Services guest session
Due to the pandemic, I remotely access my development computer in the office via windows remote desktop. I am attempting to use the free Questa-Intel FPGA Starter edition v2021.3. In this issue, the resolution is to create a floating license. I don't see that as an option at https://licensing.intel.com/psg/s/sales-signup-evaluationlicenses for the Questa-Intel Starter edition. Error message: How can I use the Starter edition from remote desktop? Thanks, PaulRe: DDIO Output Timing Errors on a Source Synchronous Interface (RGMII)
Edit: Sorry, I should have read more thoroughly--you're referencing timing violations, not a broken interface. Best regards, Paul --- Hi, I'm not sure if this relates to your issue, but I got recently got burned trying to apply that Application Note by the DDIO IP's port naming. It turned out my forwarded clock was inadvertently flipped 180 degrees, breaking my source synchronous interface: https://community.intel.com/t5/FPGA-Intellectual-Property/GPIO-DDRIO-IP-output-swapped-datainhi-datainlo-inverts-forwarded/m-p/1317982#M24752 The documentation for that IP is not my favorite.Re: GPIO DDRIO IP output swapped: datainhi/datainlo inverts forwarded clock
Amin, Thank you for looking into this issue! That is exactly where I ended up: I swapped the din values as you did. I see the waveform you posted from the documentation, but that is for half-rate conversion. We are not doing half-rate conversion in this case. My issue is that the behavior contradicts the documentation: from https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_gpio.pdf In this case, datain_width is 1. So datain_h = din[(2 * 1 - 1):1] = din[1:1] and datain_l = din[(1 - 1):0] = din[0:0] which matches what I see in the technology mapped netlist (see my initial post in this issue). The comment at the end of the document states: which is what I expect to happen, however swapping values in din is required to get the expected behavior. Thanks, PaulRe: GPIO DDRIO IP output swapped: datainhi/datainlo inverts forwarded clock
Looking at the very bottom of ug_altera_gpio.pdf there is this note: I feel like this is a clue, though this paragraph is as clear as mud to me. In my case I did not migrate the IP, I am not using the legacy top-level port names, and the port meaning in that bullet list is what I expect the IP to do.GPIO DDRIO IP output swapped: datainhi/datainlo inverts forwarded clock
I have a source-synchronous interface for which I am forwarding a clock with a DDRIO register as recommended in AN433 pp6-7 to minimize skew between the clock and data waveform: I created a GPIO IP in Quartus Prime Pro 21.1 to forward the clock: and instantiate as follows: module ddriotest ( input logic clk, output logic clk_fwd, output logic [7:0] data ); // forward clock ddr_output i_ddr ( .ck(clk), .din(2'b10), .pad_out(clk_fwd) ); // generate example source synchronous output data logic [7:0] count = '0; always @(posedge clk) count <= count + 1'b1; always @(posedge clk) data <= count; endmodule When I look at the post-fitter technology map netlist, I see DATAINHI = 1'b1 and DATAINLO = 1'b0 on the DDIO_OUT primitive, which matches the connections shown in AN433 to forward the clock (see pic above for comparison): But when I simulate this project, I see: Notice that clk and clk_fwd are inverted with respect to one another! I believe they should be in-phase aside from Tco delay and clock delay, and both of those delays wouldn't be present in this functional sim. I have to swap din[0] and din[1]to get desired behavior. I have good reason to believe this is happening with the actual hardware as well, so it isn't just a sim issue. I've followed the connection all the way to the cyclone10gx_ver.cyclone10gx_ddio_out primitive, which is encrypted so I can't look any further. Why is this inversion taking place? I'm using Quartus Prime Pro 21.1 and GPIO IP 20.0 with Questa Intel Starter Edition-64 21.1 (beta) for a Cyclone 10 GX device. Full example project and sim attached. Thanks, PaulRe: Bus index reversal when SystemVerilog module instantiates a BDF in Quartus Prime Pro 21.2
I agree with your sentiment about these schematics, and I can't wait to be completely rid of them. I don't think there are any extra wire bits in the .bdf. I opened it in Quartus II 9.1 SP2--that's all I have installed that can generate BDF->HDL--and generated a Verilog HDL file for it. Quartus 9.1 created a compact, correct representation for it: // PROGRAM "Quartus II" // VERSION "Version 9.1 Build 350 03/24/2010 Service Pack 2 SJ Full Version" // CREATED "Tue Aug 31 08:30:37 2021" module bdftest( clk, x_in, y_out ); input clk; input [7:0] x_in; output [7:0] y_out; reg [7:0] y_out; always@(posedge clk) begin begin y_out[7:0] = x_in[7:0]; end end endmodule If I instantiate that in my Quartus Prime Pro 21.2 project instead of the .bdf, I get a correct instantiation: If I instantiate that same .bdf rather than the generated verilog file in my v21.2 project, I get reversed connections. One gotcha I ran into was that regardless of the files listed in the project, the generated HDL file would get picked up for synthesis rather than the BDF if it was left in the project directory. Are you suggesting that as the workaround: generate the HDL for the .bdf from an old version of Quartus and use that in the project? I can give that a try. Thanks, Paul Edit: attached the .bdf. Had to add a .txt extension to get the forum software to allow me to attach. This is further proof these schematic files are antiquated: you can't even post them to the forum as-is!
