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, >We are currently doing a project which requires implementation of >around >25K gate-logic and 2K-byte RAM. There should be no problem fitting the design onto a FPGA ( Xilinx or Altera ). >We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software. >But, looks like the XACT5.2.1 has support only upto XC4025E with 25K >gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can >somebody >recommend how much would be fetch factor when we put the logic >into the Xilinx CLBs? To my knowledge a CLB can implement 16 bits of synchronous dual port RAM and 32 bits of regular synchronous RAM. I would have to check the datasheets to confirm this. My information is based on the M1.4 flow. One restriction is that the RAM cannot be deeper than 256 ( 8 x 256 =2K), larger RAMs can, however, be easily made by smaller RAM blocks and some simple glue logic. >So, we need to split the logic into two FPGAs which we don't want to do >now. There will be no problem finding a FPGA to fit this design if the design environment is 3.3 V or less. >Also, one more disadv of XACT5.2.1 is no support for back-annotation if >we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler. >After synthesis, is there any way to do a pre-layout functional >simualtion to make sure the design netlist is Ok? My personal opinion is that in FPGA design backannotation is not vital in the design flow. My reasons are: - Using synchronous design methodologies simulation and synthesized result should match very well. - Static timing analysis is a good way to ensure that the timing requirements are met. - Bugs in prototype designs aren't costly to fix. Finding bugs is, of coarse , harder in protos than on a simulator. But probing internal signals via unused pins helps a great deal. - Backannotation is just an estimate and does not guarantee anything. - Backannotation wastes precious time on a model when the same time can be spend in the lab with the actual product. - Simulation is slow. - The actual software can be tested on the hardware. Note: Performing backannotation on a FPGA is not a bad thing. I am just stating that it is not absolutely necessary as in ASIC design. >Also, can somebody recommend if there are any Altera devices which can >do this efficiently >than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM... > >We can buy Xilinx new software M1.3 which has support for larger FPGAs >and VITAL-support >for backannotation, but is any Altera-approach going to be cheaper? Selecting an FPGA is a complicated process. There are so many factors to consider. You might have to buy some new software but the cost can easily be covered if the FPGA used is cheaper. Other factors that must be taken into consideration, a few follow. What is the production volume? Will future product updates demand spare FPGA capacity? What type of support the FPGA manufacturer provide? ********************************************************** * * * Umesh Gowda +358 9 4131 2458 (Direct) * * ASIC Dvelopment +358 40 503 7028 (Mobile) * * Tellabs Oy +358 9 4131 2200 (Fax) * * FIN-02630 Espoo http://www.tellabs.fi * * Finland http://www.hut.fi/~ugowda * * * * Umesh.Gowda@replace_with_tellabs.fi OR * * ugowda@cc.replace_with_hut.fi * * * **********************************************************Article: 9176
Hi, >We are currently doing a project which requires implementation of >around >25K gate-logic and 2K-byte RAM. There should be no problem fitting the design onto a FPGA ( Xilinx or Altera ). >We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software. >But, looks like the XACT5.2.1 has support only upto XC4025E with 25K >gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can >somebody >recommend how much would be fetch factor when we put the logic >into the Xilinx CLBs? To my knowledge a CLB can implement 16 bits of synchronous dual port RAM and 32 bits of regular synchronous RAM. I would have to check the datasheets to confirm this. My information is based on the M1.4 flow. One restriction is that the RAM cannot be deeper than 256 ( 8 x 256 =2K), larger RAMs can, however, be easily made by smaller RAM blocks and some simple glue logic. >So, we need to split the logic into two FPGAs which we don't want to do >now. There will be no problem finding a FPGA to fit this design if the design environment is 3.3 V or less. >Also, one more disadv of XACT5.2.1 is no support for back-annotation if >we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler. >After synthesis, is there any way to do a pre-layout functional >simualtion to make sure the design netlist is Ok? My personal opinion is that in FPGA design backannotation is not vital in the design flow. My reasons are: - Using synchronous design methodologies simulation and synthesized result should match very well. - Static timing analysis is a good way to ensure that the timing requirements are met. - Bugs in prototype designs aren't costly to fix. Finding bugs is, of coarse , harder in protos than on a simulator. But probing internal signals via unused pins helps a great deal. - Backannotation is just an estimate and does not guarantee anything. - Backannotation wastes precious time on a model when the same time can be spend in the lab with the actual product. - Simulation is slow. - The actual software can be tested on the hardware. Note: Performing backannotation on a FPGA is not a bad thing. I am just stating that it is not absolutely necessary as in ASIC design. >Also, can somebody recommend if there are any Altera devices which can >do this efficiently >than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM... > >We can buy Xilinx new software M1.3 which has support for larger FPGAs >and VITAL-support >for backannotation, but is any Altera-approach going to be cheaper? Selecting an FPGA is a complicated process. There are so many factors to consider. You might have to buy some new software but the cost can easily be covered if the FPGA used is cheaper. Other factors that must be taken into consideration, a few follow. What is the production volume? Will future product updates demand spare FPGA capacity? What type of support the FPGA manufacturer provide? ********************************************************** * * * Umesh Gowda +358 9 4131 2458 (Direct) * * ASIC Dvelopment +358 40 503 7028 (Mobile) * * Tellabs Oy +358 9 4131 2200 (Fax) * * FIN-02630 Espoo http://www.tellabs.fi * * Finland http://www.hut.fi/~ugowda * * * * Umesh.Gowda@replace_with_tellabs.fi OR * * ugowda@cc.replace_with_hut.fi * * * **********************************************************Article: 9177
Hello Ray, Correlation is not like FIR. You must normalize! It is possible but might be tricky. Regards, Moti Ray Andraka wrote: > > Erik Kobal wrote: > > > > We are looking to implement signal arrival time detection using the > > correlation method. Our design involves a steady stream of 8-bit > > samples at a sampling rate of 20 Msps. Our pattern that we are > > attempting to match is 40 samples wide. Now the problem we have arrived > > at is the following: we need to perform a 40x8 bit matrix > > multiplication. This is only the root of our design problem, since our > > application is multichannel. We are not sure whether our design would > > work best using a standard DSP, or whether we should use an FPGA to > > allow for multiplication in parallel. Any information would be much > > appreciated. > > > > Thank you, > > > > Erik Kobal, Cleveland State University > > Assuming your reference is relatively constant, correlation is the same > arithmatic operation as FIR filtering with the order of the coefficients > reversed. That said, FIR filtering using FPGAs is well documented in > app notes from many of the FPGA vendors. The method described in the > Xilinx and Altera notes uses a distributed arithmetic technique that > essentially breaks the multiplications into partial products, thereby > avoiding the need for multipliers. > > The 20 MSPS rate at 40 taps is easy to do using distributed arithmetic > in an FPGA. Off the top of my head, I think each filter will occupy > somewhere about 100 Xilinx CLBs to get this data rate. A single DSP > won't even get close to 20MSps at 40 taps. > > Xilinx also describes a symbol correlator in their literature, but that > is not what you are looking for. That design correlates a bit stream to > find occurrences of a reference pattern. > > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka > > Andraka Consulting Group, Inc is a digital hardware design firm > specializing in high performance FPGA designs for digital signal > processing, computing and control applications.Article: 9178
Peter, has *anyone* ever done a public-domain DPLL design like the one in the Zilog 85c30? Sorry if a bit off-topic. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 9179
>My personal opinion is that in FPGA design backannotation is not vital in >the design >flow. I would agree. Just make sure that the longest delay in your design is less than the clock period. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 9180
I just wondered if there are any hidden gotchas there. It seems to work, using the libraries from the pro-view stuff which is on the Xact6 CDROM. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 9181
The APS FPGA VHDL newsletter for Q1 98 will be released in MARCH. The newsletter features EDA products and features as well as giving FPGA and VHDL tips and hints. Past copies of the newsletter can be viewed from our website at: http://www.associatedpro.com/aps To subscribe to the newsletter simply email us as at: subscribe@associatedpro.com Please but the word SUBSCRIBE in the subject header. -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9182
In recent months there have been many successes for the Linux operating system: * InfoWorld's OS of the year for the second year (for the RedHat 5.0 distribution of Linux). see: http://www.infoworld.com/cgi-bin/displayTC.pl?/97poy.win3.htm#linux * InfoWorld's award for technical support was not given to a company, but in an unprecedented move it was awarded to the Linux user community (better than any commercial company's 800 or 900 help line - just try getting tech support from Micro$oft sometime). see: http://www.infoworld.com/cgi-bin/displayTC.pl?97poy.supp.htm * A cluster (or render farm) of 160 DEC Alpha based PCs running Linux was used to render the scenes for the movie Titanic. * Similar clusters of Linux running on PCs have been set up at NASA ( http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html ), Fermilab ( http://www.fnal.gov ), Oregon State Univ( http://www.CS.ORST.EDU/swarm/ ) and others. Also see the following article from The Chronicle of Higher Education: http://chronicle.com/data/internet.dir/itdata/1998/02/t98022601.htm * The decision by Netscape to release the source code for Communicator 5.0 has brought a lot of attention to Linux as well. See: http://www.mozilla.org/ So far, though, the EDA market has been a tough one for Linux to move into. It seems that the engineers (the users of EDA apps ) are quite willing to use Linux, but the EDA companies want to push NT. The case for EDA applications on Linux is compelling: 1) For many EDA companies whose apps started out on Unix it is quite easy to port them to Linux (in fact I've heard rumors that some EDA companies actually build their software internally on Linux boxes). Porting Unix apps to NT can be difficult. 2) The move to NT has been fueled by the lower prices of PC hardware and the fact that PC hardware has gotten very close to workstation performance. Given that Linux runs on the same PC hardware as NT, the same motivations exist while at the same time maintaining the Unix environment that many engineers prefer. 3) Given the price motivation from #2, note that Linux is available at no (or very low) cost when compared to NT (~$200). Also note that in order to get NT to work in an NFS network you typically need to spend another $300 per node. 4) Stability. Linux typically has uptimes measured in months while NT crashes about twice a week (in my experience, and in the experience of others I've talked to). 5) Performance. When NT is doing any kind of disk access it seems to be very unresponsive. In last week's EETimes (Desktop EDA column) another compelling reason was given: Using 'farms' (or clusters, see the links above) to speed simulation. SpeedSim is reporting some high profile customers are using this approach. As the article says this could be the killer EDA app for Linux. It is difficult to set up such clusters using NT and it is very expensive to do it using traditional workstations. Linux excells in this area - which is why NASA and others are setting up such clusters as a low cost alternative to supercomputers. Some point to the Exemplar experiment with Linux last year as evidence that there is no demand for EDA tools on Linux. I suspect that this is the wrong conclusion based on the following: 1) I believe that when a customer bought Leonardo, they got a CDROM that contained binaries for all platforms that Leonardo runs on. How did they track what platform was really installed? The license manager apparently did not track what platform requested licenses, so there are no statistics. 2) The tool chain was incomplete. Since Leonardo is a synthesis tool, you still needed to have a simulator. At the time there were no VHDL simulators for Linux. Perhaps Exemplar could have persuaded Model Technologies (since they were both owned by Mentor at the time) to release V-System for Linux at the same time as Exemplar released Leonardo for Linux. As it was, users had to simulate on one platform and synthesize on another if they were to use Leonardo on Linux. Now there are some simulators out there from VeriWell and GreenMountain, though neither is as high-profile as V-System. The conclusion is that the Exemplar experiment was inconclusive. Linux could still be a very successful EDA platform. Perhaps the companies that are building Linux clusters for simulation will demand that other parts of the tool chain be made available on Linux as well. jdArticle: 9183
I'm looking for a VHDL or Verilog core to do a simple DMA controller in an FPGA. I'm not looking for anything real fancy. I need to put 32 channel's worth of DMA into an FPGA and I want it to be cost effective. Some variation of an 8237 or a MC68450 ?? would be fine. If anyone can suggest sources for this, I'd appreciate it. Thanks, GaryArticle: 9184
Hi, In addition, a Correlation typically is used with a variable sequence in place of the fixed FIR coefficients. The FPGA design utilizes a lookup table to impliment the multiplier by a fixed coefficient. This would not be easily programable for a variable Correlation pattern. To impliment a multiplier of two variables requires a very large amount of resources in an FPGA. If on the other hand, you only have a small number of Correlation patterns you need to use, then you can use a separate download for each pattern. Rick Collins re:DSP redsp@writeme.com Moti Barkan wrote: > Hello Ray, > > Correlation is not like FIR. You must normalize! > > It is possible but might be tricky. > > Regards, > Moti > > Ray Andraka wrote: > > > > Erik Kobal wrote: > > > > > > We are looking to implement signal arrival time detection using the > > > correlation method. Our design involves a steady stream of 8-bit > > > samples at a sampling rate of 20 Msps. Our pattern that we are > > > attempting to match is 40 samples wide. Now the problem we have arrived > > > at is the following: we need to perform a 40x8 bit matrix > > > multiplication. This is only the root of our design problem, since our > > > application is multichannel. We are not sure whether our design would > > > work best using a standard DSP, or whether we should use an FPGA to > > > allow for multiplication in parallel. Any information would be much > > > appreciated. > > > > > > Thank you, > > > > > > Erik Kobal, Cleveland State University > > > > Assuming your reference is relatively constant, correlation is the same > > arithmatic operation as FIR filtering with the order of the coefficients > > reversed. That said, FIR filtering using FPGAs is well documented in > > app notes from many of the FPGA vendors. The method described in the > > Xilinx and Altera notes uses a distributed arithmetic technique that > > essentially breaks the multiplications into partial products, thereby > > avoiding the need for multipliers. > > > > The 20 MSPS rate at 40 taps is easy to do using distributed arithmetic > > in an FPGA. Off the top of my head, I think each filter will occupy > > somewhere about 100 Xilinx CLBs to get this data rate. A single DSP > > won't even get close to 20MSps at 40 taps. > > > > Xilinx also describes a symbol correlator in their literature, but that > > is not what you are looking for. That design correlates a bit stream to > > find occurrences of a reference pattern. > > > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > Andraka Consulting Group, Inc is a digital hardware design firm > > specializing in high performance FPGA designs for digital signal > > processing, computing and control applications.Article: 9185
Hi
I am an undergraduate electrical engineering student
I like to do a project that is related to DSP systems and to implement
it on a single FPGA by using the VHDL language.
please do you have any Idea about such a project that can be built
within 3 mounthes ( single term ) ?
Please help I want to learn more about these feilds because I think
that they are the future of the electronics design
thanks in advance
please send your comments to my email at
jamil.khatib@pemail.net
\\\|///
\\ ~ ~ //
( =@=@= )
+------------oOOo---(_)---oOOo-------------+
| |
|e-mail: jik@planet.edu |
|www.planet.edu/~jik/JamilHomepage.html |
|www.geocities.com/SiliconValley/Pines/6639|
| |
| .oooO Oooo. |
| ( ) ( ) |
+---------------\ (-----) /----------------+
\_) (_/
Article: 9186
Umesh,
Concerning your remarks about simulation of backannotated
FPGA designs, I agree with you for the most part. However,
backannotation usually provides worst case timing into the
simulation. Therefore, if it works in the simulator, it should
work in the lab. I have found instances where a particular
design may meet timing on one FPGA and not on another. These,
of course, would be pushing the limits, but it has happened.
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9187
Jay,
I completely agree with you. For a short while there, I was
using Leonardo (Exemplar's tool) on a Linux box. However, I switched
away for two reasons. 1. They unsupported Linux in the next
version released. 2. I used Leonardo to generate EDIF for Xilinx
FPGAs. Xilinx does not support Linux. I refuse to move to
NT however, and have been doing all my VHDL compilations under
Solaris (on a Sun ULTRA). In fact, I don't even use the GUIs
of either product. I write VHDL and use 'make' to compile it
to the destination Xilinx BITfile.
I think most engineers would find that UNIX tools are easier
and more fluid to use. Not to mention more stable and often
faster than their NT counterparts. At this point, the only
reason I use Windows NT is because my board layout software
(MicroSim Schematics/PCBoards) is Windows only. I am
contemplating moving away from that software as well, in
favor of something that supports UNIX.
Perhaps more good press supporting Linux would help.
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9188
J. Khatib wrote:
>
> Hi
>
> I am an undergraduate electrical engineering student
>
> I like to do a project that is related to DSP systems and to implement
> it on a single FPGA by using the VHDL language.
>
> please do you have any Idea about such a project that can be built
> within 3 mounthes ( single term ) ?
>
> Please help I want to learn more about these feilds because I think
> that they are the future of the electronics design
>
> thanks in advance
>
> please send your comments to my email at
> jamil.khatib@pemail.net
>
> \\\|///
> \\ ~ ~ //
> ( =@=@= )
> +------------oOOo---(_)---oOOo-------------+
> | |
> |e-mail: jik@planet.edu |
> |www.planet.edu/~jik/JamilHomepage.html |
> |www.geocities.com/SiliconValley/Pines/6639|
> | |
> | .oooO Oooo. |
> | ( ) ( ) |
> +---------------\ (-----) /----------------+
> \_) (_/
For a start, check out http://www.associatedpro.com/aps
-- JYA
Remove "X" from the address to reply.
** Be advised: my email address will be changing. **
You can always use jya@juno.com, but not for attachments.
Engineering is the art of making what you want
from things you can get.
Article: 9189In article <6d6u7l$hkc$1@ankka.csc.fi>, "Umesh Gowda" <ugowda@cc.hut.fi> wrote: In the interest of adding information, my personal experience differs in this regard. I recommend backannotation and analyzing the backannotation for timing problems early in the design. Especially, when timing requirements come into play. But, I guess that depends upon how much you are trying to get out of the part. And, perhaps, the software tools at your disposal. >Hi, > >My personal opinion is that in FPGA design backannotation is not vital in >the design flow. My reasons are: >- Using synchronous design methodologies simulation and synthesized result >should match very well. >- Static timing analysis is a good way to ensure that the timing >requirements are met. In my experience static timing is optimistic. Route delays are not include. In my case I was getting estimates which were off by a factor of 2. >- Bugs in prototype designs aren't costly to fix. Finding bugs is, of coarse >, harder in protos > than on a simulator. But probing internal signals via unused pins helps a >great deal. This is certainly doable and time consuming unless you have lots of extra pins. Also, you have to recompile anytime you wish to reassign any of the test pins. >- Backannotation is just an estimate and does not guarantee anything. It's a pessimistic estimate. >- Backannotation wastes precious time on a model when the same time can be > spend in the lab with the actual product. This may depend upon how transparent your design is. >- Simulation is slow. >- The actual software can be tested on the hardware. In the early stages of design, I would expect that your simulation will lead the software. At some point in the project, software may break the FPGA in ways that were not simulated or completely modeled. If I could not reproduce the failure on the simulator, I knew I was in for a long debug cycle. Either to improve the simulator or to get visibility into the significant net or function in the FPGA. > >Note: Performing backannotation on a FPGA is not a bad thing. I am just >stating that it is >not absolutely necessary as in ASIC design. > I believe that you "need" backannotation as soon as you start making changes to improve performance rather than functionality.Article: 9190
umesh: : >My personal opinion is that in FPGA design backannotation is not vital in : >the design flow. My reasons are: : >- Using synchronous design methodologies simulation and synthesized result : >should match very well. : >- Static timing analysis is a good way to ensure that the timing : >requirements are met. daniel: : In my experience static timing is optimistic. Route delays are not : include. In my case I was getting estimates which were off by a factor : of 2. rk: i have had good luck with static timing analyzers. your estimates off by a factor of two does sound like a real problem. with the tools that i'm using, the static timing analyzer can be used in a predictive mode or a post-layout mode with extracted parameters. and route delays are most definitely included. as for back annotating, we had a discussion here (at least it started out as a discussion ;) a while back about the back annotation of delays and the fidelity of the logic simulation with respect to clock skew. i've been called in to troubleshoot a number of failed fpgas that passed dynamic simulations; these simulators all modelled the clock nets as having no skew, not the case in real devices at all. and the static timing analyzer i used, provided with the p&r tools, did do the modelling correctly. another factor is the time investment in analysis and the quality of it. with a dynamic timing analyzer, you must create stimulus to exercise the worst-case path. creating the stimulus is time consuming and running it, particularly for long sequences, takes a while, unless you go in and either add extra circuitry or do forces. the extra stuff is, well, extra stuff. and adding the forces is a royal pain - and is made clumsier with the move to more vhdl where you don't get to see all of the net names easily. also, if you provide your own deratings, you need to modify the parts libraries - a very expensive and time consuming procedure. umesh: : >- Bugs in prototype designs aren't costly to fix. Finding bugs is, of coarse, : > harder in protos than on a simulator. But probing internal signals via unused : > pins helps a great deal. daniel: : This is certainly doable and time consuming unless you have lots of extra : pins. Also, you have to recompile anytime you wish to reassign any of the : test pins. rk: not necessarily true. with the actel devices, for example, you can, while the chip is running, simply dial in your net name and the internal signals come out. no muss, no fuss. iirc from a conversation with our #1 orca guy, they're able to shoot wires out to pins from specified nodes without having to recompile and reload. not sure about the other manufacturers, perhaps the xilinx, altera, amd, motorola, atmel, etc. guys could chime in. umesh: : >- Backannotation is just an estimate and does not guarantee anything. daniel: : It's a pessimistic estimate. rk: i would expect that timing models supplied from the manufacturers hit all the corners from best-best case to worst-worst case, so the timing could be adequately bounded and shown correct, for a particular set of environmental conditions, and any part that gets delivered. if this is not true, it would be interesting to know more. <snip bunch of stuff about s/w - and i thought the idea of fpga's was to get rid of the s/w ;) > umesh: : >Note: Performing backannotation on a FPGA is not a bad thing. I am just : >stating that it is not absolutely necessary as in ASIC design. daniel: : I believe that you "need" backannotation as soon as you start making : changes to improve performance rather than functionality. rk: two opposite views here in design flow. i'm mostly with umesh on this one. i use the logic simulator for verifying that the logic of the device is correct and i use the static timing analyzer for verifying performance. this creates a flow of (vhdl+macrogen+schematics) to the logic simulator for functional verification. for the p&r, i use the static timing analyzer to verify timing performance and perhaps adjust controls on the layout or placement. i'd agree with daniel that you need the logic simulator (but not the back annotation) to change performance if you make architectural changes to change the performance; i.e., change of pipelining, different adder structure, different optimization settings on the synthesizer, etc. here, the logic simulator would be used to verify that the module-level netlist is still functionally correct. just a thought or two, -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9191
<major snip about linux successes and analysis of examplar effort>
what do you think the impact of the synopsis announcement of moving almost
all of it's tools to NT by the end of this year will be? [ee times,
2/23/98, page 1, r. goering].
also note that synopsys recently bought viewlogic, which produced tools for
both windows (and dos for those not yet upgraded ;) and unix.
with respect to linux, this is what the article said:
as to whether synopsys will support linux, a freely distributed version of
pc unix, baden said the company has received on a couple of inquiries to
that effect from synopsys users, despite apparently strong interest in
internet newsgroups.
"we're not in a position to take on the support mantle for linux,"
baden said. [baden is new product development manager at synopsys].
it'll be interesting to see how it all works out.
--------------------------------------------------------------
rk
"there's nothing like real data to screw up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9192Hi, I was wondering if anyone had any information regarding an FPGA Implementation of a Sony DAT Interface using VHDL. I am a complete newbie at VHDL and need to design the interface for the output of a Sony DAT to be able to read the audio data into memory of a PC and play it back without loss of quality. The implementation is to be done using an FPGA and programmed in VHDL. The main problem I am having is a complete lack of VHDL knowledge. The first step is to determine the clock rate of the incoming serial data stream from the DAT. This in itself may be trivial for an experienced VHDL programmer but is a brick wall for myself! Any help, (no matter how small!) will be GREATLY appreciated! Thanks! Steve PhillipsonArticle: 9193
Check out the boards and kits at http://www.associatedpro.com/aps J. Khatib wrote: > Hi > > I am an undergraduate electrical engineering student > > I like to do a project that is related to DSP systems and to implement > it on a single FPGA by using the VHDL language. > > please do you have any Idea about such a project that can be built > within 3 mounthes ( single term ) ? > > Please help I want to learn more about these feilds because I think > that they are the future of the electronics design > > thanks in advance > > please send your comments to my email at > jamil.khatib@pemail.net > > \\\|/// > \\ ~ ~ // > ( =@=@= ) > +------------oOOo---(_)---oOOo-------------+ > | | > |e-mail: jik@planet.edu | > |www.planet.edu/~jik/JamilHomepage.html | > |www.geocities.com/SiliconValley/Pines/6639| > | | > | .oooO Oooo. | > | ( ) ( ) | > +---------------\ (-----) /----------------+ > \_) (_/ -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9194
You may want to check the tools/kits/tutorials at http://www.associatedpro.com/aps There are complete tool kits including boards for getting started in VHDL and FPGAs Stephen Phillipson wrote: > Hi, > > I was wondering if anyone had any information regarding an FPGA > Implementation of a Sony DAT Interface using VHDL. I am a complete > newbie at VHDL and need to design the interface for the output of a Sony > DAT to be able to read the audio data into memory of a PC and play it > back without loss of quality. The implementation is to be done using an > FPGA and programmed in VHDL. > > The main problem I am having is a complete lack of VHDL knowledge. The > first step is to determine the clock rate of the incoming serial data > stream from the DAT. This in itself may be trivial for an experienced > VHDL programmer but is a brick wall for myself! > > Any help, (no matter how small!) will be GREATLY appreciated! > > Thanks! > Steve Phillipson -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9195
I agree with much of the following statements. I also feel that having a good multipurpose FPGA test board is a great way of testing algorithms in the actual technology. It also gives you a good verification of your HDL. We all know that simulations don't always produce the expected implementations as the synthesis. An ever increasing number of FPGA test boards can be seen at : http://www.associatedpro.com/aps Coupled with the POD ALYZER 18 channel logic analyzer --which can be seen at the same site-- you have a powerful FPGA test system. > - Bugs in prototype designs aren't costly to fix. Finding bugs is, of coarse > , harder in protos > than on a simulator. But probing internal signals via unused pins helps a > great deal. > - Backannotation is just an estimate and does not guarantee anything. > - Backannotation wastes precious time on a model when the same time can be > spend in the lab with the actual product. > - Simulation is slow. > - The actual software can be tested on the hardware. > -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9196
I am thinking of purchasing ORCAD Express to use as a front end tool for XILINX M1 and Lattice CPLDs. Anyone have advice on using these tools ?Article: 9197
I need help on verifying my proto-typing board which uses ISP. I have
read
the Datasheet on the XC4000 series. I'm still not sure how to design
the
ISP circuitry. I'm planning to use a parallel cable to program the
FPGA.
I have the software, XSLOAD, which will do the downloading for me.
Here are some of my questions:
1. Do I need to isolate the I/O pins during configuration?
2. When programing the FPGA in slave mode, do I need TDI, DIN and TCK?
3. What do I do to startup the FPGA?
4. I notice that some of the pins on the FPGA has more than one purpose
besides
I/O, what pins do I need to avoid during configuration stage and
startup stage?
Article: 9198
In article <34F80FF7.221C764E@worldlink.nsp.net>,
Jay Darmon <jdarmon@worldlink.nsp.net> wrote:
>In recent months there have been many successes for the Linux operating
>system:
[snippage of a lot of recent Linux accomplishments]
Just to add my 2 cents: I'm seeing positive articles on Linux all over
the place these days - in the regular press, PC rags, there was even one
on the MSNBC site recently. Linux is competing with NT favorably in a lot
of areas (and in some areas like web serving, its probably beating NT).
>So far, though, the EDA market has been a tough one for Linux to move
>into. It seems that the engineers (the users of EDA apps ) are quite
>willing to use Linux, but the EDA companies want to push NT. The case
>for EDA applications on Linux is compelling:
>
[snippage of a lot of good reasons to use Linux instead of NT]
The case for Linux is indeed compelling. The problem at this point is
that we need to educate those who are 'in power' (ie those who control the
purse strings). Most marketing and management types (the suits) don't see
more than about six inches in front of them when it comes to new trends
like this (and even then it has to be spelled out to them in big, bold
print :) so for the most part they've never even heard of Linux.
Since Linux is THE fastest growing part of the UNIX world right now it is
inevitable that more EDA companies will be supporting it in the future -
the question is, how long will it take the suits to figure this out?
>
>In last week's EETimes (Desktop EDA column) another compelling reason
>was given: Using 'farms' (or clusters, see the links above) to speed
>simulation. SpeedSim is reporting some high profile customers are using
>this approach. As the article says this could be the killer EDA app for
>Linux. It is difficult to set up such clusters using NT and it is very
>expensive to do it using traditional workstations. Linux excells in
>this area - which is why NASA and others are setting up such clusters as
>a low cost alternative to supercomputers.
>
>Some point to the Exemplar experiment with Linux last year as evidence
>that there is no demand for EDA tools on Linux. I suspect that this is
>the wrong conclusion based on the following:
[snipped analysis of Leonardo for Linux experiment]
>
>The conclusion is that the Exemplar experiment was inconclusive. Linux
>could still be a very successful EDA platform. Perhaps the companies
>that are building Linux clusters for simulation will demand that other
>parts of the tool chain be made available on Linux as well.
A synthesis tool by itself on Linux was probably not the best tool to be
there first - would have been much better to have had a simulator on Linux
first (and as was pointed out, there are some available on Linux now).
We can only hope that Exemplar will be willing to try the 'experiment'
again, but this time with some better monitoring.
There's also the Open-source route ('Open-source' being the new preferred
name for free software - ie the source is readily available). There is a
group that is working on a free (open-source) VHDL simulator at:
http://www.linuxeda.com/~freehdl
and I've heard some rumblings about a GNU-CAD project (don't have a link)
that is trying to develop a schematic capture package.
So if the companies won't listen, take it to the people!
phil
Article: 9199I'm using Capture with M1 and its fine.
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