Hello,I have a long standing methodological question about the IP generation tools from Altera. They seem to all generate 2 sets of VHDL/Verilog code: one for synthesis, one for simulation. But, isn't it asking for trouble ? why can't we just maximize the amount of common code that gets synthetized AND simulated ? if you have any light on the matter, please share :-)
--- Quote Start --- Hello, I have a long standing methodological question about the IP generation tools from Altera. They seem to all generate 2 sets of VHDL/Verilog code: one for synthesis, one for simulation. But, isn't it asking for trouble ? why can't we just maximize the amount of common code that gets synthetized AND simulated ? if you have any light on the matter, please share :-) --- Quote End --- Which IPs? Tools output one set of design files. The simulation files are given for testbenching(top level and other associated data files) or occasionally the tool may output simulation model e.g. for PLLs. Can you explain your thoughts in more detail.
Sure, for example:I want to produce an avalonMM interconnect system out of the Qsys tool. Once generated, and only asking for the (VHDL) simulation models (ie. not the testbenches) I get 2 sub-folders "simulation" and "synthesis". What is the difference of the code lying under the "simulation" folder and under the "synthesis" one ?
the simulation folder probbly cpntains simulation models, with synthesis containing netlists ( not simulatable directly). you could simulate a post place a route model, if you've got lots of spare time.
No, I am not speaking about synthesis at all, just IP generation.Let me point you to a clear example, if you generate any AvalonMM interconnect, in the "synthesis/submodules" subfolder you will find a file called "altera_avalon_mm_bridge.v". This file can be found (or the template of it more precisely) under <your_quartus_path>\ip\altera\merlin\altera_avalon_mm_bridge. It is a perfectly good file for simulation. So, what does the "simulation" folder bring to the party ?
--- Quote Start --- So, what does the "simulation" folder bring to the party ? --- Quote End --- In my experience, absolutely nothing. When I started using Qsys and SOPC Builder I found it very annoying that the tool would *copy* code, rather than simply providing a link to the source file. Copying the file makes it a pain, since any edits to the Avalon-MM slave or whatever you are working on, do not get reflected in the synthesis unless you re-run "Generate" (a pointless step). I recently found the "work-around" for custom logic; in the _hw.tcl file, rather than add your files, add a .qip file that points to your source. You can setup components.ipx to make sure Quartus knows the paths to all your custom source. Bottom line is that I don't think the Qsys files generation was well thought out, i.e., there are many typical use-cases that were not considered. For example, if you use VHDL and put your code into various VHDL libraries, then Qsys _hw.tcl does not have any support for describing the library in which to compile code, or which library include statements to include in the generated wrapper file. The "solution" is to use the Tcl "generate" callback to construct your own top-level file, and to construct your own .qip files with the appropriate library directives. Cheers, Dave
Some Altera (and 3rd party) IP cores use encrypted source files. While this encrypted source can be decrypted and synthesised by Quartus, it cannot be read by simulator tools such as ModelSim. To get around this Qsys will generate a separate code base for simulation that will substitute the encrypted RTL code for something that ModelSim can read. This may take the from of some manually written clear-text model for the IP core in question (this is often used for hard blocks like PLLs and transceivers as thay don't have RTL code), or one of two other options. The old flow for encrypted cores was to generate a non-synthesisable netlist description for the IP block, but this is largely being replaced by IEEE encryption. For IEEE encrypted cores, Altera releases a version of the code that encrypts the code with an Altera specific key, and separate versions of the code that are encrypted with each simulation vendor's encryption key. Quartus can only decrypt and synthesise the Altera encrypted file, and each simulator tool can only decrypt the version of the code encrypted for it.The Qsys output directories and methods may not be optimal, but there is at least a clear reason why it separates synthesis and simulation directories.
--- Quote Start --- The Qsys output directories and methods may not be optimal, but there is at least a clear reason why it separates synthesis and simulation directories. --- Quote End --- I would agree if those directories were *only* used to contain Qsys generated code and encrypted cores. However, the tool also copies over library components that exist in the Quartus installation, and copies user code, rather than leaving it where the user wants. I have also heard the argument that copying the code allows the whole folder be zipped and passed off to another user. However, I don't buy into that argument either. HDL development is akin to software development. Most software developers would not be happy if every time they compiled a program, their source file was copied to a build folder, and then *that* copy referred to in subsequent builds, rather than the original source the user pointed the tool to. I know, its impossible to make all users happy. But it would be nice to have Qsys Tcl options to control whether or not source that is valid for both synthesis and simulation gets copied or not (i.e., left at the original source path). Cheers, Dave