From: Joel H. <jo...@ai...> - 2013-05-25 12:10:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Iztok, A couple of things to discuss with you... First, I've just been doing a little work on the butterfly logic. https://github.com/jhol/butterflylogic/commits/public This branch contains a simple infrastructure to port the project for various boards. The user can now do the following: $ ./configure --board--board=boards/openbench-logic-sniffer/board $ make syn The board files specify the FPGA and the constraints file. Specifying a board is not mandatory. If no board file is specified synthesis will be disabled. The project then has a central project file that lists the sources, and the top-level module. From this we can do the synthesis, as well as in the future make IDE project files for debugging purposes. Some things could be improved - e.g. the layout of the project folder, but I wanted to submit it sooner rather than later. Also the mapper says the current version of the source won't fit in the OLS FPGA - I don't know if this is a mistake or not. The branch also contains an automated tidy-up verilog patch, deleting trailing whitespace, replacing tabs with spaces, and replacing are the CRLFs with LFs. Second, is about licensing. It seems like there's several licenses in the code now. Some files are missing copyright headers. It seems like there's a mixture of LGPL and GPL 2 and 3. Then I see you added the Xilinx headers in the lib/ folder - which seem to be proprietary. Do you need these files to be here? because it seems like they shouldn't be. Then all the (L)GPL files need to be rationalised to a common license. Any thought about all this? Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRoKnVAAoJEHgUeO+Es/hF0nwH/1UOjRi6zqOsoz2p9zwTXzIC DH/I8jTVs/Xaw2K+VCIuI9rihpQzzvFqOW975nSdw63uipU+qIJFfytzGj1a1pGO TvCGpAhpR6TaR8a47O1EzeFK7sn0h0pv57jRVGcuXe4f9F55DDdgMdThCbuutnob HEpbDyWjoIzJcqiz64cSMCcfodoM7GORylfY79gQYYcXus/UoOPovR5ERM/EQFFx 0u4MiXsGFJFJPHTFHwacSW2+4Kv+87WcJpjANQwfx6KIC6b80Gshgqkj070Eef74 DBDihcXsQui43woLP3w2qfNHs/tCt2epw6ZiHk+sv+bM43sdAFIGpF4Gi1NKTg0= =e4EZ -----END PGP SIGNATURE----- |
From: Joel H. <jo...@ai...> - 2013-05-26 17:09:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good news - the firmware synthesizes now via my makefile setup. Right now the Xilinx ISE tools have to be in the PATH. Soon the configure script will handle that. On 25/05/13 13:08, Joel Holdsworth wrote: > Hi Iztok, > > A couple of things to discuss with you... > > First, I've just been doing a little work on the butterfly logic. > > https://github.com/jhol/butterflylogic/commits/public > > This branch contains a simple infrastructure to port the project > for various boards. The user can now do the following: > > $ ./configure --board--board=boards/openbench-logic-sniffer/board $ > make syn > > The board files specify the FPGA and the constraints file. > Specifying a board is not mandatory. If no board file is specified > synthesis will be disabled. > > The project then has a central project file that lists the > sources, and the top-level module. From this we can do the > synthesis, as well as in the future make IDE project files for > debugging purposes. > > Some things could be improved - e.g. the layout of the project > folder, but I wanted to submit it sooner rather than later. Also > the mapper says the current version of the source won't fit in the > OLS FPGA - I don't know if this is a mistake or not. > > The branch also contains an automated tidy-up verilog patch, > deleting trailing whitespace, replacing tabs with spaces, and > replacing are the CRLFs with LFs. > > Second, is about licensing. It seems like there's several licenses > in the code now. Some files are missing copyright headers. It seems > like there's a mixture of LGPL and GPL 2 and 3. Then I see you > added the Xilinx headers in the lib/ folder - which seem to be > proprietary. Do you need these files to be here? because it seems > like they shouldn't be. Then all the (L)GPL files need to be > rationalised to a common license. > > Any thought about all this? > > Joel > > ------------------------------------------------------------------------------ > > 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 sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRokGDAAoJEHgUeO+Es/hFSisH/1kMUZQPvWx7nSYdbt6Vl0oL OMn716iGIf12tu0hbfScje7S2ndWifl+F6EPbAvIZJyCyJ1Ul1rHQk+skxxM8iWD P+aWyex+iotWqUkV7KrpHXBmzYE+1NFzdZezx0RGgPW5Dxjg90mLcP8StBfAtx9b NjTLBVoFKpRJ00YCyR4BM/1viKL/WadaRbQaYNskaHLzReVjNX0TV6wFU18KCtDQ THEQUs30PjpgPDUpdU1bQQVKvaXtQv63qvHqa1JeUHBSVJhQUUdmEXRnTtB+EPZT wZEwn1R6nSUi4BH1FDMsVvnIbKpGDky0FV+pHY5Qxss4OfwVwHYJVxHQubHZ50s= =1lRf -----END PGP SIGNATURE----- |
From: Iztok J. <izt...@gm...> - 2013-05-27 05:39:24
|
Hi Joel, On Sat, May 25, 2013 at 2:08 PM, Joel Holdsworth <jo...@ai...>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Iztok, > > A couple of things to discuss with you... > > First, I've just been doing a little work on the butterfly logic. > > https://github.com/jhol/butterflylogic/commits/public > > This branch contains a simple infrastructure to port the project for > various boards. The user can now do the following: > > $ ./configure --board--board=boards/openbench-logic-sniffer/board > $ make syn 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. 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. > > The board files specify the FPGA and the constraints file. Specifying > a board is not mandatory. If no board file is specified synthesis will > be disabled. > > The project then has a central project file that lists the sources, > and the top-level module. From this we can do the synthesis, as well > as in the future make IDE project files for debugging purposes. > 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) 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. > > Some things could be improved - e.g. the layout of the project folder, > but I wanted to submit it sooner rather than later. Also the mapper > says the current version of the source won't fit in the OLS FPGA - I > don't know if this is a mistake or not. > 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. > > The branch also contains an automated tidy-up verilog patch, deleting > trailing whitespace, replacing tabs with spaces, and replacing are the > CRLFs with LFs. > OK, but please do not make it automatic, I do not like if tools update source file, without user knowledge. > > Second, is about licensing. It seems like there's several licenses in > the code now. Some files are missing copyright headers. It seems like > there's a mixture of LGPL and GPL 2 and 3. Then I see you added the > Xilinx headers in the lib/ folder - which seem to be proprietary. Do > you need these files to be here? because it seems like they shouldn't > be. Then all the (L)GPL files need to be rationalised to a common license. > 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. Regarding lib/ folder file, you can remove them right away, I will use the originals from the Xiling ISE installation path. > Any thought about all this? > > Joel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRoKnVAAoJEHgUeO+Es/hF0nwH/1UOjRi6zqOsoz2p9zwTXzIC > DH/I8jTVs/Xaw2K+VCIuI9rihpQzzvFqOW975nSdw63uipU+qIJFfytzGj1a1pGO > TvCGpAhpR6TaR8a47O1EzeFK7sn0h0pv57jRVGcuXe4f9F55DDdgMdThCbuutnob > HEpbDyWjoIzJcqiz64cSMCcfodoM7GORylfY79gQYYcXus/UoOPovR5ERM/EQFFx > 0u4MiXsGFJFJPHTFHwacSW2+4Kv+87WcJpjANQwfx6KIC6b80Gshgqkj070Eef74 > DBDihcXsQui43woLP3w2qfNHs/tCt2epw6ZiHk+sv+bM43sdAFIGpF4Gi1NKTg0= > =e4EZ > -----END PGP SIGNATURE----- > |
From: Joel H. <jo...@ai...> - 2013-05-27 08:03:50
|
-----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----- |
From: Iztok J. <izt...@gm...> - 2013-05-27 11:36:30
|
Hi Joel, On Mon, May 27, 2013 at 10:01 AM, Joel Holdsworth <jo...@ai...>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----- > |
From: Joel H. <jo...@ai...> - 2013-05-28 08:59:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Iztok, >> 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. In minsoc I believe these are being generated from a language agnostic list. >> 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. Cool! When you do that, can you take a look at my branch. If you think it still needs more work, you could git cherry-pick any commits you are happy with, and toss the rest back to me for more polish. >> 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. So the basic formula is $ git rebase -i <some revision before the problem> If the problem is caused by a whole commit you can just remove it from the list, close the editor, and git will rewrite the branch with the commit removed. If the problem is part of a larger commit, set the action from "pick" to "edit", or "e", then close the editor. Git will now drop you at the point right after the commit to edit. "git rm" the files you want to remove, then when you are happy, do a "git commit --amend" to modify the commit. Then finish the rebase with "git rebase --continue". In your case there shouldn't be any merge conflicts to deal with. If you screw up, you can always find the ID of the old commits lying around in history using git reflog. In this case simply attach a branch to it and try again with that. Then when everything is done, push the branch to github. It will complain because of the divergence you just created, so you will need to push it with "git push -f ...." > >> `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. Cool! I'll take a look. >> 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. Yes, I'm surprised $clog2 only made it into Verilog 2001. I mean it's a pretty fundamental use case: Calculate how many bits I need to store this maximum value. I would have thought it would be have been introduced earlier and much more widely. Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRpHHzAAoJEIsWlGmq62IgImkH/RuCng/v1koFxox9ExNsY8ou z8klY1DvWxwqVGiwgfClh4VhnRA4LWqJ1d2zSePpHX16D2KluTWCd92W8KnoO6y9 KVrfW0Xuz52o3EQ9qTtECnhE/iJsn2bQcvYB3NJXxTPB48DHH5nrIQbniy4eXNcE 9tLTJXIhSOAUorPl57Gs6OPM0OfsL5xppnFxn4lGsW5Z5/VG4BzS/GmIxkxTMzzL LYTSGH+qoH+Ah/ICe2pmZaoR49d7fCOyQFLF1Kv10AihqxiH4C7GfyIxWOYJ/omN OpdIoIZ2bW0m5IoohLVx3NfIWuL9/waAy17mv9qPe/E+hNra8serJG2rPg7Jcnc= =kc0m -----END PGP SIGNATURE----- |
From: R. D. <rdi...@ya...> - 2013-05-31 13:17:30
|
>>> 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. > >In minsoc I believe these are being generated from a language agnostic >list. This is one of the things in MinSoC that I didn't like, for those project files are in a propietary format which is bound to change without notice. Most tools (Icarus, Verilator...) allow you to specify verilog source files as command-line arguments, so you can keep your proprietary tool projects down to a minimum. At first, I could not find a way to do the same with Xilinx's synthesizer, but in the end I managed to do it with Verilog's keyword "`uselib" like this: `define OR10 dir=/blah/blah/OpenRISC/OR10 libext=.v `define OR10_CPU dir=/blah/blah/OpenRISC/OR10/CPU libext=.v ... `uselib `OR10 `OR10_CPU ... That way, whenever you reference a module, the synthesizer will try and find it in those directories, so that you do not need to add those paths or files to any vendor-specific project file. Regards, rdiez |