engrpetero
Members-
Posts
182 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
engrpetero's Achievements
-
Thanks @Viktor Nikolov. I figured parameters were probably a good way to go about this.
-
engrpetero started following Different GPIO driver versions? , module knowing clk frequency , (very) beginner question and 2 others
-
I'm playing around with a pretty simple module, the intent of which is to trigger some outputs at specific time intervals (e.g., 1ms, 50ms, 100ms). So the module has some simple counters that count clk pulses to determine when timed outputs should change. I'm trying to figure out efficient/good ways for the module to function correctly with different input clock frequencies. Since I don't think there is a way for the module to 'know' the clk frequency - it can merely act to count clks - I'm trying to think of other options. I *guess* the module could have a parameter a module user could set and internally, it could act on that parameter. Are there other mechanisms?
-
Thanks for the response. I sometimes see a mixture of these things in the same code samples and usually just pass it off as readability or ease of understanding. The 'evaluate as 32 bits wide' comment is certainly a useful one as is the comment about potentially being treated as signed or unsigned. I'll find a copy of the standard and see if I can glean anything else. When I am using constants, particularly with large numbers, I often find a base 10 representation to be easier to visualize (so 10000 instead of 0x2710). If I'm masking something off, I often use 4'b1100 instead of 4'hC as I think it is easier to visualize the intent.
-
I must have missed that day in class. Sometimes (often?) when I look at example verilog code, I'll see statements like shown in the code snip below. My understanding (through reading and in practice) is that all of these samples show valid ways to set the registers to 0 or in the case of test2, to 5, and the difference is in readability (or to get a point across considering the vector). Am I wrong? reg test1; reg [3:0] test2; // set to 0 test1 <= 0; test2 <= 2'b00; test2 <= 0; // set to 5 test2 <= 4'b0101; test2 <= 4'h5; test2 <= 5;
-
I never responded your post, @artvvb. When first getting back into Verilog designs, I got familiar with the Vivado and Vitis tools, mainly from Digilent website links and tutorials. One thing led to another and eventually, I made a few very simple IP Packaged designs and at the time saw the usefulness. At the same time, I was not aware of other tools, templates, workflows and unfortunately due to business reasons and time demands, didn't have time to look into them. I'll get to do so soon, I hope. There are a few designs I share with others and having the IP packaged does seem to work very well for sharing. There is some time involved in the packaging, but that time is much less than the Syn-Impl-Gen Bitstream time so probably doesn't matter much in the big picture. One good thing having focused much on the IP Packager design workflow/methodology/whatever you call it is it forced me to figure out better ways to test (your guys posts have been invaluable in also figuring out better ways). With my computer, the SIGB process takes about 8 minutes. So to waste as little time as possible, I try to be very confident with things like test benches and implementing hardware debug features (easily configurable from software but not intended for the final hardware) that the designs will work before even beginning the SIGB process. Sometimes that's a pain but in the long run saves time. You guys know this - it's just good design practice. Things that continue to trip me up relate to the way the Vivado tool works, where it pulls info from, what gets 'pushed' to higher level designs, etc. And I am still woefully 'under-knowledged' on design rule setting (or checking) or on fixing what I often feel are trivial warnings (at least none have come back to bite me yet). rggen and cheby are on my list to research. As always, thank you for taking the time to respond.
-
Well, this is the darndest thing. The 0xFFFFFFFF address always shows if the names in that 'tcl' file @artvvb mentioned several posts above are not consistent with the names of the AXI bus in the peripheral itself. I can't figure out how to get that file to 'reset' itself. So I manually edited it to provide the correct names. Even so, when updating the hardware in Vitis, the address is still not right. Fortunately, if I manually edit the base address value in the xparameters.h file (or better yet, where it's used in the Vitis application project), I can access the peripheral as expected. I compared the Ports, AXI Bus settings, etc., between this peripheral and a peripheral that works fine (meaning the Vivado-to-Vitis 'train' works correctly) and I can find no differences. I did not yet try simply creating a brand-new peripheral using the same verilog files to see if that fixes the issue. Obviously not too much work to try this - I just haven't had time yet.
-
@Pavankumar Gogula - This thread was intended to examine issues with IP addresses ways people were doing Vivado code reuse. You might get more responses if you started a new thread. Do that, please, and provide some additional details (for example, I don't understand your comment 'using the IP method'). In your schematic, what do you mean you 'there is no clock signal on the PL side'? If you a missing a clock, why don't you add one? Again, a separate thread though is the way to start.
-
This ought to be in a new thread. But what have you done so far?
-
I have a few questions of the ways you guys handle such things, primarily towards reuse and maintainability. (Almost) anytime I consider a new feature for a module (or custom IP), I add the module as a source to a 'TestItems' project. THis project also contains several test benches for testing new modules. So the actual verilog files are under the TestItems.srcs/sources_1_new folder of the TestItems project. Once I'm happy the module works in the TestItems project (I get the expected results from the test bench), I then allow reuse of the module so it can be instantiated in other modules (or custom IP). Conceptually, this makes sense to me - in theory, the versions in the folder above *should be* 'correct' and I ready for reuse. Following the custom IP route, when I make a new custom IP (often only after I've tested as a simpler RTL module), and I want to reuse something from the TestItems project, I'll add as design sources the desired TestItems modules to the custom IP project. When adding design sources, I'm often unsure about what to do with the check box that says 'Copy Sources into IP Directory'. My assumption (and experience) when I check that box is the sources I'm adding get copied to the custom IP's sources (new) directory. Which means there are local copies with the IP and then it's my manual responsibility to ensure if changes are made, they stay consistent with my TestItems 'gospel' source. Also, if the files are not local, then weird things happen with the Files group when repackaging IP. I might have a follow up to this question after seeing some responses.
-
I am using Vitis Classic and still using Vivado 2023.1 so I think your post applies. I've spent some time this morning looking into your comments and my peripherals and it's opened a lot of questions to me, more about how the tools work than any verilog code itself. And perhaps I should be looking for some best practices (or at least things you guys to that give you ease of use and ease of maintenance). I think I'll continue that line of discussion in another post and keep this one for additional info I learn or about which I have questions.
-
Yeah, in this instance, I even created a new HW platform using the XSA file and no luck. There must be something to the 0xFFFFFFFF (not anything normal). I found this thread on one of the Xilinx/AMD fora but it hasn't proven helpful yet. IP Address of 0xFFFFFFFF in one of the first few comments, stephenm (AMD) offered this comment but I have no idea what the 'p' parameter is... 0xfffffff is the default if the p parameter is not found. Can you share your driver and I'll have a look? Further down, UserNotFound offered a suggestion about the ' TCL file in the data folder of the driver' for both a peripheral that is working correctly (that is, one I can change the address of) but looking at the file wasn't helpful. In neither case did the TCL file contain information about the base address/offset.
-
More weird behavior I don't understand. I have a few peripherals in a project. I've had no issue changing their Addresses up until this morning. I adjust them in the Address Editor in Vivado, synth, implement, gen bitstream, export hw (SIGBE) for use in Vitis. In Vitis, one of the peripherals base address in the xparameters.h file never updates though. In fact, it always shows incorrect (default) addresses. I've tried changing it a few times to similar random addresses, I even removed it and readded it to my project (doing the SIGBE sequence while it was removed, then again when readded). For the config shown in the pics below, I expect to find the item in the xparameters.h file defined as 'XPAR_ADSSIP_0_S_AXI_BASEADDR' (not the XPAR_ADSSIP_0_S00_AXI_BASEADDR shown) as it is virtually identical to the other two items highlighted. Internet searches concerning the issue have not been helpful. Any thoughts as to why the changes are not getting to Vitis?
-
artvvb reacted to an answer to a question: Different GPIO driver versions?
-
Thanks @artvvb. As the error message indicated, somehow the driver version for that one GPIO item was set to 4.9. I changed in on the drivers tab to 4.10 to match the others (on both the zynq_fsbl and the ps_cortexta9_0 items). Then a 'clean' and 'build' worked. I'll have to do some research to try to find out how this was changed because as mentioned, I certainly don't remember doing anythingn to explicitly change them. Your help, as always, very much appreciated!
-
I've been away from Vivado/Vitis for a few weeks. I wanted to confirm some behavior of a project today so like usual, I opened my Vivado 2023.1 and Vitis Classic. Loaded my two projects into both. I made a minor change to some verilog code in a peripheral used in the design in the Vivado project. I then, saved, resynthesized, implemented, generate bit stream, exported hardware. Updated the hardware spec in Vitis and get an error I haven't seen before, not related to the change I made. ERROR: [Hsi 55-2091] Multiple versions of driver "gpio" assigned to different peripherals."gpio" driver version 4.10 assigned to peripheral "Zybo_UI_ZYBO_BUTTONS", version 4.9 assigned to peripheral "AXI_GPIO_DSPL".Assign same version of driver to all peripherals. I'm not sure how a different driver version could be assigned - I certainly don't remember doing anything to assign a different driver version. In the Vivado project, all the AXI CPIO instances are at version AXI GPIO:2.0. And when I go look at the BSP items in Vitis, they simply list the driver as being 'gpio' - I can't figure out how to determine a driver version, much less update it. Maybe if I 'Reset BSP Sources' that would do it? But not sure how this happened anyway since last time I used Vivado or Vitis, I did not see this issue.
-
artvvb reacted to an answer to a question: XADC Example with Vivado block diagram?
-
Have you looked at the collection of documentation about the AXI Interrupt Controller? It looks like this documentation... 'Describes the AXI Interrupt Controller (AXI INTC) core which receives multiple interrupt inputs from peripheral devices and merges them to a single interrupt output to the system processor.' The PG099 document has a nice feature list. Perhaps start with that doc if you haven't already read it.