Hi Joel,
On Mon, May 27, 2013 at 10:01 AM, Joel Holdsworth
<[email protected]>wrote:
> -----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.
>
This all sound as sensible use of configure.
>
> 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.
>
This can wait. I will use ModelSim for some time. I encountered a bug in
Icarus GIT, and reported it (it is confirmed but not yet fixed).
>
> >> 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.
>
There are some vendor agnostic file formats (for example for timing
constraints), but are usually only shared between few and not all vendors.
>
> >> 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.
>
Vendor project files are needed for running the tools in both GUI or batch
CLI mode. The GUI can be avoided, the mouse click sequence is usually
replace by a TCL script. Almost everything the tool offers can be done
without a GUI, but project files are still needed.
>
> >> 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.
>
There was a point in GIT history which worked well, but I am not sure if
synthesis works right now. I will retry and fix issues later this week.
>
> >> 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.
>
I actually do not care about licensing too much, I will add my full name
and email to all source files, so if somebody wishes to re-license the code
I will be available. Licenses tend to complicate legal code sharing, so in
the future I will probably be moving to more permissive ones. For this
project LGPL 2+ seems right.
>
> >> 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.
>
The code in lib files is publicly available, so it is not a big (time
sensitive) issue, but removing it altogether form Git blobs would make
sense. I can do it when I get back to simulating top level. Never done it,
but the web is full of instructions.
>
> 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.
>
`include is executed before parsing, so it is not clear what the tool
complaint is about, maybe the path to the include file was not specified.
Try putting a syntax error inside, to see if the file was actually read. If
the issue persists it might be a language support issue triggered in
combination with local parameters. There is actually an integrated function
$clog2() in Verilog 2001, but it is not supported by Xilinx ISE (it is in
most other tools), therefore I copied the recommended workaround from
Xilinx support pages. Anyway, I can look into it this week.
>
> 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
