Hi everybody, reading the news about OpenCores Certified Projects I read again over the OpenCores Design Guidelines. After a good document and I can agree on almost all recommendations. However I have a problem with the "recommended directory structure". The top level entries are totally fine but the sub-sub-directories make little sense to me: totally perfect to have a synthesis directors called "syn" with a subdirectory for a specific vendor tool. e.g. "/syn/Altera_quartus/" But now the design guide specifies a "log", "run", "bin", "src" directory. The "src" still makes sense for specific souces/settings but the rest make just no sense to me since I have a very hard time to tell quartus to put its logfiles (*.rpt) in another directory than the project directory (run).
Additionally I don't have scripts to put in "bin" - all I have written is a makefile and the project settings file.
Fellow community, what do you think - did we put a too fine granular recommendation that becomes unwieldy? At what point it is legitimate to deviate form design recommendation?

yours truly

p.s. I just discovered that I can'T delete uploaded documents and links in the "downloads" section of my project - I only can add new...

Hi everybody,
reading the news about OpenCores Certified Projects I read again over the OpenCores Design Guidelines. After a good document and I can agree on almost all recommendations. However I have a problem with the "recommended directory structure". The top level entries are totally fine but the sub-sub-directories make little sense to me:
---------------------

Actually the top level has problems. sim,syn,rtl,doc and sw are all major functions that interplay with multiple other major functions. bench and backend do not. They only interplay with one other function. bench should be under sim and backend should be under syn

There should also be a bin directory at the top level if for no other reason than to hold a Makefile that calls all the other scripts in the lower levels. The top level Makefile should be consistent between projects so that typing make all in the bin directory will run everything in that
project


---------------------------------

totally perfect to have a synthesis directors called "syn" with a subdirectory for a specific vendor tool. e.g. " root_dir /syn/Altera_quartus/"
But now the design guide specifies a "log", "run", "bin", "src" directory. The "src" still makes sense for specific souces/settings but the rest make just no sense to me since I have a very hard time to tell quartus to put its logfiles (*.rpt) in another directory than the project directory (run).
-----------------------------------

You write a script that calls quartus and when it finishes then script then moves all the log and rpt files to their proper locations. If your smart you can also write a script that parses out the important data and lets you know if it ran ok.

---------------------------------------------------

Additionally I don't have scripts to put in "bin" - all I have written is a makefile and the project settings file.

---------------------------------------------
Put Makefiles in bin. It's for any program or script that is executed

---------------------------------------------------------

Fellow community, what do you think - did we put a too fine granular recommendation that becomes unwieldy? At what point it is legitimate to deviate form design recommendation?

yours truly


-----------------------------------------------------------

The granularity isn't the problem. The structure is the problem. the syn directory allows for multiple vendors which is great when you want to target a design to more than one board. But I have three different fpga boards that all have xilinx parts on them. Now what? A target is much more than a vendor , it is a vendor and a part number and a pinout. If you have the same fpga on two different boards with different pinouts then you need different directories. Theres no good place to put them in the current spec

rtl code is more than simply verilog or vhdl. You use a state machine tool? put that source in a rtl/fsm directory and use a makefile to generate the code. Do the same with any other tool like a register or bus builder.

Rtl should also have a directory to support variants. I want to be able to use something like the or1200 and put in multiple cores with different cache configurations. You need a variants directory to hold the different define files and preprocess them into different gen files.

sims needs to contain the bench directory that contains the testbench and any models used in the testbench. You also need a lib for any srams, clock/pll sources, pads and other nonsynthesisables.
Sims is also a two dimensional space. If my component has 3 embedded software programs and 4 variants then I might need 12 sims to check every configuration. Thats rtl sims. Gates sims will need that times the number of different targets that you are planing to use. That means whatever structure you use under rtl_sims will not work for gate_sims. gate_sims would fit better under the syn directory that creates the gates.

You also need a second rtl_sim under each syn/gates directory. The main rtl_sims uses your generic non-vendor models for pads, srams etc. If the vendor provides those models then you must rerun the rtl using those models instead of the generic ones.

The directory structure recommendation in the guidelines is for one single IP core, not for a complete FPGA or a complete ASIC. You could have several IP cores in on FPGA or ASIC. I guess you shouldn't synthesize the complete FPGA or ASIC within the directory structure of one of the IP cores. This is where you synthesize a netlist for the IP core, so the pinout of the FPGA doesn't matter here.

In an FPGA, I guess you put several IP core directories in parallel, and also a top level directory which contains your own stuctural source code that connects the IP cores together. Here you can make sub directories for for synthesis of the top level. You can do this to support variants, different PCBs, etc in any way that you want.

The guidelines does not specify how you should make your FPGA or ASIC top level directories, only the directories for the cores that are part of the complete FPGA or ASIC.

Or is there something that I have misunderstood?

But I think that for each core, there should be syn sub directories not only for synthesis tool vendors, but also for different FPGA families. Example: quartus2_cyclone4, ise_spartan6, etc.

The guidelines does not specify how you should make your FPGA or ASIC top level directories, only the directories for the cores that are part of the complete FPGA or ASIC.
--------------------

But they should do that. You create component IP and then configure and combine them to make a larger component that is then used to create a even larger one until you have a single design that represents one chip. You now need to be able to synthesize this design into one or more targets and the guidelines need to spell out where to put these top level files.

We also need to support partitioning. You create one design that could go into a single asic or it could also be partitioned into a pca and multiple fgpas. You want to be able to do this with a single database in order to ensure that the asic and fpga logic matches.

John Eaton