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
Mike Treseler wrote:
> Check the Xilinx GUI for EDIF writer settings.
Make that EDIF *reader* settings.
Article: 38526Let's say you need a delay of 1 sec max. That means 32k samples of 32 bits each. Store them in an SRAM ( 1 Mbit is cheap) and use an FPGA or CPLD to manipulate the two FIFO address pointers ( one 15-bit counters and a 15-bit adder and a 15-bit register). The design is fully synchronous, so the FIFO control is trivial. I suppose that somebody has already implemented an I2S interface. Total: 2 chips plus a Xtal oscillator ( plus SPROM for the FPGA configuration) Peter Alfke ============================= Simon Fisher wrote: > Hi, I'm new to all this, so please bear with me. > > I need to implement a variable time delay for digital audio signals of > several hundred milliseconds. The data comes in and out of an I2S > interface using 32khz sample rate, stereo 16 bit samples. The device > also needs to be controlled (ie precise time delay selected) via an > I2C slave interface. > > Any ideas please? > > Cheers > Simon FisherArticle: 38527
If the two clocks are unrelated, you WILL have set-up time violations, sooner or later even metastability problems. I published something a while ago ( they even put my picture in there ;-). http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm Peter Alfke ======================= hamish@cloud.net.au wrote: > Peter Alfke <peter.alfke@xilinx.com> wrote: > > I have a simple, quick-and-dirty method of transferring data between unrelated > > clock domains: > > Transfer twice in a row, and then compare the two values. If they are identical, > > the data is good. If they differ, discard the data. > > A robust solution but it has quite a bit of overhead (duplicate signal, > comparison logic etc). Especially since I can guarantee that my > circuit works as long as I don't violate any setup times -- for > which I need the timing constraints. > > cheers, > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 38528
"Simon Fisher" <Simon.Fisher@hitachi-eu.com> schrieb im Newsbeitrag news:2cbcf39d.0201160940.7eec6579@posting.google.com... > Hi, I'm new to all this, so please bear with me. > > I need to implement a variable time delay for digital audio signals of > several hundred milliseconds. The data comes in and out of an I2S > interface using 32khz sample rate, stereo 16 bit samples. The device > also needs to be controlled (ie precise time delay selected) via an > I2C slave interface. Take a small FPGA (or a big CPLD) and build some state machines that get the data from the incomming audio device, stores it on an SRAM and read it back from the SRAM. The read/write operation uses some kind of circular pointer to the SRAM (similar to a FIFO). The difference of the pointers times the data transfer rate (I want to aviod the term sampling rate) gives the time delay. This difference can be easyly adjusted to the needs of the user. -- MfG FalkArticle: 38529
Is there verilog code available in public domain that will multiplex an I2C bus among multiple I2C busses? Thanks, AndyArticle: 38530
Thanks a lot for your guide, It really helped to solve my problem, As you said synplicity looks at the core as a black box. Ahmad Darabiha "Angel Pino" <escorpiontale@hotmail.com> wrote in message news:<EBq%7.30659$_j6.3312171080@newssvr14.news.prodigy.com>... > You need to make sure that the .edn file generated by CoreGen is in the same > directory as the .edf file generated by Symplicity. Simplicity only > considers the core as a black box and ignores whats in it. In ourder to > place and route you need both the .edf ( netlist from Symplicity ) and .edn > ( netlist from CoreGen ). > Hope this helps > Angel Pino > > "a_darabiha" <a_darabiha@yahoo.com> wrote in message > news:88a1211d.0201081317.13f3a1f1@posting.google.com... > > Hi all, > > can one Xilinx ISE tools experts help me please! > > I have gone through the Core Generator guide but > > still confused! :( here is the story: > > > > As a new user of Xilinx Core Generator I am trying > > generate a very simple core (16bit comparator) and then > > instantiate it in my vhdl design and finally synthesize and > > implement it on a virtexII platform. > > > > The Core Generator works fine and produces .vho, .edn and > > .vhd files. I then cut and paste from the .vho file to instantiate > > the component in my own design with the proper port map names... > > > > I synthesize the desing by Synplicity VHDL compiler v6.2.0 and it seems > > there is not any problem but after that in ngdbuid I get this error > message: > > > > **************************************************************** > > . > > . > > . > > WARNING:NgdBuild:329 - Line number 5: Invalid PART record value "4003pc84" > > ignored. Please consult the Xilinx Programmable Logic Data Book for > valid > > part/package/speed conbinations. > > Writing NGO file "my_adder_coregen_ports.ngo" ... > > Loading design module > > > "/jayar/q/q6/ahmadd/tm3/coregen/test_5/tm3a/xilinx/fpga0/my_adder_coregen_po > rts. > > ngo"... > > > > Annotating constraints to design from file "virtex0.ucf" ... > > > > Checking timing specifications ... > > > > Checking expanded design ... > > ERROR:NgdBuild:604 - logical block > > > 'wrapped_my_adder_coregen_inst/my_adder_coregen_inst/your_instance_name' > with > > type 'new_comp' is unexpanded. Symbol 'new_comp' is not supported in > target > > 'virtexe'. > > WARNING:NgdBuild:454 - logical net 'GND' has no load > > WARNING:NgdBuild:454 - logical net 'VCC' has no load > > > > NGDBUILD Design Results Summary: > > Number of errors: 1 > > Number of warnings: 2 > > > > . > > . > > . > > **************************************************************** > > > > Has any friend had this problem before? > > > > I have some guesses in my mind that might also help you > > to figure out the problem: > > > > 1- I have not compiled the XilinxCore Lib. Is that the problem ? > > There were several reasons for that: > > - it seems compiling VHDL behavioral library requires > > MTI ModelSim and in our package ModelSim is only supported > > for PC and not for Solaris... > > > > - in fact at this time I do not need to do any simulation > > and want to synthesize it directly, so I dont feel > > any need for simulation. and It should be possible > > to generate a core and synthesize it without any simulation in > > between... > > > > So, is it really neccessary to compile XilinxCoreLib for synthesis? > > if so, could someone help how to do that? (the info in Xilix Core > > Generator guide for compile_hdl.pl is too short not clear :( ) > > > > 2- in page 4-33 of Core generator guide for Synplicity synthesis tool it > says: > > "do not read in a separate .vhd file or EDIF file for Core Generator > mudule" > > what dose that mean !? > > > > > > > > I would really appreciate any help, > > and please let me know if the problem is not described clearly, > > thanks, > > a_darabiha@yahoo.comArticle: 38531
"Simon Fisher" <Simon.Fisher@hitachi-eu.com> wrote in message news:2cbcf39d.0201160940.7eec6579@posting.google.com... > Hi, I'm new to all this, so please bear with me. > > I need to implement a variable time delay for digital audio signals of > several hundred milliseconds. The data comes in and out of an I2S > interface using 32khz sample rate, stereo 16 bit samples. The device > also needs to be controlled (ie precise time delay selected) via an > I2C slave interface. > > Any ideas please? > > Cheers > Simon Fisher A circular buffer will do this for you. You will need a fair mount of RAM, depending on how much delay you want. Leon -- Leon Heller, G1HSM leon_heller@hotmail.con http://www.geocities.com/leon_heller Low-cost Altera Flex design kit: http://www.leonheller.comArticle: 38532
Hi All, I'm trying to implement a Computer Vision Algorithm on Xilinx Vitex2000E fpgas. I am now using CoreGen for some blocks of my system. We are thinking of switching to System Generator to do the simulation in the highest level and then translate the system to VHDL. I hope it would make the life much easier! So does anybody have experience of using SysGen for Image Processing applications? how easy is that compared with the standard method of writing the whole VHDL myself? what are the major problems that might be in the way? ... Any coment would be helpful, Thanks, Ahmad DarabihaArticle: 38533
Hi All, Currently SysGen is only available for PC. The problem is that the implementation of my designto on FPGA board can be done only from Unix machine. So if I start from SysGen on PC then at some intermediate point of the design flow I need to transfer the files to Unix. I have heared that the files are fully PC/Unix compatible. ( for instance send the NGDBUild results from PC to Unix and continue the Place and Route on Unix) But On the other hand I heared that sometimes Unix can not read the encription code on the file headers written by PC... So is there ay experience? any comment or suggestion? Thanks, Ahmad DarabihaArticle: 38534
Hi, I was hoping someone could answer questions I had regarding digital signal processors vs. FPGAs for implementing computationally intensive signal processing algorithms: 1. Can FPGAs (especially newer ones) achieve better performance than DSPs? 2. If so, then why do ppl use DSPs as opposed to FPGAs? 3. Which is more flexible in terms of reprogrammability (I would think they would be the same in this regard). 3. What are other (dis)advantages of using FPGAs vs. DSPs. In general, I understand that DSPs provide a low cost solution due to high volume of generic products, but performance tends to fall short for many applications. Any input would be greatly appreciated. Thanks! -AmitArticle: 38535
See below, Austin Amit Thakar wrote: > Hi, > > I was hoping someone could answer questions I had regarding digital signal > processors vs. FPGAs for implementing computationally intensive signal > processing algorithms: > > 1. Can FPGAs (especially newer ones) achieve better performance than DSPs? Yes. 70 to over 100 times better performance. > > 2. If so, then why do ppl use DSPs as opposed to FPGAs? Tools. Hard to create DSP structures for FPGAs as opposed to writing C code. Hard to simulate. The Xtreme DSP (tm) program is addressing these issues with better tools (ie CoreGen, interface to MatLab (Simulink), etc). > > 3. Which is more flexible in terms of reprogrammability (I would think they > would be the same in this regard). Easy to reprogram either, but you need the program! FPGAs can change their hardware, not just the algorithm, so they are more flexible (potentially). > > 3. What are other (dis)advantages of using FPGAs vs. DSPs. Tools. Hard to design, hard to simulate. Cost. If you need 100X performance, the cost is low. If you look to do what a simple DSP chip can do, the cost is high (in comparison). > > > In general, I understand that DSPs provide a low cost solution due to high > volume of generic products, but performance tends to fall short for many > applications. FPGAs are also mass produced, so their cost is low (see Spartan for example). > > > Any input would be greatly appreciated. > Thanks! > > -AmitArticle: 38536
Amit Thakar wrote:
> Hi,
>
> I was hoping someone could answer questions I had regarding digital signal
> processors vs. FPGAs for implementing computationally intensive signal
> processing algorithms:
>
> 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?
Yes, We typically see just under 100:1 performance advantage in our designs
(mostly radar and imaging). That ratio hasn't change much over the last 10
years.
>
> 2. If so, then why do ppl use DSPs as opposed to FPGAs?
Obtaining that performance from FPGAs requires a relatively rare skill set: The
FPGA DSP designer needs to be skilled in logic design, specifically FPGA design,
and also has to be familiar enough with Hardware based DSP to be able to
optimize the algorithm implementation for a hardware, make that FPGA,
implementation. Most DSP algorithms in use today are geared toward a software
solution. The efficient hardware solution often requires a quite different
approach. Most people doing DSP work these days are software types (which makes
sense seeing the DSP field has been dominated by the microprocessor for the past
quarter century), so it follows that DSP designs will continue to use
microprocessors as the preferred platform as long as the project requirements
are met.
>
> 3. Which is more flexible in terms of reprogrammability (I would think they
> would be the same in this regard).
The microprocessors still hold an edge on flexibility, mostly because of the
state of the tools. Microprocessor code typically takes seconds to compile
changes where the FPGA code can take hours. The tools, especially when it comes
to evaluation of algorithms, are also much better for the software side.
>
> 3. What are other (dis)advantages of using FPGAs vs. DSPs.
The biggest disadvantage to using FPGAs is the relative scarcity of expertise
needed for the performance gains I noted above. FPGAs also cost more per device
than typical DSP micros, but when you consider dollars for a specific
performance then the PFGAs get cheaper as soon as performance drives you over
one or two DSPs.
I tell my customers that if it can be done in a (single or at most two) DSP
micro, then they should do it there rather than in an FPGA because it is a lot
easier (and somewhat cheaper) to find expertise on the processors.
>
>
> In general, I understand that DSPs provide a low cost solution due to high
> volume of generic products, but performance tends to fall short for many
> applications.
>
> Any input would be greatly appreciated.
> Thanks!
>
> -Amit
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38537
--------------8CF0AA49EAE5C084DF6A8496
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Right.
For coherent clocks you need the skew included in the timing analysis to make
sure your data crossing domains does not violate the setup/hold of the
reciever. Constraints covering the path between the domains are critical in
this case to ensure proper operation. I'm with Hamish on this one, no need for
the overhead indicated by Peter if you can guarantee the condition won't occur
through the use of contraints.
The other case, where clocks are async to each other, it is still a good idea to
constrain the path because you want to minimize the transport time from the
flip-flop in one domain to the flip-flop in the other domain so as to maximize
the metastability settle time. A from:to constraint is needed here so that the
tools do this. So even though intuition might indicate that a timing constraint
is not needed here since you *will* go metastable at some time, the truth is a
constraint is vital here to keep from eating up your metastability resolution
time with propagation delay. In this case, the skew doesn't matter much, so it
probably doesn't hurt to include it (it is meaningless anyway). I usually
floorplan the flops on each side of a crossing like this so that they are in
adjacent slices within a CLB. That alone doesn't guarantee use of the fast
connect, but it at least makes it possible.
Peter Alfke wrote:
> If the two clocks are unrelated, you WILL have set-up time violations, sooner
> or later even metastability problems.
>
> I published something a while ago ( they even put my picture in there ;-).
>
> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
>
> Peter Alfke
> =======================
> hamish@cloud.net.au wrote:
>
>> Peter Alfke <peter.alfke@xilinx.com> wrote:
>> > I have a simple, quick-and-dirty method of transferring data between
>> unrelated
>> > clock domains:
>> > Transfer twice in a row, and then compare the two values. If they are
>> identical,
>> > the data is good. If they differ, discard the data.
>>
>> A robust solution but it has quite a bit of overhead (duplicate signal,
>> comparison logic etc). Especially since I can guarantee that my
>> circuit works as long as I don't violate any setup times -- for
>> which I need the timing constraints.
>>
>> cheers,
>> Hamish
>> --
>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38538
Mike,
I don't recall ever seeing settings in the Xilinx tools for the edif reader.
Sounds to me like a problem with the way leo is writing the edif. I think there
may be settings in leo for the edif output format. Also, the tri_state warnings
indicate that it couldn't find a matching component. If it is not a primitive
for the device you are using, it better have an edif file for the component or
you get the error.
Mike Treseler wrote:
> Mike Treseler wrote:
>
> > Check the Xilinx GUI for EDIF writer settings.
>
> Make that EDIF *reader* settings.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38539Thanks a lot Austin and Ray, your responses were really helpful. -Amit "Amit Thakar" <athakar@uwaterloo.ca> wrote in message news:z7l18.253991$KT.59135022@news4.rdc1.on.home.com... > Hi, > > I was hoping someone could answer questions I had regarding digital signal > processors vs. FPGAs for implementing computationally intensive signal > processing algorithms: > > 1. Can FPGAs (especially newer ones) achieve better performance than DSPs? > 2. If so, then why do ppl use DSPs as opposed to FPGAs? > 3. Which is more flexible in terms of reprogrammability (I would think they > would be the same in this regard). > 3. What are other (dis)advantages of using FPGAs vs. DSPs. > > In general, I understand that DSPs provide a low cost solution due to high > volume of generic products, but performance tends to fall short for many > applications. > > Any input would be greatly appreciated. > Thanks! > > -Amit > > >Article: 38540
Austin Lesea wrote:
> Rick,
>
> The part was never intended to support M and D values to 4095. The intent was to
> find out just where it did work to.
>
> The measured performance was such that with values > 32, the jitter became too large
> as a % of the period, making the feature much less useful.
>
> As well, to verify M and D values for {1,32} requires thousands of patterns to be
> run over hundreds of frequencies (over hundreds of parts) to characterize, not to
> mention production test. In keeping with our commitment to the customer to provide
> a quality part, we decided to limit the M and D values to less than what the part
> was capable of to be sure all values worked in actual designs with other resources
> in a production environment.
>
> Future silicon is not intended to operate at any values greater than 32. The basic
> issue is the Q of the oscillator, or resonator used. In silicon, with devices, this
> is limited to a practical value of about 100. Thus, the oscillator can not for very
> long before it accumulates a phase error (jitter) from the desired phase. Perhaps
> with integrated inductors, we could achieve a Q of 200, but even that is beyond the
> technology. Maybe MEMS? Tuning forks?
>
> I apologize for not catching the 4095 in the original information. I was
> responsible for checking the info, and preventing just that kind of slip. I missed
> it. The bits are free in the memory, and thus they are there for future use. It
> was never intended that we actually support such values. It is also true that such
> M and D values require a quartz crystal for stability, so I am surprised anyone took
> those numbers seriously when they were first published ... (they were impossible to
> achieve -- at least to anyone skilled in the art of frequency synthesis).
>
Not a problem. I must admit that I was a little suspicious but such is my belief that
all Xilinx designers have been trained at the Hogwarts School of Silicon Wizzardry that
I sort of thought o.k. well these guys just might ...
<snip>
Just one question: What does ICAP stand for ?
BTW: The new CoolRunner-2 looks really nice but only the '64 is showing yet - what's the
roll out plan for the bigger devices ? I need the '256 in particular.
Article: 38541
Rick,
Funny you mention "Hogwarts School of FPGA Design" .....there was a certain little Holiday
Play that had various characters like "Alteramort" in it, and the three headed management
monster ..... (all in good fun).
ICAP = Internal Configuration Access Port.
Austin
Rick Filipkiewicz wrote:
> Austin Lesea wrote:
>
> > Rick,
> >
> > The part was never intended to support M and D values to 4095. The intent was to
> > find out just where it did work to.
> >
> > The measured performance was such that with values > 32, the jitter became too large
> > as a % of the period, making the feature much less useful.
> >
> > As well, to verify M and D values for {1,32} requires thousands of patterns to be
> > run over hundreds of frequencies (over hundreds of parts) to characterize, not to
> > mention production test. In keeping with our commitment to the customer to provide
> > a quality part, we decided to limit the M and D values to less than what the part
> > was capable of to be sure all values worked in actual designs with other resources
> > in a production environment.
> >
> > Future silicon is not intended to operate at any values greater than 32. The basic
> > issue is the Q of the oscillator, or resonator used. In silicon, with devices, this
> > is limited to a practical value of about 100. Thus, the oscillator can not for very
> > long before it accumulates a phase error (jitter) from the desired phase. Perhaps
> > with integrated inductors, we could achieve a Q of 200, but even that is beyond the
> > technology. Maybe MEMS? Tuning forks?
> >
> > I apologize for not catching the 4095 in the original information. I was
> > responsible for checking the info, and preventing just that kind of slip. I missed
> > it. The bits are free in the memory, and thus they are there for future use. It
> > was never intended that we actually support such values. It is also true that such
> > M and D values require a quartz crystal for stability, so I am surprised anyone took
> > those numbers seriously when they were first published ... (they were impossible to
> > achieve -- at least to anyone skilled in the art of frequency synthesis).
> >
>
> Not a problem. I must admit that I was a little suspicious but such is my belief that
> all Xilinx designers have been trained at the Hogwarts School of Silicon Wizzardry that
> I sort of thought o.k. well these guys just might ...
>
> <snip>
>
> Just one question: What does ICAP stand for ?
>
> BTW: The new CoolRunner-2 looks really nice but only the '64 is showing yet - what's the
> roll out plan for the bigger devices ? I need the '256 in particular.
Article: 38542On Wed, 16 Jan 2002 22:29:20 GMT, Ray Andraka <ray@andraka.com> wrote: > >--------------8CF0AA49EAE5C084DF6A8496 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Right. > >For coherent clocks you need the skew included in the timing analysis to make >sure your data crossing domains does not violate the setup/hold of the >reciever. Constraints covering the path between the domains are critical in >this case to ensure proper operation. I'm with Hamish on this one, no need for >the overhead indicated by Peter if you can guarantee the condition won't occur >through the use of contraints. > >The other case, where clocks are async to each other, it is still a good idea to >constrain the path because you want to minimize the transport time from the >flip-flop in one domain to the flip-flop in the other domain so as to maximize >the metastability settle time. A from:to constraint is needed here so that the >tools do this. So even though intuition might indicate that a timing constraint >is not needed here since you *will* go metastable at some time, the truth is a >constraint is vital here to keep from eating up your metastability resolution >time with propagation delay. In this case, the skew doesn't matter much, so it >probably doesn't hurt to include it (it is meaningless anyway). I get the feeling that Hamish's clock is running at 350MHz or so (based on the contents of previous posts). The skew ends up being a significant part of the timespec (about one third). It would be much more satisfactory if the tools gave the option of not including the skew in the timing analysis, on a timespec by timespec basis. Regards, Allan. > I usually >floorplan the flops on each side of a crossing like this so that they are in >adjacent slices within a CLB. That alone doesn't guarantee use of the fast >connect, but it at least makes it possible. > > > >Peter Alfke wrote: > >> If the two clocks are unrelated, you WILL have set-up time violations, sooner >> or later even metastability problems. >> >> I published something a while ago ( they even put my picture in there ;-). >> >> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm >> >> Peter Alfke >> ======================= >> hamish@cloud.net.au wrote: >> >>> Peter Alfke <peter.alfke@xilinx.com> wrote: >>> > I have a simple, quick-and-dirty method of transferring data between >>> unrelated >>> > clock domains: >>> > Transfer twice in a row, and then compare the two values. If they are >>> identical, >>> > the data is good. If they differ, discard the data. >>> >>> A robust solution but it has quite a bit of overhead (duplicate signal, >>> comparison logic etc). Especially since I can guarantee that my >>> circuit works as long as I don't violate any setup times -- for >>> which I need the timing constraints. >>> >>> cheers, >>> Hamish >>> -- >>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> >> >-- >--Ray Andraka, P.E. >President, the Andraka Consulting Group, Inc. >401/884-7930 Fax 401/884-7950 >email ray@andraka.com >http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 38543
Exactly. I mentioned that in an earlier post, because there are times when to skew or not to skew is not in question.
Allan Herriman wrote:
> On Wed, 16 Jan 2002 22:29:20 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >
> >--------------8CF0AA49EAE5C084DF6A8496
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >Right.
> >
> >For coherent clocks you need the skew included in the timing analysis to make
> >sure your data crossing domains does not violate the setup/hold of the
> >reciever. Constraints covering the path between the domains are critical in
> >this case to ensure proper operation. I'm with Hamish on this one, no need for
> >the overhead indicated by Peter if you can guarantee the condition won't occur
> >through the use of contraints.
> >
> >The other case, where clocks are async to each other, it is still a good idea to
> >constrain the path because you want to minimize the transport time from the
> >flip-flop in one domain to the flip-flop in the other domain so as to maximize
> >the metastability settle time. A from:to constraint is needed here so that the
> >tools do this. So even though intuition might indicate that a timing constraint
> >is not needed here since you *will* go metastable at some time, the truth is a
> >constraint is vital here to keep from eating up your metastability resolution
> >time with propagation delay. In this case, the skew doesn't matter much, so it
> >probably doesn't hurt to include it (it is meaningless anyway).
>
> I get the feeling that Hamish's clock is running at 350MHz or so
> (based on the contents of previous posts). The skew ends up being a
> significant part of the timespec (about one third).
>
> It would be much more satisfactory if the tools gave the option of not
> including the skew in the timing analysis, on a timespec by timespec
> basis.
>
> Regards,
> Allan.
>
> > I usually
> >floorplan the flops on each side of a crossing like this so that they are in
> >adjacent slices within a CLB. That alone doesn't guarantee use of the fast
> >connect, but it at least makes it possible.
> >
> >
> >
> >Peter Alfke wrote:
> >
> >> If the two clocks are unrelated, you WILL have set-up time violations, sooner
> >> or later even metastability problems.
> >>
> >> I published something a while ago ( they even put my picture in there ;-).
> >>
> >> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
> >>
> >> Peter Alfke
> >> =======================
> >> hamish@cloud.net.au wrote:
> >>
> >>> Peter Alfke <peter.alfke@xilinx.com> wrote:
> >>> > I have a simple, quick-and-dirty method of transferring data between
> >>> unrelated
> >>> > clock domains:
> >>> > Transfer twice in a row, and then compare the two values. If they are
> >>> identical,
> >>> > the data is good. If they differ, discard the data.
> >>>
> >>> A robust solution but it has quite a bit of overhead (duplicate signal,
> >>> comparison logic etc). Especially since I can guarantee that my
> >>> circuit works as long as I don't violate any setup times -- for
> >>> which I need the timing constraints.
> >>>
> >>> cheers,
> >>> Hamish
> >>> --
> >>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
> >>
> >--
> >--Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930 Fax 401/884-7950
> >email ray@andraka.com
> >http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38544Amit Thakar wrote: > Hi, > > I was hoping someone could answer questions I had regarding digital signal > processors vs. FPGAs for implementing computationally intensive signal > processing algorithms: > > 1. Can FPGAs (especially newer ones) achieve better performance than DSPs? It depends what you mean by performance. If you mean speed, then yes. An FPGA solution can generally be 1 to 2 orders of magnitude faster. If you means capable of implementing extremely complex algorithms well, then no. The complexity of handling, say, a CELP vocoder in dedicated hardware makes it a poor choice. > 2. If so, then why do ppl use DSPs as opposed to FPGAs? Use dedicated hardware solutions for simple things - if you need a simple filter in a CD player, nothing will beat a bit serial solution in hardware. Use dedicated hardware solutions for speed - if you do real time radio channel processing you generally have a high throughput requirement, but the algorithms aren't too complex. Doing this with programmable DSPs would require a large bank of the, splitting up the work. FPGAs are ideal here. Use programmable DSPs where the algorithms are complex - things like vocoders can be a nightmare to implement in an FPGA. Use programmable DSPs where the requirements change frequently - FPGA may be reprogrammable, but minor changes in requirements tend to become major changes in an FPGA DSP solution. In a programmable solution they may be just a few lines of code. Use programmable DSPs for low volume - this is not a clear cut thing, as FPGAs are the right things for a lot of low volume uses. However, your chances of being able to use, say, a standard PCI card solution are far better with the programmable approach. > 3. Which is more flexible in terms of reprogrammability (I would think they > would be the same in this regard). Depends what flexibility you need. If you got the board layout wrong you are more likely to be able to fix that by reprogramming an FPGA, than a programmable DSP. You you want to make algorithm changes its usually much quicker with programmable DSPs. > 3. What are other (dis)advantages of using FPGAs vs. DSPs. I think these issues are too application dependent to generalise. > In general, I understand that DSPs provide a low cost solution due to high > volume of generic products, but performance tends to fall short for many > applications. What does "performance fall short" mean? Nothing will match the current consumption of the programmable solutions in my GSM phone. If battery life if your overriding criteria, that very current consumption focussed solution will beat anything a more general purpose FPGA can do. In terms of mere processing speed, in most DSP applications some specific level is enough and you can't take any real advantage of any left over compute resources. You can never have too low a level of battery consumption, though. No solution will maximise all performance parameters - pretty much like any other area of engineering. Regards, SteveArticle: 38545
I have a XC18V02 PROM in a VQ44 package connected to an XCV300 FPGA in slave serial mode. I'm trying to program the PROM via JTAG via parallel cable. In Foundation 3.1, it used to ask me for the PROM family (XC18V02) and the package (VQ44). In ISE, I can't seem to find any place to set the package. When I program the PROM via iMPACT, it says it did it successfully and verify confirms that it got to the PROM. But the FPGA does not seem to receive the program on reset. An .mcs file created via Foundation 3.1 downloads and runs as expected, so the hardware and all connections are fine. The same simple program created via ISE 4.1 does nothing. Any ideas would be appreciated. I have a feeling I need to set the PROM package somehow.Article: 38546
Hello Amit, You have received indeed an enthusiastic feedback about implementing D.S.Processing in FPGA. (is this a surprise ? ;-) One issue you may soon face is getting/building a hardware platform, and how to interface it with the real world. For some of these designs, we now use a superb platform made by a UK company named Hunt Engineering. http://www.hunteng.co.uk This architecture is real clever, and you can freely mix FPGA(s) and DSP(s) in your system and get the best of both worlds. The control by the PC is also a breeze. Hope this helps, Bert Cuzeau Technical Manager ALSE rance - Digital Design - VHDL + Verilog - Training Courses -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 38547
Hi Incidentally, I just stumbled over the Virtex2 ICAP (Internal configuration access port) primitive. Just looking at the name of the component this sounds very interessting. Is it possible to access/modify the Virtex2 configuration from a circuit within the FPGA itself using this component? Unfortunately I could not find any documentation ICAP on the Xilinx webpage. Does anybody know, what this component is good for? Is there any documentation on this? Thanks for any hints. ChristianArticle: 38548
Hi, sorry, this doesn't really concern this posting, but an old posting of yours in comp.sys.laptops concerning the use of a DVD in a Digital Hinote Ultra 2000. Your email address in that posting just doesn't seem to work, so I thought I'd try to track you down this way, since I might be having the same problem. Assuming that the connectors were pretty much standardized, I bought a TEAC CD-RW to go as replacement for the existing Toshibar CD-ROM, but, same in your case, it won't boot when the drive is plugged in. However, one single time I managed to get it running by booting Windows98 without the drive, plugging in the drive (it's supposed to be hot-swappable, anyway, although it usually doesn't work) and restarting Windows. Everything worked fine and I could burn an CD, but I haven't managed to get it working again ever since. Do you have any idea how that can be and do you think it is the same problem? If so, could you please send me the extra information on how to do the changes (I am able to put computers together, but not very experienced with subtle changes of the elec like these - alternatively: were would I have to ship it to? I am in Scotland). Please email. Your help is greatly appreciated. And sorry again for this misplaced posting. Stefan KleinArticle: 38549
The reference design (ftp://ftp.xilinx.com/pub/applications/xapp/xapp205.zip) is a (16x255 write-1020x4 read)'s fifo.Now,my request is (32x64 write-16x128 read) how should i change it?
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