In Quartus standard edition,it supports 'HDL convert to bsf file' function(create symbol files for current file).But in Pro edition,I can't find this function.Does the Pro edition removes this function?How to solve it If I want to use bsf design？Thanks!
Yes, Quartus Pro edition had remove this function.
The reason of the removal is Intel want to encourage user to use coding instead of schematic to do the design. There are no plan to bring this function back.
Please let your Quartus Pro software designers know that the solution to this problem is very simple. All that is needed is to incorporate the .BSF symbol building function as part of the Platform or IP Designer programs. By simply providing an option to build a .bsf instead of a full IP module from the library, this allows the .bsf symbol to be treated exactly like the .IP files, and everything works perfectly! Even things like .SDC constraint files and IEEE encryption can be managed using this .bsf symbol approach. That should would help us old poor electrical engineers out here with no way to manage our own IP!
(P.S., I'm not such a beginner!)
I don't want to be-labor this point ... but the idea that Intel wants to move Engineers back to HDL coding is ridiculous. Intel is telling us they want to move us to a higher level of abstraction. That's all that the schematic does .... is gives us a higher level of abstraction! SCHEMATICS ARE IMMEDIATELY CONVERTED TO HDL BEFORE COMPILING NOW! if Intel would put a little more effort into the schematic editor, the symbol editor, and make it part of platform designer, that would be a big help for us, and for Intel.
Some point's Intel should consider:
1) SCHEMATICS ARE IMMEDIATELY CONVERTED TO HDL BEFORE COMPILING NOW ANYWAYS!
2) QUARTUS PRO ALREADY SUPPORTS BLOCK SYMBOLS FOR ALL ITS IP !!!!!!!!!!!!!!!!!!!!!! (you can't claim what you're claiming)
REMEMBER .... XILINX VIVADO still supports block symbol entry with total backing !!!!
This whole deprecation (converting HDL to .BSF) is stopping engineers from developing their own IP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Deprecating the ability to convert HDL to .bsf format should not affect the integrity Intel's platform design, and this is a huge mistake. It is now nearly impossible for me to port a previous design in Quartus Standard edition to Quartus Pro edition because of this deprecation. The designers of Quartus should know that symbol files are converted to specific instances of the Verilog module, and so there is no portability if we cannot regenerate the block symbols in the Pro version. So it's a huge mess with no apparent work-around other than try to go back to standard edition.
If you still have Standard installed, you can convert any .bdf or .bsf to code that you can bring into Pro.
Schematics are nice for a top-level or a smaller design from back in the day, but working with an HDL is really the standard now for FPGA design (or even a higher level language like C++).
I'm not sure what you mean about Pro supporting block symbols. There is a block symbol view in the parameter editor to help with parameterizing IP. Yes, strangely you can generate a .bsf in the parameter editor and Platform Designer. I'm not sure why that option is still there.
Yes, thanks for the tip. What I'm doing is keeping a dummy project open in the Standard edition, and that allows me to generate .bsf symbols for my project in the Pro edition. I just load the files I need to create in standard, and update them from Pro. I keep two File Explorer windows open so I can slide some of the .bsf symbol files created in Standard edition over to the correct directory.
There is great misunderstanding by Intel when it comes to schematic level/block level design entry for FPGAs. Intel must be thinking we're using "AND" gate symbols or something like that out of their old library. That's not what we're doing! What engineers are doing is building complex modules in Verilog or VHDL. Once that's debugged, they convert the module to a block diagram, just like the Intel IP does now.
The reason Engineers do this, is because the complexity of the module interconnections is made simple. For example, consider a systolic matrix multiplier comprised of many sub-module ALU units. It's just easier to connect these ALU modules into a full-blown matrix multiplier using the block symbol approach. Once that is done, we convert the top-level schematic back to Verilog for simulation.
Block diagrams that are generated automatically from your Verilog code is NO replacement for the block diagram structure created by the designer. This is another misconception.
I DO see why Intel doesn't want to support the old .bsf symbol creation process in Pro. But just taking it out is the wrong action. Intel should create a way to create .bsf files from the IP configurator platform and allow engineers to drop associated .sdc files to be associated with those symbols. In other words, Intel CAN make the .bsf symbol generation compliant to their new directory structure under Pro. Apparently, Intel doesn't want to.
If Intel was thinking of electrical engineers, and how EE's might pollenate new applications for Intel devices, then Intel should provide an easy method to encrypt our Verilog during the symbol creation process. (IEEE standard made easy). (It's another problem Intel doesn't understand .... Electrical Engineers end up going into the software profession because software can easily be developed and licensed. On the other hand, electrical engineers are being stripped of any such opportunities (and I hate to say it .... by Intel).
Lastly, Xilinx Vivado supports block diagrams throughout the entire design process. There is no limiting the Engineers ability to use block symbols. But if Quartus can solve this simple issue, make the schematic capture software a bit better, then Intel would really have a leg up over Xilinx. It's a shame. So, until Intel realizes that this decision was very poorly made, I'll need to work between the standard and Pro editions to get the job done! Ooouch!!!
Look, some of these feature deprecations are being decided because of other factors, like not having control over the schematic software. Fix that!