Modelsim PE vs. Aldec Active-HDL (PE)
in [FPGA]
|
Prev: Antti....
Next: Laptop for FPGA design?
From: KJ on 6 Mar 2010 11:41 On Mar 5, 4:53 pm, Andy Peters <goo...(a)latke.net> wrote: > > It turns out that it is reasonable to create one workspace for an FPGA > project and within this workspace create a "design" for the > subentities and the top level. If you let it use the design name as > the working library for the design, then as long as you "use" the > library in a higher-level source, that source can see those other > libraries. Why do you think that you need to segregate the library that the source files get compiled into? In other words, what is wrong with compiling everything into 'work'? That's not a source file, it's an intermediate folder(s) that gets created along the way to doing what you need to have done. What do you gain by trying to have tidy intermediate folders? Having a separate library helps you avoid name clashes, but for things that you're developing yourself this is more easily avoided by considering some of the following points: - Question the validity of why you have two things named the same (presumably doing the same thing) - Consider parameterizing the design instead so that there is only one thing with that name, but now you have a parameter that can select what needs to be different. - If the differences between the designs are significant such that parameterizing simply encapsulates each approach within big 'if xyz generate...end generate', if abc generate...end generate' statements then consider collecting each design as simply differently named architectures of the same entity (i.e. 'architecture RTL1 of widget', 'architecture RTL2 of widget') - Avoid the name clash by renaming one of them to be more descriptive to distinguish it from it's sibling > > Now I'm thinking that the usual method of doing: > > u_foo : entity work.foo port map (bar => bar, bletch => bletch); > > might be better as: > > u_foo : entity foo.foo port map (bar => bar, bletch => bletch); > > The other option is to create a package with a component definition > for foo, and analyze that package into the foo library, so the > instantiation can be: > > u_foo : foo port map (bar => bar, bletch => bletch); > > I really don't know which is "better." > Neither one is particularly good in my opinion. The reasons against the first approach I've mentioned above (i.e. what do you really get for not simply compiling everything into 'work'?). The only place I've found a component declaration to be useful is when you would like to use a configuration to swap things out and about. The only time I've found configurations to be useful really is when the VHDL source is not really under my control (such as when a PCBA model is generated by a CAD tool). With a component declaration, you still have to decide where to put that declaration. The best place is in the source file with the entity so that changes to one are more likely to get changed in both places. Given that, I don't see how components will help you manage anything better....my two or three cents Kevin Jennings
From: Brian Drummond on 6 Mar 2010 19:44 On Sat, 6 Mar 2010 08:41:57 -0800 (PST), KJ <kkjennings(a)sbcglobal.net> wrote: >On Mar 5, 4:53�pm, Andy Peters <goo...(a)latke.net> wrote: >> >> It turns out that it is reasonable to create one workspace for an FPGA >> project and within this workspace create a "design" for the >> subentities and the top level. If you let it use the design name as >> the working library for the design, then as long as you "use" the >> library in a higher-level source, that source can see those other >> libraries. > >Why do you think that you need to segregate the library that the >source files get compiled into? In other words, what is wrong with >compiling everything into 'work'? That's not a source file, it's an >intermediate folder(s) that gets created along the way to doing what >you need to have done. What do you gain by trying to have tidy >intermediate folders? as you said, tidiness... I use separate libraries for major categories within the design; e.g. memory interface, core logic, common (reusable) blocks, testbench - not separate libraries for foo, bar and bletch. I can't say it buys me a whole lot but it does help me keep the design hierarchy straighter - e.g. if the synthesis project contains something from the Testbench library, the design has gone seriously astray somewhere! though Xilinx EDK also uses it to version libraries that are common (apart from being different versions) to different IP blocks. >Having a separate library helps you avoid name clashes, not if you're using Xilinx XST it doesn't... unfortunately. Incredibly, XST doesn't support VHDL qualified identifiers from different libraries. In the presence of unqualified name clashes it will pick the right name from whichever library it wants, so WILL synthesise something completely different from what you intended, and tested in simulation. This has been around since 6.1 at least, and may or may not be fixed in ISE 12. which, as far as I can see, is the ONLY reason why all those EDK blocks get separately synthesised, then black boxed into the top level design. - Brian
From: KJ on 6 Mar 2010 20:26 > > What do you gain by trying to have tidy intermediate folders? > > as you said, tidiness... > tidy intermediate folders...i.e. folders that are not important to me as the user of the tool, but are needed by the tool to do it's job. In other words, I don't care if the tool's private folders are tidy or not. > I use separate libraries for major categories within the design; e.g. memory > interface, core logic, common (reusable) blocks, testbench - not separate > libraries for foo, bar and bletch. > My point was why even bother to separate them unless there are name clashes...or perhaps you're creating your own separate IP for resale and want to avoid clashes with some other potential IP. > I can't say it buys me a whole lot I agree > but it does help me keep the design hierarchy > straighter - e.g. if the synthesis project contains something from the Testbench > library, the design has gone seriously astray somewhere! > If it's actually a problem, the synthesis tool will complain quickly (like less than 1 minute into the run)...but the synthesis tool won't be looking at any libraries (testbench or other) it will create the libraries itself based on the source files you tell it are in there to be synthesized. Whether you compile such a testbench file into 'work' or 'testbench' won't matter. If the source file is included it will be analyzed. If it happens to be synthesizable code (even if it is only intended for sim testbench) synthesis will be OK with it. It won't generate any logic from this extraneous code since it won't be called from within the hierarchy of the design to be synthesized. I confess though, I'm not quite sure what your point is here for compiling stuff into separate libraries. It *sounds* like you're talking about organizing source files into separate 'libraries'...in which case what you said would make more sense but that's not at all the same thing as compiling something into a library other than 'work'. Kevin Jennings
From: Brian Drummond on 7 Mar 2010 08:08 On Sat, 6 Mar 2010 17:26:24 -0800 (PST), KJ <kkjennings(a)sbcglobal.net> wrote: >I confess though, I'm not quite sure what your point is here for >compiling stuff into separate libraries. It *sounds* like you're >talking about organizing source files into separate 'libraries'...in >which case what you said would make more sense but that's not at all >the same thing as compiling something into a library other than >'work'. You can't keep source files in separate libraries - separate folders, yes, hence (I presume) your quotes around 'libraries'. While I do that, I also tend to use a VHDL library structure that reflects the same source folder structure and design intent. Except when tool bugs prevent it. It's really mostly habit, a satisfactory (to me) way of working acquired back in my Modula-2 days. I'm not making wild claims that it's better in any substantial way, but VHDL was designed to allow compilation into separate libraries... Speculating why, it would presumably have allowed compiled libraries to have been re-used across multiple projects, in the days when compilation and synthesis were expensive operations. Nowadays, that is trivially unimportant, except for the highly optimised treatments given to standard libraries. Tools could make use of it for distributing IP as compiled libraries instead of source, but they don't... .... aah, that must be it - I'm just waiting for the tools to catch up! ;-) - Brian
From: Martin Thompson on 8 Mar 2010 06:53
rickman <gnuarm(a)gmail.com> writes: > I find the GUI will save me a lot of typing when instantiating > modules. I use the "generate test bench" feature to build a file > with the meat and potatoes in it and I copy that to the higher level > module. Ahh, I use VHDL-mode in Emacs for that, which is why I haven't missed it :) -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html |