03-11-2018 07:25 AM
I'm using Vivado 2017.1, coding in SystemVerilog, hosted on Windows 10. This post picks up where a previous one erroneously believed the problem solved: https://forums.xilinx.com/t5/Design-Entry/Problematic-repeating-message-quot-update-compile-order-fileset/td-p/802687
This problem of the message "update_compile_order -fileset sim_1" repeating over and over again has returned, and it has now hamstrung me to the point of not being able to make sufficient forward progress. I am going to call this a Vivado "parsing bug".
First of all, simply turning off Hierarchy Update / Automatic Update and Compile Order was NOT a solution. It turns out that this parsing bug occurs with simulation as well. So, while synthesis will run fine and I can build a bitstream, simulation does NOT run fine when this parsing bug occurs. As a result, whenever I encounter the GUI problem, I know I won't be able to simulation. This is not acceptable. (So, the GUI and simulation seem to share a common code base. When the GUI encounters the indefinite-loop update_compile_order problem, simulation will encounter it as well. Rather than getting stuck in an indefinite loop, however, simulation reports that a particular hierarchical structure reference can't be resolved. Parsing fails. Which hierarchical structure reference can't be resolved changes from time to time. The definition for the structure is in an include file (that I name "SoAndSo.include.sv"). So the problem is that simulation can't figure out how to look at things in the correct order. Synthesis does it for the same files, no problem. But simulation can't. It shouldn't be an impossible order of things, because, I'll repeat, Synthesis works fine. Of course, I did notice long ago that Synthesis seems to respect the Verilog `include macro, but Simulation seems to automatically include all source files irregardless of the `include macro. This situation is near the bottom of this problem.)
Second of all, deleting the .cache and .run folders made the problem go away only temporarily. It didn't make simulation start working.
Third, I have recently discovered that the occurrence of this parsing bug corresponds to my exact SystemVerilog source code. I have adopted a pattern of optionally including an ILA at the bottom of many of my modules. I will surround that ILA instantiation with an if(parameter)...end block so that I can easily include or exclude the ILA from the bitstream build. After a while, rather than changing the parameter passed in from the very top of the source code tree, I found it easier to simply comment the "if(parameter)" and "end" in or out. This allowed me to more quickly include or exclude the ILA from the bitstream. HOWEVER, I have found that for some modules, with the ILA included, the parsing bug doesn't happen. But when I try to exclude the ILA, the parsing bug happens, which means I can't simulate. Now, realize, the fact that I am including or excluding a module that is an ILA shouldn't be important to the question. So let's not get bogged down into why am I wanting to include an ILA at times. What should be important is that the list of modules to be used at the moment is changing, and sometimes the parsing succeeds and sometimes it fails. Through all of this, remember that Synthesis parsing works all the time. It's only GUI and Simulation parsing that get stuck in the indefinite loop.
Finally, the fact that I cannot choose at will to include or exclude the ILA's of my choice is hurting me tremendously. Furthermore, I have been recently trying to reduce the complexity of my project with some smaller testbenches. However, guess what? The parsing bug is happening again, relating to modules being included or not, whether they are ILA's or something totally different. This has totally prevented me from making any progress on smaller testbenches in order to speed up my work.
I need to get to the bottom of and get around this parsing bug in a way that allows me to still run simulation. This should then lead to my ability to make some smaller testbenches to speed up my work.
I believe this means I need to figure out what is the actual sensitivity to source code that the parser has, and see if I can arrange the source code differently. Unfortunately, company policy won't allow me to post company proprietary source code. And I'm concerned that trying to make a reduced source code example with the names changed will be an effort in futility, as I've already found that which optional ILAs cause the problem does change from time to time.
Alternatively, maybe I do *manually* set compile order, and I have to do so in a way that simulation won't get the hierarchical structure reference failure. (Remember, Synthesis handles it fine. GUI and Simulation do not.)
At this point, I need to stop writing and go work. Maybe someone can add some ideas. Then I'll try to come back and write some more.
03-11-2018 09:08 AM
Note: I've been playing with setting Hierarchy Update to Automatic Update / Manual Compile Order. I created a situation where the parsing bug was happening. I confirmed simulation wouldn't work (parse). I changed to manual compile order and rearranged files for simulation (note that combobox at the top of the screen) to be logical Now simulation works.
So I've disabled automatic compile order, which seems to be the origin of the parsing bug. I've made manual compile order such that simulation parses OK now and works. I guess the automatic was leaving the order funky, causing simulation parsing to fail.
Next, I've gone back to trying to make some reduced size test benches in the SAME project folder, with the intent of swapping back and forth which is the current "Top", for either synthesis or simulation. This will allow me to have only a single copy of my leaf source modules -- a good thing. This seems to be progressing well so far...
03-12-2018 06:57 AM
I've not had these problems before. But then again, I never use manual compile order, since Vivado has always been able to figure out the correct compile order, provided I do not have syntax errors.
Have you been checking the non-module files in your sources window?
Having a file in the non-module files folder is an indication of a syntax error so severe that Vivado cannot figure out where it belongs in the hierarchy, and, consequently, cannot figure out the correct compile order. And by severe, it could be as "severe" (read: apparently trivial) as a misspelled keyword. The fix for it is not to go to manual compile order. The fix is to fix all syntax errors until the number of files in the Non-module Files folder is 0. And even then, you may have other minor syntax errors that prevent synthesis or simulation.
At the risk of asking a triggering question, we are rooting for you to succeed, and this is a potentially profitable question for you to think about: how much training on Vivado have you had?
The reason I ask is Vivado is a sophisticated piece of software that performs disparate, complex, and powerful tasks. It is not something that one can just pick up while in the heat of a project.
I've known Ph.D.s who have very high IQs get themselves into a lot of trouble with the thought: "I did a dissertation and years of research on [some narrow and deep esoteric subject]. I know several programming languages. I taught myself LaTex. I even took Verilog as an undergraduate, and finished top in my class, completing a shift add multiplier three weeks before any of my classmates. How hard could it be to design an FPGA?"
Or worse, "I've been writing complex object oriented programs for over 10 years, and even dabble at multi-threaded programs. How hard can concurrency be?" Well, the truth of the matter is, it is very rare for a computer science type to be able to design FPGAs that work with Verilog, VHDL, or System-Verilog. It is easier with HLS or SDSoC.
With enough time and no real world project pressures a smart engineer could figure out all the features.and then decide which of those features she needs. But with project milestone pressures, it is harder to achieve this goal. And this is where training can save valuable time and reputation.
With the advent of HLS and SDSoC, this is changing, because the tools are handling more low level details, but that is another topic.
As you are seeing, FPGA design requires a lot of knowledge about tools written by other engineers. The tools are not part of the natural world, and, consequently, require the user to some extent get into the head of the engineers who created the tools.
The situation you're in now, working 7 days per week, running into all sorts of "bugs" that nobody else sees, is exactly the situation that can be avoided with appropriate tool training.
I would recommend LANG-VERILOG and LANG-SV, FPGA-VDES1 through FPGA-VDES3, and FPGA-STAXDC. Training is expensive but will pay for itself very quickly. You'll have to go with a mind unencumbered with your current project, and some additional time to play around with Vivado on tiny toy projects. Otherwise, carve out two or three months to peruse the user guides and tutorials in DocNav. Vivado is design to work in several different environments, from small FPGA flows to multi-card and multi-FPGA/card ASIC prototyping flows.
In any event, from the sounds of it, given the point you are at now, you may also look for sit down consulting help from a principal level engineer who has successfully used Vivado on several projects. It is not inexpensive, but neither are late projects, no weekends, untold frustration, and other stuff. Missing market windows can lead to layoffs, even corporate bankruptcy, or worst of all--bickering with a project taskmaster can create another layer of frustration and possibly led to a stroke. Especially if the project taskmaster is yourself.
03-12-2018 08:36 AM
@maps-mpls , more about the classes I've taken later.
For now, this issue is indeed a Vivado bug. Specifically, I have seen this "Non-module Files" entry come and go over time, and it has indeed alerted me to syntax errors from time to time. However, not always. Right at this moment, in fact, there is a "myfle.include.sv" in there. I looked at it and it has no syntax errors. In fact, it only has a few lines in it.
`timescale 1ns / 1ps ////////////////////////////////////////////////////////////////////////////////// // ////////////////////////////////////////////////////////////////////////////////// `ifndef MyFile_INCLUDE_SV `define MyFile_INCLUDE_SV `define FSS_0 (0) `define FSS_1 (1) `endif
In fact, I simplified it to contain only
`define ONEANDONLY (1)
and it STILL shows up as a Non-module File.
MEANWHILE, remember, I've said over and over that SYNTHESIS continues to work. So aside from some if(parameters) that vary between simulation and synthesis, what syntax error could I have? And I certainly don't have a syntax error in this file.
My guess is that there MIGHT be a syntax ambiguity at best (whatever that means), and this is in a DIFFERENT file than myfile.include.sv. I've OFTEN seen the TOTALLY WRONG ERROR MESSAGE provided in a message log. This is remotely similar in that the WRONG PROBLEM FILE is being provided in this group. I don't know how the Vivado code makes this kind of mistake, but it does. So, along this theory, the syntax ambiguity gets Vivado confused, and it reports the wrong file as having the problem. I say it's a syntax ambiguity, because Synthesis can deal with it fine. I was getting these kinds of errors BEFORE I put in any if(parameters) that differed between simulation and synthesis.
Yes, I wish I could give you the whole project and you could see it. But I can't. And I don't have time, unfortunately, to reduce it down to a small non-proprietary project. Darn. Maybe long from now in the future when I retire and have nothing else to do... (unlikely)
@maps-mpls please note that I'm a bit P.O.'d at all these problems with Vivado, combined with the home office license server being down this morning and my being dead in the water. This has colored the tone of this post. I do remain optimistic about getting somewhere, and even perhaps about finding the root cause to this specific problem. I'm just not in the right mood right now. But do note that I don't hold grudges and I have very thick skin. So I might snap for a moment, but I come right back.
03-12-2018 09:04 AM - edited 03-12-2018 11:52 AM
LOL. Actually, this was an include file that was still in the project yet no longer referenced anywhere. I simply removed it from the project and the "Non-module Files" group went away.
(BTW, the bug mentioned in my original post persists. Just because I got rid of the "Non-module Files" group doesn't mean the bug went away.)
03-12-2018 01:28 PM
Did you try to recreate the project in a new location without messing with the compile order?
03-12-2018 02:36 PM
I did a number of things, so I'm not sure if I did that, and I'm not sure exactly what you mean by that. I do frequently copy my whole existing project folder folder to a new folder, to do alternative development in the new folder, and then I later merge them back. (I do this rather than using a single workspace, partly because my company's SVN through VPN is too slow to use effectively.)
I'm not sure what you mean by "recreate". If you mean to really start from scratch and add all the modules and IP, definitely NOT. That would be a lot of work. I have in the past deleted the .runs and .cache folders, but that only helped temporarily. (See original post referenced in my first post on this thread.)
All of these things I've done while still automatic compile order. My original description, of commenting ILA's in and out was with automatic compile order.