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 John, John wrote: > John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<ck1rpt$ubf$1@bunyip.cc.uq.edu.au>... > >>Austin Lesea wrote: >> >>>I refer to this as a 'tap dance.' (please forgive my humor, but it is >>>part of my personality....) > > Austin, > Keep it up, I for one enjoy the pun-ishment. Yes, it certainly keeps the punters happy. >>I'm picturing a self-reconfiguring microblaze uClinux system dynamically >>scaling its own clock... > > > I'd suggest a numerically controlled oscilator (NCO) / scaling > accumulator / DDFS (see http://www.xilinx.com/xcell/xl31/xl31_32.pdf). > In the latest parts, you can clock a 10 bit accumulator at >500 MHz, > allowing your microblaze to run up to 250MHz (do they go that fast? > I'll be using one soon). I think Microblaze fmax is somewhere around 150MHz these days, but climbing all the time esp in V4. > You would get more resolutions than the > 5-bits M, 5-bits D of the CLKFX. If you are scaling the clock for > power conservation, you probably would not need more than 6 bits. > Also, no worries about the period dropping below the minimum that the > microblaze configuration was routed for. And far easier to program > than partial re-config. Thanks for the tip - certainly much easier than partial reconfig. I confess a strange desire to find useful things to do with partial reconfiguration - however as the devices get bigger and faster, the candidate set seems to get smaller and smaller. Perhaps if it weren't so painful re: tools and design flow (and I hear there are changes in the wind that might answer that wish) Cheers, JohnArticle: 74401
At the moment I'm playing around with Kolja's changes and Pauls Quartus suggestions. Setting the PLL factor to different values (to relax the timing constraints for smaller area) gives some surprising Fmax results from the timing analyzer: fin is always 20 MHz, LC count stays the same. PLLout = 50 MHz => Fmax = 131 MHz PLLout = 100 MHz => Fmax = 100 MHz PLLout = 120 MHz => Fmax = 101 MHz The first line is really strange! Martin -- ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74402
Martin Schoeberl wrote: > At the moment I'm playing around with Kolja's changes and Pauls Quartus > suggestions. Setting the PLL factor to different values (to relax the > timing constraints for smaller area) gives some surprising Fmax results > from the timing analyzer: > fin is always 20 MHz, LC count stays the same. > > PLLout = 50 MHz => Fmax = 131 MHz > PLLout = 100 MHz => Fmax = 100 MHz > PLLout = 120 MHz => Fmax = 101 MHz > > The first line is really strange! Have you tried these files in real systems ? The timing numbers (presume after P&R?) will be corner values, but you should be able to overclock until it fails, and then get usefull RELATIVE speed limit comparisons. -jgArticle: 74403
>> At the moment I'm playing around with Kolja's changes and Pauls >> Quartus suggestions. Setting the PLL factor to different values (to >> relax the timing constraints for smaller area) gives some surprising >> Fmax results from the timing analyzer: >> fin is always 20 MHz, LC count stays the same. >> >> PLLout = 50 MHz => Fmax = 131 MHz >> PLLout = 100 MHz => Fmax = 100 MHz >> PLLout = 120 MHz => Fmax = 101 MHz >> >> The first line is really strange! > > Have you tried these files in real systems ? > The timing numbers (presume after P&R?) will be corner values, > but you should be able to overclock until it fails, > and then get usefull RELATIVE speed limit comparisons. > -jg > I've worked with the 100 MHz setting, but I don't want to overclock the FPGA. I just want to get 'safe' values. I don't understand the different Fmax reports when only the PLL multiplication factor changes. As there is no 'external' fmax constraint the way I want to go is: Obtain fmax from one compilation (with any PLL setting) and than set the PLL factor to this limit. With the above results it seems not so easy. MartinArticle: 74404
Martin Schoeberl wrote: >>>At the moment I'm playing around with Kolja's changes and Pauls >>>Quartus suggestions. Setting the PLL factor to different values (to >>>relax the timing constraints for smaller area) gives some surprising >>>Fmax results from the timing analyzer: >>>fin is always 20 MHz, LC count stays the same. >>> >>>PLLout = 50 MHz => Fmax = 131 MHz >>>PLLout = 100 MHz => Fmax = 100 MHz >>>PLLout = 120 MHz => Fmax = 101 MHz >>> >>>The first line is really strange! >> >>Have you tried these files in real systems ? >>The timing numbers (presume after P&R?) will be corner values, >>but you should be able to overclock until it fails, >>and then get usefull RELATIVE speed limit comparisons. >>-jg >> > > I've worked with the 100 MHz setting, but I don't want to overclock the > FPGA. I just want to get 'safe' values. I don't understand the different > Fmax reports when only the PLL multiplication factor changes. > As there is no 'external' fmax constraint the way I want to go is: Obtain > fmax from one compilation (with any PLL setting) and than set the PLL > factor to this limit. With the above results it seems not so easy. Understood. I was giving a suggestion for a way to check which numbers are correct - it does sound like something is in error. Reminds me of the saying "A man with one watch always knows that time it is, A man with two is never sure" :) -jgArticle: 74405
Hi Tony, T Lee wrote: > What's the easiest way to partition one 128 MB dram into > two 64 MB sections with each section control by one of the > ppc in the VP20? I don't know any easy ways - but there are at least two fairly hard ways: 1 - as you suggest, somehow mux the physical off-chip interface between two independent controllers. This is going to be tricky to say the least, and probably quite inefficient, depending on how much L1/L2 cache you have to play with. You'd need some sort of arbiter that can selectively stall one of the controllers, and switch the mux in such a way that it all works seamlessly. Maybe not as hard as a I think, but surely not easy. 2 - implement a classic SMP (symmetric multiprocessing) architecture with the two PPCs tied to a common bus, bus arbiters, a single memory interface and so on. I'm not sure how the PPC architecture typically implements SMP, and if the V2Pro / PLB can support it without radical effort. Also this results in all memory being shared (at least at the physical level, you could use the VM capabilities of the processors to make it look like they are distinct). If what you really want is two completely independent PPC systems it could be easier to build/buy a more suitable board. Take a look at the Insight/Memec V2P20/30/50 boards, they have dual independent SDRAM banks for exactly this purpose. http://www.insight.na.memec.com/Memec/iplanet/link1/VirtexIIPro_FF1152_2.pdf There may be others as well. > Also if I like to have some special fpga logic to > > * offload some special ppc packet processing functions > * the functions require access the DDR used and update by the > ppc CPU at the same time. Interesting questions, with no easy answers. If you make your custom processing logic bus master capable, then in principle you could use DMA to handle all of this. You need to be careful that you don't end up in a bus-bound mess, losing any performance gains that might otherwise be achieved with the hardware offloading in the first place! It depends on the nature of what you are trying to do - if it is heavy on the computation, and light on the communication, then it's not so bad. However, if the opposite is true, you will end up saturating the bus. Regards, JohnArticle: 74406
Hi, there: I was working in ASIC/FPGA industry and I came across a book Miceomechatronics by Kenji Uchino. It reminded me of all the mechanics knowledge I learnt in the university and high school. Is there many opportunities in this field? Thanks. KelvinArticle: 74407
240 MHz, 4 samples per clock coming in
Marc Randolph wrote:
> Ray Andraka <ray@andraka.com> wrote in message news:<41649515.80D21B73@andraka.com>...
> > I did a design a couple years ago in a VirtexE-7 that interfaced to an
> > Atmel 1GHz 8 bit ADC. IIRC, that ADC output 4 samples at a time (perhaps
> > there was a matching mux chip). Once inside the FPGA the signal was
> > mixed and FFT'd. The incoming sample rate was 960MHz. So yes, the
> > answer is most current FPGAs can handle the throughput with some
> > clever/careful design. The new crop of FPGAs are considerably faster
> > than the VirtexE devices.
>
> Howdy Ray,
>
> How fast were your IOB's toggling on that design? Was it really
> 960 MHz? A coworker and I got to looking yesterday, and it appears
> that the general purpose IOB hasn't really gained any clock rate
> performance since VirtexE - all the way to now with the Virtex4. We
> were hoping to do 1.25 GHz LVDS (or any other standard), but our FAE
> is steering us away from doing anything much over 840 or 900 MHz.
> Comments from Xilinx reps also welcome...
>
> BTW, Alex, I agree with Ray. 500 MHz LVDS should be doable without
> alot of grief. Just be aware that the internal termination can be
> less than ideal.
>
> Have fun,
>
> Marc
>
> > Alex wrote:
> > >
> > > It's not the first time this question has been asked, but I'd like to
> > > know todays state of art:
> > > Are their any devices at Altera, Xilinx or others, capabable of
> > > handling the fast throughput of high-speed ADCs (1 GS), such as
> > > Atmel's AT84AD001B or NS ADC08D1000 ? Preferably without an external
> > > DMUX-device...
> > > Using the ADC's internal DEMUX leaves us with 16 500 MHz LVDS lines
> > > per channel.
>
> --
> Marc Randolph
> Reply address is a spam trap. Please post responses.
--
--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: 74408
I just answered a similar question last Tuesday. Google for it in this
newsgroup
Sine function implementation in FPGA??
Date:
Tue, 05 Oct 2004 19:14:29 -0400
From:
Ray Andraka <ray@andraka.com>
Organization:
Andraka Consulting Group, Inc
Newsgroups:
comp.arch.fpga
References:
1
SD wrote:
> Hi all,
> I am trying to implement a DSP algorithm in a FPGA. My algorithm has
> sine and cosine functions in it. Can somebody comment on implementing
> sine and cosine functions in VHDL or MATLAB fixed point (using fixed
> point toolbox).
> Thanks,
> SD
--
--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: 74409
The copy of the clock is a signal that is clocked by the faster clock such that
it is a duplicate of the lower speed clock. I usually use a 90 degree version
of the slower clock as the reference for the clock copy to make sure it is in
phase with the real slower clock.. How it helps is it gives you a phase
reference in the faster clock domain so that you know which cycle is the one
where you can change the interface flip-flop values knowing that it will occur
away from the active edge in the slower domain.
Brad Smallridge wrote:
>
> Ray Andraka suggested making a copy of the slow clock in the fast domain,
> and using that signal as a clock enable, I guess in the fast domain? I'm
> not sure how this helps. The idea of using 90/270 clocks to get rid of skew
> issues seems good.
>
> I have found XAPP253 which is an DDR SDRAM controller with some of the same
> issues. Trying to work through that.
--
--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: 74410Burched has an interesting product line (http://www.burched.biz/). Their products let you build a system to meet your needs. DerekArticle: 74411
Tony, > What's the easiest way to partition one 128 MB dram into > two 64 MB sections with each section control by one of the > ppc in the VP20? if you do not have any specific requirements (like "either one of the two processors must see its part of the memory at address zero") it is straight forward: 1) hook up both PPC to the same PLB together with the PLB SDRAM controller 2) write seperate linker scripts for each of the two processors. The first processor uses the memory in [0,64[ and the second one uses [64,128[. - PeterArticle: 74412
Hi Peter, Peter Ryser wrote: >> What's the easiest way to partition one 128 MB dram into two 64 MB >> sections with each section control by one of the ppc in the VP20? > > if you do not have any specific requirements (like "either one of the > two processors must see its part of the memory at address zero") it is > straight forward: > > 1) hook up both PPC to the same PLB together with the PLB SDRAM controller > 2) write seperate linker scripts for each of the two processors. The > first processor uses the memory in [0,64[ and the second one uses [64,128[. Nice solution - what will the caches do in this configuration? Duplicate / thrash? Get incoherent? JohnArticle: 74413
Hi, I have decided to post this problem again because it has gone down in my last post, so here it is; How do I route the output of the PLL (Altera Cyclone) to the PLL_OUT+ and PLL_OUT- pins for differential clock use? I mean the PLL has only one output ... Do I have to create an inverted clock - only by an inverter ? How do I have to make clock settings to get differential clocks? Thank you for your help. Kind regards AndreArticle: 74414
Hi, I am a Actel 54SXA family user. I would like to get from the fusefile what I/O standard I have selected in my Designer software (i.e. PCI, LVTTL). Is that possible ? I am doing so because I have been messed up my files and I cant trace back. Thanks in advance.Article: 74415
Hello everybody!! Maybe some CORDIC guru's can help me??? I've seen a lot of papers, designs and cores and I still don't understand why always everybody offers (for example) a Frequency Resolution of 32bit when at the input of CORDIC's block the angle just have 16bits+guard bits(log2(16)) = 20 bits. That's not a 32 bits resolution!!!! The phase offset is 16 bits, That's OK but 32 bits frequency resolution!!!! I think maybe it's all about the guard bits but I'm not sure!!! Can some one please Help me to understand it!!!! Thank's for your time!!! Carlos MurilloArticle: 74416
Hi Gary, I am working in TooMuch Semiconductor solutions www.toomuchsemi.com. This is a startup (2 months old) and focuses on providing EDA & Verification solutions. We have experianced engineers in Design and Verification. We can help you do this, and we don't expect anything in return. The work doesn't include any risk/responsiblity from our part. We'll do this design and post it in the groups itself. Thanks & Regards, Naren. garyswindell@hotmail.com (G Swindell) wrote in message news:<4ae002c2.0410101308.1ff35942@posting.google.com>... > I need to accomplish the following using the Spartan-3 Starter Kit. > This is a small part of my overall project and I don't have time to do > it. > > Inputs- > > 5V differential quadrature (A+ A- B+ B-) signal > Enable (active high) > Counter Reset (active high) > > Output- > > Trigger Pulse (active low) > > > Specifics- > > I need a trigger pulse that is n clocks wide (n should be changeable > in code- pulse length will need to range between 10us and 500us) > whenever the quadrature counter (24 bit) increments/decrements by x > counts (x should be changeable in code and will range from around 15 > to 200). Quadrature input max speed is 7.8mhz. The trigger pulse > should only be output when the enable signal is active (the counter > can run all the time). > > I am not asking for free help, I just need a complete solution and I > will pay for it ;) > > Thanks, > > GaryArticle: 74417
Hello, I have the problem to discern whether a long line in my VirtexII is used (driven just in this moment). Furthermore against the background of partial reconfiguration I can't use a central arbitration. Each module shall listen and decide whether it can activate it's TBUF or not. Any hints? Bye Tom.Article: 74418
Brad, The design was done using MicroBlaze and the Embedded Development Kit (EDK). The project was built from the MicroBlaze Master System. http://www.xilinx.com/products/spartan3/s3boards.htm There is a VGA controller core in the project and if you look at the source code and the output to the VGA port in the Master System then you should be able to decipher what character maps to what value in the RAM. If you are using the core outside of the EDK environment then you will have to make changes to the source code files as they to use some Libraries only found in the EDK tools. Cheers, Shalin- Brad Smallridge wrote: > Where is the demo software for this wonderful Spartan 3 kit? > > I was most surprised when I plugged in a VGA monitor and saw > all the switches, buttons, and jumper dispalyed in multicolors. > > Does the keyboard input do something as well? > > >Article: 74419
Hello I'm trying to perform some partial reconfiguration experiments using EDK/ISE 6.2 on Virtex2 PRO. My design includes 3 modules, one reconfigurable and 2 fixed. One fixed module includes the PPC and some of the basic peripherals, one of the peripherals is included in the other fixed module the connection between the two is made is made without the TBUFs, but that shouldn't pose a problem according to a recent article from Xilinx. My problem is this, when I reach the assembling stage my final design, when I manage to avoid the recurrent "FATAL_ERROR:Guide:basgitaskphyspr.c:255:1.28.20.2:137" and "FATAL_ERROR:Ncd:basncsignal.c:283:1.39.8.2" errors, always as some unrouted lines that I canīt route even and in the FPGA_EDITOR, the problem seems to come from the fact that in the main module there are always some unguided slices, I tried changing the parameters of ngdbuild and map but I only managed to change the slices that are unguided. My questions are these: As anyone made successful attempts at partial reconfiguration with similar designs, or at least one with PPC and peripherals? Is it essential to get a 100% guided design or is it possible to achieve partial reconfiguration without it? The slices seems to be unguided because their structure changes from the module stage to the assemble stage, registers are missing or change places, any ideas on why this could be happening? Thanks Miguel SilvaArticle: 74420
Symon wrote:
>>Just be aware that the internal termination can be
>>less than ideal.
>
> Care to relate your experiences of the internal termination? I've had no
> trouble at 600Mbit/s data and a 600MHz clock. Some of my colleagues have
> mentioned that they've run into problems, and they've reverted to fitting
> external 100R resistors.
Howdy Symon,
We are using the internal _DT resistors on a V2P7 for receiving a
LVDS clock that is slightly over 600 MHz, as well as the source
synchronous data that goes along with it. It technically works (we
never have bit errors over all operating conditions), but using a
differential probe at the vias immediately below the inputs pins show
that there isn't much margin - the signal quality looks pretty poor.
A more serious problem that we had was with a 600+ MHz GCLK input. What
we believe we discovered was that a nearby GCLK input with a single
ended 3.3V 66 MHz clock was affecting its signal quality enough that
we'd sometimes miss clocks. The 66 MHz clock looked good (no excessive
overshoot or other noise on it). Lowering the frequency to 311 MHz,
with no change to routing, fixed the problem.
Have fun,
Marc
Article: 74421
There is a difference between phase resolution and frequency
resolution. Typically, you'll have a phase accumulator that adds some
fixed increment to itself every clock cycle. The increment value sets
the frequency, which is the frequency of the accumulator wrap-arounds.
The frequency is Fo = Fc*N/(2^k) where Fc is the clock frequency, N is
the increment value (integer) and k is the number of bits in the phase
accumulator. The more bits in the accumulator, the finer the resolution
to which you can set the frequency. The CORDIC width does not affect
the frequency at all, rather it will affect the noise added by the
CORDIC. You have several factors here: number of iterations, width of
I and Q paths and width of phase path.
First, look at the number of iterations. If we assume for the moment
that there is infinite precision in the I and Q data paths as well as in
the phase accumulator path, then each iteration performs a perfect
rotation with no error, but the angle of rotation is fixed at the
elemental angle for that iteration. If you limit the number of
iterations, you limit the total number of possible rotation
angles...that is limiting the number of iterations introduces a phase
error in the rotated output. There is no amplitude error due to
limiting the number of iterations.
Next, lets consider limited precision in the phase accumulators. Again,
we'll assume infinite precision in the I and Q paths. If the phase
accumulator width is limited, we introduce a truncation/rounding error
in the phase for each iteration accomplished. Again, the error is only
in phase angle, not in amplitude.
In both the above cases, the phase error is not cumulative from sample
to sample, so it manifests itself as phase noise. Note this has no
effect on the average frequency, and that there is no amplitude noise.
Finally, in the case of limited precision I and Q, the rotations are no
longer perfect, as there is a rounding or truncation error on sum at
each iteration. The result is the rotated vector is forced to fall on a
retangular grid, which introduces both angular and magnitude errors.
Again, there is no effect on the average phase or amplitude, but the
instantaneous values will have some error bounded by the resolution of
the IQ grid defined by the I and Q resolution. The extra LSBs, which
you are calling guard bits are there to make the I and Q truncation
error smaller with respect to the signal, and therefore reduce this
noise source.
I hope this helps explain it.
Carlos Murillo wrote:
> Hello everybody!!
>
> Maybe some CORDIC guru's can help me???
>
> I've seen a lot of papers, designs and cores and I still don't
> understand
> why always everybody offers (for example) a Frequency Resolution of
> 32bit when at the input of CORDIC's block the angle just have
> 16bits+guard bits(log2(16)) = 20 bits. That's not a 32 bits
> resolution!!!! The phase offset is 16 bits, That's OK but 32 bits
> frequency resolution!!!! I think maybe it's all about the guard bits
> but I'm not sure!!! Can some one please Help me to understand it!!!!
> Thank's for your time!!!
>
> Carlos Murillo
--
--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: 74422Article: 74423
John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<ckd6rb$c62$1@bunyip.cc.uq.edu.au>...
> Hi Peter
> >
> > 1) hook up both PPC to the same PLB together with the PLB SDRAM controller
> > 2) write seperate linker scripts for each of the two processors. The
> > first processor uses the memory in [0,64[ and the second one uses [64,128[.
>
> Nice solution - what will the caches do in this configuration?
> Duplicate / thrash? Get incoherent?
>
> John
John, Peter, Thanks both for reply.
Caches will be fine for the application I have in mind, since each PPC will
run different application without share any common data structures.
Worst case, I can use volatile with the data structures access and also
design the code/structure that one always read, the other always write.
> Interesting questions, with no easy answers. If you make your custom
> processing logic bus master capable, then in principle you could use DMA
> to handle all of this. You need to be careful that you don't end up in
> a bus-bound mess, losing any performance gains that might otherwise be
> achieved with the hardware offloading in the first place!
>
> It depends on the nature of what you are trying to do - if it is heavy
> on the computation, and light on the communication, then it's not so
> bad. However, if the opposite is true, you will end up saturating the bus.
>
For an application that needs to process 1-2 millions packets per seconds,
process =
* look at the headers and some data structures and make forwarding
decision,
* append packets descriptor to various Qs.
* A TX engine, check all Qs and tx them out to RIO base on time and
QOS setting, update counter values in the DDR.
The packets is already stored in a different DDR. This process only need to
controls the DMA descriptors of the packets at the rate of 1-2 millions per second.
Thanks again for both of your comments.
-Tony
Article: 74424I don't work for Atmel. I am interested in knowing how they did it. (I am using Xilinx at this time - a few very expensive one.) Since it is from a fpga company, I wonder if it use one of those FPGA 2 ASIC conversion process to get such low cost price pointer for such complex chip. I wonder if has anyone done similar complex SOC chip with xilinx/altera? .... The AT76C120 device supports high performance still-image and video decoding of media files encoded according to JPEG, MPEG4, MPEG1, Motion JPEG standards .... The AT76C120 is compatible with its predecessors, and is an integrated ARM7TDMI processor that controls the entire application and manages file-system, decoding and display functions. All necessary peripherals, including TV video output, USB, UART and SPI, and digital audio interfaces, have been integrated on the chip .... http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=109&STORY=/www/story/10-04-2004/0002264661&EDATE= http://www.atmel.com/dyn/resources/prod_documents/5676s.pdf -Tony
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