Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, Using the menu pulldown Design -> Settings, you get at the design settings window. Here, on the left hand side there is a category sub-window. If you go to General -> Simulation -> Generic/Parameters you can add your generic settings to the window on the right hand side. The design settings window should pop up automatically if there is no top-level design configured and you select the Simulation -> Initialise Simulation menu pulldown. All that said, I prefer to put everything in a *.do file, with the -g switches set in the call to asim. But then I normally use riviera under Linux and only resort to activeHDL when a customer needs it. Charles > > restart > # ELBREAD: Elaboration process. > # ELBREAD: Elaboration time 0.0 [s]. > # KERNEL: Main thread initiated. > # KERNEL: Kernel process initialization phase. > # KERNEL: Time resolution set to 1ps. > # ELAB2: Elaboration final pass... > # ELAB2: Create instances ... > # ELAB2: Create instances complete. > # ELAB2: Elaboration final pass complete - time: 0.1 [s]. > > It does say "final pass", so maybe this is not the "full" > elaboration. But it does the same thing after compiling the entire > project. > > It seems I have to use the small square button (VCR stop) to stop the > simulation to get it to accept a new set of top level generics even if > the source is recompiled... strange... > > RickArticle: 146526
True. Reducing jitter does need a higher clock speed. and a stable power supply.Article: 146527
Hello Everybody, I'm a newbie of the Actel devices and they seems to be promising for many purposes. We brought a AGL-DEV-KIT-SCS-SA, an evaluation board for Actel IGLOO AGL600 FPGA. I want to use the Core8051s on it since the design software allow me to instantiate it. Do you have a sample design for this FPGA? I found a sample design for the Fusion FPGA but it doesn't fit my FPGA and I have several problems in importing it.... I have some questions: 1. Which Memories I need? How are connected to the Processor? 2. Once I create the Design, where I'll put the "ihx" software code? Any Idea or reference is welcome Thank youArticle: 146528
I've been running Quarus under Gentoo for quite a few years. Despite that Gentoo is not an officially supported Linux distribution by Altera, it has worked fine with practically no problems. After upgrading to 9.1 I keep getting the message: rpm: Command not found. whenever I launch an Altera program. However, I thought this caused no problems other than the output of this message on stdout. I don't know why Quartus always runs rpm, maybe to query packages under Red Hat. But it seems like if I run "sopc_builder --generate" sopc_builder will be confused by the excessive output and think that its sub-process has failed: Error: qmegawiz command failed stdout: stderr:rpm: Command not found. Have anybody figured out a workaround for this? I tried to write a script called rpm which quitely returns success, but it seems like Quartus looks for rpm at a specific location as it does not take my bait. Petter -- .sig removed by request.Article: 146529
rickman <gnuarm@gmail.com> writes: > It is just the repetition of the message I think. I should try to go for some more frequent variation in the future. gnus-posting-styles makes this easy so I have no excuse other than it's been a while since I looked into its syntax and features. > The same is true for commercials on TV. I can't stand some of them > the first time I see them. Others start getting on my nerves after a Luckily(!?) I live in a country where they only have crap on TV so it's not worth watching, though every TV owner has to pay even if your're watching it or not. Petter -- .sig removed by request.Article: 146530
Hi, I am using MIG 3.3 for generating memory interface for Micron MT4HFT3264HY-53 memory part. The user_design and example_design simulations work fine. I just need one clarification. The addresses generated by the stimulus for the user interface (app_af_addr, app_af_cmd, app_af_wren, app_wdf_data, app_wdf_wren etc) are at an offset of 8 (design generated for sequential reads/writes with a burst length of 4 for a single ended clock). I need to understand the relationship of this address offset, is it related to the memory part MT4HFT3264HY-53 ( 32M x 64) or is it related to the user address/data FIFOs which are in 512x36 configuration. anyone please? Thanks Seeker...Article: 146531
Rob, I have your case notes now. Here are some of the comments (edited for brevity): -snip- This customer is cascading 2 PLLs together. The software group had the case for some time before dispatching it to IP. I just received a subcase from XXXX on this today but haven=92t looked at the files yet. -end snip- So, it looks like the case was dispatched to the wrong internal group. Our fault. Sorry for that, but it looks like it is at the right person. More: -snip- - Timing errors seems (but I need to verify now that I have files) to be due to cascaded PLLs - I have had no reports of port mismatches in our MIG 3.2 (ISE 11.3) VHDL code - Polarity issue in calibration logic in ISE 11.4 is a known issue documented in a Design Advisory AR - Debug signal in simulation is a documentation issue that I will look into. -end snip- So, yes, the polarity issue is documented, but we also will see this again (below)... - snip- There are some known limitations to S6. Initial clock planning and pin placement can cause challenges later. Performance is not a significant step above S3. The memory controller does have many issues. - While the controller does have issues, all known problems are documented and so are our clocking guidelines. This is a case of not following our guidelines, difficulty in finding the needed documentation, and a documentation error (the later 2 definitely being our issue). -end snip- OK, finally an admission that we should have done a better job. In any event, "not following our guidelines" is not an acceptable reason, as it just points to the fact we did not do a good job of documentation! -snip- 11.3 was a significant update for S6 and improvements/fixes continue to come in 12.1. He was a first adopter if he was using 11.2, there were definitely issues in 11.2. -end snip- Then follows an apology to me (and you), along with some details of what happened internally. Basically, your early adoption suffered from S6 support being "brand new." So, now that the right person has the case, I think it will go smoother. If it doesn't email at austin@xilinx.com. Did we (Xilinx) make mistakes? Yes, we did. Is it worth working with ES parts and the first release of software? In my opinion, yes, as you still get a tremendous competitive edge ahead of all those who will adopt the new part. Is it a perfect experience? Unfortunately, no, not in this case. We will do better next time, and we do learn from each mistake. It is important that Xilinx hears about the bad, and the good. My role (in a very small way) is to make sure we are not fooling ourselves (which is very easy for a large company to do).Article: 146532
It's part of Altera's 'check for updates'. Just install rpm and be done with it; that's what I did. RK Top-posted only to annoy ;) On Mar 22, 6:38=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > I've been running Quarus under Gentoo for quite a few years. Despite > that Gentoo is not an officially supported Linux distribution by > Altera, it has worked fine with practically no problems. > > After upgrading to 9.1 I keep getting the message: > > rpm: Command not found. > > whenever I launch an Altera program. However, I thought this caused no > problems other than the output of this message on stdout. I don't know > why Quartus always runs rpm, maybe to query packages under Red Hat. > > But it seems like if I run "sopc_builder --generate" sopc_builder will > be confused by the excessive output and think that its sub-process has > failed: > > Error: qmegawiz command failed stdout: stderr:rpm: Command not found. > > Have anybody figured out a workaround for this? I tried to write a > script called rpm which quitely returns success, but it seems like > Quartus looks for rpm at a specific location as it does not take my > bait. > > Petter > > -- > .sig removed by request.Article: 146533
rickman <gnuarm@gmail.com> wrote >I also have old versions of the Xilinx tools complete with dongle and >programming cables. That's one of the reasons why I hate licenses. >You may have everything you need, except if the PC is different you >may need a new license file. That's the way it is with my current >Lattice software. So far they have been happy to provide a license >file for every new machine I've wanted to port the software to. But I >am sure that one day that will no longer be the case and I'll be >stuck! Xilinx did this to the software I am selling. Old dongles no longer supported, and all schematics got orphaned. Fortunately, some enterprising chap developed a "work around" :) Incidentally, does Viewlogic still exist as a product? I see they were bought by Mentor.Article: 146534
Charles, Thanks for the reply. I understand how to change the generic parameters. The problem is that they aren't used until I stop the simulation. Using the restart control or even recompiling doesn't seem to load the new values unless I actually use the "stop simulation" control. I guess I'm used to the GUI understanding things like this and when I update a generic I expect the tool to do what it takes to have it take effect. Rick On Mar 22, 7:12=A0am, Charles Gardiner <inva...@invalid.invalid> wrote: > Hi, > Using the menu pulldown Design -> Settings, you get at the design setting= s window. > Here, on the left hand side there is a category sub-window. If you go to = General > -> Simulation -> Generic/Parameters you can add your generic settings to = the > window on the right hand side. > > The design settings window should pop up automatically if there is no top= -level > design configured and you select the Simulation -> Initialise Simulation = menu > pulldown. > > All that said, I prefer to put everything in a *.do file, with the -g swi= tches set > in the call to asim. But then I normally use riviera under Linux and only= resort > to activeHDL when a customer needs it. > > Charles > > > > > restart > > # ELBREAD: Elaboration process. > > # ELBREAD: Elaboration time 0.0 [s]. > > # KERNEL: Main thread initiated. > > # KERNEL: Kernel process initialization phase. > > # KERNEL: Time resolution set to 1ps. > > # ELAB2: Elaboration final pass... > > # ELAB2: Create instances ... > > # ELAB2: Create instances complete. > > # ELAB2: Elaboration final pass complete - time: 0.1 [s]. > > > It does say "final pass", so maybe this is not the "full" > > elaboration. =A0But it does the same thing after compiling the entire > > project. > > > It seems I have to use the small square button (VCR stop) to stop the > > simulation to get it to accept a new set of top level generics even if > > the source is recompiled... strange... > > > RickArticle: 146535
On Mar 22, 12:34=A0pm, Peter <nos...@nospam9876.com> wrote: > rickman <gnu...@gmail.com> wrote > > >I also have old versions of the Xilinx tools complete with dongle and > >programming cables. =A0That's one of the reasons why I hate licenses. > >You may have everything you need, except if the PC is different you > >may need a new license file. =A0That's the way it is with my current > >Lattice software. =A0So far they have been happy to provide a license > >file for every new machine I've wanted to port the software to. =A0But I > >am sure that one day that will no longer be the case and I'll be > >stuck! > > Xilinx did this to the software I am selling. Old dongles no longer > supported, and all schematics got orphaned. Fortunately, some > enterprising chap developed a "work around" :) > > Incidentally, does Viewlogic still exist as a product? I see they were > bought by Mentor. Yes, Mentor bought them some time ago and I believe it is still a product, but with a different name. Everyone still uses schematics for board level design, so the tools will always be there. Although to a large extent, even schematics are really just pin lists. When I plop an FPGA on the drawing page I am treating it like a pin connection list tying each pin (with its pin name) to a short net with its net name. The other end of the connection is almost always on a different page with the same net name/pin name connection list. The fact that the pin names are inside a box and have numbers doesn't really make it anything much different from a pin connection table. I wonder how long it will be before we give up on schematics altogether and just write pin lists or net lists? The only real advantage to a schematic from what I have seen is that our minds are pretty good at remembering things like orientation around a dial. So the component box becomes a watch face, if you will, and we can more easily remember that signal foo is in the upper right hand corner than we can remember that it is two thirds down in the pin list. RickArticle: 146536
rickman <gnuarm@gmail.com> wrote >I wonder how long it will be before we give up on schematics >altogether and just write pin lists or net lists? The only real >advantage to a schematic from what I have seen is that our minds are >pretty good at remembering things like orientation around a dial. So >the component box becomes a watch face, if you will, and we can more >easily remember that signal foo is in the upper right hand corner than >we can remember that it is two thirds down in the pin list. IMHO functionality is much more obvious from a schematic. Less so, I admit, if the design is just a load of random digital logic.Article: 146537
On Mar 22, 8:23=A0am, jacko <jackokr...@gmail.com> wrote: > True. Reducing jitter does need a higher clock speed. and a stable > power supply. Yes, without that stable power supply, your lsbs might get lost in the digital noise... what??? RickArticle: 146538
On Mar 22, 10:06=A0am, rickman <gnu...@gmail.com> wrote: > Charles, > > Thanks for the reply. =A0I understand how to change the generic > parameters. =A0The problem is that they aren't used until I stop the > simulation. =A0Using the restart control or even recompiling doesn't > seem to load the new values unless I actually use the "stop > simulation" control. > > I guess I'm used to the GUI understanding things like this and when I > update a generic I expect the tool to do what it takes to have it take > effect. Yeah, that's an Aldec annoyance -- you must stop the current simulation and then initialize it again with the new generics. If you go the do-file or tcl-script route, you must still stop the current simulation before executing your script. -aArticle: 146539
rickman wrote: snip.. > I wonder how long it will be before we give up on schematics > altogether and just write pin lists or net lists? After I'm retired I hope. A well drawn schematic is a thing of beauty, helping techs to troubleshoot and customers to understand a product. You could also ask when mechanical engineers will stop using fab drawings and just send the data as G codes.Article: 146540
On Mar 22, 1:46=A0pm, Jim Stewart <jstew...@jkmicro.com> wrote: > rickman wrote: > > snip.. > > > I wonder how long it will be before we give up on schematics > > altogether and just write pin lists or net lists? > > After I'm retired I hope. =A0A well drawn schematic is a > thing of beauty, helping techs to troubleshoot and > customers to understand a product. > > You could also ask when mechanical engineers will stop > using fab drawings and just send the data as G codes. I guess if you have an analog design with a lot of small components a schematic is good, but for many digital designs there is almost no point. Look inside any number of modern products and you see one, two or three large IC packages with lots of traces between them and few smaller components. The schematics for these products are horrendous, often much less clear than a simple pin list. Its not that they were drawn badly, but that it is impossible to draw a 300+ pin part with much utility. Even by breaking the part into sections it still ends up being a pin list with a box around it. I'll grant that analog designs can gain from schematic, but many of the digital ones are pointless when drawn. RickArticle: 146541
On Mar 19, 6:32=A0am, rickman <gnu...@gmail.com> wrote: > Yes, it was a typo... in other words, a mistake... =A0Why do they call > it a "typo". =A0It was a mistake regardless of how you categorize it. "typographical error," in other words, a mistake made by the typesetter, back in the days when such jobs existed. -aArticle: 146542
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip) > Yes, Mentor bought them some time ago and I believe it is still a > product, but with a different name. Everyone still uses schematics > for board level design, so the tools will always be there. Although > to a large extent, even schematics are really just pin lists. Some time ago, I was wondering about using Verilog for PC board design. One reason was the idea of taking an old circuit design and implementing it on a new PC board, but also the whole thing in an FPGA. If both could be done from the same Verilog, it seemed easier... (I mostly write structural Verilog, that is, continuous assignment, with a minimal amount of behavioral Verilog.) > When I plop an FPGA on the drawing page I am treating it like a pin > connection list tying each pin (with its pin name) to a short net with > its net name. The other end of the connection is almost always on a > different page with the same net name/pin name connection list. The > fact that the pin names are inside a box and have numbers doesn't > really make it anything much different from a pin connection table. And that list could be in the form of Verilog continuous assignment. That seems a little less obvious for power and ground, though. > I wonder how long it will be before we give up on schematics > altogether and just write pin lists or net lists? The only real > advantage to a schematic from what I have seen is that our minds are > pretty good at remembering things like orientation around a dial. So > the component box becomes a watch face, if you will, and we can more > easily remember that signal foo is in the upper right hand corner than > we can remember that it is two thirds down in the pin list. With BGA packaging, though, that doesn't seem so important. It does seem interesting that many have gone away from schematic capture for logic design, but do they still use it for PC design? -- glenArticle: 146543
In comp.arch.fpga Peter <nospam@nospam9876.com> wrote: (snip) > IMHO functionality is much more obvious from a schematic. There are netlist to schematic programs. They never work quite as well as you wish, but sometimes good enough. > Less so, I admit, if the design is just a load of random digital > logic. -- glenArticle: 146544
In comp.arch.fpga Jim Stewart <jstewart@jkmicro.com> wrote: (snip) > After I'm retired I hope. A well drawn schematic is a > thing of beauty, helping techs to troubleshoot and > customers to understand a product. But some things just get too big to do that way. Would you really like to see the schemtic for the Itanium chip? > You could also ask when mechanical engineers will stop > using fab drawings and just send the data as G codes. There is the story about the design of the Boeing 777, all done on computers. When the designers saw the actual airplane, they were surprised by how big it was. They had been looking at it all those years on computer monitors. I suppose in previous designs, that parts would be constructed along the way, looked at by designers, and changed as needed. That may have been done much less in the case of the 777. -- glenArticle: 146545
Integrated Development Environments (IDEs) have long been the primary tool for software engineers. Like an airplane cockpit, an IDE is the control center from which the engineer accesses all of the data and tools that he needs. IDEs, and especially Eclipse, have proven to be extensible, open, high quality platforms. However, until now, IDEs have not been popular in hardware development circles. This is partly because many of the available IDEs for hardware development have not lived up to the potential of IDEs that is typical in the software world. Instead, IDEs tend to be overly complex, closed, and they lock the customer in. Today, though, Eclipse is finally gaining traction among EDA (electronic design automation) and FPGA companies. One such EDA company, Sigasi, has just released the first commercial VHDL plugin for Eclipse. Now, at last, hardware design teams can use Eclipse as a basis for their own customized IDEs, based on the commercial and open- source plugins that they need in their central cockpit for hardware design. I've published a white paper on this subject. http://www.sigasi.com/content/why-hardware-designers-should-switch-eclipse I'd be interested to know what you guys think. kind regards Philippe Faes Founding CEO Sigasi http://www.sigasi.comArticle: 146546
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote >> IMHO functionality is much more obvious from a schematic. > >There are netlist to schematic programs. They never work quite >as well as you wish, but sometimes good enough. There is a prog called VIEWGEN I think (in the package I am selling). I used it to generate a schematic from a state machine done in CUPL. There was no point in going to a schematic as the result made no sense but it was the only way I could see of merging the ex-CUPL state machine block into the rest of the design. Nowadays I guess one would use VHDL or similar and it would integrate into the workflow properly. Towards the end of my era of doing complicated logic designs, a very nice product was from somebody like Altera. It was a FREE VHDL compiler, crippled to work with just a few low end devices e.g. a 22V10. People used this to do VHDL designs for devices totally unconnected with that device vendor, because VHDL compilers were so expensive :)Article: 146547
On Mon, 22 Mar 2010 12:43:04 -0700, Philippe wrote: > Integrated Development Environments (IDEs) have long been the primary > tool for software engineers. Like an airplane cockpit, an IDE is the > control center from which the engineer accesses all of the data and > tools that he needs. IDEs, and especially Eclipse, have proven to be > extensible, open, high quality platforms. > > However, until now, IDEs have not been popular in hardware development > circles. This is partly because many of the available IDEs for hardware > development have not lived up to the potential of IDEs that is typical > in the software world. Instead, IDEs tend to be overly complex, closed, > and they lock the customer in. > > Today, though, Eclipse is finally gaining traction among EDA (electronic > design automation) and FPGA companies. One such EDA company, Sigasi, has > just released the first commercial VHDL plugin for Eclipse. Now, at > last, hardware design teams can use Eclipse as a basis for their own > customized IDEs, based on the commercial and open- source plugins that > they need in their central cockpit for hardware design. > > I've published a white paper on this subject. > http://www.sigasi.com/content/why-hardware-designers-should-switch- eclipse > I'd be interested to know what you guys think. > > kind regards > > Philippe Faes > Founding CEO Sigasi > http://www.sigasi.com Nothing beats EmacsArticle: 146548
d_s_klein <d_s_klein@yahoo.com> writes: > It's part of Altera's 'check for updates'. > > Just install rpm and be done with it; that's what I did. It seems like the real rpm is causing problems when I run sopc_builder: Error: i2c_hdmi: error: cannot open Packages index using db3 - No such file or directory (2) I don't have a single rpm file in my Altera installation nor in my design database, or in my home directory. Is Quartus actually trying to store IP in /var/lib/rpm (which usually requires root access)? This is odd as I never had any problems with Quartus up to 9.0. Petter -- .sig removed by request.Article: 146549
On Mar 22, 4:06=A0pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > Nothing beats Emacs On whole I agree with you, however let's be realistic, the learning curve for Emacs is incredibly steep. For folks who are eyeball-deep in VHDL code 100% of the time, learning Emacs pays off in dividends that continue for years to come. However, not all engineers are in positions where that payback will be as great or continuous. For those, something like Sigasi might work pretty well. I have done a little bit of work with Sigasi in the last week or so. As IDE's go, it's pretty decent. It's far more code centric than most IDE's I've used, and seems well put together. While I suspect I'm faster with Emacs (and as such, some of the refactoring tools Sigasi implements aren't as useful) I've been very interested in how someone new would respond to the environment. It's a lot better than shoving someone into the text editors in any of the vendor tools, and similar products like HDL Designer have the siren call of the schematic capture design which I think leads into bad design practices. Anyhow, Sigasi does seem to be a good tool. I don't know if the price point will make it successful -- another reason emacs is kind of amazing is that it's entirely open source and free, but I wish the developers the best of luck. I daresay it's a hard market to break into. If we get into a position to be purchasing more tool licenses, I'll definitely ask folks to evaluate it. I know I'd feel a lot better about someone using that tool, rather than HDL Designer.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z