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
There is a fairly comprehensive list of available boards at 'http://www.optimagic.com/boards.html'. In specific, I would look at the TB4025PQ ISA prototyping board from Fliptronics (see 'http://www.geocities.com/SiliconValley/2256/products.htm') and the Constellation FLEX 10K board from Nova Engineering (see 'http://www2.nova-eng.com/nova/constellation.html'). -- Steven Knapp OptiMagic, Inc. E-mail: sknapp @ optimagic.com Programmable Logic Jump Station: http://www.optimagic.com Nestor Caouras <nestor@ece.concordia.ca> wrote in article <3433A8B5.6647@ece.concordia.ca>... | Hi. | | I've been looking around for development/prototyping boards that support | the larger XILINX and ALTERA devices (such as xc4085 and FLEX10k100). Up | to now I've only been able to find boards for Xilinx devices up to 10k | devices (i.e. xc4010). If anyone knows of a third party | vendor/manufacturer that develops such boards, can you please contact | me. | | Your help will be greatly appreciated. | | Thanks in advance. | -- | Nestor Caouras | nestor@ece.concordia.ca | http://www.ece.concordia.ca/~nestor/addr.html | |-------------------------------------------| | | Dept. of Electrical and Computer Eng. | | | Concordia University | | | 1455 de Maisonneuve Blvd (West) | | | Montreal, Quebec, Canada H3G 1M8. | | | Tel: (514)848-8784 Fax: (514)848-2802 | | |-------------------------------------------| |Article: 7726
In article <01bccf48$9074cd20$1f38d926@dan.i-tech.com>, dan_kuechle@SPAM_NOTi-tech.com says... > >For Xilinx you need to use a tbuf with an ibuf to get the input portion, >and an obuft for the output portion. Don't know how other vendors do it. > >david.surphlis@gecm.com wrote in article ><6107sd$t4r@gcsin3.geccs.gecm.com>... >> >> does anyone know how to but a birectional bus on to an fpga >> using in ibuf and obuf components as there does not seem to be a >> bidirectional buf. >> >> Thanks >> Davey >> >> Dan recommended a obuft for the output, while Nicholas recommended an obufe. These are not equivalent! The obufe was added recently by Xilinx to comply with the industry standard of enabling tri-state buffers with an active high. The way they did it was to make a macro with an obuft and an inverter in the control line. This inverter is not included in the output pin driver of 4000e parts, so it consumes a CLB function generator just for the inverter! If you have wide output tri-state busses you should always use obuft. If you need the inversion, use one inverter to drive all your obufts. The software is not smart enough to do this for you, and if left to its own resources, it will use separate inverters for each obufe which could consume valuable CLB function generators. I have Philip Freidin to thank for this bit of trivia. Dave Decker Diablo Research Co. LLC "Animals . . . are not brethren they are not underlings; they are other nations, caught with ourselves in the net of life and time, fellow prisoners of the splendor and travail of the earth." Henry Beston - The Outermost HouseArticle: 7727
In article <01bcd2e6$e74374c0$LocalHost@tecra>,
Jan Gray <jsgray@acm.org.nospam> wrote:
>As for hosting an OS, you will notice J32 has no MMU. I have
>some promising schemes for reasonable MMUs for FPGA
>implementation along the lines of 1 bit per 16 KB page write
>protection (only) and some related software conventions. Either
>that or slow sequential (nonassoc) TLB entry lookup.
How about 1-way associative (or direct mapped) TLB? It would be like a
simple cache, and would require only a single address comparitor. I might
have my terminology mixed up here, maybe that's what you have in mind?
>The J32 is designed to be as close to MIPS as possible but yet
>achieve good performance in half an XC4010. In particular there are
>no PC-relative branch instructions because the jump instructions
>are adequate and adding another adder, mux, and bus would add
>at least 20% to the datapath area.
>If we eliminate J32 condition codes then it would be
>straightforward to write a MIPS to J32 cross assembler.
>It would map multiplies, exotic shifts, floating point, etc.
>into calls to emulation routines.
This is a really good idea that I hadn't thought of. I'm thinking that you
don't have to change anything (but you do need to make sure that the number
of registers is equal or greater). If the MIPS had condition codes and the
J32 didn't you would have a problem, but since it's the other way around,
the effects of the condition codes are clearly defined within a single MIPS
instruction. Also, you would not have to worry about saving the flags
register at all, for the same reason. So a beq would be translated into a
compare and jump on Z set (or into whatever instructions you have).
So is your design publically available? :-)
>BTW, if I recall correctly, MIPS has patents on lwl lwr etc.
This doesn't matter. GNU C keeps everything aligned (in structures) and
won't generate these instructions in any other cases. In fact these
instructions are useless. For example in:
int foo(char *s)
{
return *(int *)(s+1);
}
GNU C compiles the '*(int *)' into a lw and hopes you know what you're
doing. It has no way of knowing whether (s+1) is going to be a multiple of
4 or not at compile time, so it doesn't know whether it should generate
lwl/lwr or not. It assumes you know what you're doing and generates the
faster version (lw):
.file 1 "test.c"
# GNU C 2.6.3 [AL 1.1, MM 40] DECstation running ultrix compiled by GNU C
# Cc1 defaults:
# Cc1 arguments (-G value = 8, Cpu = 3000, ISA = 1):
# -quiet -dumpbase -O -o
gcc2_compiled.:
__gnu_compiled_c:
.text
.align 2
.globl foo
.text
.ent foo
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, extra= 0
.mask 0x00000000,0
.fmask 0x00000000,0
lw $2,1($4)
j $31
.end foo
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 7728Vadem AISC dept. has 2 design verification job openings: a senior level and a junior level engineering positions. Job descriptions: * chip level design verification for single chip computer; * external module designs, such as EDO ram, flash rom, USB transceiver; * functional verification by Verilog; * timing verification by static timing analyzer; * power calculation. Requirements: * BSEE or equivalent with 1+ yrs related experience for junior position; * BSEE or equivalent with 6+ yrs related experience for senior position; * understanding of ASIC design and verification flow; * good at Verilog; * for senior position, understanding of timing and power analysis; * understanding of perl and IP is plus. Please email your resume to etam@vadem.com. You can surf our website for the company background at www.vadem.com. We are located at San Jose, CA. Best Regards Edmond Tam Verification Leader Vadem (408)467-7708 etam@vadem.comArticle: 7729
I have been taking herbs and my health has greatly improved over 2 yrs and I'm in a company called shaperite
the best of the best herbs you can join the company for $9.95.
You will receive free voice mail so you can talk to me by leaving me messages? also you will benefit from these
fantastic herbal formulas like Idid.
You can start a business if you wanted to but most all it's your health?
Leave your name,address and phone for information pack.
William Semonis
Article: 7730In article <01bcd2dd$d098a000$LocalHost@tecra>, Jan Gray <jsgray@acm.org.nospam> writes [amongst other things...] >> They argue against multiple processors on a single chip, because it >> makes what is already an I/O bound system even worse. Just because you >> can put multiple processors on a dies doesn't mean you can feed them >> instructions and data. True, but surely the whole point about FPGAs is that you are trying to do something that was awkward or impossible with standard parts - so you will likely deal with this issue on a case-by-case basis. >Also, Patt et al.'s statement is: > "In our view, if the design point is performance, the > implementation of choice is a very high-performance > uniprocessor on each chip, with chips interconnected > to form a shared memory multiprocessor." Hmmm. IMHO you have a tough time convincing yourself that big shared-memory systems will do what you want them to do in all possible circumstances - synchronisation is either very difficult or somewhat inefficient. Enough local memory for the local process's needs, and fast-ish comms to other processing nodes, is more elegant and easier to think about logically. That was what Inmos were doing with the Transputer more than a decade ago... It worked superbly but nobody believed them, so the processor family didn't get enough development resource thrown at it. RIP, almost. >Finally, let's discuss where we can go with a fast uniprocessor >on a large FPGA. I have given this some thought over the >years. >One big challenge is register file design. yes, most FPGA structures are quite bad for implementing this, I agree. The big problem, as is well known, is that general configurable architectures (FPGAs) are not likely to be optimal for any particular task. We have become so dependent on the notion of a CPU that people have invested inordinate effort in optimising them, raising our expectations spectacularly, so that you and I with our FPGAs cannot match the performance and flexibility that you can buy for the price of a hamburger from commodity CPU suppliers. But the flexibility of a standard CPU is really needed only for what someone in this thread called "dirty deck" work - infrequently executed, very irregular operations with lots of branching and few opportunities for pipelining. How about this for a new compromise: put a small RISC machine on your FPGA, not fussing too much about performance because you won't need it; and leave the rest (50%?) of your FPGA free for the wacky pipelined stuff; but here's the new idea: *** expose the register file of the CPU to the rest of the FPGA, *** so that the FPGA can provide application-specific functionality *** behind the registers. That way you can go on using compilers that you know and love for your CPU, you can write the rest of your FPGA in Handel-C or whatever, and the application-specific stuff gets a uniform, high-bandwidth interface to the CPU. ---- I was the person who said VCRs would never catch on. ---- Jonathan BromleyArticle: 7731
You can make use of the IOC registers by using the PLSI PROPERTY key word in ABEL syntax. The format goes somthing like this: PLSI PROPERTY 'reg_name REGTYPE IOC'; where the reg_name is the name of the register that you want in the IOC. Please check the documentation for the exact order of what is in the single quotes. I may have the order of the reg_name in the wrong place but I think you get the idea. The ABEL compiler simply passes the PLSI PROPERTY statements to the Lattice ispDS+ Fitter. The ispDS+ Fitter then handles the proper placement of the register. Keep in mind that this statement has to go in your declaration block -- outside of your equation or statemachine block. -- ISP is LATTICE Bulent UNALMIS <unalmis@club-internet.fr> wrote in article <342EF2EC.1620@club-internet.fr>... > Hello all Lattice users., > > I am writing ABEL program for ISPLSI1048. > I want to use IOC registers for registereted inputs. > I dont have any problem if I use GLB FlipFlops. > But How can I use IOC FlipFlops I dont know. > > Can you send me any example ABEL program ? > > Thanks. >Article: 7732
Jonathan Bromley wrote: > How about this for a new compromise: > put a small RISC machine on your FPGA, not fussing too much about > performance because you won't need it; and leave the rest (50%?) of > your FPGA free for the wacky pipelined stuff; but here's the new idea: > *** expose the register file of the CPU to the rest of the FPGA, > *** so that the FPGA can provide application-specific functionality > *** behind the registers. > That way you can go on using compilers that you know and love for > your CPU, you can write the rest of your FPGA in Handel-C or whatever, > and the application-specific stuff gets a uniform, high-bandwidth > interface to the CPU. > ---- I was the person who said VCRs would never catch on. ---- > Jonathan Bromley That leads me very neatly onto the ASPIRE project! The aim is to incorporate the ARM core in an ASIC. A PCI plug-in card is being developed with an ARM chip connected to a Xilinx FPGA to try out the ideas. The FPGA is being programmed with Handel-C, which explains the association with Embedded Solutions who are marketing the board. Brief summary of ASPIRE is at: http://www.omimo.be/scripts/dbml.exe?template=/_srproj2.dbm&Project_Number=20451 Charles Charles Sweeney, Engineering Director, Embedded Solutions Ltd Tel/fax +44 1235 510456 <http://www.embedded-solutions.ltd.uk/> Email CharlesSweeney@compuserve.com or csweeney@embedded-solutions.ltd.uk 6 Main Road, East Hagbourne, Didcot, Oxfordshire. OX11 9LJ. UK.Article: 7733
Hi !
My name is Tadaaki Koyama . I'm Japanese so I can write poor English. sorry.
In Japan, FPGA Infomations is poor and We can not get FPGA's Information
because we weakly read English .
So I made Japanese FPGA mailing-list. I want to give and take about infomation
of FPGA in Japan. If you want to know this mailing list, Please access
my home page.
http://www01.u-page.so-net.or.jp/fa2/basaro/ It is only Japanese.
Thank you.
Tadaaki Koyama basaro@yumenet.com
basaro@fa2.so-net.or.jp
Article: 7734Jonathan Bromley wrote: > How about this for a new compromise: > put a small RISC machine on your FPGA, not fussing too much about > performance because you won't need it; and leave the rest (50%?) of > your FPGA free for the wacky pipelined stuff; but here's the new idea: > *** expose the register file of the CPU to the rest of the FPGA, > *** so that the FPGA can provide application-specific functionality > *** behind the registers. > That way you can go on using compilers that you know and love for > your CPU, you can write the rest of your FPGA in Handel-C or whatever, > and the application-specific stuff gets a uniform, high-bandwidth > interface to the CPU. > ---- I was the person who said VCRs would never catch on. ---- > Jonathan Bromley Now this is an interesting idea. Experimenting with home-brewed computer architectures is an interesting (if a little nerdy <g>) hobby, but it's a bit perverse to use a programmable device to emulate fixed-instruction set computers. The programmable device starts with roughly a 10X penalty, relative to a top of the line microprocessor, in how fast it can wiggle those gates. As several posters have pointed out, it's unlikely you can keep the multiprocessors fed with instructions fast and data enough to gain in parallelism what you have lost in clock speed relative to the main CPU. On the other hand, using the configurable device for configurable computing has considerable merit.... John Koza from Stanford has an interesting paper on using an FPGA (Xilinx 6200) to accelerate a genetic programming problem. On an intrinsically parallel genetic/systolic/cellular type of algorithm, you might get a 1000:1 algorithmic speedup relative to a sequential CPU. So even with the 1:10 clock hit, you have a large net win. atw not speaking for intel....Article: 7735
Dave Decker wrote: > This inverter is not included in the output pin driver of 4000e > parts, so it consumes a CLB function generator just for the inverter! > I have Philip Freidin to thank for this bit of trivia. In spite of the usually excellent, reliable and enlightening source you quoted here, this is a misunderstanding. The IOB output enable or 3-state control has a built-in inverter that is, therefore, free. And the software knows how to handle this. The chip-internal T-buf does not have such an inverter option, and that's perhaps where this confusion originated. Peter Alfke, Xilinx ApplicationsArticle: 7736
dementia wrote: > ------------------------------------------------------------------------ > > Subject: [Fwd: [Fwd: [Fwd: READ THIS MESSAGE AND PASS IT ON....]]] > Date: Mon, 06 Oct 1997 17:46:50 -0700 > From: shelley tantan <shmelley@skyinet.net> > Organization: SKYinternet Philippines > Newsgroups: alt.teens,alt.romance,alt.romance.teen,alt.music.lyrics > > Subject: [Fwd: [Fwd: READ THIS MESSAGE AND PASS IT ON....]] > Date: Sun, 05 Oct 1997 01:53:40 -0700 > From: Afro Jon <sleater@earthlink.net> > Organization: EarthLink Network, Inc. > Newsgroups: alt.sex.oral,alt.sex,alt.love,alt.suck > > ------------------------------------------------------------------------ > > Subject: [Fwd: READ THIS MESSAGE AND PASS IT ON....] > Date: Wed, 01 Oct 1997 15:19:18 -0600 > From: Jon Lacousta <jlacoust@geocities.com> > Organization: University of Alberta, Edmonton, Canada > Newsgroups: alt.locksmithing,alt.cellular.nokia,alt.cellular-phone-tek,alt.drugs.psychedelics,alt.drugs.pot > > ------------------------------------------------------------------------ > > Subject: READ THIS MESSAGE AND PASS IT ON.... > Date: 30 Sep 1997 20:13:28 GMT > From: x.traktor@beyond.hell (Ex Traktor) > Organization: The Men They Couldn't Hang > Newsgroups: alt.catastrophism,alt.comp.blind-users,alt.disney.disneyland,alt.drugs.mushrooms,alt.tasteless.jokes > > READ THIS MESSAGE AND PASS IT ON.... > > A man takes the day off work and decides to go out golfing. He is on the > second hole when he notices a frog sitting next to the green. He thinks > nothing of it and is about to shoot when he hears, "Rabbit. 9 Iron" > The man looks around and doesn't see anyone. "Rabbit. 9 Iron." He > looks at the frog and decides to prove the frog wrong, puts his other club > away, and grabs a 9 iron. Boom! he hits it 10 inches from the cup. He > is shocked. He says to the frog, "Wow that's amazing. You must be a > lucky frog, eh?" The frog reply's "Rabbit. Lucky frog." The man decides to > take the frog with him to the next hole. "What do you think frog?" the > man asks. "Rabbit. 3 wood." The guy takes out a 3 wood and Boom! Hole > in one. The man is befuddled and doesn't know what to say. By the end > of the day, the man golfed the best game of golf in his life and asks the > frog,"OK where to next?" The frog reply, "Rabbit. Las Vegas." They go > to "Las Vegas and the guy says, "OK frog, now what?" The frog says, > "Rabbit Roulette." Upon approaching the roulette table, the man asks, > " What do you think I should bet?" The frog replies, "Rabbit.$3000,black 6." > Now, this is a million-to-one shot to win, but after the golfgame, the man > figures what the heck. Boom! Tons of cash comes sliding back across > them table. The man takes his winnings and buys the best room in the hotel. > He sits the frog down and says, "Frog, I don't know how to repay you. > You've won me all this money and I am forever grateful." The frog > replies, "Rabbit, Kiss Me." He figures why not, since after all the frog did > for him he deserves it. With a kiss, the frog turns into a > gorgeous15-year-old girl. "And that, your honour, is how the girl > ended up in my room." > > The origination of this letter is unknown, but it brings good luck to > everyone who passes it on. The one who breaks the chain will have bad > luck. Do not keep this letter. Do not send money. Just forward it to > five other newsgroups to whom you wish good luck. You will see that > something good happens to you four MINUTES from now if the chain is > not broken. You will receive good luck in four minutes. > > ---------------------- > lifeforce@beyond.hellArticle: 7737
In an article by Dave Decker (see below), he notes that OBUFT and OBUFE
are not equivalent, and that there is an issue of the inverter that is
used to convert a OBUFT into an OBUFE. Dave credits me for this info, and
tragically, he probably did get it from me. Tragic because it is incorrect.
Here's the Truth (tm)
An OBUFT is a primitive for all XC3K and XC4K families. It is an output
buffer, that drives when the T pin is low. When the T pin is
high, the output goes to its third state: High Impedance (Z)
An OBUFE is represented in the libraries as an OBUFT with an inverter
driving the T signal, and the user connects to the input of
the inverter, which is labeled E.
If you use multiple OBUFE symbols in your design and connect all the E
pins together, there will be multiple inverters in your netlist.
This is not an issue, as the OBUFE is also a primitive in all the XC3K
and XC4K families, even though the library symbols represent it
as an inverter and an OBUFT. The software recognizes this
construct, and the inverters are absorbed into the I/O primitive,
and the OBUFE is what is actually instantiated in the placed and
routed chip.
So ... No extraneous inverters.
The problem is that the same is not true for the tristateable buffers in
the main array. These are called BUFT and BUFE, and the BUFE symbols are
a macro with an inverter and a BUFT. If you use multiple BUFE symbols,
and tie their E pins together, you will get multiple inverters, both in
the netlist and the placed and routed chip. This is probably not
desireable. If the E pins are all fed from one flipflop for example, then
you end up wasting a function generator per OBUFE, to implement all the
inverters. It is better to design with BUFT symbols, and instantiate just
one inverter your self.
Philip Freidin.
In article <61drrk$h3j$1@ultra.exodus.net> ddecker@diablores.com (Dave Decker) writes:
>In article <01bccf48$9074cd20$1f38d926@dan.i-tech.com>,
>dan_kuechle@SPAM_NOTi-tech.com says...
>>
>>For Xilinx you need to use a tbuf with an ibuf to get the input portion,
>>and an obuft for the output portion. Don't know how other vendors do it.
>>
>>david.surphlis@gecm.com wrote in article
>><6107sd$t4r@gcsin3.geccs.gecm.com>...
>>>
>>> does anyone know how to but a birectional bus on to an fpga
>>> using in ibuf and obuf components as there does not seem to be a
>>> bidirectional buf.
>>>
>>> Thanks
>>> Davey
>>>
>>>
>Dan recommended a obuft for the output, while Nicholas recommended an obufe.
>These are not equivalent! The obufe was added recently by Xilinx to comply with
>the industry standard of enabling tri-state buffers with an active high. The
>way they did it was to make a macro with an obuft and an inverter in the
>control line. This inverter is not included in the output pin driver of 4000e
>parts, so it consumes a CLB function generator just for the inverter!
>
>If you have wide output tri-state busses you should always use obuft. If you
>need the inversion, use one inverter to drive all your obufts. The software is
>not smart enough to do this for you, and if left to its own resources, it will
>use separate inverters for each obufe which could consume valuable CLB function
>generators.
>
>I have Philip Freidin to thank for this bit of trivia.
>
>Dave Decker
>Diablo Research Co. LLC
>
>
>"Animals . . . are not brethren they are not underlings; they are other
>nations,
>caught with ourselves in the net of life and time, fellow prisoners of the
>splendor and travail of the earth."
>Henry Beston - The Outermost House
>
Article: 7738Pierre-Yves BRETECHER wrote: > In the past I have experienced many difficulties for fitting ALTERA device > (MAX 5K and 7K) when I started my design by setting the pin allocation (to > get the PCB at the right time) . > Today I have to design with a FLEX 10K30 (208 pins) where I have to fix now > about 130 pins (I have 3 bus of 16bits and I expect my design to be less > than 15k gates). Hello Pierre, I will take the opportunity to answer this one - even if you will possibly regard me as somewhat biased: I've been working as an FAE with an Altera distributor for the last 2 1/2 years. In most designs I've been working with recently, using the newer versions of Max+Plus II, FLEX 10K pin allocation problems has virtually disappeared in my experience. I've been able to fill the devices almost to it's limits (90-95-100%), using almost all the pins (95-100%). Then - I've rearranged all the pins at random - and then recompiled without any problems whatsoever! I've seen this in several designs. Also - in the FLEX devices there is very seldom a speed penalty to pay when you start filling the device to it's limits, and the I/O timing will normally not change very much when doing design changes. FLEX 10K is really a pleasure to work with when it comes to pin locking, and I also believe FLEX 6000 series has been designed with the experiences gained from 10K fitting in mind - even if I don't have that much experience with the FLEX 6000 yet. About MAX7000, pin locking can be a problem in some very few cases, caused by a limitation of the fan-in width into the LABs. But if you know what you're doing and know the limitations of the architecture you're using - you will very seldom run into trouble. I believe I've seen only 2 or 3 cases with pin locking problems in MAX 7000 during the past two years. If you have to - I would suggest you just go ahead and lock the pins. Chances are quite good that you will not run into fitting trouble. Regards, Rune BaeverrudArticle: 7739
Here's an upcoming event you may be interested in: Praegitzer Industries Inc.'s Technical Symposium '97 "Everything New Under The Sun" November 20, 1997 The Fairmont Hotel, San Jose, CA. The all-day event will feature discussions on microvias, buried passive components, surface finishes and future technologies. Admission is free but space is limited. To reserve your space now, please send e-mail to symposium@pii.com. For more information, please contact Sonya Seyle via phone at 503.221.7421 or e-mail at sonya_seyle@kvo.com. Be sure to visit Praegitzer’s Web site at http://www.pii.com/.Article: 7740
I am looking to simulate my VHDL FPGA design and would like to design a testbench that includes a VHDL model of an SRAM (32K x 8). Does anyone have a good way of doing this? I was thinking of using textio statements to use a file as the memory but am not quite sure how to go about doing this, and even then am not sure this wouldn't slow the simulator (ModelTech) to a crawl. Any suggestions would be appreciated....thanks!! db brandis@dlcc.com remove <no spam> from replyArticle: 7741
In article <5ASPUFAia3O0UA$k@oxim.demon.co.uk> Jonathan Bromley <jseb@oxim.demon.co.uk> writes: >How about this for a new compromise: >put a small RISC machine on your FPGA, not fussing too much about >performance because you won't need it; and leave the rest (50%?) of >your FPGA free for the wacky pipelined stuff; but here's the new idea: >*** expose the register file of the CPU to the rest of the FPGA, >*** so that the FPGA can provide application-specific functionality >*** behind the registers. >That way you can go on using compilers that you know and love for >your CPU, you can write the rest of your FPGA in Handel-C or whatever, >and the application-specific stuff gets a uniform, high-bandwidth >interface to the CPU. >---- I was the person who said VCRs would never catch on. ---- >Jonathan Bromley Great idea, and it was implemented in my 16 bit RISC processor (RISC4005) that I developed in 1990. This processor is about 150 CLBs, runs in a XC4005 at about 20MHz, and is architecturally similar to the AM29000. The 32 bit CPU that Jan has designed is also quite similar, except for size. In the RISC4005, both of the register fetch busses and the result bus were available for the user to add new function units, with the core processor performing the register fetches for the external (to the CPU, but still on the same FPGA) function unit, and then take its result and put it back in the appropriate register. There were even reserved op-code positions for these external function units. I went one better though, for very high speed output. I created a facility I called a 'View Register', and an associated 'View Register Selector'. The selector is a 4 bit field that specifies one of the 16 registers in the main CPU register file. Whenever a write to that CPU register is done, the 'View Register' is updated as well with a copy. This effectively gives you a control register within a peripheral function that can be written to with any instruction that puts a result back into the register file. So moves, ands, ors, adds etc can all do their thing, and the result also goes to the peripheral 'View Register'. If you have a set of back to back register to register move instructions, then you can achieve a burst rate of 20M transfers per sec, until you run out of registers. Obviously, this can be extended to multiple selectors with multiple view registers. The cost is that a general purpose register within the register file now has side-effects (and so cant be made available to a compiler as a general purpose register), but the advantage is stunningly fast output capability. This is ideal for applications that have the processor bit-banging some type of output protocol. I guess it's time for me to dust off my design and port it to the newer XC4000E, XC4000EX, and XC4000XL, and see how much faster I can make it. I suspect that I could probably get it to run at 40 to 50 MHz in one of the faster speed grade chips. Philip FreidinArticle: 7742
Any of these kicking around for Altera, if not for a good reason, ? Somehting of an interest but not in aposition to find the time for the money to get into, we use 10k10's at present and the techniques would be intersting, any pointer greatfully recieved. In article <fliptronEHsptF.Ev6@netcom.com>, Philip Freidin <fliptron@netcom.com> writes >In article <5ASPUFAia3O0UA$k@oxim.demon.co.uk> Jonathan Bromley ><jseb@oxim.demon.co.uk> writes: >>How about this for a new compromise: STUFF Removed ! > >I guess it's time for me to dust off my design and port it to the newer >XC4000E, XC4000EX, and XC4000XL, and see how much faster I can make it. I >suspect that I could probably get it to run at 40 to 50 MHz in one of the >faster speed grade chips. > > >Philip Freidin -- David AtkinsArticle: 7743
G. Herrmannsfeldt <gah@u.washington.edu> wrote in article <61bqes$dcg$1@nntp6.u.washington.edu>... > I am working on a design using XC4000 logic, which I want to be as > fast as possible. The basic design is a pipelined systolic array > processor, so it is already well pipelined. > > What I want to do is add more pipeline stages, so I can run even faster. > > I have designs that have only one or two CLB worth of logic between > latch stages. The CLB will be arithmetic logic, such as 16 bit adders or > comparators. > > How fast can I go with something like XC4013E or even an EX part, such > as XC4028EX? > > I am looking for a little more than in the Xilinx databook. > > thanks, > > -- glen > The current fastest Xilinx parts are the 4000XL series (3.3 volt). This family is also cheaper than the earlier families. I'm in the process of designing something in the 4010XL which is using about 98% of the CLBs, has about half the CLBs being clocked at 100MHz and is still meeting all timing constraints. I'm really quite impressed. ErikArticle: 7744
> Dan recommended a obuft for the output, while Nicholas recommended an obufe. > These are not equivalent! The obufe was added recently by Xilinx to comply with > the industry standard of enabling tri-state buffers with an active high. The > way they did it was to make a macro with an obuft and an inverter in the > control line. This inverter is not included in the output pin driver of 4000e > parts, so it consumes a CLB function generator just for the inverter! > > If you have wide output tri-state busses you should always use obuft. If you > need the inversion, use one inverter to drive all your obufts. The software is > not smart enough to do this for you, and if left to its own resources, it will > use separate inverters for each obufe which could consume valuable CLB function Not true. The IOBs have the capability of inverting the tristate enable. The inverter in the library gets interpreted by PPR and is absorbed into the IOB logic. This is not true however for the internal BUFT's (BUFE's will instantiate a separate inverter, which will be absorbed into preceeding combinatorial logic if possible. If you are driving a BUFE's control with a flop, use a BUFT and do the inversion on the input side of the flop or you'll wind up with an extra level -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: 7745
Thanks for the info. -- Nestor Caouras nestor@ece.concordia.ca http://www.ece.concordia.ca/~nestor/addr.html |-------------------------------------------| | Dept. of Electrical and Computer Eng. | | Concordia University | | 1455 de Maisonneuve Blvd (West) | | Montreal, Quebec, Canada H3G 1M8. | | Tel: (514)848-8784 Fax: (514)848-2802 | |-------------------------------------------|Article: 7746
"Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au> wrote: > > >G. Herrmannsfeldt <gah@u.washington.edu> wrote in article ><61bqes$dcg$1@nntp6.u.washington.edu>... >> I am working on a design using XC4000 logic, which I want to be as >> fast as possible. The basic design is a pipelined systolic array >> processor, so it is already well pipelined. >> >> What I want to do is add more pipeline stages, so I can run even faster. >> >> I have designs that have only one or two CLB worth of logic between >> latch stages. The CLB will be arithmetic logic, such as 16 bit adders or >> comparators. >> >> How fast can I go with something like XC4013E or even an EX part, such >> as XC4028EX? >> >> I am looking for a little more than in the Xilinx databook. >> >> thanks, >> >> -- glen >> > >The current fastest Xilinx parts are the 4000XL series (3.3 volt). This >family >is also cheaper than the earlier families. > >I'm in the process of designing something in the 4010XL which is using >about 98% >of the CLBs, has about half the CLBs being clocked at 100MHz and is still >meeting >all timing constraints. I'm really quite impressed. > >Erik I understood there was a "tweaked" 3000 series which could be _clocked_ at around 300 MHz (and achieve quite impressive speeds with real designs too) the XC3100A family. This still seems (on paper) faster than the 4000XL family ( but of course, smaller). Are there any plans to match this sort of performance in the XC4000 family? - BrianArticle: 7747
brian@shapes.demon.co.uk (Brian Drummond) writes:
> "Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au> wrote:
> >The current fastest Xilinx parts are the 4000XL series (3.3 volt). This
> >family
> >is also cheaper than the earlier families.
> >
> >I'm in the process of designing something in the 4010XL which is using
> >about 98%
> >of the CLBs, has about half the CLBs being clocked at 100MHz and is still
> >meeting
> >all timing constraints. I'm really quite impressed.
> I understood there was a "tweaked" 3000 series which could be _clocked_
> at around 300 MHz (and achieve quite impressive speeds with real designs
> too) the XC3100A family.
In `Signal Processing at 250MHz using high speed FPGAs', Proc. FPGA'97,
pp62-68, B. von Herzen reports a spectral correlator measured
at 250MHz using XC3195-09. This is achieved in a timing-by-construction
design flow. Indeed clock speeds of 300MHz are possible with 3195.
As usual, getting a clean clock signal and propogating it in the circuit is
the simple problem that turns out to be more of a barrier than the
pipeline stages, at these speeds and loadings.
>
> This still seems (on paper) faster than the 4000XL family ( but of
> course, smaller). Are there any plans to match this sort of performance
> in the XC4000 family?
The quote in the reference above "..it is faster to travel to the right than
to the left, and slightly faster to travel down than up...(XC3100) .. Families
such as the XC4000 do not have this directionality, but are not as fast for
direct interconnect between neighbours."
This indicates the above question is unlikely to have a positive answer.
The original poster's question about the XC4000 max pipelined speed can be
calculated by following the analysis of von Herzen.. or just work it out
by hand from a timing budget and the databook (which I don't have to hand)
--
Regards, <pre>
--------------------logo:Silicon Wafer----------------------------------
Christy Looby, .--~~~~~--. E-mail: clooby@nmrc.ucc.ie
NMRC, Univ. College, .'/_N_M_R_C_\`. Phone +353 (0)21 904 064((Direct)
Lee Maltings, Cork, |_/_/_|_|_|_\_\_| Fax " " 270 271
REPUBLIC OF IRELAND \_I_R_E_L_A_N_D_/ Nat'l-Microelctronic-Res'rch-Cntr
`-------------' (NMRC)
------------------------------------------------------------------------
http://nmrc.ucc.ie http://www.ucc.ie/ucc/socs/squash/clooby.html </pre>
Sender: SRIRAM SRINIVASAN <sriram@rocket.cc.umr.edu>
Article: 7748
Wow, You can now get foundation base kits and base VHDL kits
with the APS X84 development board for as low as 300.00 total !!!!!!
That includes schematic capture, ABEL HDL AND M1 ROUTER!!!Plus the X84
development board (ISA/stand alone) ,with 5202 FPGA, prom socket,
oscillator socket, timer circuit, status LEDs, download software, C
code, 8255 chip, decode pal, strapable PC address, accepts XILINX
Download cable. Four 20 pin IDC IO connectors. VHDL examples and C code
boilerplates. with on board FPGA and oscillator socket etc. etc.. The
software is limited to 8000 gates, but that's alot of
bang for the buck.300.00 bucks total !!! (plus shipping) I have never
seen such a great deal. This is all possible because XILINX has cut
their prices (for a limited time) on
their software, and we have lowered our price on the X84 board in kind.
For those who want VHDL for $700.00 you can get the same deal mentioned
above with VHDL.
You can only get the X84 boards through APS.
APS-X84-FB01 kit: $300.00
X84 board kit (see above)with the XILINX Foundation base software kit.
Includes: XACT router, Schematic, simulation, ABEL-HDL, design support,
XILINX CPLD and FPGA implementation tools.
APS-X84-FBV $700.00
X84 board kit (see above) & Foundation XACT router, VHDL synthesis,
schematic BASE VHDL, simulation, ABEL-HDL XC7300 family design
support, Xilinx CPLD and FPGA implementation tools.
We accept VISA and MASTER CARD
http://www.associatedpro.com/aps
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: aaps@erols.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 7749
APS is now selling the PeakPers VHDL Simulator for only $699.00 !!!
This simulator supports VHDL 1076-1987 1076-1993 (some restrictions
aply) It includes built in VHDL editor, Hierarchy browser, VHDL wizards,
Includes the Text Book "VHDL made easy!" and is compatible with Windows
and NT
http://www.associatedpro.com/aps
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: aaps@erols.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
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