Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
What are some good linting tools for verilog? I'd prefer one that can be configured to either handle or ignore certain vendor specific primitives like LUT's, PLL's, etc.
I recently tried verilator-3.810, but out of the box it needs a little help with the primitives.
So what (linting) tools do you use to deal with the not-so-strict syntax of verilog?
I have never used a free linting tool, such as the one you mentioned (verilator).
My only experience has been with (expensive) commercial linting tools. Thus far, every one I have used has required me to spend time to customize the rule-set to filter out checks which I consider unimportant. For example, by default, every tool generates many warnings related to signal naming conventions. Since these in no way affect how RTL is synthesized to gates or lead to simulation issues, I choose to disable them.
The Spyglass tool (Atrenta) seems to have the widest range of capabilities, but also requires quite a bit of set-up. I like the Hal tool (Cadence) because it is very easy to start using right away (but, it too requires some set-up).
In my experience, it's generally not worth it. Anything I've tried needs loads of initial setup because out-of-the-box they try to check everything. But each shop has it's own coding standards - so you spend loads of time seasoning the linter to taste. Then once you try to integrate IP or code from another section of the company (which generally have a different idea of nice code), the linter goes mental, so you end up saying, wire im_happy = Verdi_happy & simulator_happy & synth_happy;
I also have used Spyglass and, like toolic indicated, it requires setting up a run script just to check even one file and the default checks complain about useless things like unloaded bits on array data types. Conformal will also output quite a bit of detail for its RTL warnings and you would have to have certain modules excluded anyway, if Formal Verification is part of your flow. Like Spyglass it requires a bit of setup.
Despite having access to these tools I only use them at the very end. During coding and validation I use VCS with lint checks turned on, and fix anything Verdi complains about. This catches quite a bit and does not require any configuration/script files to use. Neither are free(or cheap).
Ascent Lint from Real Intent is pretty good. It runs fast and is easy to set up.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Working on a large and complex application, I wonder where and whether we should be storing scenarios to document how the software works.
When we discuss problems with an existing feature, it's hard to see what we have already done and it would be hard to look back with a scrum tool such as TFS. We have some tests but these are not visible to the product owner. Should we be looking to pull out some vast story / scenario list, amending / updating as we go or is this not agile.
We have no record of how the software works other than the code, some unit tests,some test cases and a few out of date user guides.
We tend to use our automated acceptance tests to document this. As we work on a user story we also develop automated tests and this is part of our Definition of Done.
We use SpecFlow for the tests and these are written as Given, When, Then scenarios that are easy to read and understand and can be shared with the product owners.
These tests add a lot of value as they are our automated regression suite so regression testing is quicker and easier, but as they are constantly kept up to date as we develop new stories they also act as documentation of how the system works.
You might find it useful to have a look at a few blogs around Specification by Example which is essentially what we are trying to do.
A few links I found useful in the past are:
http://www.thoughtworks.com/insights/blog/specification-example
http://martinfowler.com/bliki/SpecificationByExample.html
Apart from the tests we used also a Wiki for documentation. Especially the REST API was documented with request/response examples but also other software behaviour (results from long discussions, difficult to remember stuff).
Since you want to be able to match a description of what you've done to the running software, then it sounds like you should put that in version control along with the software. Start with a docs/ directory, then add detail as you need it. I do this frequently, and it just works. If you want to make this web-servable, then set up a web server somewhere to check out the docs every so often and point the document root at the working copy docs/ directory.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My team is building a product that has a lot of components that rely on each other. For example, whenever we add a new type of data to the system, we also have to add logging code to track the changes that use that data type. Or, when we add a new UI screen, we have to make sure that its strings are externalized so they can be translated. These things slow down almost every task we do, and sometimes one of the the steps gets forgotten.
The traditional way to handle this problem is to add required checklists and documentation and things like that. How do Agile methodologies handle it?
The design you describe sounds like it might be a little too tightly-coupled. A renewed focus on enterprise patterns (such as Inversion of Control, programming to interfaces, etc) could help a lot.
If you are doing pair programming, you should be checking each other's work, making sure all of the i's are dotted and the t's are crossed.
If you are doing Test Driven Development, your tests should not be passing until all requirements for that particular portion of the development effort are satisfied.
If you are developing a large, complex system, you need experienced developers who understand the design and development process. You may also need a hands-on (read:coding) architect who can oversee the whole process.
Oh, and checklists (despite their traditional nature) are good too.
I'd suggest reading Alistair Cockburn's "”Agile Software Development: The Cooperative Game" - he takes quite an intelligent approach to Agile that's largely "do what gets the job done". That might help you work out how to get some kind of checklist / documentation into what you're doing without making everything horribly top-heavy.
Could some of your problems be solved by better tests? When you talked about not doing things that need to be done, my first thought was "why hasn't a test failed?" Maybe you need to look at tools for testing user interfaces? (edit: or even some small script on commit that greps code for whatever indicates the need for translation strings and checks against the files with the translations in?)
Also, can you change your design so that it's both less coupled and "forces" you to do the right thing. Perhaps making those data types implement a logging interface that the logger delegates to, or similar...?
Depending on your IDE there are various tools to help identify strings that need to be externalized, but if you are in a habit of just not putting in static strings this can be avoided.
If you need to add logging I would suggest AOP, as, at some point you will want to remove the logging code and you risk breaking the application.
But, a long-term, complex system is ideal for agile development, as, while you are developing, the needs of the client/customer may change, and you can adapt to it.
You need to ensure that the customer has feedback on a regular basis (ideally daily, and in a perfect system the customer has a rep sitting by for questions).
When I have many steps that must be done, esp for something like datatypes, I will resort to using a spreadsheet, so, you add a datatype, you add a row to the spreadsheet. Then you can track everything that needs to be done before that datatype is completely added to the application.
Have cross-component teams. That way when you add some functionality, the member(s) from the logging component will update their part and the translator(s) will update the strings.
I think it is important to understand that Agile methodology is only a process framework, not a process in itself. For example it says to follow test driven development and do pair programming but it does not say how to write the tests, or suggest a review checklist or suggest a coding guideline or say what documents to write. Those parts are entirely upto you or your organization to define and follow.
When planning a feature, you can add a engineering task called "review" and allot time for it. You could do the review task in whatever way works best for you and your organization. If pair programming doesn't work as well as a formal inspection for you, you should do formal inspections.
Do what needs to be done, but not more:
better definition of done (the definition of done is a kind of checklist to me),
better testing,
"just enough" documentation (Agile != no documentation),
etc.
Well, where I work we have QA that can catch some of the bugs if there are missing requirements or something slips through. I'm not saying the development team is intentionally putting in bugs, but as a codebase grows, it becomes harder and harder to remain nimble and thorough in checking everything.
Wikis can be useful for capturing methods used to try to get the clearest requirements. By clear I mean that the story card isn't likely to list all the requirements and that there may be discussions with an end-user or business analyst to get their understanding of what is desired. Part of our sign-offs involve getting an end-user to see the functionality and approve it before moving from the development environment.
Once every handful of sprints, we may have most of a sprint devoted to bug fixing/refactoring so that things can be cleaned up that would otherwise not get done as they aren't likely to be important. This can be cosmetic bugs or broken windows that while they have little business value initially can be useful in the long run.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I'm currently looking for diagramming software that allows me to quickly map stuff and jot down concepts such as a filesystem directories represented by nested boxes containing icons (representing files.)
Off course the simplest solution of all would be to just use paper and pencil, but unfortunately i have such poor motor skills that after minutes i cannot even distinguish the shapes I've drawn myself, never mind have these notes be of any use to someone else in order to have him/her work with them.
So far I've tried a ton of software packages but none of it seem to be simple/flexible/powerful enough to help fulfill the modeling /sketching tasks I'm trying to achieve
Visio,
smartdraw
Edraw
conceptdraw
Vue
yEd
Dia
Kivio
paint.net
photoshop
Illustrator
GIMP
in addition I've played around with modeling tools including staruml,argouml and Visual Paradigm as well as Eclipse modeling, but most of them were too complicated, too constricting and in some ways completely alien. On a side note, I absolutely HATE eclipse, I'm used to writing shellscripts with nano on a shell, The sheer amount of features (That i will never ever have any use for) make it hard for me to find that which I'm really looking for. YAGNI GDDMM*T!
Allthough UML modeling is at times important, such models are more for the next follow up phase and would be overkill (as well as a creativity killing burden) when I'm trying to come up with something from scratch.
Right now I'm looking for something new, I would be more than happy if someone could perhaps suggest something,
Most importantly i would like to find a program where the software allows me to do add new shapes and with the parent shape automatically growing so that that added shapes all fit inside of it rather than that i have to manually resize the parent shape
Your problem is a common one, and in recent years the big UML tool vendors have started adding functionality for sketching, as opposed to traditional modelling. My favourite, Enterprise Architect from Sparx Systems, has got "whiteboard" sketching and is also able to import from Visio.
It boils down to whether you know you'll just want to sketch, in which case you should get a tool which does that really really well (that last feature you mentioned is something I haven't seen in any UML tool). If on the other hand you know that you'll eventually want to turn the sketches into UML models, you need to consider whether you'll want to start over (which might be the easiest option, honestly) or have some sort of in-tool support to do that.
For "UML as a Sketch" I use the Hruby UML Stencil for Visio. These do not enforce eny semantics, so you can be as sketchy as you need to quickly record ideas and communicate.
See http://www.softwarestencils.com/uml/index.html
I use Dia. It is cross platform. Very simple tool.
However, My favorite has always been to sketch it on paper and scan (fotopragh it on my mobile) and keep it for records. Nothing beats pen and paper yet !
I tried yEd recently, because I happened to see it mentioned in another thread here. I'm quite impressed with it. Its pretty easy to use. I think the feature I liked the most is that I can draw my diagram regardless of the spacing and orientation. Then 1 button and poof, the whole things rearranges into the ordering I want.
As a linux diagramming tool, im pretty impressed with it.
this one is good for remote team members.
Nothing to install
http://www.dabbleboard.com/
I've used Visio for so long IMHO nothing beats it.
That said, I rarely use Visio in meetings to take initial notes. We'll diagram on whiteboards (get someone else to do the diagramming while you "facilitate") and then I take pictures of the result. Transcribing the photos to a Visio diagram helps me think it through.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm interested in evaluating bug trackers, but I wanted to back up and figure out what sorts of criteria were most important in bug software. So far things I've thought of include:
integration with source control
usability
basic features (email notifications, rss, case states)
customization
advanced features (reporting, visualizations)
stability
cost
IDE integration
Any ideas?
Ease of use
This should, in my opinion, be on the top of your list of features to evaluate against. You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
A tool that has 15+ fields on the screen, where 10+ are required in order to just be able to submit the issue, is not such a system. With such a system, you'll get postit notes from testers to developers about the little things.
When evaluating BugTracker X, which bugtracker do the developers of BugTracker X use?
customizable workflows (from "open" to "in work" to "resolved" to "closed")
fine granular access control
There was a recent thread on Hacker News about this exact question. Lots of good stuff in there!
An API. Mandatory.
You MUST be able to catch and automatically submit bugs into your bug tracker from applications running in the field.
(Copy/Pasted from "Lasse V. Karlsen"'s answer)
You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
Even good, conscientious testers, if they are focused on testing component A but happened to stumble on a bug in component B, might not actually enter that bug if there is a lot of friction in the bug tracker. Friction means, required fields. It's not that the testers are bad or lazy - it's just how the human mind works. We focus. We don't see the guy in the gorilla suit.
The Joel/FogBugz philosophy of NO required fields is the right one (Also the philosophy of my own BugTracker.NET). You almost always can gather the details later - what os, what version, what browser, etc.
Also, take a look at "Bug Shooting", if your app has a GUI. You want to make it as easy as possible for the testers to take a screenshot and get it into the bug tracker, and that's a great tool for it. Pick a tracker that works with Bug Shooting or has its own dedicated screen shot tool.
Distribution. My version control system is distributed, why shouldn't my bugtracker? If I fix a bug on the train, why should I be able to make the fix but not record it?
Probably everything mentioned by others, plus some from me.
If you have long term big project, separate testing team that will do functional tests, you should take few additional things into consideration:
- can bugs be linked to test cases (and more precisely to given run)?
- can defect tracking system exchange data with test management system?
- can it produce (useful) reports?
- can bugs be grouped by release?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I have long been of the opinion that the time and resources it would take to write a piece of malicious software, of whatever type, could better be spent on other things. However, as a developer I am constantly worried about the possible security flaws in systems I work on.
Of course I know about validating input, I understand fully how code and sql injection can work and obsessively sanitise against these risks. Also, whenever I am able, I bone up on new security risks with whatever resources are to hand (e.g. articles, whitepapers, presentations etc.) but I often feel I'm missing the point, maybe because most of my knowledge could well be classed as "new-fangled" (C#, MSSQL, PHP, some Python, a smattering of Ruby): the oldest language I know is Classic ASP.
Sometimes when I read about things like Cross Site Scripting and URL hijacking I read the articles upon which they are based but I feel like I'm not following 100%.
What are the best resources you know to get to grips with security concerns and really understand how they work? Could be anything, books, websites, other types of resource. I know I don't know enough about these issues so where could I go to learn more?
http://www.owasp.org/
Well, you could start with a recent post from Jeff:
Top 25 Most Dangerous Programming Mistakes and work your way forward from there.
Try James Whittaker's How to break software security
One Monkey,
The fact that you are asking the question means you are well on your way. The real issue is that so many don't ask, are not worried as you are.
One thing I would modify is change the thought that you know some security issues fully. There are some really devious little jerk-offs out there. I am of the opinion you are better off assuming they are smarter than you and so bolt things down as tight as possible. I find it is a better mindset.
Two resources you should look at:
XSS Cheat Sheet
A good example of SQL Injection
I must admit to being somewhat surprised at the lukewarm response to this query. Does this mean:
a) everyone else knew about OWASP and I'm way behind the curve?
b) everyone else is confident enough in the security of their code to not need a little help staying up to date?
c) no one else cares?
d) other?
I have found the reference to OWASP most helpful, so far I'm about to install some of their project software to see how it works, once I feel that I'm better off security wise for having a look at their site I'm marking that answer as accepted, unless something better comes in in the meanwhile.
http://www.securityfocus.com/ and the categorised mailing lists.