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
Thanks for the info. I'll stick with external ADC/DAC's. Jamie Morken "Jim Granville" <jim.granville@designtools.co.nz> wrote in message news:3D9AA226.2D08@designtools.co.nz... > Jamie Morken wrote: > > > > Hi, > > > > > I haven't seen any 12-bit Sigma-Delta ADCs faster than 3 MSPS, but perhaps > > > some exist. > > > > Is there another type of ADC that could be implemented in an FPGA other than > > sigma-delta > > that would be faster (say 20MSPS) and still have 12 bits resolution? > > > > cheers, > > Jamie Morken > > Sigma-Delta ADC's are fundamentally bit-serial integrators. > Being integrators, they are extremely component-spread tolerant. > > You can use maths summation filters to effectively oversample, > and so increase the apparent sample rate, but there is no free > lunch - you loose step response, and so find that values > depend on those that came before. > > To get 12 bits with a Bit-serial integrator, at 20MSPS, gives > a virtual clock of 20 x 4096, or 81GHz (!). > Also, consider jitter of 100ps -> one part in 500, or appx 9 bits, > so you need 10ps region for 12 bits. > > Other ADC topologies are Successive approximation, and FLASH. > Both use high performance comparitor(s), and increasing component > precision, to give better numbers at lower clock rates. > > FPGAs have no precision analog numbers, so you will need external > analog blocks to achieve 20Msps > > There may be scope for using some simple analog precision > ( eg 1% resistors, multiple outputs ) to simplify SD-ADCs, > ( just as they can simplify DACs ), but I have not seen > info on this. > > viz For a DAC, you can use two 6 bit DACS, and a 64:1 summing junction > ( two good tolerance resistors ), to give 12 bit DAC, but with 6 bit > clock rates. > DPLLs in FPGAs could give interesting scope for finer time-definition. > > -jgArticle: 47726
less than 1MHz. DS ADCs work by oversampling and noise shaping to get the
quantization noise out of the band of interest. At 20 MS/sec and 12 bits,
I'm afraid that you are stuck with using an external ADC and DAC.
Jamie Morken wrote:
> Hi,
>
> I would like to implement a high speed 12 bit ADC and a high speed 12 bit
> DAC
> using the 200Kgate Spartan IIE device.
>
> Here are the Xilinx appnotes:
> Virtex Synthesizable Delta-Sigma DAC
> http://www.xilinx.com/xapp/xapp154.pdf
>
> Virtex Analog to Digital Converter
> http://www.xilinx.com/xapp/xapp155.pdf
>
> What would the maximum sampling rate be for the ADC and the DAC using the
> maximum clock speed for the FPGA?
> Is there any chance of the sampling rate being 40MSPS at 12 bits?
>
> cheers,
> Jamie Morken
--
--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: 47727Hi I would be grateful if anywone could tell me if they have used Nallatech's BenNUEY ... We are planning to procure a development board and would like to have some foreknowledge about the different boards. Also, it would be nice if someone could tell us the approx cost of such a board. We are essentially planning to buy a board based on Virtex II and which will aloow us to do DMA. Thanks in advance KolinArticle: 47728
That rule of thumb dates back a ways. It was/is due to the structure of
the carry chains and tristate busses which run vertically and horizontally
respectively. The result is that the architecture favors dataflow from
side to side, and since controls are generally orthagonal to the data
flow, the controls should be vertical. In newer xilinx devices, the
tristate busses are less abundant and fill a much smaller role.
Additionally, the routing resources are more plentiful so getting a signal
to route to an I/O is not as critical. So, while the rule of thumb is
still a little bit applicable, it is by no means as important as it once
was.
Now for Altera. The 10 and 20K families have carry chains that run within
a row. TIming within a row is pretty fast (there is a penalty for
crossing row boundaries). The result is that data flow favors an up-down
direction and control favors a horizontal orientation. Stratix has a
different structure. In that case the carry chains are vertical and the
penalties are gone. Because of the carry chains and the DSP block
connections, the preferred data flow is horizontal.
Itsaso Zuazua wrote:
> Hi,
>
> I have heard that, as a general rule on Xilinx chips, data busses
> should be
> placed on the sides of the chip and control signals should be placed
> on the
> top and bottom. This has something to do with routing resources being
> used
> more efficiently and itīs closely relationated with the internal
> architecture of the FPGA. Is this rule valid also for Alteraīs FPGAs?
>
> Thanks a lot,
>
> Regards,
>
> Itsaso.
--
--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: 47729geeko wrote: > What are the chances of implementing a TCP/IP stack using VHDL anybody do > anything similar.Can the Spartan FPGA be used to hold the design > > See this link .... http://www.xilinx.com/xilinxonline/MMT_html/cs_005.htmArticle: 47730
geeko wrote:
> What are the chances of implementing a TCP/IP stack using VHDL anybody do
> anything similar.Can the Spartan FPGA be used to hold the design
>
>
I picked this up at
http://www.fpgacpu.org/log/apr02.html
Hope it helps
FPGA TCP
On the fpga-cpu list, Anand Gopal Shirahatti asks:
"... What I was wondering is, are there are Implementations of the
TCP/IP Implementation over a Single FPGA, for mutilple connections. ..."
The simplest thing to do is run a software TCP/IP stack on a soft CPU
core. For example, at ESC I saw TCP/IP running on uCLinux on Altera Nios
with a CS8900A ethernet MAC.
Note that a compact FPGA CPU core with integral DMA (e.g. xr16) may be
hybridized into the data shovel aspect of an ethernet MAC. (Flexibly
shovel the incoming bits to/from buffers, etc.) Indeed, one enhanced
FPGA CPU might (time multiplexed or otherwise) manage several physical
links.
You can also build hardware implementations of the TCP/IP protocol
itself. There are several such implementations in custom VLSI. For FPGA
approaches, see:
* Smith et al's XCoNet.
* BlueArc SiliconServer white paper.
"The SiliconServer runs all normal TCP/IP functionality in state
machine logic with a few exceptions that are currently dealt with by
software running on the systems attached processor (e.g. ICMP traffic,
fragmented traffic reassembly)."
And related things: FPXKSM
Article: 47731>Additionally, the routing resources are more plentiful so getting a signal >to route to an I/O is not as critical. So, while the rule of thumb is >still a little bit applicable, it is by no means as important as it once >was. What's the speed/time penalty for good vs reasonable vs horrible IOB placements relative to where they get generated/used? In the old old days, that used to be one of the reasonably common critical paths. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47732
Hi folks: (Please skim down to "Question:" if you don't want to read the details...) In our engine labs we have a "magic box" which is a chassis with a panel covered with BNCs, connected to the inputs and outputs of a variety of basic logic gates (AND, OR, etc). This magic box is used to implement various glue logic functions for our research engine control, experimental apparatus, and data acquisition control schemes. There are two problems with the existing magic boxes: 1. They have terrible crosstalk problems, since they were done with wire wrapping and not much thought to the existance of such things as mutual inductance and capacitance. 2. The scientists tend to use up a lot of one type of gate, leaving the others unused. Then they come to me and say "I ran out of AND gates" or "I need a 6-input OR gate, can you modify the magic box?" They also come to me periodically asking for me to implement various logical gizmos of somewhat greater complexity than the magic box can handle, requiring the design of custom hardware. Rather than get my name associated with the poorly functioning device after performing mods, and rather than waste my time futzing with the wiring of the thing to add more gates only to have to make another hardware change in a few more months, I decided to get modern: I plan to build a universal magic box with a Xilinx Coolrunner XPLA3 XCR3128XL-VQ100 CPLD device. This seemed like a good way to start learning the ropes with PLDs, which I've been eager to do for some time. My box will have nice ESD protection networks on each of an array of 32 BNC connectors. Each connector can be changed from a Schmitt trigger input buffer, or to a 50R back terminated 3x paralleled 74ACTQ14 output buffer, by switching a little DPDT switch (on the inside of the chassis). A bi-color LED will go with each connector, and will glow red for outputs active, and green for inputs active. Most of the space on the new magic box PCB, which will fit directly into the panel so I don't have to run any wires from the connectors to anywhere, is consumed by the IO buffering, switches, and LEDs. So I plan to fit the CPLD on a little daughterboard that will plug into the main board, kind of like a giant DIP package. The CPLD daughterboard will have available 40 IOs, the 4 global clock inputs, the JTAG signals, and will have an on-board 3.3V regulator. Everything is pretty well thought out so far, I think. The only problem is, the CPLD has 84 IOs available, of which I plan to use up to 40. 32 IOs will be connected to the user BNCs for certain, and I will have a little header on the main PCB for expansion to another 8 user IOs if needed in the future, as well as a header for access to the global clocks, which will also be jumper selectable to connect to four of the BNCs, if desired. Enough bells and whistles? ;-) I hope the CPLD will allow me to reconfigure the logic available to the user on the fly, and even to implement those "more complicated than just a few gates" functions that get asked for now and then, without having to build a new physical circuit prototype breadboard and PCB. Question: How should I map the user IOs to the CPLD IOs, ie. function blocks and macrocells, so as to result in the greatest likelyhood of always being able to route whatever functions I want, to the pins I choose? There seem to be two possible approaches: 1. Take a few IOs from each function block, so that all function blocks are ultimately represented to the outside (example: take 5 random macrocells from each of the 8 function blocks, for 40 IOs). Or 2. Use all the macrocells of the first few function blocks until my 40 IOs are mapped out, then leave the rest of the function blocks available for internal-only routing (example, take all 16 macrocells from the first 2 function blocks, plus 8 macrocells from the 3rd function block, leaving 5.5 function blocks not connected to the outside). Any suggestions? Is this a wierd problem? Thanks for comments! Good day. -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 47733
Hi Ulises Hernandez,
In fact,I truely use a test design
to configure my device.Here is my test code:
module test_Counter16(clk,rst,cout);
input clk,rst;
output [3:0] cout;
reg [3:0] cout;
always @(posedge clk or negedge rst)
begin
if(!rst)
cout<=4'b0000;
else
cout<=cout+1;
end
endmodule
As for the startup section of configuraton option for ISE,I do use the default just as you mentioned.
I have tested all the pins of my test design.clk pin is 20MHz,rst pin is 3.3v(Virtex-E device),all the output pins,that are cout[3:0],are low voltage 0.
As for the systhesis level,I truly get 4 FD type FFs.
Every thing seems ok,but it just won't work.:o(
Article: 47734>i want to implement a moving average filter in my FPGA. That's not the >big problem, but the window size of the filter should be changeable >during runtime... This isn't what you asked for, but it might be good enough. You can get a weighted-average without any memory if you can multiply. The recent samples get more weight and the weight of older samples decays exponentialy. Formula is: new-avg = old-avg*(1-w) + sample*w Where w is less than 1. Values of w like 1/8 are typically used in networking code to "average" out round trip time measurements. If you pick w to be a power of 2 then the multiply is just a shift. General barrel-shifters are ugly, but it might be OK if you only want to use a few values of w. Or you could use a real multipler and then use any value of w that you want. Note there are no glitches when changing w between samples. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47735
I've found the Altera SignalTap solution helpfull when I needed to probe internal FPGA nodes. lee "Djohn" <deepucjohn@yahoo.com> wrote in message news:<anbej7$cg0fi$1@ID-159866.news.dfncis.de>... > Hi all, > I am now designing a Uart chip for study purposes. Now I am almost over > with my design and VHDL Coding . I would like to integrate the DFT strategy > in the chip . > > 1)what are the different methods by which i can implement "Design for Test " > strategy in my chip. > > 2) I have a fair good knowledge of JTAG . So If I integrate a JTAG circuitry > in the chip (the tap controller , data registers and instruction > registers), will it become DFT compatible? > > 3) What exactly is BIST ? How is it implemented ? Any online tutorials or > good links ... > > 4) What is ATPG ? how is it implemented? Any online tutorials ....... > > 5)Any other DFT strategies other than these.???? > > 6) A comparison between these strategies? any links also welcome > > thanks > DjohnArticle: 47736
[snip description of magic-box gizmo] Sounds like a fun project. I'd suggest that you look at your current collection of circuits your users are using and try implementing them with various proposed IO connections/mappings. How are you going to program the CPLD? Perhaps another small connector on your daughter card so you can plug in a PC/laptop. Are you expecting to do a lot of programming on the fly, or mostly use a handful or normal/popular boxes? How are you going to test things? Are you going to program them all or will you setup a system so your users can program their own boxes? Are you going to leave enough room on the front to attach a drawing of the circuit diagram? Maybe the drawing should slip over the BNC connectors so it's really obvious which gate is connected to which connector. Are the in/out LEDs really necessary of you have a good drawing? How many are you going to make? Would it be simpler/cheaper to dump the LEDs, switches, and unused IO gear and always put the output connectors on the top (or someplace distinctive)? If you have more IO pins than connectors, can you parallel several of them and get rid of your 74ACTQ14 output buffer chips? (Might be ugly to program.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47737
christopher.saunter@durham.ac.uk (Christopher Saunter) wrote in message news:<anehm3$i4b$1@sirius.dur.ac.uk>... > Peter Alfke (peter@xilinx.com) wrote: > > Peter, > Thanks for adding another meaning to my understanding of the word > 'Fast' - it seems the more meanings a word gets, the more meaningless it > becomes ;-) > > > --- > > cds > > : There are two aspects to "fast": > : data throughput, and speed of change on the select input. > : I can build a 128-input 200 MHz mux in just four or five CLBs, but it > : might take many microseconds to change it, using partial reconfiguration. > : Might not be useful in all cases, but is good for some... > > : Peter Alfke, Xilinx Applications > : ========================================= > : Christopher Saunter wrote: > > : > I'd have though a better question would be: > : > Any way to implement a fast 128 to 1 multiplexer for a ______ > : > device. > : > > : > Also a definition of fast - data rate or latency? Can you pipeline the > : > mux over several stages? Are you building it out of transistors or > : > LUTs/FFs etc. > : > > : > --- > : > > : > cds > : > > : > Moky (plmok@ee.cityu.edu.hk) wrote: > : > : Dear All, > > : > : Any way to implement a fast 128 to 1 multiplexer with VHDL? > > : > : Moky Hi, Is it possible to build a 64:1 Multiplexer in virtex-2 -4 device for 200 Mhz. Note: Inputs are changing at 200MHz. and the output should not be pipelined... So, it is possible to have a 5ns delay for 64:1 multiplexer. Best regards, MuthuArticle: 47738
"Austin Franklin" <austin@da98rkroom.com> writes: > "Ray Andraka" <ray@andraka.com> wrote in message > news:3D9A76DD.453A4B46@andraka.com... > > > > > > Brett Cline wrote: > > > > > Hi All- > > > > > > Synthesis from a C/C++ algorithm is absolutely possible and has been > in > > > use for some time. Even "plain vanilla C" algorithms can be used with > the > > > right synthesis product. > > > > Show me. > > Yeah, and show me too. I've yet to see any benchmarks that show any where > near usable performance and size. From my experience, you are better off > re-writing it in an HDL, then trying to fight with these tools in both the > size and speed arena. Celoxica have some fairly impressive demos. In particular, the ray-tracing one I saw (can't find a reference for it though). The MP3 decoder which "...took a two man team less than eight weeks to produce a working silicon prototype, including implementing a CD-ROM controller to allow management of the input data stream." http://www.celoxica.com/products/technical_papers/case_studies/cs_001.htm And that included converting the algorithm from floating point to fixed point. I don't know much about MP3, or how representative of 'average engineers' the team that did it is, but that sounds reasonably quick. Anyone else care to comment? Yes, the device may be bigger than required, but if the development time is reduced by an order of magnitude, surely that's a gain, in some circumstances? Especially in the research realm, where some problems may be intractable because a) software isn't fast enough, b) the HW solution will take too long to design the traditional way. Agreed, you are never going to get as good results as a hand optimised, laid-out device, but wasn't the argument against C compilers by the assembler programmers similar many years ago. And against java... <snip> > > > > But at what price? Is the performance and density reasonably > close to a what a skilled hardware designer can accomplish? > > Of course not, Ray, you know better than to ask that question ;-) > And indeed it will be a long time before high-end designs can avoid getting *that* close to the hardware. Still, I imagine in 20 years time, the Ray's of this world will be pushing the then current methodoligies to the limits of performance anyway - there'll always be a demand for clever HW designers! Just MHO! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 47739
Hi Cisa,
All seems okey, but I suggest three things you could do, one change at a
time:
1) Keep the process you already have and add a second process, but this
time COMBINATIONAL only, just invert the reset line internally or invert an
input, for example an input controlled for a jumper (new_probe <= not
jumper_0; --VHDL)
This will tell you if your image has been really downloaded to the FPGA and
also that your FFs are held on RESET.
2) Change your RST# level to active HIGH, I have always used active high
resets in Virtex E designs and works.
always @(posedge clk or posedge rst)
if (rst)
cout ....
else ...
3) Use the ROC component and forget about your external reset. You can
instantiate it in your code, in VHDL is as follows:
component ROC
port (
O : out std_logic);
end component;
signal reset : std_logic; -- initial reset
begin
g1 : ROC port map (O => reset);
rega : process (clock_a, reset) is
begin
if (reset = '1') then
q <= (others => '0');
elsif rising_edge(clock_a) then
q <= d;
end if;
This should be enough to get it working. I WOULD TRY step 2 first, it should
be the easiest change.
Good luck.
Regards
Ulises Hernandez
Design Enginner
ECS Technology Ltd.
www.ecs-tech.com
"Cisa" <jjyy@hotmail.com> wrote in message news:ee794a2.3@WebX.sUN8CHnE...
> Hi Ulises Hernandez,
>
> In fact,I truely use a test design
> to configure my device.Here is my test code:
> module test_Counter16(clk,rst,cout);
> input clk,rst;
> output [3:0] cout;
> reg [3:0] cout;
>
> always @(posedge clk or negedge rst)
> begin
> if(!rst)
> cout<=4'b0000;
> else
> cout<=cout+1;
> end
> endmodule
>
> As for the startup section of configuraton option for ISE,I do use the
default just as you mentioned.
>
> I have tested all the pins of my test design.clk pin is 20MHz,rst pin is
3.3v(Virtex-E device),all the output pins,that are cout[3:0],are low voltage
0.
>
> As for the systhesis level,I truly get 4 FD type FFs.
>
> Every thing seems ok,but it just won't work.:o(
>
Article: 47740Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:<qh8z1hsb85.fsf@ruckus.brouhaha.com>... > russelmann@hotmail.com (Rudolf Usselmann) writes: > > The USB 2.0 core is currently being tested by another customer of > > mine with an Spartan 2e ... > > How many LUTs does the USB 2.0 core require? It depends on the configuration of the core. But to give you a basic idea: USB 2.0 with 4 endpoints: part: xc2s200e pq208-6 Total LUTs: 2837 (60%) clk_i 107.2 MHz phy_clk_pad_i 67.3 MHz (required 60MHz) USB 1.1 (including usb 1.1 PHY, with 8 endpoints but no endpoint FIFOs): part: xc2s200e ft256-6 Total LUTs: 876 (18%) clk_i 4.2 MHz (required 48MHz) Hope this helps ! Best regards, rudi ---------------------------------------------- www.asics.ws - Solutions for your ASIC needs -Article: 47741
"Christopher R. Carlen" wrote: > > > How should I map the user IOs to the CPLD IOs, ie. function blocks and > macrocells, so as to result in the greatest likelyhood of always being > able to route whatever functions I want, to the pins I choose? > With such a low proportion of IOs to cells, you will probably have no problem at all whichever way you do it. The Coolrunner architecture seems to route better than the Lattice CPLDs, and the Lattice ones have let me route most things however I like for some years now. Suggestion: Tell the eggheads you have put in 128 cells, but use a 256 cell CPLD in the actual box. Paul BurkeArticle: 47742
Martin Thompson wrote: > Celoxica have some fairly impressive demos. In particular, the > ray-tracing one I saw (can't find a reference for it though). > Yes, the device may be bigger than required, but if the development > time is reduced by an order of magnitude, surely that's a gain, in > some circumstances? Especially in the research realm, where some > problems may be intractable because a) software isn't fast enough, b) > the HW solution will take too long to design the traditional way. Good point, but AFAIK Celoxica's solution is occam, with a C syntax. Occam is a reasonable solution to the problem. It is probably not too difficult to fiddle with the VHDL syntax to make it more C-like, but you would not be moving the problem forwards. Parallel programming, as in hardware design, is much harder than sequential programming. It is a little optimistic to hope that we will be able to write a parallel program by 1. writing a sequential equivalent 2. summoning up a magic parallelizer Though you can certainly use your parallel hardware as sequentially as your budget can stand, and you can obviously use any sequential language to express the core dataflow graph (I think I mean dataflow :-)) /TimArticle: 47743
Hi , anyone have good links for BIST and ATPG . thanksArticle: 47744
Hi all, Can some one give me an introduction to low power SoC design . What is difference from an ordinary design and low power design in the design stage . Suppose I am designing a fsm based sequential logic , at which stage the "LOW POWER " Comes in . thanks skillieArticle: 47745
I agree that the C to hardware things have their place. If nothing else, it
lowers the bar for entry into FPGAs. What is missing is the necessary caveat
explaining that there is a lot of performance/density left on the table...and
that is much more than is commonly touted. I think an order of magnitude
wouldn't be far wrong as an average.
Martin Thompson wrote:
> "Austin Franklin" <austin@da98rkroom.com> writes:
>
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3D9A76DD.453A4B46@andraka.com...
> > >
> > >
> > > Brett Cline wrote:
> > >
> > > > Hi All-
> > > >
> > > > Synthesis from a C/C++ algorithm is absolutely possible and has been
> > in
> > > > use for some time. Even "plain vanilla C" algorithms can be used with
> > the
> > > > right synthesis product.
> > >
> > > Show me.
> >
> > Yeah, and show me too. I've yet to see any benchmarks that show any where
> > near usable performance and size. From my experience, you are better off
> > re-writing it in an HDL, then trying to fight with these tools in both the
> > size and speed arena.
>
> Celoxica have some fairly impressive demos. In particular, the
> ray-tracing one I saw (can't find a reference for it though). The MP3
> decoder which "...took a two man team less than eight weeks to produce
> a working silicon prototype, including implementing a CD-ROM
> controller to allow management of the input data stream."
> http://www.celoxica.com/products/technical_papers/case_studies/cs_001.htm
>
> And that included converting the algorithm from floating point to
> fixed point. I don't know much about MP3, or how representative of
> 'average engineers' the team that did it is, but that sounds
> reasonably quick. Anyone else care to comment?
>
> Yes, the device may be bigger than required, but if the development
> time is reduced by an order of magnitude, surely that's a gain, in
> some circumstances? Especially in the research realm, where some
> problems may be intractable because a) software isn't fast enough, b)
> the HW solution will take too long to design the traditional way.
> Agreed, you are never going to get as good results as a hand
> optimised, laid-out device, but wasn't the argument against C
> compilers by the assembler programmers similar many years ago. And
> against java...
>
> <snip>
> > >
> > > But at what price? Is the performance and density reasonably
> > close to a what a skilled hardware designer can accomplish?
> >
> > Of course not, Ray, you know better than to ask that question ;-)
> >
>
> And indeed it will be a long time before high-end designs can avoid
> getting *that* close to the hardware. Still, I imagine in 20 years
> time, the Ray's of this world will be pushing the then current
> methodoligies to the limits of performance anyway - there'll always be
> a demand for clever HW designers!
>
> Just MHO!
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt, Solihull, UK
> http://www.trw.com/conekt
--
--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: 47746
WIth careful design and floorplanning, in a -6 part it should be, but you also need to consider the timing in and
out of it. Don't count on the automatic place and route to get a minimal delay solution: you may find you need to
do some hand routing on this. I suggest you try it out with a one or 2 bit version first and see if you can make
your requirements.
Muthu wrote:
> christopher.saunter@durham.ac.uk (Christopher Saunter) wrote in message news:<anehm3$i4b$1@sirius.dur.ac.uk>...
> > Peter Alfke (peter@xilinx.com) wrote:
> >
> > Peter,
> > Thanks for adding another meaning to my understanding of the word
> > 'Fast' - it seems the more meanings a word gets, the more meaningless it
> > becomes ;-)
> >
> >
> > ---
> >
> > cds
> >
> > : There are two aspects to "fast":
> > : data throughput, and speed of change on the select input.
> > : I can build a 128-input 200 MHz mux in just four or five CLBs, but it
> > : might take many microseconds to change it, using partial reconfiguration.
> > : Might not be useful in all cases, but is good for some...
> >
> > : Peter Alfke, Xilinx Applications
> > : =========================================
> > : Christopher Saunter wrote:
> >
> > : > I'd have though a better question would be:
> > : > Any way to implement a fast 128 to 1 multiplexer for a ______
> > : > device.
> > : >
> > : > Also a definition of fast - data rate or latency? Can you pipeline the
> > : > mux over several stages? Are you building it out of transistors or
> > : > LUTs/FFs etc.
> > : >
> > : > ---
> > : >
> > : > cds
> > : >
> > : > Moky (plmok@ee.cityu.edu.hk) wrote:
> > : > : Dear All,
> >
> > : > : Any way to implement a fast 128 to 1 multiplexer with VHDL?
> >
> > : > : Moky
>
> Hi,
>
> Is it possible to build a 64:1 Multiplexer in virtex-2 -4 device for 200 Mhz.
>
> Note: Inputs are changing at 200MHz. and the output should not be pipelined...
>
> So, it is possible to have a 5ns delay for 64:1 multiplexer.
>
> Best regards,
> Muthu
--
--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: 47747
Hi,
There are a lot of things to consider in a low power design.
- Your core voltage (1.5V is a good figure)
- Packaging aspects (lower die tempearature, 'the hotter it runs, the
quicker it fails' :o)
- Metal Layers (passive silicon no longer dissipates/sink heat in these days
because there is no passive stuff)
- ...
- RTL code
For me the interesting bit is the RTL coding, for a FSM as you said, you can
use one-hot encoding because only one-bit will change every clock (reduces
clock activity which is a killer in power consumption). If you change from
state A to state B more often than to state C try state A and B encoded with
low toggle rate ("most likely branch encoding"). Disabling your clock in
your IDLE state could be interesting (if you have the capability to do it)
and enable it with the scape condition.
There are a whole bunch of things you could do.
This Xilinx paper is quite interesting
http://www.xilinx.com/xcell/xl38/xcell38_40.pdf
Google also helps.
Regards
Ulises Hernandez
Design Enginner
ECS Technology Ltd.
www.ecs-tech.com
"skillwood" <skillwood@hotmail.com> wrote in message
news:anhas6$e4ro0$1@ID-159866.news.dfncis.de...
> Hi all,
> Can some one give me an introduction to low power SoC design . What is
> difference from an ordinary design and low power design in the design
stage
> . Suppose I am designing a fsm based sequential logic , at which stage
the
> "LOW POWER " Comes in .
>
> thanks
> skillie
>
>
Article: 47748With CoCentric SystemCompiler I generate a rtl synthetizable vhdl file for fpag_shell. (target Virtex) Xilinx Designware components such as xdw_incdec, xdw_comp_uns are instanced. I get this message : XDW_INCDEC is not declared. (VSS-575) (FPGA-hci-hdlc-unknown) when analyzing this file with f fc2_shell. In fact there is no component declaration and no xdw library declaration and use clause in the generated vhdl file ; Unfortunately the source of the XDW vhdl files in $XILINX/synopsys/libraries/dw/src/virtex are not readable (encrypted ?) : xdw_incdec.vhd.e So I cannot extract the right component declaration to insert in the vhdl code. Can anyone help me ? CharlesArticle: 47749
Has anyone tried to implement a tone detector based around a goertzel algorithm filter. I am looking for an example in VHDL or schematic form as we are experiencing difficulty in getting the System Generator software working to be able to pull our Matlab/Simulink model into the Spartan-II device we are currently using.
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