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
Any one know good book teaches how to write testbench in VHDL and/or Verilog?Article: 34401
Andy Peters > > Mark wrote: > > > > Hi there! > > > > I'm pretty new at FPGAs, and what I'm trying to do is > > program an MP3 decoder into an FPGA.. > > Does anyone have experience at this? > > Are there VHDL or Handel-C mp3 decoder sources around? > > Or anyone wants to discuss this subject with me? :-)) > > Seems to me that you're better off implementing the decoder in a DSP. Or even better, use a ASSP have a look at www.vlsi.fi their decoder is just 20$ and has an integrated DAC. -- MFG FalkArticle: 34402
MY book Component Design by Example . provides a complete example in VHDL for the application of transaction based TB designs, along with a reusable textio parser for commands defined in files. At my site there is also a SNUG paper (under papers link) that demonstrates the TB concepts along with a verilog example. Ben --------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Component Design by Example ... a Step-by-Step Process Using VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 -------------------------------------------------------------------------- ------------------Article: 34403
Very good description of DRAM modes, access etc. can be found in Micron's datasheets (http://www.micron.com). Jan > Hi All, > > I can read and write data using a fpga and dram but have no information on > how to use the burst mode. > Has anyone got any information that could help me? > > I know that I need to change the mode and then assert the burst command but > do not have any of the mode information. > > Intel used to have a good page but it has since been removed and I never > downloaded the pdf (DOH) > > > Cheers in advance > Dave > > > >Article: 34404
Janick Bergeron's book "Diedricher" <yangpece@yahoo.com> wrote in message news:f418afeb.0108230943.206f0d6d@posting.google.com... > Any one know good book teaches how to write testbench in VHDL and/or Verilog?Article: 34405
"Andy Peters > Hey, Mr. Headhunter: > > 1) Stop posting off-topic ads in this newsgroup -- nowhere in your ad > did you mention the four magic letters "F-P-G-A" > > 2) Stop posting HTML-formatted crap. Figure out how to properly > configure your news-posting software. > > 3) Go away. > Methinks #3 is quite sufficient and basically way too polite.Article: 34406
This is a multi-part message in MIME format. --------------9DA19003B9976025BA3CF1D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------9DA19003B9976025BA3CF1D9 Content-Type: text/plain; charset=us-ascii; name="foo" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="foo" Ignore - testing attach. --------------9DA19003B9976025BA3CF1D9--Article: 34407
Amplify does much more than just better timing estimates based on your floorplan. 1) It makes it very easy to reorganize your logical hierarchy into an appropriate physical hierarchy for optimization. The reorganization can include replication of larger structures like state machines/counters or whole RTL paths. This can make it much easier for Amplify to optimize the logic and timing along the paths. 2) RTL floorplan assignments are done on the names of the RTL components (modules, adders, state machines, rams, logic ...) before they go through the complete optimization and mapping flow. This reduces the complexity of building the floorplan. Another benefit is that the HDL compilers in Amplify are pretty good at preserving names even when changes to the HDL are made, so your floorplans can survive design changes. 3) Timing estimates are better during optimization. 4) The floorplan you enter is optimized concurrently with timing optimization. At a detail level, logic and flip-flops are moved from region to region as part of timing optimizations like replication or restructuring of long paths. This is the reason we call it a physical synthesis tool instead of just an RTL floorplanner and is responsible for a lot of the performance gains. Essentially, your RTL floorplan is just a starting point for the construction of a gate level floorplan. 5) I should also mention the TOPS technology announcement we made at DAC time (June) about mixing of detailed placement and optimization. Ken McElvain, CTO Synplicity Inc. Joey Oravec wrote: > > hamish@cloud.net.au wrote in message news:<ZvNg7.21651$A5.65678@news1.eburwd1.vic.optushome.com.au>... > > Do you see much advantage with Amplify? Do you see it doing anything > > which you couldn't do yourself with Synplify Pro and the Xilinx floorplanner? > > > > I have access to an Amplify license at work and in my brief experience > > with it, it just seems to be a way to enter your floorplan and have > > it appear in an NCF. So I just enter it into the UCF myself, with > > floorplanner or by hand. > > > > I'd like to be proven wrong though. What does the tool itself actually > > do with the floorplanning information? What optimisations can > > it make at synthesis time given the floorplan? > > Well, amplify feels superior to synplify pro in synthesis. It's kind > of comparing apples to oranges between versions of the software > because I used synpro 7.0b2 and amplify 2.2.4. For me, Amplify's > timing report was far more conservative which was great. Some designs > failed by just a 4-5 ns during PAR (level2) with SynPro that succeeded > under the same conditions with Amplify. Could have just been > dumb-luck, but synthesis time I had those more accurate timing > predictions with Amplify. > > As for floorplanning effect on synthesis, I have no idea offhand. You > make a good point that everything could probably be done by hand or > with the floorplanner tool. This tool's strength lies more in its ease > of use. In about an hour using the Amplify floorplanner with little > knowledge of the RTL, I lowered cycle time from 47ns to 37ns post-PAR > meeting the 25mhz constraint with under an hours work. The paths were > 25% logic 75% route. > > There's not a lot of choice for improving a design besides modifying > the RTL code and improving placement/routing. Since modifying the RTL > is a non-option in an ASIC prototype, Amplify was really the only > route for improvement. > > I was very skeptical of the tool, especially because the thought of > rearranging a million gates on a large Virtex is absurd. However it > really was pretty easy working with the RTL structures instead of > gates. My design had a lot of block repetition and wide structures, so > that really helps. Your mileage may vary. > > -joey --Article: 34408
There is nothing wrong with gating clocks if you have the timing analysis tools to check/optimize for them in all points in your tool flow. If you don't, then you are taking a big risk. Gating of clocks is very important in power reduction for ASICs. Falk Brunner wrote: > > Tim schrieb: > > > > Gated clocks in ASICs, less common in FPGAs > > AHHHHH, there it is again, the ugly word. > > GATED CLOCKS!!! > > Jehova, Jehova, Jehova. ;-)) > > Can someone tell, how common they truely are? Are there special tecnics > that simpifies verification of gated clocks? > > -- > MFG > Falk -- Ken McElvain, CTO Synplicity Inc. (408)215-6060Article: 34409
This is a multi-part message in MIME format. --------------F211BF12E2A1203EA81F14C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------F211BF12E2A1203EA81F14C0 Content-Type: text/plain; charset=us-ascii; name="syn-map.error" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syn-map.error" I'm getting some warnings from MAP that I think are being caused by a bum synthesis [Synplify] but I'm not sure, it might be a MAP problem. The warning message is: WARNING:Pack:249 - The following adjacent carry multiplexers occupy different slice components. The resulting carry chain will have suboptimal timing. cpu/data/cpubuff/un1_fifo_level_1_cry_0 cpu/data/cpubuff/un1_fifo_level_1_cry_1_0 Looking into the code I can see this relates to this fragment [from the post-synth .vm file]. I can't see anything wrong but (i) I'm probably missing something, (ii) it maybe a more global problem of resource conflicts elsewhere. All the other instances of this problem occur in the same place i.e. at the beginning of a sort-of up/down counter. // @6:112 LUT4_007F N_1551_i_Z ( .I0(fifo_level_0[0]), .I1(fifo_almost_empty78), .I2(o1), .I3(G_50), .O(N_1551_i) ); ... // @6:112 LUT3_78 un1_fifo_level_1_axb_1_Z ( .I0(fifo_almost_empty78), .I1(o1), .I2(fifo_level_0[1]), .O(un1_fifo_level_1_axb_1) ); // @6:112 LUT3_78 un1_fifo_level_1_axb_2_Z ( .I0(fifo_almost_empty78), .I1(o1), .I2(fifo_level_0[2]), .O(un1_fifo_level_1_axb_2) ); // @6:112 LUT3_6A un1_fifo_level_1_axb_3_Z ( .I0(fifo_level_0[3]), .I1(o1), .I2(fifo_almost_empty78), .O(un1_fifo_level_1_axb_3) // @14:55 MUXCY_L un1_fifo_level_1_cry_0_Z ( .DI(fifo_level_0[0]), .CI(GND), .S(N_1551_i), .LO(un1_fifo_level_1_cry_0) ); // @14:55 MULT_AND un1_fifo_level_1_cry_1_Z ( .I0(fifo_almost_empty78), .I1(o1), .LO(un1_fifo_level_1_cry_1_0) ); // @14:55 MUXCY_L un1_fifo_level_1_cry_1_0_Z ( .DI(un1_fifo_level_1_cry_1_0), .CI(un1_fifo_level_1_cry_0), .S(un1_fifo_level_1_axb_1), .LO(un1_fifo_level_1_cry_1) ); // @14:55 MULT_AND un1_fifo_level_1_cry_2_Z ( .I0(fifo_almost_empty78), .I1(o1), .LO(un1_fifo_level_1_cry_2_0) ); // @14:55 XORCY un1_fifo_level_1_s_1 ( .LI(un1_fifo_level_1_axb_1), .CI(un1_fifo_level_1_cry_0), .O(un1_fifo_level_1_s_1_0) ); // @14:55 XORCY un1_fifo_level_1_s_2 ( .LI(un1_fifo_level_1_axb_2), .CI(un1_fifo_level_1_cry_1), .O(un1_fifo_level_1_s_2_0) ); // @14:55 XORCY un1_fifo_level_1_s_3 ( .LI(un1_fifo_level_1_axb_3), .CI(un1_fifo_level_1_cry_2), .O(un1_fifo_level_1_s_3_0) ); --------------F211BF12E2A1203EA81F14C0--Article: 34410
In article <9m1vnt$e6d$1@slb7.atl.mindspring.net>, austin@87darkroom.com says... > I'd suggest before telling people that they are "missing the point", you > might want to take a look at exactly what "point" prople were answering. Austin, good "point". Very sorry. In fairness the post I replied to was recommendations including how to design the state machines when "The goal is to prototype an ASIC in an FPGA." was part of the quoted text. Anyway, I should have noticed that that info was not in the original post. -- Rich Iachetta iachetta@us.ibm.com I do not speak for IBM.Article: 34411
Speedy Zero Two wrote: > Hi All, > > I can read and write data using a fpga and dram but have no information on > how to use the burst mode. > Has anyone got any information that could help me? > > I know that I need to change the mode and then assert the burst command but > do not have any of the mode information. > I find its a lot easier (?) to set the mode register once at the beginning of time and then to truncate bursts shorter than the mode register setting using some combination of the byte masks (DQMB) and early pre-charge. Which one depends on whether or not you are using auto-precharge bursts. Another thing to watch out for is the burst order in a system where you might have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even here its possible to set sub-block and arrange that other bursts are always a power of 2 and start at offset 0 modulo their size.Article: 34412
> It's not hidden, Ben, it's just in a different form. The way you know it's > the same is twofold: first, you have a testbench you can run on the > synthesized result, which should produce the same results as your original > code. Second, you have formal verification tools, that can compare the > synthesizer output (gate level verilog, in the case I'm familiar with) with > your original VHDL or verilog code. Since I use free tools I don't have access to the fancy tools. Secondly I use paper and pencil most of my small design work. Since I use schematics, the old eyeball and a logic probe for testing none of the above will work for me. None the less I need to know what logic I enter for FPGA does generate correct and efficient nets for the FPGA. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.Article: 34413
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3B856F0F.71DE9A7B@algor.co.uk... > > > Speedy Zero Two wrote: > > > Hi All, > > > > I can read and write data using a fpga and dram but have no information on > > how to use the burst mode. > > Has anyone got any information that could help me? > > > > I know that I need to change the mode and then assert the burst command but > > do not have any of the mode information. > > > > I find its a lot easier (?) to set the mode register once at the beginning of > time and then to truncate bursts shorter than the mode register setting using > some combination of the byte masks (DQMB) and early pre-charge. Which one > depends on whether or not you are using auto-precharge bursts. > > Another thing to watch out for is the burst order in a system where you might > have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even here > its possible to set sub-block and arrange that other bursts are always a power > of 2 and start at offset 0 modulo their size. > So how do I set the mode to "say4 or 8" ? DaveArticle: 34414
"Andy Peters > > Ben Franchuk wrote: > > > > > It's not hidden, Ben, it's just in a different form. The way you know it's > > > the same is twofold: first, you have a testbench you can run on the > > > synthesized result, which should produce the same results as your original > > > code. Second, you have formal verification tools, that can compare the > > > synthesizer output (gate level verilog, in the case I'm familiar with) with > > > your original VHDL or verilog code. > > > > Since I use free tools I don't have access to the fancy tools. > > Further proof of the old adage, "you get what you pay for." That must mean all the tools are JUNK. You don't buy the tools you RENT them! Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.Article: 34415
Speedy Zero Two wrote: > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > news:3B856F0F.71DE9A7B@algor.co.uk... > > > > > > Speedy Zero Two wrote: > > > > > Hi All, > > > > > > I can read and write data using a fpga and dram but have no information > on > > > how to use the burst mode. > > > Has anyone got any information that could help me? > > > > > > I know that I need to change the mode and then assert the burst command > but > > > do not have any of the mode information. > > > > > > > I find its a lot easier (?) to set the mode register once at the beginning > of > > time and then to truncate bursts shorter than the mode register setting > using > > some combination of the byte masks (DQMB) and early pre-charge. Which one > > depends on whether or not you are using auto-precharge bursts. > > > > Another thing to watch out for is the burst order in a system where you > might > > have a CPU using sub-block and some DMA (e.g. PCI) that needs linear. Even > here > > its possible to set sub-block and arrange that other bursts are always a > power > > of 2 and start at offset 0 modulo their size. > > > > So how do I set the mode to "say4 or 8" ? > > Dave I could describe this & all the others but I think the advice to download a Micron SDRAM data sheet is correct. They are well written & their web site has a very good DRAM FAQ section. The other source is the Intel site. Search for PC100 or PC133 and then grovel through all the screeds of stuff about motherboards & chip sets.Article: 34416
Every time this happens I have been sending a standard complaint email to the perpetrator. This seems to have worked most times. I would recomend that others also send private email to the headhunters. Sending it to the group really serves no purpose. By the way Andy, did we really need for you to include his whole post ? :-) Philip Freidin On Thu, 23 Aug 2001 17:25:34 GMT, "Andy Peters <andy [@] exponentmedia" <".> com"> wrote: >Hey, Mr. Headhunter: > >1) Stop posting off-topic ads in this newsgroup -- nowhere in your ad >did you mention the four magic letters "F-P-G-A" > >2) Stop posting HTML-formatted crap. Figure out how to properly >configure your news-posting software. > >3) Go away. > Philip Freidin FliptronicsArticle: 34417
This is one I think I've done before, so I probably just need my memory jogged. I'm sure it's something that happens, and that you need, all the time. I've defined a hard macro, call it custommacro.nmc. This macro will have internal routes and external macro pins (not the pins/I/O pads of the device, the logical pins of the macro). Now, at least one of the nets connects to an external pin and an internal route. One common example, for instance, is CLK. You want the signal to be common to the internal CLB's of the macro and to connect to external routes (in the case of CLK, to the global clock net). Now, within the macro I define a proper external pin for the clock net, attaching it to one of the CLK pins for a slice. Then I instantiate the macro in the design within FPGA editor. So now I go to route a net, for instance the global clock net, to the appropriate external pin on the macro, thus connecting the external signal to the internal macro net. What I do is highlight the macro pin I want, and all segments of the external net I want to route. Then I click the route button. No success. FPGA Editor complains "WARNING:FPGAEditor: 145 - Cannot add to net "Macro1CLK" -- it is an internal macro net." What am I doing wrong? Is it an error in how I've defined the external pins in the macro? Using the wrong procedure to route the external nets? Or something else? This situation must surely be pretty common (clock signals, in particular, are almost always going to have to be common to internal routes in a macro and external routes) so I think I'm missing something. As I say, I think I've solved this problem before. But in any event, can someone give me the basic idea of what to do? Thanks. Alex Rast arast@inficom.com arast@qwest.netArticle: 34418
On Thu, 23 Aug 2001 15:01:22 GMT, "Dave Feustel" <dfeustel1@home.com> wrote: Dave, please don't spam us again, or I'll tell the story of how Maxim screwed a lot of people with the MAX9690. JohnArticle: 34419
For testbenches, is there a method to read in a text file in Verilog? The $fdisplay function is great for writing to files, but the functions for reading in files are limited; the only method I know of to read in a file is to dump it into a register using the $readmemh command. However, that only works with files formatted in ascii-hex, e.g. "41 42 43", not files formatted in text, e.g. "ABC". I wrote a Perl script to convert text files to ascii-hex but that seems a lame workaround. -KevinArticle: 34420
> I'd rather have a version > I can compile with Visual Studio 6 (either as a project or with a make > file) and run Icarus natively on Windows than use Cygwin Icarus Verilog 0.5 runs natively under Windows, complete with a working installer. It is a mingw port rather then a Cygwin port. (Cygwin compiled binaries are just too much of a pain to work with, as you seem to know.) Compiling Icarus Verilog from source still requires a Cygwin installation, but that is only for the tools other then the compiler -- gperf, make, bison, flex, and a shell to run the configure script. There is a text file in the source tarball that explains the mingw build process that works. And 0.5 also supports some minimal synthesis for 4000 series Xilinx parts. I have a new xnf code generator in the works that will support Virtex series as well. -- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com But I have promises to keep, steve@picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 34422
Austin Lesea wrote: > John, > > Make, model number, and where to buy the IR temp sensor? > > I get sooo many questions, and it would be worth its weight in gold to publicize this > info! You can buy an Extech infrared thermometer from Techni-tool for $99.00. Measures 0 - 600 degrees F with a 6:1 field view. > > > Austin > > John Larkin wrote: > > > On Mon, 20 Aug 2001 19:10:26 +0100, Rick Filipkiewicz > > <rick@algor.co.uk> wrote: > > > > >Peter, > > > > > >On top of all the other useful stuff you contribute to CAF you have just answered a > > >long-standing (or burning ?) question of mine regarding the calibration of heat > > >sensing fingertips. > > > > Peter, > > > > my right forefinger is calibrated as follows: > > > > 50C - ok for infinite duration contact > > > > 52C - 10 seconds to pullaway > > > > 60C - 1 second to pullaway > > > > Interpolate linearly between points. Your digits may vary. > > > > We just got a cheap ($79) infrared temp sensor, which is cool (no pun, > > really) for scanning FPGAs on a board. > > > > John > > > > > > > >To go further and get another data point: Last summer I was wondering why our new > > >board wasn't doing anything from power-on. I, very briefly, put my finger on it & > > >came away with a large & painful blister that was still very sore 2 days later. > > > > > >Cause = BGA chip pinout mirrored (not by me I hasten to add). > > > > > >What temp do you think the package would have reached ? -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 34423
> Amplify does much more than just better timing estimates based on your floorplan. > > 1) It makes it very easy to reorganize your logical hierarchy into > an appropriate physical hierarchy for optimization. The reorganization > can include replication of larger structures like state machines/counters > or whole RTL paths. This can make it much easier for Amplify to optimize > the logic and timing along the paths. > > 2) RTL floorplan assignments are done on the names of the RTL components > (modules, adders, state machines, rams, logic ...) before they go through the complete > optimization and mapping flow. This reduces the complexity of building the > floorplan. Another benefit is that the HDL compilers in Amplify are pretty > good at preserving names even when changes to the HDL are made, so your > floorplans can survive design changes. > > 3) Timing estimates are better during optimization. > > 4) The floorplan you enter is optimized concurrently with timing optimization. > At a detail level, logic and flip-flops are moved from region to region as > part of timing optimizations like replication or restructuring of long paths. > This is the reason we call it a physical synthesis tool instead of just an > RTL floorplanner and is responsible for a lot of the performance gains. > Essentially, your RTL floorplan is just a starting point for the construction > of a gate level floorplan. You know, all this fancy (and expensive) "stuff" that you have to do to get synthesized code to work "fast" is absolutely no effort to do with the design correctly done using schematics as the entry methodology. Sigh.Article: 34424
Why is this spam? What's the story with the Max9690? "John Larkin" <jjlarkin@highlandSNIP_THIStechnology.com> wrote in message news:YqCFO=k8XHLXXAnBopne+EW6S45p@4ax.com... > On Thu, 23 Aug 2001 15:01:22 GMT, "Dave Feustel" <dfeustel1@home.com> > wrote: > > > Dave, > > please don't spam us again, or I'll tell the story of how Maxim > screwed a lot of people with the MAX9690. > > John > > >
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