Modelsim PE vs. Aldec Active-HDL (PE)
in [FPGA]
|
Prev: Antti....
Next: Laptop for FPGA design?
From: Martin Thompson on 8 Mar 2010 07:04 KJ <kkjennings(a)sbcglobal.net> writes: > On Mar 5, 5:34�am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: >> >> Am I the only one that makes *no* use of the various "project things" >> (either in Modelsim or Aldec)? �I just have a makefile and use the GUI >> to run the sim (from "their" command-line) and show me the waveforms. >> I guess I don't like to be tied to a tool (as much as I can manage) >> much as I don't like to be tied to a particular silicon vendor (as >> much as I can manage :) >> > > But you're also running *their* commands to compile, run and view so > you're not really any more independent. This is true, but the "porting" can be done once and pushed into scripts. Porting my "muscle-memory" is a lot harder, if the buttons to click move around :) Waveform viewing is still an issue, as that will likely change the most, but I spend a lot less time doing that than most other tasks. Certainly, the differences between two tools didn't pain me much when I was trying two in parallel. > Maintaining make files can be a chore also, unless you use something > to help you manage it...but then you're now dependent on that tool > as well. Emacs. I don't mind being dependent on that so much. > >> Am I missing something valuable, or is it just different? >> > Probably depends on which scenario is more likely to occur > 1. Change sim tools Or using a variety all the time... I'd like to do more experimentation and comparison, esp. of the open source tools. > 2. Add new developers (temporary, or because you move on to something > else in the company) > > If #1 is prevalent, then maybe using other tools to help you manage > 'make' is better. If #2 is more prevalent, then using the tool's > project system is probably better in easing the transition. I guess that's a point in its favour (assuming I can't "convert" the incomers to Emacs :) > If neither is particularly likely...well...then it probably doesn't > much matter since one can probably be just as productive with > various approaches. Which is probably why we have lots of approaches - dofferent strokes and all that! Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Andy Peters on 8 Mar 2010 13:51 On Mar 6, 9:41 am, KJ <kkjenni...(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 I said, I have always just dumped everything into 'work' without thinking too much about it, mainly because it always just worked. I thought about using separate libraries as a sop to how Active-HDL organizes its workspaces. > 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) No issues with namespaces here. I've adopted a simple prefix nomenclature for things that hopefully mitigates any potential clashes. > > 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). I agree: I never use component declarations except to work around other tool issues (like with the Xilinx EDK and how it apparently analyzes things into particular non-work libraries). > 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 Those component declarations I've described are in a package that's in the same source file as the entity. I think I need to simply stop using the Active-HDL GUI and do the command-line thing. -a
From: rickman on 8 Mar 2010 15:32 On Mar 8, 6:53 am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > rickman <gnu...(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 :) Are you saying that Emacs understands VHDL well enough to build a test bench for you? Will it also build a component declaration or instantiation automatically? These three things could be automated, but I have never taken the time to do it. Making it part of the editor makes perfect sense. Rick
From: rickman on 8 Mar 2010 15:34 On Mar 8, 7:04 am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > KJ <kkjenni...(a)sbcglobal.net> writes: > > I guess that's a point in its favour (assuming I can't "convert" the > incomers to Emacs :) You can convert me. I just need to know that it is an advantage to switch. Rick
From: Andy Peters on 8 Mar 2010 16:40
On Mar 8, 1:32 pm, rickman <gnu...(a)gmail.com> wrote: > On Mar 8, 6:53 am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > > > rickman <gnu...(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 :) > > Are you saying that Emacs understands VHDL well enough to build a test > bench for you? It will create a skeleton for you. > Will it also build a component declaration or > instantiation automatically? These three things could be automated, > but I have never taken the time to do it. Making it part of the > editor makes perfect sense. The skeleton has a nice header, an instance of the DUT, signal declarations for all DUT I/O and a simple clock generator. Of course you have to create your own stimulus and add instantiations of other models as necessary. -a |