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
On Sun, 17 May 1998 13:42:38 -0700, Jeff Graham <drjeff@actrix.gen.nz> wrote: > >Has anyone else tried to migrate existing XC5200 designs to the new >tools and what sort of success have you had ? > > M1.4 failed to route three 5210's and one 5204. I even took one of the 5210's which started at 70% CLB usage and kept stripping out logic. I had the usage down to 20% and it still wouldn't route!! So I went back to XACT.Article: 10426
Anyone know a good site for info on using the 'C5x and 'C5000x series of Ti DSPs??? -BILL Andrew Phillips wrote: > Hi, > > Looking for good info about the Texas Instruments TMS320C6x DSPs? > > Please check out my website: > http://www.scs.ch/~andrew/c6x.html > > Here you'll find: > > - latest documentation and silicon availability info. > - heaps of stuff about HW and SW design with these DSPs > - application notes > - comprehensive bug list > - commercially available 'C6x processor boards > > and lots of other stuff ..... > > Have a look and please send me any comments. Don't forget to join my > mailing list if you want to be notified when the site is updated ... > > Cheers, > > Andrew Phillips > Supercomputing Systems AG > Zurich, SwitzerlandArticle: 10427
Dynamic FPGA organization is experiencing tremendous growth in their High density, high performance FPGA product line. They are currently looking for qualifified individuals to serve as a MTS FPGA Field Applications Engineer. Applicant should have at least 3 years experience in the design and development of high performance, high density integrated circuits, either ASIC or FPGA. Expertise in VHDL and/or Verilog is required. Syntheis required as well. Our typical customers are at the leading edge of networking, datacom, telecom, computing, and signal processing applications who have run out of steam with competing FPGAs. Duties include: Working with engineers to implement/customize their designs Presentations to engineers and managers Providing detailed technical info/ assistance Working with engineers to teach them tool flows Benchmarking customer circuits Educating customers on methods and techniques to get best results from our FPGA Evaluating and prioritizing opportunities PRoviding feedback for future products, features, and tools Converting existing design from competitors to companies FPGAs AND CHECK OUT THE COMPENSATION PACKAGE SALARY- To 100K + up to 40% design win bonus + 12 to 15% annual company bonus + 4k MBO bonus + car + cell phone and stock options. THIS IS AN EXCELLENT POSITION FOR A TALENTED DESIGNER THAT IS READY TO COME OUT FROM BEHIND THE CUBICLE. A GREAT COMPANY, A GREAT LINE OF PRODUCTS AND GREAT COMPENSATION!! LOCATIONS AVAILABLE- BOSTON, MA. AND SANTA CLARA, CA. -- EDDIE AMARA - Executive Recruiter SpencerSearch, Inc. "Specializing in the Semiconductor Industry" Voice- 972-378-0280 Fax- 972-378-0279 Email- amaraju@onramp.net Website- www.spencersearch.comArticle: 10428
In article <Et568q.1zq@world.std.com>, Joseph H Allen <jhallen@world.std.com> writes >In article <355f5eaf.6311596@news.megsinet.net>, <msimon@tefbbs.com> wrote: > >>Read a book called "Stack Computers" by Phil Koopman available free on >>the net. > >>Some of the ideas in this book are being used in a Java Engine by >>Patriot Scientific. > >I've been thinking about these stack processors, but I'm still not >convinced. They don't do particularly well with structure accesses or even >with simple block copies, and they tend to require that a lot of the stack >to be cached on the FPGA (so they're bigger). I'm not sure what you mean about simple block copies - surely this is just something which a chip either does well or doesn't do well depending on the hardware available, irrespective of whether it's a stack machine or not? Load source address to register A Load destination address to register B Load count to register C Read data at A, post incrementing A Write data at B, post incrementing B Decrement C and repeat till zero. FWIW the PSC1000 does the above loop with three 8bit opcodes for up to 2^32 iterations, these three making 3/4 of a 32bit instruction group. IMO you're right about the stacks - these ideally need to be on-chip for efficiency and this can use (for an FPGA) a fair amount of resources. An alternative is to have an external RAM for each of the two stacks like the Novix chip had. This approach, of course, uses a lot of I/O as it needs three data busses, one address bus for main memory, and two small address busses for stack memory plus associated control lines. [rest snipped] Cheers -- Keith WoottenArticle: 10429
Jeff: There's a big headline about the 5200 parts on the Xilinx support page on their web site (http://www.xilinx.com/support/support.htm). When you check the bulletin (something about a bad bitstream), the patch refers to fixing the bitstream problem AND "This fix is also included in the Core Tools #5 patch, which also contains some other 5200 related fixes for PAR." You may want to see what's up with that. -andyArticle: 10430
daveb@iinet.net.au (David R Brooks) wrote: :Brad Rodriguez <bjaa@aazetetics.com> wrote: : ::David Tweed wrote: :... ::For what it's worth, those following this thread may be amused by my ::"pathetic instruction set computer" made from discrete TTL. See ::<http://www.zetetics.com/bj/papers/piscedu2.htm>. I've occasionally ::described it as "PDP-11 meets 1802". : : Also my "Simplex-III". It's on my website (URL below). : My last post left off the URL: here it is :) -- Dave Brooks <http://www.iinet.net.au/~daveb> PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or serversArticle: 10431
On Sun, 17 May 1998 15:10:33 GMT, dave@dave-ltd.co.uk.NOSPAM (David Knell) wrote: >Anyone spot what I've got wrong? Wrong tool for the job? xor_reduce(my_bus) ; is a little nicer, and most synthesis tools should give you a half-decent result to 4000x or Spartan. Failing that, schematics is OK. Should be able to do this simply in 11 4i/p XORs and a 3i/p XOR. (or is that XNOR? no matter). 2 levels of logic max. StuartArticle: 10432
Keith Wootten wrote: ...snip... > IMO you're right about the stacks - these ideally need to be on-chip for > efficiency and this can use (for an FPGA) a fair amount of resources. > An alternative is to have an external RAM for each of the two stacks > like the Novix chip had. This approach, of course, uses a lot of I/O as > it needs three data busses, one address bus for main memory, and two > small address busses for stack memory plus associated control lines. -- The term "a lot of chip resources" is subjective, but I would implement the data stack using the dual port RAM in a Xilinx part. I have always questioned the way Xilinx designed the dual port RAM since you only get a single bit of dual port in a CLB which can otherwise support two bits of single port RAM. I usually want to implement a FIFO which does a read and a write simultaneously. That could be done while providing two RAM bits from a CLB. But when you want to perform two READs from the RAM, as in a register file or stack, this dual port implementation shines. With the appropriate control logic, you can implement the top 16 words of stack and perform almost any basic operation to the top of stack in one clock cycle. When your stack gets full, you can write a couple of words from the bottom of stack to memory. This could be thought of as a stack "cache". The Xilinx dual port RAM is also very good for straight register files. You can read any two registers and write back to one of them in a single clock cycle. Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10433
Graham Eastwood wrote: > > On Sun, 17 May 1998 13:42:38 -0700, Jeff Graham <drjeff@actrix.gen.nz> > wrote: > > > > >Has anyone else tried to migrate existing XC5200 designs to the new > >tools and what sort of success have you had ? > > > > > M1.4 failed to route three 5210's and one 5204. I even took one of the > 5210's which started at 70% CLB usage and kept stripping out logic. I > had the usage down to 20% and it still wouldn't route!! So I went back > to XACT. -- This sounds very scary to me. What happens if you just bought the M1 tool and you don't have the XACT stuff? You also wouldn't even know that this is not normal!!! The M1 tools have been out for about 5 or 6 months now. Is anyone working on this??? I assume that this is not a problem for any of the XC4000 families? Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10434
Graham Eastwood wrote: > > On Sun, 17 May 1998 13:42:38 -0700, Jeff Graham <drjeff@actrix.gen.nz> > wrote: > > > > >Has anyone else tried to migrate existing XC5200 designs to the new > >tools and what sort of success have you had ? > > > > > M1.4 failed to route three 5210's and one 5204. I even took one of the > 5210's which started at 70% CLB usage and kept stripping out logic. I > had the usage down to 20% and it still wouldn't route!! So I went back > to XACT. -- This sounds very scary to me. What happens if you just bought the M1 tool and you don't have the XACT stuff? You also wouldn't even know that this is not normal!!! The M1 tools have been out for about 5 or 6 months now. Is anyone working on this??? I assume that this is not a problem for any of the XC4000 families? Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10435
David Knell wrote: > > Hi folks, > > Just wondered if someone might be able to help before > I pull my last hair out -- I've a little bit of code > in ABEL which I'd like to use as a part of a design > going into one of the Xilinx Spartan things - an XCS30, > to be exact. All it's supposed to do is to generate > even parity over 36 signals. > > Anyway, it turns into a netlist OK; 'bit slow' thought > I, as about 30 minutes passed before the design was fitted. > 'Good Lord!' thought I, as the report showed it filling 87% > of my XCS30. What I'd think to be an equivalent drawn out > as a schematic behaves much more reasonably. > > Anyone spot what I've got wrong? > > Thanks, > > Dave > > Here's the code (with some lines wrapped to fit in the > requisite number of columns): > > module Parity > Title 'Parity' > > Declarations > > PCICBEI3..PCICBEI0 PIN; > PCICLK PIN; > PCIPARO PIN istype 'reg'; > PCIDO31..PCIDO0 PIN; > PARDELAY NODE ISTYPE 'REG'; > PAR1 NODE; > PAR2 NODE; > PAR3 NODE; > PAR4 NODE; > PAR5 NODE; > > Equations > > PAR1 = PCIDO0 $ PCIDO1 $ PCIDO2 $ PCIDO3 $ PCIDO4 $ PCIDO5 $ PCIDO6 $ > PCIDO7; > PAR2 = PCIDO8 $ PCIDO9 $ PCIDO10 $ PCIDO11 $ PCIDO12 $ PCIDO13 $ > PCIDO14 $ PCIDO15; > PAR3 = PCIDO16 $ PCIDO17 $ PCIDO18 $ PCIDO19 $ PCIDO20 $ PCIDO21 $ > PCIDO22 $ PCIDO23; > PAR4 = PCIDO24 $ PCIDO25 $ PCIDO26 $ PCIDO27 $ PCIDO28 $ PCIDO29 $ > PCIDO30 $ PCIDO31; > PAR5 = PCICBEI0 $ PCICBEI1 $ PCICBEI2 $ PCICBEI3; > > PARDELAY.CLK = PCICLK; > PARDELAY := PAR1 $ PAR2 $ PAR3 $ PAR4 $ PAR5; > > PCIPARO.CLK = PCICLK; > PCIPARO := PARDELAY; > > end Parity -- I have a dumb question. Could it be that you are solving the wrong problem? It looks like you have four bytes and one parity bit for each byte. If this is true, then you should XOR each bit in the byte along with its parity bit. But the four results from this should be ORed to find out if there was no error. If you XOR the four results (equivalent to what you are doing) you can only find odd numbers of bit errors. If you have one bit errors in two bytes, the parity will still be even! Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10436
In article <X0F+fHAUJLY1Ew92@wootten.demon.co.uk>,
Keith Wootten <Keith@wootten.demon.co.uk> wrote:
>In article <Et568q.1zq@world.std.com>, Joseph H Allen
><jhallen@world.std.com> writes
>>In article <355f5eaf.6311596@news.megsinet.net>, <msimon@tefbbs.com> wrote:
>>
>>>Read a book called "Stack Computers" by Phil Koopman available free on
>>>the net.
>>
>>>Some of the ideas in this book are being used in a Java Engine by
>>>Patriot Scientific.
>>
>>I've been thinking about these stack processors, but I'm still not
>>convinced. They don't do particularly well with structure accesses or even
>>with simple block copies, and they tend to require that a lot of the stack
>>to be cached on the FPGA (so they're bigger).
>
>I'm not sure what you mean about simple block copies - surely this is
>just something which a chip either does well or doesn't do well
>depending on the hardware available, irrespective of whether it's a
>stack machine or not?
>
>Load source address to register A
>Load destination address to register B
>Load count to register C
>
>Read data at A, post incrementing A
>Write data at B, post incrementing B
>Decrement C and repeat till zero.
>FWIW the PSC1000 does the above loop with three 8bit opcodes for up to
>2^32 iterations, these three making 3/4 of a 32bit instruction group.
Huh? Wouldn't you need something like:
1000 ; push destination address
2000 ; push source address
loop:
over ; dup destination
over ; dup source
@ ; replace source with contents
! ; write contents to destination
2 ; increment source
add
swap ; increment dest
2
add
swap
...
I.E., 10 instructions to move each word (unless I'm really missing something
about these 0-address top of stack machines). Maybe 8 if you have an
increment by 2 instruction. The load and store each require at least 2
cycles and the rest require at least one each, so that's 10 cycles per word.
A one-address machine with indexing (and a 16-bit accumulator) needs:
loop:
lda 0,r1
sta 0,r2
lda 1,r1
sta 1,r2
...
I.E., two instructions per move.
>IMO you're right about the stacks - these ideally need to be on-chip for
>efficiency and this can use (for an FPGA) a fair amount of resources.
>An alternative is to have an external RAM for each of the two stacks
>like the Novix chip had. This approach, of course, uses a lot of I/O as
>it needs three data busses, one address bus for main memory, and two
>small address busses for stack memory plus associated control lines.
>Keith Wootten
--
/* 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: 10437I had a similar problem with 5200 design. I had wide compares, I shortened them to only 4 bit resolution for simulation purposes. Then increased them back to 16 bit. I worked in F1.3 but won't in F1.4. I have since converted this section of the design to schematic (it is very ugly, but hey it works) Anyway the problem was with in DATA I/O able. There was a work around, it was a single line of code added to the declarations to allow greater than 4 inputs. I don't remember the line, since I just avoided the able, too much grief.Article: 10438
John Huang wrote: > > Hi: > I 've a problem with my design , could anyone can tell me that > 3.3V and 5V chip has any differents? > My current design using altera 10K20-3, it's 5V I/O chip, but > its speed is too slow that does not suit my timing, I've contact the > sales of altera, he tell me the -3 is the fastest chip of 10K20, If > I want a faster chip, they have 10K70 for -1, but it is 3.3V, but > my board's I/Os are connect to 5V chip, I wonder if they can't > work fine, can I replace 10K20 for 5V to 10K70 for 3.3V directly > ? > > John Huang > if you'll check the altera data book 1998 on page 57 there's an explanation on how to interface 3.3V devices to 5V I/O . 3.3V devices are tolerant to 5V inputs and can output 5V if you connect the VCCINT pin. benny.Article: 10439
Joseph H Allen wrote: > >FWIW the PSC1000 does the above loop with three 8bit opcodes for up to > >2^32 iterations, these three making 3/4 of a 32bit instruction group. > > Huh? Wouldn't you need something like: > > 1000 ; push destination address > 2000 ; push source address > loop: > over ; dup destination > over ; dup source > @ ; replace source with contents > ! ; write contents to destination > 2 ; increment source > add > swap ; increment dest > 2 > add > swap > ... > > I.E., 10 instructions to move each word (unless I'm really missing something > about these 0-address top of stack machines). No, you are just missing a few special case operations of the PSC1000. There are two address registers (A and top of returnstack) which allow addressing with postincrement mode. And there is a counter and a decrement and branch if not zero instruction. The PSC1000 is not really a MISC processor. -- Bernd Paysan "Late answers are wrong answers!" http://www.jwdt.com/~paysan/Article: 10440
In article <Et6LoJ.LE0@world.std.com>, Joseph H Allen
<jhallen@world.std.com> writes
>In article <X0F+fHAUJLY1Ew92@wootten.demon.co.uk>,
>Keith Wootten <Keith@wootten.demon.co.uk> wrote:
>>In article <Et568q.1zq@world.std.com>, Joseph H Allen
>><jhallen@world.std.com> writes
>>>In article <355f5eaf.6311596@news.megsinet.net>, <msimon@tefbbs.com> wrote:
>>>
>>>>Read a book called "Stack Computers" by Phil Koopman available free on
>>>>the net.
>>>
>>>>Some of the ideas in this book are being used in a Java Engine by
>>>>Patriot Scientific.
>>>
>>>I've been thinking about these stack processors, but I'm still not
>>>convinced. They don't do particularly well with structure accesses or even
>>>with simple block copies, and they tend to require that a lot of the stack
>>>to be cached on the FPGA (so they're bigger).
>>
>>I'm not sure what you mean about simple block copies - surely this is
>>just something which a chip either does well or doesn't do well
>>depending on the hardware available, irrespective of whether it's a
>>stack machine or not?
>>
>>Load source address to register A
>>Load destination address to register B
>>Load count to register C
>>
>>Read data at A, post incrementing A
>>Write data at B, post incrementing B
>>Decrement C and repeat till zero.
>
>>FWIW the PSC1000 does the above loop with three 8bit opcodes for up to
>>2^32 iterations, these three making 3/4 of a 32bit instruction group.
>
>Huh? Wouldn't you need something like:
>
> 1000 ; push destination address
> 2000 ; push source address
>loop:
> over ; dup destination
> over ; dup source
> @ ; replace source with contents
> ! ; write contents to destination
> 2 ; increment source
> add
> swap ; increment dest
> 2
> add
> swap
> ...
>
>I.E., 10 instructions to move each word (unless I'm really missing something
>about these 0-address top of stack machines).
[snipped]
Yes, if your stack machine were to be *only* a hardware implementation
of the 'standard' Forth virtual machine. Stack machines (actual Silicon
ones) never implement exactly and only this or any other virtual
machine, but always add extra useful instructions.
eg on the PSC1000 (using Patriot's syntax and after loading the three
registers)
align to 4 byte boundary
copying
ld[x++] \ push TOS with (x) and increment x by 4
st[r0++] \ pop TOS to (r0) and increment r0 by 4
mloop copying \ decrement ct and goto copying if non-zero
which is three 8bit opcodes. The mloop instruction works with up to
three preceeding opcodes in the same 32bit (four instruction) memory
group. Other stack machines do differently, just as register based
machines do (eg Z80 block move), but I don't know of any which would be
limited to the Forth virtual machine. This is really my point - IMO
block moving ability is pretty much unconnected to the *fundamental*
chip architecture. In the above example, the stack isn't really used as
a stack, just a convenient transfer register.
Cheers
--
Keith Wootten
Article: 10441Hi folks, Thanks for all your help.. I hadn't realised that I was giving the poor thing something that it could be expected to find indigestible. Some results: Coding the thing using equations XORing together pairs of inputs in a hierarchy worked rather better than XORing them in 8s, but the result was still nowhere near as good as a schematic featuring 4x9-input XORs and 1x4-input XOR. I've managed not to bring the numbers with me, but if anyone's interested, let me know and I'll endeavour not to forget. Thanks again, DaveArticle: 10442
Hi,
I am trying to build some kind of architecture to delay a signal
(typical delay ranging from 1 to 3 useconds). I have thought of doing it
with chained flip-flops, but if I have a fast clock signal, it will
waste a big amount of resources. Also, a FIFO could be an option, but it
would spend lots of resources as well.
Is there any other possibility to do it?.
Thanks in advance.
__________________________
Alfredo Rosado Muņoz
GPDS. U. Valencia.
C/ Dr. Moliner, 50.
Burjassot. Valencia. SPAIN.
e-mail: alfredo.rosado@uv.es
Article: 10443>There's a big headline about the 5200 parts on the Xilinx support >page on their web site (http://www.xilinx.com/support/support.htm). >When you check the bulletin (something about a bad bitstream), the >patch refers to fixing the bitstream problem AND "This fix is also >included in the Core Tools #5 patch, which also contains some other >5200 related fixes for PAR." > >You may want to see what's up with that. > We are currently using Core Tools #10 patch, but it doesn't help.Article: 10444
Alfredo, With what degree of precision must you delay your signal? In the crudest terms, lets say you have three flops (in serial) each clocking at a 1 us rate: What goes in comes out 3 us later. OK, that's probably not what you'd want BUT, how about 30 flops (or FIFO stages) clocking at 0.3 us? You get the idea. More precision / resolution --> more flops at a higher rate. Plan 'B': use an counter! On the occurrence of your signal, release a counter that was held in reset. After N clocks of frequency, the count value reaches N which then signals the completion of your delay period. To get a bit more technical, the latter approach would implement an inertial delay the former, a transport dely. Best wishes. -- Ed McCauley Bottom Line Technologies Inc. Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, (908) 996-0817 FAX: (908) 996-0817 Alfredo Rosado wrote: > > Hi, > I am trying to build some kind of architecture to delay a signal > (typical delay ranging from 1 to 3 useconds). I have thought of doing it > with chained flip-flops, but if I have a fast clock signal, it will > waste a big amount of resources. Also, a FIFO could be an option, but it > would spend lots of resources as well. > Is there any other possibility to do it?. > Thanks in advance. > > __________________________ > Alfredo Rosado Muņoz > GPDS. U. Valencia. > C/ Dr. Moliner, 50. > Burjassot. Valencia. SPAIN. > e-mail: alfredo.rosado@uv.esArticle: 10445
Sorry, this news article is in German language only:
Aktuell ist in der bekannten KOCHBUCH-Reihe erschienen:
"Das FPGA-Kochbuch", Markus Wannemacher
International Thomson Publishing
416 Seiten, 103 Abbildungen, 74 Tabellen
mit einem Geleitwort von Prof. Waldschmidt
gebunden, mit CD-ROM, ISBN 3-8266-2712-1
79,- DM, 1998, ab sofort lieferbar
Online-Infos + Probetexte:
http://www.fernuni-hagen.de/IT/FPGA/kochbuch
Aus dem Inhalt:
- Grundlagen: Was ist ein FPGA?
- Anwendungen & Entwurfsmethoden, VHDL
- Programmiertechnologien: SRAM, Antifuse, Flash
- FPGA-Bausteine: Uebersicht, Auswahl- und Vergleichskriterien
- Designwerkzeuge: Electronic Design Automation Programme
(EDA) im Vergleich
- Entwurfsrichtlinien, Tips, Ausblick & Trends, Investitionsplanung
- Glossar, FPGA-Adressenliste u.v.m.
Das Buch bietet eine umfassende Einfuehrung in den Schaltungsentwurf mit
Feldprogrammierbaren Gate Arrays (FPGAs). Alle am Markt befindlichen
Bausteinfamilien werden ausfuehrlich vorgestellt . Der Entwickler
erhaelt Kriterien, die ihm die Auswahl des geeigneten FPGAs erleichtern.
Der Autor erklaert ausfuehrlich den Entwurfsablauf, die verschiedenen
Programmiertechnologien und die Anwendung neuer Entwurfsmethoden. Die
dazu benoetigen Werkzeuge (EDA-Programme) werden mit ihrem Leistungs-
umfang vorgestellt.
Der umfangreiche Anhang mit Glossar und FPGA-Kontaktadressen sowie
die beiliegende CD mit Datenblaettern, Designsoftware und einem VHDL-
Online-Tutorial machen das Buch zu einem unentbehrlichen Leitfaden
bei der FPGA-Entwicklung.
Weitere Infos gibts online oder auf Anfrage per E-Mail
Markus Wannemacher
---
mailto:markus.wannemacher@fernuni-hagen.de
http://www.fernuni-hagen.de/IT/FPGA/kochbuch
Article: 10446I may have missed the original post, but may I ask why anyone wants to do this project? Is it just an exercise? Many people have thought about doing a CPU in an FPGA, but AFAIK it is always a futile exercise because one can buy a CPU with a given capability for far less than the cost of the FPGA. Certainly one can build a simple microsequenced device in an FPGA, but by the time one has added support for stacks, interrupts, and such, the logic grows too much. If someone wants to do an exercise, what *would* be useful is a public domain design for something good and common, e.g. a Z80, in either schematics or VHDL. Then one could incorporate this into an ASIC - that is where a CPU core really comes in handy. Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 10447
There are a number of good reasons for doing a small CPU in
an FPGA:
* Cost and size: With a single $20 chip, you get a CPU, which is
as fast or faster than common 8-bit or 16-bit embedded control
CPUs, *plus* you get all your peripheral logic for ports,
timers, UART, etc. For example, the 68HC11 is still very
commonly used in small robotics apps, and it only runs at
a few MHz. I expect at least 10 MHz from a carefully designed
FPGA-based CPU; 30 MHz or better with good pipelining.
* Performance: You can use reconfigurable computing techniques
to customize CPU instructions, and/or include "accelerator"
hardware to increase performance on your specific app.
* Education: The guts of the CPU and its peripherals are
completely open for inspection and modification. It's
an ideal teaching tool for undergraduates to get hands-on
exposure to hardware architecture and systems design.
* Satisfaction: Building a small computer from the gates up
through the instruction set architecture up through the
OS and compiler up to apps is a very satisfying exercise,
akin to building one's own small sailboat. It can be a
potent antidote to the shrink-wrapped proprietary HW and
SW we generally must live with.
--Mike
Peter wrote:
>
> I may have missed the original post, but may I ask why anyone wants to
> do this project? Is it just an exercise?
>
> Many people have thought about doing a CPU in an FPGA, but AFAIK it is
> always a futile exercise because one can buy a CPU with a given
> capability for far less than the cost of the FPGA.
>
> Certainly one can build a simple microsequenced device in an FPGA, but
> by the time one has added support for stacks, interrupts, and such,
> the logic grows too much.
>
> If someone wants to do an exercise, what *would* be useful is a public
> domain design for something good and common, e.g. a Z80, in either
> schematics or VHDL. Then one could incorporate this into an ASIC -
> that is where a CPU core really comes in handy.
>
> Peter.
>
> Return address is invalid to help stop junk mail.
> E-mail replies to zX80@digiYserve.com but
> remove the X and the Y.
Article: 10448You can use unbonded pads to add delay like setup in the following manner: ->---------------------[OBUF]-----[UPAD]----------[IBUF]-----> The delayed signal is the output of the IBUF. This should add at least 7ns of delay in a 4000XL-09 device. If you want to get an idea of the min delay expect a conservative 50% out of the max delay reported in the static timing analyzer. In article <35614A77.D253C2E3@uv.es>, Alfredo Rosado <alfredo.rosado@uv.es> wrote: >Hi, > I am trying to build some kind of architecture to delay a signal >(typical delay ranging from 1 to 3 useconds). I have thought of doing it >with chained flip-flops, but if I have a fast clock signal, it will >waste a big amount of resources. Also, a FIFO could be an option, but it >would spend lots of resources as well. > Is there any other possibility to do it?. > Thanks in advance. > >__________________________ >Alfredo Rosado Muņoz >GPDS. U. Valencia. >C/ Dr. Moliner, 50. >Burjassot. Valencia. SPAIN. >e-mail: alfredo.rosado@uv.es >Article: 10449
Peter wrote in message <3561443d.214920709@news.netcomuk.co.uk>... > >I may have missed the original post, but may I ask why anyone wants to >do this project? Is it just an exercise? > >Many people have thought about doing a CPU in an FPGA, but AFAIK it is >always a futile exercise because one can buy a CPU with a given >capability for far less than the cost of the FPGA. You're right. But what fun! I used to envy processor designers in industry and academia. Now I can do my own processors, on-chip peripherals, cache, etc. In fact, I have it far better. I can design the entire system, the ISA, the microarchitecture, and get working hardware in a few days. In contrast, the typical big company CPU designer works for months at a stretch on a small piece of a huge and complex system. And there is a certain pleasure in minimalism and self-sufficiency. It is one thing to read about simple microarchitectures in H&P, it is another to go build and debug and boot them. You can "squish the CLBs between your toes" -- you become familiar with the same pipe stages, clock speed, area, IPC tradeoffs, although your units are CLBs and ns rather than rbes and ps. The resulting designs are only as fast as seven year old commodity processors, but that's OK. Maybe 20X a VAX is fast enough for your application -- you don't need 200X a VAX. And whether you have a StrongARM, an R4640, or a custom FPGA CPU, you are using the same external memory, more or less -- cache misses still cost 100 ns. True, commodity processors are cheaper on an absolute basis, especially if you don't take into account total system cost. But FPGA prices are coming down. By end of 1998, the Xilinx XCS20 will be $6.50 Q100K (ref: http://www.xilinx.com/prs_rls/spartan.htm). This part, equivalent to the XC4010 that hosts the J32 (1995), can implement a 33 MHz conventional pipelined 32-bit RISC processor leaving 5,000 gates of logic for system-on-chip peripherals. You will soon be able to build highly integrated and customized glueless systems with just FPGA+SDRAM for ~$10. And there is the soon-to-be-$3 XCS05, adequate for a nice little 10 MIPS 16-bit processor with logic to spare. Implications/Predictions (some from other folks) * falling FPGA prices will eventually clamp an upper bound on the price of many custom parts, including embedded CPUs * RISC CPU design is no longer rocket science -- HDLs, tools, and the FPGA's abstraction of all the hard EE, means that undergrads will increasingly design their own processors. Of course, these designs will never complete with commodity microprocessors for specmarks. * a number of these designs will be published under GPL or put in the public domain. There will be communities of users of certain free CPU designs, similar to the open software movement. There will be GCC tools chains, lunatic fringe Linux ports, etc. * there will be free implementations of legacy ISAs. Or perhaps free implementations of cross-assemblers/cross-loaders from legacy ISAs to simplified minimalist FPGA CPU ISAs. * embedded CPU vendors will start to ship with some FPGA on chip (Motorola and Atmel have announced this). Jan Gray (J32 described at http://www3.sympatico.ca/jsgray/homebrew.htm)
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