Hi Joel,

On Mon, May 27, 2013 at 10:01 AM, Joel Holdsworth <joel@airwebreathe.org.uk> wrote:
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.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/