-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Iztok
>> I do not have enough experience with configure to know, how it >> would help. For synthesis the only dependency is the vendor >> tool. Although sometimes an older version of the tool is >> required, this is usually, because the parser became more strict, >> so the issue can be seen as a bug to be fixed in the source. Some >> very old Xilinx devices are not supported in the latest ISE >> tools, but we will probably not encounter any. So in this case configure is custom-written - rather than using the one provided by autotools. The goal being to allow the user to specify the board, which simulator etc. one time without having to repeatedly specify it every time they call make. The configure script should also search the users path for the needed vendor tools or give the user an opportunity to manually specify the paths. These will be stored for use during the build later. For simulation I will >> probably create separate Makefile-s for Icarus and ModelSim, I >> can use a single file, if I find a good way to do it. I will >> probably later add a code coverage tool, but not an open source >> one, Covered<http://covered.sourceforge.net/> does not support >> Verilog 2001 well. In any case coverage is less important. Separate Makefiles makes sense given the tools are so different to call. I've seen other projects make a wrapper script that abstracts away the differences - I'm not convinced that is any better though. With configure you could have a plain Makefile in addition to Makefile.modelsim and Makefile.iverilog that selects between them depending what the user specified with a "./configure --simulator=" option. It would also make sense to add a "make sim" command to the root makefile. >> I had a quick look at your environment, but I have not attempted >> to run it yet, so I have some questions based only on your >> description. Each synthesis project, regardless of vendor, >> requires the definition of the next information: - source list, >> name of the top level module, additional macro defininitions - >> FPGA pinout (which pin is connected to which signal - IO >> constraints (IO standard type, voltage, current, slew rate, >> optional pullup, ...) - timing constraints (for IO and internal >> code) I'm happy to use Xilinx UCF for Xilinx pinout and constraints. Every board will have to have it's own constraint/pinout file anyway (unless common components can be factored out into some include file). So there's no sense making these vendor agnostic. >> This information is usually in a vendor specific format. In most >> cases this files (text or XML or ...) are just committed to VCS. >> I am under the impression you are trying to create all this >> files from tool agnostic files "a central project file that lists >> the sources" (prj/src/logic_sniffer_top.prj), this would be hard >> and impractical. But I could have understood incorrectly. Doesn't that rather tie you to working in the fugly vendor IDEs? I rather wanted to shift the emphasis away from these. >> I was able to finish synthesis with most of my updates to the >> source, but I am not sure how many mistakes I made, therefore my >> current focus on tests. It's a bit weird - more testing is needed. I got it to synthesize once, but thereafter neither uwe_ or myself have been able to get it to work again. Maybe I made a mistake - it never worked, but at the time I was pretty sure. More investigations is needed. >> OK, but please do not make it automatic, I do not like if tools >> update source file, without user knowledge. No no. Nobody likes that. This was just a one-time cleanup I did with a little script I have. >> I added a source file with a GPL 3 license "rtl/cdc.v" this can >> be changed to GPL/LGPL 2. LGPL is the preferred license for HDL >> projects, since they are similar to libraries. There were many >> discussions on OpenCores, regarding licensing, but I think LGPL >> is a good choice. I actually plan to license the original >> version (not the copy in this project) of cdc.v under CC0 >> (public domain), since the code is very common and generic. It is >> possible I added some test files without a license, you can >> assume they are GPL/LGPL. For test files GPL is also >> appropriate, since this files are rarely reused elsewhere. LGPL makes sense - particularly if we every manage to support the ChipScope use case. 2 or 3 - I'm not so sure. I guess it depends what we'd be happy to allow a commercial vendor to do with the project down the line. >> Regarding lib/ folder file, you can remove them right away, I >> will use the originals from the Xiling ISE installation path. I think these need to be rebased out of the history altogether. That way no part of the project or it's history will become non-free. I figure you know how to do that - I can help if not. Another thing, I had a problem with verilog functions. I wanted to put the log2 function in a common utils/log2.v file, then replace the two definitions of log2 with `include utils/log2.v. But for some reason the Xilinx synthesis tools complain about using an external function to resolve a constant local parameter. Is this what you would expect? It seems pretty crippling if you need to re-define a function any time you want to use it. Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRoxLSAAoJEHgUeO+Es/hFyacIAJ7S+f9DngDZpN28KCuVDSA1 9UUHEjXqx+vsWc18jPZdw/M3D4v4OysHBbhTqGBvD2R21qqvYLfBO+rn58D5w2hI QZCSrv54GgB56RuekZrnO7igo548PMffVgEis05gHEfWH+8Wt+mAMw+VOmFvfTcx MrzP0Ty9zHll6qEVdnFfvajx4i5QWSbQ2EkKPOT8jOMw8RcS/44yqtA8jOwqXOut vy9LQ7TLjkvpqcgSjn0FuuH0dMtj3A94l7+4c/R+hPiXWn8ejpJQOjpnITJDNAFd Lgch1bvqzLmnRt3XFBrT2L5Kr0hdeI2qpLvx99OHKBwRLQpsFbyO8eQqFTzabiE= =6sHX -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
