08-15-2013 09:16 PM
I know it's easy to point out bugs here or there with a new product. But when one starts to question whether your software is telling you the truth... It's time to seriously reconsider the software release process. See attached picture.
I would feel very much embarrassed if I were on the software team right now.
08-15-2013 10:07 PM
Provide a small testcase which reproduces this issue.
08-16-2013 07:45 AM
The advantage you have is that everyone is listening, and actively looking for bugs, and fixing them right now.
Vivado is more than ready for prime time. Show a piece of software with no bugs, and I will show you "hello world" (and maybe even that is not bug free....).
Why is the display not a solid 1 or 0 green line for these signals? What happens when you change the time scale? Is that signal really a pulse waveform, with a low off duty cycle and the cursor really did catch a zero? If so, it isn't a bug at all.
08-16-2013 08:54 AM
More likely it is a bug. I've seen this same thing reported on earlier versions of ISIM, so it may have just come along to Vivado if they started from the same source code and the bug was never fixed for ISIM.
08-16-2013 08:57 AM
But Vivado is a clean slate. Old code was intentionally NOT moved forward. Maybe this is one of those issues that is a bit trickt to resolve. It wouldn't be the first time the same bug was coded so very carefully, again.
08-16-2013 09:39 AM
I'd rather not post the entire project here. Can you please email me and I'll respond privately? I trust that as moderator you have access to my email?
Good questions. The signal is an 8 bit BRAM address that is really an up counter. The counter is trigger by a positive edge 200 MHz clock in the simulation, as is every other signal in the simulation. If the simulator is unable to catch the up count change for some reason, it would be very surprising and not at all consistant with any other simulation I've run.
For the record, I'm on the producing side of software as well. So I can understand Xilinx's position when releasing new software products. I haven't been posting about issues with random crashes (which happen nearly every day), because it is only a few revs old. I suggested revisiting the software release process explicitly because it seems fixed or non-existant in ISE/iSIM. (Are there no regression tests that can be run on both simulators?) So it is especially frustrating to see Vivado be a step backwards in this respect. Xilinx may consider adopting the practice of applying the BETA moniker to new releases until they become stable enough to use on a daily basis (as other companies do)... Hence revisting the sofware release process.
08-16-2013 10:08 AM - edited 08-16-2013 10:10 AM
We do have beta (and alpha, too!) programs.
Your points are valid, and I have forwarded them to the right people here. I want to know if any QA steps got skipped, as much, or even more, than you do (as I get to see the results of such a lapse, if it happened, here in the forums).
The Xilinx software suite is one of the largest in terms of seats (if not the largest) CAD tool suites, downloaded and used, in the world. It represents a great challenge, and we take great pride in doing the (great?) job that we do.
08-16-2013 02:04 PM
I'd like to point out a couple of things. First of all, as Austin points out we do take out QA very seriously and continually look to shore up and improve our coverage. I can tell you that we have improved our infrastructure immensely over what we had for ISE, but it cannot be perfect. Every bug that is reported does tend to spark a conversation along the lines of "how come we didn't catch this." This is why the almost automatic response to any illustration of a problem with the software is "can you please file a support case and upload and example so we can reproduce the issue."
Now this specific screen capture that you have appears to be an issue in the waveform viewer. I know it does not fully matter to our customers how we do these things, only that we deliver the highest quality product possible. But I will point out that issues involving the graphical user interface components are much harder to catch and trap than something that can be regressed with scripts and automation infrastructure. We can automate scripts to verify behavior, positive and negative and we have hundreds of thousands of these that run even nightly on many levels of our software to ensure things operate properly. But invariably, things always escape. And in the GUIs it requires manual review and often these are corner cases are not readily apparent - or things can change between the times when someone has manually verified that the waveform looks as it is reported by the engines.
So, while it is unfortunate that bugs escape our QA practices. I would not throw the baby out with the bath water - to use a cliche'. Many people are using our tools, and we work hard to ensure that it is indeed ready for primetime. If you've been around long enough to know the experience with the rollout of m1, or observe our competitors releases of a number of years ago, then it is not a stretch to accept our claim we are faring much better than other tool rollouts - and Vivado is on a much, much greater scale than anything that has ever been attempted in the EDA world.
So, once again, we are committed to fixing issues and improving our processes - so thank you for pointing this out - and thank you for helping us to reproduce it so the next person can have a better experience than you did.
08-19-2013 04:32 PM
Thanks for your response. I'd be happy to provide a test case. The project is somewhat large at the moment and I'd rather not try to post it to the forum. So if someone in QA is interested in contacting me via email I can provide a link to them privately.
08-20-2013 12:44 AM
Please check your private mail and send the test case to those mail id's...
08-21-2013 10:34 PM
Can you please check your private messages and send us the test case to the mail ID's mentioned so that we can verify it at our end.
11-15-2013 04:40 AM - edited 11-15-2013 04:43 AM
I will have to agree with the OP. The issues i have encoutered while working with the tools either suggest incomplete testing, incomplete integration or too hard dealines on delevopers to be able to deliver a robust product. I have been using HLS, IDE and SDK but their integration is really problematic.
Many times I have encoutered wierd bugs, things operating in completely counter-intuitive manner, fundemental functions that often do not work, new versions chaning sth that used to work but does not in the new versions and automatic processes creating things that do not work and should be picked up by validating the design but never do. Many of these issues I have posted here and I have received good help, but still I cannot seem to be able to make the complete tool flow to work properly to get a finished result.
I am truly believe now that the whole suite is not ready to support complex and large designs in full, although I must say that the issues I have encoutered could have its source to my certain application and all these issues might be non existant in most designs. Still my experience was that of a tool in an uncompleted state.
And it does make perfect sense. As a completely new EDA tool it should take a substantial amount of time to mature.
And the decision of making an completely new tool-flow from scratch is a brave one and one asbolutely required if even better EDA tools would ever be developed. What is sad is that this is not communicated at all and the tool-flow is marketed as ready. As a result many invested time into using this tools with a good chance that they were not suitable for what they needed and whole months of work went down the drain (as is might be true in my case too).
11-17-2013 09:06 PM
Following up your comments, can you let me know if you have any specific problem which you have in particular so that we can help you resolve it.
11-18-2013 01:10 AM - edited 11-18-2013 01:11 AM
My 2 main issues at the moment are these:
Althought the whole delay is the main problem due to he constant issues. I will pause the whole design for now and revisit the tool-flow in the future.