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
SynaptiCAD has an evaluation version of their Timing Diagrammer tool. There's information at http://www.syncad.com/ttd_main.htm. You can download from http://www.syncad.com/syn_down.htm. Just FYI, you can find other free or low-cost downloads on The Programmable Logic Jump Station at http://www.optimagic.com/lowcost.shtml. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Anthony Ellis - LogicWorks wrote in message <7jgvnk$28hm$1@nnrp01.ops.uunet.co.za>... >Does anyone know of any free or reasonably cheap tools that can be used >specifically for generating timing diagrams for documentation etc. >It doesn't need to support any database of parts with timing etc. just a >good drafting tool that understands electronic signal diagrams. >Something speedier and faster than using Visio or PowerPoint etc. > >Thanks. > >Article: 16776
Hi All, I want to implement a line delay using off-chip RAM (necessary for Image Convolution). On the FPGA, this is done using Synchronous RAM which has a input data line and an output data one, which makes things easy. The line delay I want to implement is big (800 pixels) and cannot be implemented on the FPGA chip. How could I use the off-chip RAM to do that (One line for both input and output) ?. I hope I'll have a reply soon. Thanks in advance.Article: 16777
Karim LIMAM wrote:
>
> i describe a design with a process with only the CLK and RESET in the
> sensitivity list in the goal to have only one clocked register at end.
> The synthesizer (Synplify) generate naturally a Warning "Incomplete
> sensitivity list" but with the remark "assuming completeness" !!!
>
> What's the meaning of "assuming completeness"? Did the synthesizer generate
> a process with a complete sensivity list ?
It means that the logic you wrote doesn't look like a flipflop.
Synplify will then try to build it with combinatorial logic, but finds
it needs other signals in the sensitivity list. So it will build
logic with whatever sensitivity list your code implies.
This is almost certainly not what you wanted.
You must be VERY specific in the way you use CLK and RST in such
a process, so that the synthesis tool can infer flipflops reliably.
A typical arrangement (for positive edge-triggered clock and active
high reset) would be
...declare flops:
signal MyFlop: std_logic;
process (CLK, RST)
begin
if RST='1' then -- Do the asynchronous reset action
MyFlop <= '0';
elsif rising_edge(CLK) then -- No reset, but rising clock
MyFlop <= [some function of various other signals];
end if;
end process;
This template will NOT generate warnings about incomplete
sensitivity lists, and will build the correct logic, with one
flipflop whose D input is fed by the specified combinatorial
function of the other inputs.
Hope this helps
Jonathan Bromley
Article: 16778
--------------683BCF1577B24EEA193CDB67
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I am selling this book: VHDL for Programmable Logic. The book is
in LIKE NEW condition with no scratches and no mark. Reserve is set
well below what you need to pay for in amazon.com. It includes a
CD-ROM. Stop by and place a bid today.
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=115246540
Artur
6.8.99
--------------683BCF1577B24EEA193CDB67
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p> I am selling this book: VHDL for Programmable
Logic. The book is in LIKE NEW condition with no scratches and no
mark. Reserve is set well below what you need to pay for in amazon.com.
It includes a CD-ROM. Stop by and place a bid today.
<br> <a href="http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=115246540">http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=115246540</a>
<p>Artur
<br>6.8.99
<br> </html>
--------------683BCF1577B24EEA193CDB67--
Article: 16779How about a dual-port RAM? Or maybe a single-port RAM running at twice your clock speed? Either way you can effectively treat it as having both a line in and line out. Hope I've understood the question. Cheers, Jamie khalid wrote in message <7jja26$osl$1@news.qub.ac.uk>... >I want to implement a line delay using off-chip RAM (necessary for Image >Convolution). On the FPGA, this is done using Synchronous RAM which has a >input data line and an output data one, which makes things easy. The line >delay I want to implement is big (800 pixels) and cannot be implemented on >the FPGA chip. How could I use the off-chip RAM to do that (One line for >both input and output) ?.Article: 16780
Allan Herriman wrote: > Hi. > I have a question about the weak pull-up resistors in 3.3V Spartan XL > parts. > > The datasheet only specifies one point on the V-I characteristic, 20 > to 250uA at Vin = 0V. > > 1. I'm interested in knowing whether they pull-up all the way to VCC. Yes > > > 2. I'm also interested in knowing what happens to the V-I > characteristic when the voltage gets above VCC. Does the current drop > to (near) zero? Or is there some significant leakage current? The pull-up "resistor", which of course is a p-channel transistor, is active even for voltages above Vcc. So you should count on a "resistor" to the Vcc terminal of about 50 kilohm. It's not "leakage", but rather a non-linear resistance. > > > The datasheet says that the pull-ups are p-channel fets. It also says > that they are 5V tolerant. XAPP 088 shows that something has been > done to bias the fet well (to avoid the problems due to the parasitic > diode in the fet) but it doesn't give any details of the well bias > circuit. > > Could someone help me please? It's a complicated circuit arrangement, and some of it is proprietary ( we put many man-months into this aspect of the design). What is it you need to know ? By-the-way: I am old fashioned and would just use a curve tracer... Peter Alfke Xilinx Applications > > > Thanks, > Allan.Article: 16781
I agree that Timing Diagrammer is an excellent tool. However, if the original poster was intending to do anything with the downloadable version other than evaluate it, he is going to be disappointed because I believe it doesn't allow printing or saving of your work which are obviously key requirements for a tool like this. In article <7jj9pu$989@sjx-ixn9.ix.netcom.com>, Steven K. Knapp <sknapp@optimagic.com> writes >SynaptiCAD has an evaluation version of their Timing Diagrammer tool. >There's information at http://www.syncad.com/ttd_main.htm. You can download >from http://www.syncad.com/syn_down.htm. > >Just FYI, you can find other free or low-cost downloads on The Programmable >Logic Jump Station at http://www.optimagic.com/lowcost.shtml. > >----------------------------------------------------------- >Steven K. Knapp >OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" >E-mail: sknapp@optimagic.com > Web: http://www.optimagic.com >----------------------------------------------------------- > > > >Anthony Ellis - LogicWorks wrote in message ><7jgvnk$28hm$1@nnrp01.ops.uunet.co.za>... >>Does anyone know of any free or reasonably cheap tools that can be used >>specifically for generating timing diagrams for documentation etc. >>It doesn't need to support any database of parts with timing etc. just a >>good drafting tool that understands electronic signal diagrams. >>Something speedier and faster than using Visio or PowerPoint etc. >> >>Thanks. >> >> > > -- George CooperArticle: 16782
khalid wrote: > Hi All, > > I want to implement a line delay using off-chip RAM (necessary for Image > Convolution). On the FPGA, this is done using Synchronous RAM which has a > input data line and an output data one, which makes things easy. The line > delay I want to implement is big (800 pixels) and cannot be implemented on > the FPGA chip. How could I use the off-chip RAM to do that (One line for > both input and output) ?. > I suggest the Xilinx Virtex family. Each internal dual-ported BlockRAM can be configured 1024 deep and 4-bits wide, and there are from 8 ( for the smallest chip) to 32 ( for the presently largest available chip) such blocks on-chip, and they are very fast, less than 5 ns access time. Peter Alfke Xilinx ApplicationsArticle: 16783
In the past I've used synchronous FIFOs for this type of job. Tie the read and write clocks together, reset the device, (synchronously)enable write, wait N clock cycles, enable read. Voila - an N-stage delay. Many fewer wires than a RAM solution. Try Cypress, T.I., IDT, etc. for synchronous FIFOs. Parts are available with widths to 36 bits, depths to 64K, speeds to 125 MHz. Though I wonder about 800 pixels at 8? bits each - this is only 6400 bits, which would use only 6400/32 = 200 Xilinx CLBs, which doesn't seem like such a huge number of CLBs these days. khalid wrote: > > Hi All, > > I want to implement a line delay using off-chip RAM (necessary for Image > Convolution). On the FPGA, this is done using Synchronous RAM which has a > input data line and an output data one, which makes things easy. The line > delay I want to implement is big (800 pixels) and cannot be implemented on > the FPGA chip. How could I use the off-chip RAM to do that (One line for > both input and output) ?. > > I hope I'll have a reply soon. > > Thanks in advance. -- Tom Burgess Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 16784
Here's my interpretation of material found at http://www.altera.com/html/products/apex.html 1) one eighth of the total I/Os can be LVDS inputs, one eighth outputs. (2.0 data sheet p. 64) 2) The html intro claims LVDS speeds to 622 Megabits/second. Don't know if this implies actual usability at those rates or not. 3) Don't know. By the way, could you tell me anything about the LVDS-output ADCs you are using? regards, Tom. Stephen King wrote: > > Does any one out there have any info on the likely configuration and > performance of the LVDS IO planned for the Altera 20KE. I have had a > look at the 20K data sheet but it contains very little info. > > What I would like to know is: > > 1) the number of LVDS inputs that will be offered. (I am interested in > 8-16;) > > 2) the maximum operating frequency/data rate; (I am interested in 500+ > MHz operation;) > > 3) what sort of demux will be offered on chip to reduce the data rate to > acceptable FPGA rates, (i.e. approx. 100 MHz.). > > My interest stems from attempting to hook high speed ADCs to FPGAs > rather than a line communications application! > > Regards > > Steve -- Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 16785
The Story So Far: I had trouble installing the Synplify tool that came free with Actel Desktop: it complained that I had been tampering with my PC's date. LAUREL WREATH FOR SYNPLICITY: ***************************** First time I e-mailed their support desk they referred me back to Actel, which was fair enough since it is Actel's s/w kit but didn't help me because it was a Synplicity problem. Second time I asked (just ever so slightly more forcefully) I got a reply within 24 hours providing a fix. Evidently this is something that causes them trouble from time to time, but they have an easy fix, and no, I'm not intending to publish it because I suspect it could be abused. Congratulations Actel for giving away IMHO the best free tools in the FPGA industry, and congratulations Synplicity for supporting s/w that they didn't make a pile of money selling. And thanks to Rich Katz for sharing experience with me so promptly. Jonathan BromleyArticle: 16786
Carlhermann Schlehaus wrote: [...] > That's right, but when I asked my local distributor, I got a horrendous > price. It was nearly five times higher than the EPC1 :-( use ATMEL AT17CxxxA EEPROM for your prototype JAArticle: 16787
Ray, I double checked and you're absolutely right. I guess I rushed to the keyboard too soon. :) Sorry about that... -Hobson Ray Andraka wrote: > Hmm, That doesn't agree with my experience. If you look at the EDIF output from the > coregen you will see the INIT= attributes in the EDIF file, assuming that you provided > a .COE file as input to the coregen. To see this, run the COREGEN on an example RAM > using a .coe file, then open the edif output file with a text editor such as wordpad, > and do a search on "INIT". > > Hobson Frater wrote: > > > Tom and Ray, > > > > The EDIF file coming out of Coregen just contains the design itself (no initial > > values or the initial values are set to zero). That's why the COE file exists. > > When you run through NGDBUILD (Translate), all of your EDIF files get merged > > together. NGDBUILD also pulls in other files like the COE file. There is no need > > to specify this file in a UCF or NCF file. It gets pulled in if it's present in > > the design directory. After NGDBUILD, you have an NGD file, so run NGD2EDIF, > > NGD2VHDL, or NGD2VER to get the appropriate structural netlist that you need for > > functional simulation. This netlist should have all of the initial values for > > your memories b/c all of your input design files have been merged. Hope this > > helps... > > > > Regards, > > Hobson Frater > > Xilinx Applications > > > > Tom McLaughlin wrote: > > > > > Ray, > > > Thanks for the help. I did find the INIT property in the edif file, but they > > > were all set to zero! I have a .coe file with initial values and Coregen > > > generated the .mif file for simulation with the correct initial values, but > > > they are not in the edif file generated at the same time. Any suggestions??? > > > By the way, I am generating a single port RAM for Virtex using Coregen v1.5.2. > > > Any help would be appreciated. > > > > > > Regards, > > > Tom > > > > > > Ray Andraka wrote: > > > > > > > The initial values do indeed get passed through the edif file using the INIT > > > > property. If the initial values are all zero for a particular LUT, then the > > > > INIT property is not placed on that LUT. If it is missing, then the default > > > > of all zeros is used. You can see the initial values if you generate a RAM > > > > component using a COE initial values file. After generating it, go into the > > > > edif file with a text editor and do a search on the string "INIT". You will > > > > find lines similar to " (property INIT (string "0f03c0f0"))" which > > > > correspond to the initial values in the COE file. > > > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randrakaArticle: 16788
Hi All, Here are some more information: I am targetting XC4k series, and I want to use an available off-chip DRAM to implement line delays. The FPGA chip is 24x24 CLBs only, so implementing the line delays on chip is impossible ( I need 2 of them for a 3x3 filter, four for a 5x5, N-1 for an NxN filter). I thought about doubling the frequency of read/write to work around the fact that there is only one line for data (input/output). So, in one pixel clock cycle, I read from the memory first, then I write to the memory. By addressing the DRAM with a Counter whose period is the image row (or column) number, I get a one line delay. First of all is that a right way? secondly, if yes, how can I use the same DRAM to implement another line delay (necessay for a 3x3 filter)? (multiply the frequency again?) Thanks in advance. khalid wrote in message <7jja26$osl$1@news.qub.ac.uk>... >Hi All, > >I want to implement a line delay using off-chip RAM (necessary for Image >Convolution). On the FPGA, this is done using Synchronous RAM which has a >input data line and an output data one, which makes things easy. The line >delay I want to implement is big (800 pixels) and cannot be implemented on >the FPGA chip. How could I use the off-chip RAM to do that (One line for >both input and output) ?. > > >I hope I'll have a reply soon. > > >Thanks in advance. > >Article: 16789
I am looking for LVDS ADCs at 250MHz any width (as long as >= 6 :-). Any ideas ? Stephen King <sking@crl.co.uk> wrote: >Does any one out there have any info on the likely configuration and >performance of the LVDS IO planned for the Altera 20KE. I have had a >look at the 20K data sheet but it contains very little info. > >What I would like to know is: > >1) the number of LVDS inputs that will be offered. (I am interested in >8-16;) > >2) the maximum operating frequency/data rate; (I am interested in 500+ >MHz operation;) > >3) what sort of demux will be offered on chip to reduce the data rate to >acceptable FPGA rates, (i.e. approx. 100 MHz.). > >My interest stems from attempting to hook high speed ADCs to FPGAs >rather than a line communications application! > >Regards > >Steve muzo Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)Article: 16790
Philip Freidin <fliptron@netcom.com> wrote:
: On topic Flame Bait thread initiator:
;-)
: In article <928349344.434604@BITS.bris.ac.uk> tt@cryogen.com writes:
[X6200]
: On the other hand, it suffered in its own way from the same problems of
: all the fine grain architectures (anything from Pilkington (Plessy,
: Toshiba, Motorola), Concurrent/CLay/Atmel/IBM, Crosspoint Solutions)
: which is that they end up burning significant amount of the available
: interconnect just building up basic macro functions, like an add with
: carry, or a 4 to 1 mux, or even something real basic like an 8 input AND
: gate.
As I understand it if you use fine-grained FPGA architectures for
applications which are not terribly well suited for them then you
wind up 'wasting' a lot of your reconfigurable logic doing mindless stuff
like moving your data around the chip.
However the fact that fine-grain architectures aren't necessarily the best
for doing FFTs - or indeed anything involving much multiplication and
addition - doesn't mean that they don't have their uses.
[snip]
: Fine grain is the wrong direction.
[snip "random bitstream tolerance" & "rapid reconfiguration" relevance]
: This type of stuff:
: Linpack.ftn -> {magic} -> FPGA configuration stream
: DhryStone.c -> {magic} -> FPGA configuration stream
: Word97.bas -> {MAGIC} -> FPGA configuration stream
: DES.C -> {magic} -> FPAG configuration stream
: I dont think we will see this in the near future, but this MAGIC is
: what I think is what will make this field of endeavor more relevant.
That's quite likely. However, your "MAGIC" appears to be mainly aimed at
allowing traditional serial programs to run vaguely effectively on
parallel hardware. While I'm all in favour of people developing such
MAGIC, it will make little difference to the applications I'm interested
in, which are not conceptually very complicated, but /are/ performance
critical and beg for highly concurrent implementations.
I don't plan to write these in a high-level serial language and feed
the result to an intelligent compiler, hoping it's smart enough to come
up with a suitably parallel design. I'll get down almost on the level of
the hardware, spend some time getting things to go at maximum possible
speed and then forget about it and concentrate of the other aspects of my
problem.
: And it should use standard, traditional FPGAs, because otherwise you wont
: be able to buy them in a few years. You NEED the devices to be main
: stream, so that more traditional uses will keep the volumes high.
This is an argument for conservatism ;-) I was originally /trying/
to express what *I* would like to see in FPGA desgins. I make no secret
of the fact that my target applications are not terribly orthodox -
they're "evolutionary computation" - and an unusual variant of it at that.
Using chips designed for purposes other than the ones I intend to use them
for is a less-than-ideal situation - but no doubt one I will have to
put up with ;-)
:>Most other Xilinx chips are "island style" FPGAs (as opposed to "cellular
:>style") and have a less uniform structure, with patches of processing
:>surrounded by interconnect.
: This is not true. What you are looking at is the data sheet representation
: of the FPGA tile. [...]
How then would you characterise the difference between 'island-style' and
'cellular-style' FPGAs?
: What matters is that the logic have sufficient routing resources to
: get from sources to destinations.
My sources are all exactly adjacent to my destinations; my application is
a cellular automata, which is in need of hardware acceleration. As such,
"routing" is absent on any but the smallest scales - as there is *no*
non-local communication.
:> Such components appear less useful than they might be to those looking
:> at cellular automata approaches.
: I disagree. Just because you look at an architecture and the diagram
: shows you that there is (for instance) nearest neighbor conectivity in
: all directions, does not mean that something like Virtex that shows a
: logic cluster and a routing cluster can't implement the same design just
: as easilly, and maybe significantly faster.
Hmm. I know this much: the _ideal_ hardware for my target problem
consists of huge numbers of identical synchronously-clocked units placed
next to one another in a two-dimensional grid.
You /may/ be right - in that FPGAs with clustered logic may be the best
and fastest way of implementing such a design.
Bluntly, the only way I can imagine that this would be the case would be
if more resources had been spent on such designs due to their uses in
other applications - and consequently more 'economies of scale' were
present in the manufacturing process. I have no use for 'routing
clusters' and 'logic clusters' - at least not on any significant scale -
/anything/ that interferes with my "millions of identical cells in a grid"
being mapped onto isomorphic hardware will only get in my way.
[too much space for look-up tables / not enough space for flip-flops?]
:>This is partly because they are used to prototype VLSI chips, which are
:>generally designed to be used in conjunction with external RAM.
: Not at all. Any FPGA vendor that optimized their architecture for
: prototyping ASICs (or VLSI chips as you say) would be out of business.
: The FPGA vendors that are successful, are so because they build parts that
: are worthy of going into production designs, and do go into production
: designs. Xilinx and Altera do not each do about $620,000,000 revenue per
: year building chips for one-off prototypes.
Perhaps I'm out of touch with this industry ;-)
It appears to me that a large volume of the FPGAs in use today are
employed to prototype silicon designs. The whole point of FPGAs, is that
they are re-usable, and that such prototyping of designs do /not/ need to
be "one-off". Perhaps you misunderstood what I was trying to say - the
'production designs' you speak of are themselves frequently /used/ for
prototyping...
: The architectures that they both use are both about 1 LUT per FF. What may
: not be apparent is that in the details of the TILE (logic + FF + routing +
: connectivity + configuration + test structures + other) the LUT + FF is
: probably less than 20%.
I know little about this. I understand how allowing configuration
(and runtime read/write ability if present) takes up space. I understand
how propagating a clock signal will take up space. However I'm uncertain
what 'logic', 'routing' and 'connectivity' correspond to in your sentence
- in the context of a fine-grained FPGA.
'Logic' presumably refers to the electronics which determines manner in
which the future state of the FF is determined from the inputs via the
LUT. I presume that this would be likely to reduce in size - though
perhaps not linearly - as the size of the LUT decreased.
:>The whole legacy VN-architecture idea of having RAM physically
:>separated from the processor seems like a real problem to me.
: And I totally agree. But look at the XC4000, Virtex, FLEX, 40K and even
: the most recent stuff from Cypress. They all are putting RAM on chip, to
: allow very high bandwidth access, without going off chip.
Yes. Some RAM manufacturers even appear to be going towards the same
destination from the opposite direction. I understand Samsung's
successors to WRAM are increasingly programmable.
:> /All/ my applications seem to require that the RAM be physically
:> situated right next to the logic elements, and distributed uniformly
:> among the processing elements.
: Sounds like the XC4000 and Virtex. So the real problem is that you are
: using (or assuming that you will be using) the 6200 which has no RAM :-)
Well, there's a sense in which /everything/ has /some/ RAM. RAM is
everywhere - the 6200 series has some flip-flops, does it not? ;-)
:>There are some other ways in which I'd like to see the FPGA market
:>develop. Currently the LUTs in FPGAs are too large and take up too much
:>space.
: Totally disagree. This is the path to the Dark Side (tm). Down this path
: is the fine grain stuff that I detest so much. [...]
I suspect your distaste is not /entirely/ rational ;-) /Surely/ you'll
grant that there are /some/ applications which are intrinsically
fine-grained, for which fine-grained FPGAs are the best match?
: The LUT is less than 10% of the tile. Reducing it further (a 3-LUT) for
: instance changes the tile by less than 5%, yet a whole lot of usefull
: functions are no longer possible, i.e 1 bit add/sub (needs An, Bn, CARRYn,
: Add/Sub control), which is also needed to build up/down counters.
If your figures about LUT space are accurate then this sounds like it
may be less of an issue than I had suspected.
However, your arguments about "useful" functions appear to me to be
somewhat application-specific:
Say I am implementing a lattice-gas automata in order to simulate
turbulent fluid flow through a confined space. What earthy use are
counters or addition and subtraction primitives to me? None whatsoever.
If I want to retain the flexibility to run more than one type of
lattice-gas simulation, FPGAs are the best type of target hardware.
I'm not saying the FPGAs /I/ want would be suitable for *you*.
What makes you think the type of FPGAs /you/ prefer are best for *me*? ;-)
:>Then there's reversibility. Current FPGAs can eat power and run hot.
:>In the next ten years this will become a significant limiting factor,
:>and it is /largely/ an unnecessary one.
:>I would like to see *reversible* FPGAs, composed of large numbers of
:>Fredkin gates - or equivalent reversible logic.
: If a company came out with such a product tomorrow, they would go bust,
: guaranteed!
Well, if it were their /only/ product ;-)
Seriously, I'm not suggesting for one moment that vendors make such an
entity /tomorrow/.
: For this to make sense, there needs to be the infrastructure to do design
: with this type of technology, including synthesys, simulation,
: verification, ATPG, BIST, etc, etc, etc. This infrastructure would need to
: be main stream (i.e. ASIC and full custom design) before it makes any
: sense for an FPGA vendor to touch it. [...]
This makes things sound like the chicken and the egg :-(
Personally, I think FPGA manufacturers may actually lead over ASIC ones
when it comes to reversibility. It's not easy to say at this stage,
though, it's true.
: FPGA vendors are incapable of driving such a change in design tools.
FPGA ventors manufacture a good number of design tools. I don't think
they're as incapable as all that ;-)
:> I think this is a completely fundamental step, one which is inevitable,
:> and consequently one which FPGA manufacturers should be looking at
:> today.
: While I would feel uncomfortable taking a shot at this, I feel that there
: are many other issues that require FPGA vendors attention before going
: down this path with any resources.
You're probably right here. The calculations I've seen - which are
effectively extrapolations of Moore's law - indicate that irreversibility
will start to become "noticible" as a factor raising temperature,
increasing noise and preventing miniturisation around 2002. It will
become "important" somewhere around 2010, and be "the dominant factor
preventing further progress" somewhere between 2015 and 2020.
I don't (realistically) know what will happen on the reversibility front.
I presume by that by and large there will be 'billions' of irreversible
programs (i.e. full of the equivalent of "x = 0") around by 2010, with no
design for handling the virtual equivalent of the heat generated in place.
However, there's a reasonable chance that by this point direct dependency
on particular hardware CPU architectures will be significantly reduced
by this stage - and more software will run inside virtual machines than
it does today.
Consequently, software will exist that allows conventional
irreversible programs to run reasonably efficiently on reversible
hardware, in very much the same way that software will exist that
allows serial programs to run reasonable efficiently on parallel
hardware.
I don't doubt that FPGA vendors have other important things on their
plate. However reversibility will remain something that it is easy
to ignore for some time; and it seems fundamental to me; making a
reversible FPGA would mean a shift in the design philosophy at quite
a low level.
While ultimately, I believe performance considerations will make its
adoption completely inevitable, I'd prefer it if /some/ conscious
foresight was involved in the process ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com
Artificial intelligence usually beats real stupidity.
Article: 16791Does anyone know this rather technical detail: what is the die size of Xilinx XC4000 series FPGAs. In particular XC40250XLA and XC40250XLV Thanks.Article: 16792
khalid wrote: > I am targetting XC4k series, and I want to use an available off-chip DRAM to > implement line delays. > The FPGA chip is 24x24 CLBs only, so implementing the line delays on chip is > impossible ( I need 2 of them for a 3x3 filter, four for a 5x5, N-1 for an > NxN filter). As I said before, you can do this more easily in Virtex, using the on-chip dual-ported BlockRAM. It is ideally suited for this application. In the smallest XCV50 device, you have 1024 x 32 bits of very fast true dual-ported RAM. How many bits per pixel, and what pixel frequency? Peter AlfkeArticle: 16793
I believe only 20K400E or above offers LDVS. The information was presented at Atlera's Apex/Quartus seminar. In article <375CC319.271725CD@crl.co.uk>, Stephen King <sking@crl.co.uk> wrote: >Does any one out there have any info on the likely configuration and >performance of the LVDS IO planned for the Altera 20KE. I have had a >look at the 20K data sheet but it contains very little info. > >What I would like to know is: > >1) the number of LVDS inputs that will be offered. (I am interested in >8-16;) 16 channels in (32 pins), 16 channels out (32 pins) > >2) the maximum operating frequency/data rate; (I am interested in 500+ >MHz operation;) 622 Mbits per second >3) what sort of demux will be offered on chip to reduce the data rate to >acceptable FPGA rates, (i.e. approx. 100 MHz.). The built-in PLL + serial->parallel converter can convert 622M bit/s to 622/8 = 77.75MHz 8 bit bus. The serial->parallel allows x8, x7, x4 conversion or bypass with x1 direct feed. For example if the LVDS signal is 100Mbits /sec, it can feed directly into the device. > >My interest stems from attempting to hook high speed ADCs to FPGAs >rather than a line communications application! > >Regards > >Steve >Article: 16794
> This is an argument for conservatism ;-) I was originally /trying/ > to express what *I* would like to see in FPGA desgins. I make no secret > of the fact that my target applications are not terribly orthodox - > they're "evolutionary computation" - and an unusual variant of it at that. > My sources are all exactly adjacent to my destinations; my application is > a cellular automata, which is in need of hardware acceleration. As such, > "routing" is absent on any but the smallest scales - as there is *no* > non-local communication. > I suspect your distaste is not /entirely/ rational ;-) /Surely/ you'll > grant that there are /some/ applications which are intrinsically > fine-grained, for which fine-grained FPGAs are the best match? > Say I am implementing a lattice-gas automata in order to simulate > turbulent fluid flow through a confined space. What earthy use are > counters or addition and subtraction primitives to me? None whatsoever. > > If I want to retain the flexibility to run more than one type of > lattice-gas simulation, FPGAs are the best type of target hardware. How much money to you have? Have you considered making an ASIC that was a big array of FPGA type cells optomized for your problem? How many chips would you have to buy before the cost would crossover using traditional FPGAs and wasting all the stuff you can't use? -- These are my opinions, not necessarily my employers.Article: 16795
The size of the line buffer is dependent on the number of bits per pixel. If I assume monochrome pixels at 8 bits/pixel, then your buffer is only 6400 bits. True, that will take up a fair amount of resources (200+ CLBs), it can fit in many of the modern FPGAs. A better solution would be to use Virtex, which provides from 8 to 32 (depending on the part size) blocks of 4K bit RAMs. That said, I've used external RAM as a much deeper delay buffer as follows: You need to set the RAM up to work at twice your clock rate and interleave reads and writes. To achieve any kind of speed, you will need to pipeline the address and data, so a few of the clock delays will be in the FPGA logic. Performance of the memory (and the FPGA) can be improved considerably by setting up the memory so that you do a read-modify-write at each address and then advancing the address. In other words, increment the address, read the old value out then write the new value in then increment the address. For SRAM, this allows you to get some overlap in the cycle that you would not have if the write address was different than the previous read address. khalid wrote: > Hi All, > > I want to implement a line delay using off-chip RAM (necessary for Image > Convolution). On the FPGA, this is done using Synchronous RAM which has a > input data line and an output data one, which makes things easy. The line > delay I want to implement is big (800 pixels) and cannot be implemented on > the FPGA chip. How could I use the off-chip RAM to do that (One line for > both input and output) ?. > > I hope I'll have a reply soon. > > Thanks in advance. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 16796
Hello Steve, >1) the number of LVDS inputs that will be offered. (I am interested in >8-16;) Each device supports 16 inputs and 16 outputs >2) the maximum operating frequency/data rate; (I am interested in 500+ >MHz operation;) 622Mbps per channel >3) what sort of demux will be offered on chip to reduce the data rate to >acceptable FPGA rates, (i.e. approx. 100 MHz.). Integrated deserializer 8 bits wide => 77Mhz Paul.Article: 16797
Ray Andraka wrote: > > The size of the line buffer is dependent on the number of bits per pixel. If > I assume monochrome pixels at 8 bits/pixel, then your buffer is only 6400 > bits. True, that will take up a fair amount of resources (200+ CLBs), it can > fit in many of the modern FPGAs. A better solution would be to use Virtex, > which provides from 8 to 32 (depending on the part size) blocks of 4K bit > RAMs. That said, I've used external RAM as a much deeper delay buffer as > follows: > > You need to set the RAM up to work at twice your clock rate and interleave > reads and writes. To achieve any kind of speed, you will need to pipeline the > address and data, so a few of the clock delays will be in the FPGA logic. > Performance of the memory (and the FPGA) can be improved considerably by > setting up the memory so that you do a read-modify-write at each address and > then advancing the address. In other words, increment the address, read the > old value out then write the new value in then increment the address. For > SRAM, this allows you to get some overlap in the cycle that you would not have > if the write address was different than the previous read address. > snip how about two ram chips, connect the addresses but "swap" read and write on the two chips, then you can read from chip 1 at the same time as you write to chip 2, once you've got to the length of the buffer you start reading from 2 and writing to 1 ? you'll need twice as many data io pins and twice as much mem but it'll only have to run at single speed --L2C --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be, june 30th 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 16798
On Tue, 08 Jun 1999 09:32:41 -0700, Peter Alfke <peter@xilinx.com> wrote: >What is it you need to know ? >By-the-way: I am old fashioned and would just use a curve tracer... A curve tracer would be fine for me, too. The information I was looking for was the shape of the V-I characteristic for voltages greater than VCC. Choice 1: ^I | | | | ----- +------+---+------>V | /3 5 | / | / | / | / |/ Choice 2: ^I | | / | / | / +------+---+------>V | /3 5 | / | / | / | / |/ (The curves would actually be bent due to the fet characteristics, but that's a bit hard to do with ascii art.) From what you said, I think Choice 2 applies. Is this correct? Regards, Allan. > > >Allan Herriman wrote: > >> Hi. >> I have a question about the weak pull-up resistors in 3.3V Spartan XL >> parts. >> >> The datasheet only specifies one point on the V-I characteristic, 20 >> to 250uA at Vin = 0V. >> >> 1. I'm interested in knowing whether they pull-up all the way to VCC. > >Yes > >> >> >> 2. I'm also interested in knowing what happens to the V-I >> characteristic when the voltage gets above VCC. Does the current drop >> to (near) zero? Or is there some significant leakage current? > >The pull-up "resistor", which of course is a p-channel transistor, is active >even for voltages above Vcc. So you should count on a "resistor" to the Vcc >terminal of about 50 kilohm. It's not "leakage", but rather a non-linear >resistance. > >> >> >> The datasheet says that the pull-ups are p-channel fets. It also says >> that they are 5V tolerant. XAPP 088 shows that something has been >> done to bias the fet well (to avoid the problems due to the parasitic >> diode in the fet) but it doesn't give any details of the well bias >> circuit. >> >> Could someone help me please? > >It's a complicated circuit arrangement, and some of it is proprietary ( we put >many man-months into this aspect of the design). >What is it you need to know ? >By-the-way: I am old fashioned and would just use a curve tracer... > >Peter Alfke >Xilinx Applications > >> >> >> Thanks, >> Allan. >Article: 16799
Paul Thanks for the info on the Altera 20K LVDS IO. Do you know if it will be possible to synchronise multiple "deserializers" together so I can take input a 16 bit 500 MHz bus and treat it as a 128 bit 62.5 bit bus on chip? I have found that standard comms demux chips do not tend to support tight synchronisation of multiple devices. Steve Paulwb007 wrote: > Hello Steve, > > >1) the number of LVDS inputs that will be offered. (I am interested in > >8-16;) > > Each device supports 16 inputs and 16 outputs > > >2) the maximum operating frequency/data rate; (I am interested in 500+ > >MHz operation;) > > 622Mbps per channel > > >3) what sort of demux will be offered on chip to reduce the data rate to > >acceptable FPGA rates, (i.e. approx. 100 MHz.). > > Integrated deserializer 8 bits wide => 77Mhz > > Paul.
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