BillM256
Occasional ContributorJoined 4 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: DE10-Nano mix GPIO I/O directions
Hi Sstrell, I think I'm getting it now. My mistake is in thinking Fitter or some other auto-mechanism would assign pins for me if I gave them "System Recognizable Names" in the schematic and/or the .v. I see now that this is not the case; I can name them whatever and then manually assign them in Pin Planner to connect them to GPIO_1, right? Yes, it's All Pins List. No, not using Project Template, just the .v, which is included in an earlier post above. I'd really appreciate your confirmation that I now have this right or correction if I don't. Regardless, I plan to close the case after hearing from you and greatly appreciate you staying with me on it. Fact is, this was supposed to just be an easy test of some of my design approaches. The system I'm working toward will have much more than can be handled with the GPIOs and will require me to implement an I2C with Bus Expanders (MCP23017). Thanks, Bill7.1KViews0likes1CommentRe: DE10-Nano mix GPIO I/O directions
Hi Sstrell, Thanks for the info. As before, I've embedded my specific responses in red. I've also included several attachments: 1. Schematic portion 2. Pin Planner auto-assignments 3. GPIO_1 pins 4. Error when I try to manually assign GPIO_1[16] I never saw this response so never responded. Not surprised; my initial reply was dropped and I had to repost several days later. The names you give have absolutely no affect on their use. Naming something "GPIO" doesn't mean anything to the compiler other than you have a top-level I/O named "GPIO". My experience is different. If I only spec GPIO_1 input pins in the .V, I get a clean compile and Pin Planner is updated with those pins in the process. See attachments 2 and 3. I'm not sure I understand what issue you are seeing. You say "I'm told they already in use." What does this mean? What error are you seeing? As described, the GPIO_1 input pins were assigned automatically for me (Fitter?) Now my problem is to assign my GPIO_1 output pins, starting with [16], which is PIN_AG24. This is where I get the error shown in attachment 4. Can you post screenshots or better describe what is not working as you expect? If you do not create specific pin location assignments in the Pin Planner, the Fitter creates suggested assignments that would be used if you programmed the device. You use the Pin Planner to pick the specific locations you want to use. Thanks as always, Bill7.1KViews0likes0CommentsRe: DE10-Nano mix GPIO I/O directions
Hi Amin, I understand from Ashlesha that you've agreed to help, many thanks! I never closed this case; I just didn't get an answer to my last post. The open issue is mixing inputs and outputs on a single GPIO header of a DE10-Nano. Simple example: GPIO_1[1] = Input; GPIO_1[2] = Output; (and perhaps GPIO_1[3] = BiDir). My original post gives more detail including things I tried unsuccessfully. Seems this should be easy, but I haven't figured it out, and, so far, no one has furnished the explanation. Thanks again, Bill7.1KViews0likes0CommentsRe: DE10-Nano mix GPIO I/O directions
Hi Sstrell, I thought I’d successfully replied several days ago, but apparently it didn’t take. My responses embedded below in red. Thanks, Bill You can't use the same name for multiple top-level ports, as the error states. Yes, completely understand. You could have something like GPIO_in and GPIO_out, each with the appropriate range, [15:0] and [19:0], respectively. This is where I’m having trouble. I tried very similar pin naming, but, because they’re not named exactly GPIO, Quartus assigns them other than GPIO Pins. I tried using Pin Planner to reassign them to GPIO Pins. But, because they’re reserved for GPIO I guess, I’m told they already in use. The pinout of the device, configured in the Pin Planner, is where you'd differentiate between the upper 20 pins and the lower 16. I suspect this is the answer, but I haven’t been able to figure out how to do. Would you please elaborate? Same thing for your schematic. And there's nothing wrong with a top-level HDL file. But to add the schematics, you have to instantiate them in the HDL code like any other code instantiation: <component name> #(<parameter mapping if any>) <instance name> (<port map>); For example for a simple multiplier with a single parameter, give it a unique instance name, pass in the mult_size value to the width_in parameter, and map each signal in top-level HDL code with the port in the instantiated design: multa #(.width_in(mult_size)) u1 (.in_a(dataa), .in_b(datab), .mult_out(mult_out)); The dot (.) ports are the ports of the lower-level design. The signal names in parentheses are the signals they connect to. If you're not familiar with the basics of Verilog, this is a good place to start: https://learning.intel.com/developer/learn/course/external/view/elearning/235/verilog-hdl-basics Thanks, I’ll definitely study. I’ve come to appreciate how powerful HDL is compared to conventional schematics. However, for this project, I need the schematic, visual presentation.7.3KViews0likes5CommentsRe: DE10-Nano mix GPIO I/O directions
Hi Sstrell, Thanks as always for weighing in. A segment of the schematic is attached. This isn’t the final design, it’s a simple test to figure out if I know what I’m doing. As such, it’s been successful at demonstrating I don’t. HDL is below. It codes what I’m trying to accomplish with a mix of GPIO_1 inputs and outputs and generates the following error: Error (10134): Verilog HDL Module Declaration error at FullRegister.v(26): port "GPIO" is declared more than once I guess the fundamental question is: is HDL the right approach to declaring the top-level? If it is, how do I get the Fitter to assign my schematic inputs and outputs to the appropriate GPIO_1 pins? As to my second question: I read that I should instantiate my schematics in the HDL. The schematic is RegU.bdf, ultimately, my design will have many .bdfs. So, the question is do I instantiate all in the HDL, and if so, how? Thanks again, Bill McDonald module FullRegister( //////////// CLOCK ////////// input FPGA_CLK1_50, input FPGA_CLK2_50, input FPGA_CLK3_50, //////////// KEY ////////// input [1:0] KEY, //////////// LED ////////// output [7:0] LED, //////////// SW ////////// input [3:0] SW, //////////// GPIO_1, GPIO connect to GPIO Default ////////// input [15:0] GPIO, output [35:16] GPIO ); //======================================================= // REG/WIRE declarations //======================================================= //======================================================= // Structural coding //======================================================= endmodule7.4KViews0likes0CommentsDE10-Nano mix GPIO I/O directions
Hello, I’m stuck on what should be a simple problem. HW: DE10-Nano SW: Quartus Lite v. 20.1.1 Goal: I need mixed GPIO_1 directions, i.e., some Input and some Output. Problem: When I try to define a mix of I/O in the top-level .v file, the compiler errors on multiple instances of “GPIO_1”. If I define them in a single direction, Pin Planner won’t let me change them, and primitive pins in my schematic are ignored by Pin Planner. I’ve tried multiple other fixes and none work. A second question: I’m told I need to spec schematic .bdf files in the top-level .v file. Is this correct? How specifically is this done, i.e., what section in the .v and how within the section? Thanks in advance, Bill McDonaldSolved7.4KViews0likes13CommentsRe: Quartus assigns Pins labeled Input and Output as Bidir
This is a simple test to confirm what I’m doing will work before I invest too much repeating errors in the overall system. Using the un-clocked Preset and Clr inputs is an easy way to do this test. Ultimately, design I sent is for Control Panel buttons and indicators; in the final design, the Ds and Clocks will be used for inter-register xfers. Among the many, many Quartus documents and videos available, I found one that recommended extending buses as I have. You’ll probably recognize that one of the major challenges for learning this complex device and all surrounding it is the plethora of info, some very helpful and some awful, with no good way to filter chaff from wheat. Regardless, as you suggest, I removed the bus-extensions and recompiled. It made no difference, including to the single-pin, un-extended GPIO_15. I.e., all pins still Bidir. Thanks, Bill3KViews0likes0CommentsRe: Quartus assigns Pins labeled Input and Output as Bidir
Hi Sstrell, Thanks as always for the help. I had the same thought about a conflict but have been over and over the design and can’t see a problem. I wonder if there’s a file assignment by System Builder that’s causing the problem, but I can’t find that either. Also, I did the 2-bit test described previously also using System Builder, and no problem with it. In my original posting, I neglected to include what’s possibly the most interesting evidence. GPIO[15] is a non-bus, single-pin input, and it, like the buses, is assigned Bidir by Quartus. See my 03 attachment. I broke the full design into 3 clips of 5-bits each, so the resolution should be adequate. My best, Bill3KViews0likes0Comments