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
The advantage the FPGA gives you is the ability to get EXACTLY the processor you want to solve a given problem. Say you don't need as many registers as a standard design but a 32bit Real Time Clock counter would be handy. No problemo. In a design as done today you got to add the counters externally if the on chip ones don't meet your needs plus some glue logic. I was recently faced with this problem with a 68332. I would have loved to trade some of the TPU logic for a 32 bit atomic counter (latches all 32 bits at once for readout. With the counter clock gated so I could start a number of them simultaneously). Instead I had to do an expensive (in CPU time) interrupt driven counter (10,000 interrupts a second). We met spec but there is no design margin. OTOH the system is designed to fail gracefully. Simon ============================================================ tgg@hpl.hp.com () wrote: >How does it compare with the MicroChip PIC devices. My personal suspicion is >that the PIC devices are smaller (probably), cheaper (certainly), faster >(probably), more peripherals such as timers/adc/dac/etc (certainly), >more software support (certainly). > >Any corrections to the above suspicions would be welcome. Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12876
On Mon, 2 Nov 1998 17:21:20 GMT, jhallen@world.std.com (Joseph H Allen) wrote: >In article <3657a81c.174862048@news.demon.co.uk>, >Brian Drummond <brian@shapes.demon.co.uk> wrote: >>On Sun, 1 Nov 1998 16:35:17 GMT, jhallen@world.std.com (Joseph H Allen) >>wrote: > >>>In article <F1qvxI.MzK@hplb.hpl.hp.com>, <tggNoSpam@hpl.hp.com> wrote: >>>>How does it compare with the MicroChip PIC devices. My personal suspicion is >>>- Can not jump to computed addresses (only direct addresses). > >>Minor correction - ADDWF PC,1 >>(from memory) but it worked fine. > >But doesn't this only affect the lower 8-bits of the PC? I guess it's >better than nothing though. Well, so did just about everything else, so I just got used to that ;) Did anyone ever get round to writing a proper assembler that correctly inserted all the right page bits and bank select bits? I kept meaning to, but somehow there never seemed to be enough time left after debugging... - BrianArticle: 12877
In article <36441df6.89059010@news.demon.co.uk>,
Brian Drummond <brian@shapes.demon.co.uk> wrote:
>On Mon, 2 Nov 1998 17:21:20 GMT, jhallen@world.std.com (Joseph H Allen)
>wrote:
>
>>In article <3657a81c.174862048@news.demon.co.uk>,
>>Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>>On Sun, 1 Nov 1998 16:35:17 GMT, jhallen@world.std.com (Joseph H Allen)
>>>wrote:
>>
>>>>In article <F1qvxI.MzK@hplb.hpl.hp.com>, <tggNoSpam@hpl.hp.com> wrote:
>>>>>How does it compare with the MicroChip PIC devices. My personal suspicion is
>
>>>>- Can not jump to computed addresses (only direct addresses).
>>
>>>Minor correction - ADDWF PC,1
>>>(from memory) but it worked fine.
>>
>>But doesn't this only affect the lower 8-bits of the PC? I guess it's
>>better than nothing though.
>
>Well, so did just about everything else, so I just got used to that ;)
>
>Did anyone ever get round to writing a proper assembler that correctly
>inserted all the right page bits and bank select bits? I kept meaning
>to, but somehow there never seemed to be enough time left after
>debugging...
What I'd like to see for the PIC is an assembler which automatically
generates state-machine based subroutine threading to circumvent the limited
stack on the smaller CPUs:
int state;
subroutine A:
...
if(state&1) goto C
if(state&2) goto E
subroutine B:
...
state|=2; goto A
E: state&=~2
...
if(state&4) goto D
if(state&8) goto F
main:
state|=1; goto A
C: state&=~1;
state|=4; goto B
D: state&=~4;
state|=8; goto B
F: state&=~8;
...
There's lots of room for optimizations here since different parts of the
subroutine call hierarchy can overlap the use of bits in 'state'. Also leaf
subroutines would automatically use the hardware stack. There are probably
further optimizations based on being able to add to the low byte of PC.
--
/* 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: 12878Steve Casselman wrote: > > > > I think antifuses aren't visible optically since a programmed > > >conductive antifuse differs from a non-conductive one only by a small > > >diffusion surface. That might be the advantage of antifuse FPGAs over > > >ASIC ICs. > > > > I would bet you could do something like a CAT or > PET scan - NMR or something like that. Maybe > using techniques like xray crystallography. > > For $350,000,000 I could just about buy > Actel! There are several reasons that your imaging suggestions won't work for determining the programmed state of an anti-fuse device. 1) CAT, PET and NMR scanners and X-ray crystallography machines do not have anywhere near the resolution to view the near micron dimensions that these devices are made of. 2) CAT, PET and NMR can not distinguish the molecular structure of this type of material. CAT is just an imaging method using X-rays. The changes to the anti-fuse will not be distinguishable in a CAT scan. PET and NMR also will not show the subtle changes in an anti-fuse. 3) None of these methods will do a good job of penetrating the metalization layers which lie on top of the anti-fuses. The only one of the above methods that has a chance is to use an X-ray crystallography machine. But I don't know of one that would have the low micron resolution you would require. So problems 1 and 3 remain. Since the antifuses connect metal traces together, couldn't a simple electron microscope be used in a voltage contrast mode to determine which traces are connected and therefore which antifuses are antifused? I have seen videos of circuits operating under an electron microscope. I would assume that one could devise a way to run the circuit at a slow speed and stimulate it to toggle all of the various traces. This sounds a lot like the test vector fault coverage problem. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12879
Could someone please explain the xilinx format of the .bit file? We want to strip out the header and have a processor serialize and toggle these bits into the xilinx fpga in slave serial mode. We want to use the .bit file as opposed to a prom formatted file to save space. ThanksArticle: 12880
I cannot get an xchecker cable to work with an XC95144 , using M1.5; however the same boardm with a 95216 on it, can be programmed using the EZTAG software from XACT STEP. When the 95144 came out , I switched production to use it because of the cost reduction. The old software will not program this device because it says that it is more recent than the software (despite me adding the relevant BSDL files in). So either way, I am in a pickle ! Can anyone help, or has anyone had similar problems ? The new software does not 'see' the cable, when I use the 'cable autoconnect ' command. I have looked on the Xilinx web page (I downloaded a patch as a result of this - no difference) , but to no avail, and I have also spoken to their tech-support. Dunstan PowerArticle: 12881
In a few years we can buy "virtual chips". You will have to spend one of your prepaid code numbers to enable the chip. There will be free "engineering samples". It will be almost the same like now, but without PCB. Any comments ? Manfred KrausArticle: 12882
In article <2992940395@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
>Subject: Re: New free FPGA CPU
>From: Bruce@hoult.actrix.gen.nz (Bruce Hoult)
>Date: Tue, 3 Nov 1998 12:19:55 +1300
>I haven't seen anyone dispute the claim that this is the only public domain
>CPU
>design. Unless such a claim arises, the Trailing Edge is in a field of one,
>and
>therefore has an absolute technical advantage.
>Are you aware of a better design which is public domain?
Since 1993 we have a laboratory course at our university, in which
students develop a full 16-bit processor, using one XILINX FPGA (using
WORKVIEW CAD-Software):
- 128 kByte memory-address
- 128 kByte i/o-address
- 5 Interrupt levels
- 3-address instructions
- 0.3 MIPS
- less than 2000 gate-functions
Two students have built a complete computer using this prozessor:
1. FPGA: processor
2. FPGA: graphics controller: 640x400 pixels, 2 pages, 2 colors out of 8
3. FPGA: - SCSI controller
- Keyboard controller
- Timer
4. FPGA: - parallel interface
- seriell interface
Multi-tasking operating system (also multiple shells can be startet)
The computer is built using only the 4 XILINX FPGA, static ram and rom
chips and line drivers. The only other components used were the hard-disk,
floppy-disk-drive, power supply, keyboard and monitor).
We are now making a redesign of the CPU with a memory management
included (16 MByte virtual address space for each task, protection
mechanism for multitasking).
The documentation and software can be downloaded from:
ftp://137.193.64.130/pub/xproz/
Article: 12883Hallo Jürgen, Have you looked at Don Lancasters's MAGIC SINEWAVES? Check out http://www.tinaja.com/magsn01.html ManfredArticle: 12884
From the archive (Tue, 7 Jul 1998 04:00:56) The bit file can not be used directly, because it has a variable length header at the beginning. After the header, the remaining data is directly downloadable, so all you need to do is either create a new file with the header removed, or do what I do: leave the header in there, and the download routine knows how to skip the header. Here's how: 00 00 09 0F F0 0F F0 0F F0 0F F0 00 00 01 61 00 0D a 10 73 72 61 6D 74 65 73 74 2E 6E 63 64 00 62 00 0C sramtest.ncd b 20 34 30 32 38 65 78 68 71 32 34 30 00 63 00 09 39 4028exhq240 c 9 30 38 2F 30 35 2F 32 30 00 64 00 09 31 34 3A 32 31 8/05/20 d 14:21 40 3A 33 36 00 65 00 01 46 43 FF 20 A3 21 1F 5F F7 :36 e FC ! _ 50 EF DE F7 EF 7D FD EF 7E F7 EF 7D FD FB DF B5 FB } ~ } The FF 20 is the real start of the bitstream, so just skip over stuff till you see this sequence (at byte 49 in my example), then start sending bits, including the FF 2X . Remember that the data is shifted from the MSB of each byte in sequence, so the starting sequence is ALWAYS 1 1 1 1 1 1 1 1 0 0 1 0 Note that the '0' of the '20' is the top nibble of the length code, and for chips up to XC4044, it is '0'. For 4052XL, 4062XL, and 4085XL it is a '1', so look for FF 21 Philip Freidin In article <01be074b$f6911f00$1f38d926@dank.i-tech.com> "Dan Kuechle" <dan_kuechle@i-tech.com> writes: >Could someone please explain the xilinx format of the .bit file? We want >to strip out the header >and have a processor serialize and toggle these bits into the xilinx fpga >in slave serial mode. We want to use the .bit file as opposed to a prom >formatted file to save space. > >ThanksArticle: 12885
Simon, what surprises me a bit is that we do not see around processors with embedded FPGA (m.b. small one) on the chip. Or did I miss something? Maxim msimon@tefbbs.com wrote: > > The advantage the FPGA gives you is the ability to get EXACTLY the > processor you want to solve a given problem. > > Say you don't need as many registers as a standard design but a 32bit > Real Time Clock counter would be handy. No problemo. > > In a design as done today you got to add the counters externally if > the on chip ones don't meet your needs plus some glue logic. > > I was recently faced with this problem with a 68332. I would have > loved to trade some of the TPU logic for a 32 bit atomic counter > (latches all 32 bits at once for readout. With the counter clock gated > so I could start a number of them simultaneously). Instead I had to do > an expensive (in CPU time) interrupt driven counter (10,000 interrupts > a second). > > We met spec but there is no design margin. OTOH the system is designed > to fail gracefully. > > Simon > ============================================================ > tgg@hpl.hp.com () wrote: > > ?How does it compare with the MicroChip PIC devices. My personal suspicion is > ?that the PIC devices are smaller (probably), cheaper (certainly), faster > ?(probably), more peripherals such as timers/adc/dac/etc (certainly), > ?more software support (certainly). > ? > ?Any corrections to the above suspicions would be welcome. > > Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12886
In article <2992940395@hoult.actrix.gen.nz>,
Bruce Hoult <Bruce@hoult.actrix.gen.nz> wrote:
)jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes:
)> In article <2992718904@hoult.actrix.gen.nz>,
)> Bruce Hoult <Bruce@hoult.actrix.gen.nz> wrote:
)> )Perhaps you would be so kind as to present your favourite design, or
)> )provide public pointers to it?
)>
)> Can't. They're proprietary.
)
)Well, there's the problem. You've got access to what you say are better designs.
)The rest of us haven't. QED.
No, I didn't say better. What I said was specialized/optimized. That's
entirely different. In my experience, when one uses one of these FPGA or
ASIC specials, they are used because they optimize some particular
aspect of operation. The ones I have used optimize serial communications
at high data rates. In any given application, that may or may not be
what you want. Their instruction sets are *very* weak at memory
addressing and fairly weak with arithmetic (no signed arithmetic, for
example). If they weren't better for some particular application, one
would use an ordinary uController for $$ less.
)> But you still haven't addressed my question. What is there about this
)> design which makes it desirable? IOW, what does it excel at? If its
)> only advantage is that it is public domain,
)
)That's a biggie.
No, because I can get decent uControllers for less, and then not have
the hassle of also having to wait for them to download their pogramming.
This can take a few 100 milliseconds. There are other drawbacks, like
current draw, for example.
)Another advantage is that is does seem to be an easy target for HLL compilers
)for typical stack-oriented languages such as C/Pascal etc. It's certainly
)much better than the likes of the 6800/6502/8080/Z80, even if you ignore the
)16 bit vs 8 bit question, as all those chips had no or poor support for accessing
)stack frames and for creating position independent code.
Well, now you are talking about computers rather than uControllers, and
for that I'd use an 8088, which has good memory addressing.
)It might be a closer race against the 6809 which had good stack support, good PIC
)support, and could be treated as a 16 bit chip if you squinted at it right.
Well, I'd have to squint pretty hard to consider the "D" register as
making it a 16 bit machine. No 16 bit logical operations, for one thing.
)> then it doesn't have a technical advantage, and that's the only reason for doing
)> a specialty, seems to me.
)
)I haven't seen anyone dispute the claim that this is the only public domain CPU
)design. Unless such a claim arises, the Trailing Edge is in a field of one, and
)therefore has an absolute technical advantage.
I see "public domain" and "technical advantage" as not even being part
of the same abstract space, let alone one being an part of the other.
)Are you aware of a better design which is public domain?
Being public domain is irrelevant, since the competing non-public domain
processors do not charge royalties.
[snip]
)It's also very helpful to be able to actually build your own machine. I didn't
)do that until my 3rd year of university, when two friends and I designed, built,
)and programmed our own wire-wrapped 6809 computer. After building the hardware,
)we created a BCPL compiler (well, VAX-based 0Code to 6809 compiler) and a PROLOG
)interpreter for it.
If that is what this is about, learning what makes a computer, then the
netlist or VHDL or whatever is not very helpful for that. I designed and
built a 4 bit computer out of DTL *gates* in order to understand how a
computer worked. THAT is how to figure such things out "by doing" if one
considers "by doing" the best way to learn.
)If this CPU -- or one like it -- had available a small OS/program loader, a C
)compiler (gcc cross compiling from Mac/Windows/Linux would be fine), a GUI-based
)simulator, and a simple and cheap design for a curcuit board that you could make
)youself with parts from Dick Smith Electronics (or Radio Shack in the US) it
)would be an incredible educational thing. *Especially* if the CPU, compiler and
Why? Why not just use a 68HC11 for this purpose? It's available and
cheap, and doesn't require a fancy programmer.
So far the only "thing this processor excels at" that I've seen is "it
is public domain".
Again, not knocking it. I want to know WHAT IS IT GOOD FOR, except being
a toy?
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
Article: 12887
In article <363e94d0.0@139.134.5.33>, Saddle <saddle@bigpond.com> wrote:
)I for one would like to have a copy of the design and play with it, so that
)I will understand how it is done. Whether or not I use it in a real app, I
)will reserve my answer on that until I've seen it. But it does fire my
)imagination and may lead to me designing/using one.
)
)
)You might also say "Why bother programming for a living, lots of people do
)it already, probably as well if not better than you".
)
)
)Regards,
)
)Saddle (In the land of OZ)
You apparently did not read my question at all. My question was not "Why
do such a uController?" My question was "Why should I use it?" They are
entirely different questions.
Let me show you the difference:
Consider the "Small C" compiler by Hendrix et. al. At the time, it was
the *only* C compiler for the 8080 which was affordable by hobbiest
types. So there was no question about "Why do it" and likewise no
question about "Why use it". But today the *only* reason to fiddle with
it on ordinary platforms (like the PC) is just to fiddle. But there is
*no* reason to use Small C on a normal platform, because better and
better supported compilers exist for them. So the question "Why
do/diddle with Small C?" has the answer "Just to diddle and learn about
a small but interesting toy compiler." But "Why should I use Small C?"
probably has the answer "You shouldn't."
That is not a knock against Small C.
I did not ask the question "Why would anyone create such a thing as a
uController in an FPGA?" I asked "Why should I use this chip?" And so
far it looks like the answer is "You shouldn't."
And that is not a knock against the uController, either.
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
Article: 12888Bruce Hoult (Bruce@hoult.actrix.gen.nz) wrote: : I've been wondering for some time how to give a child the same sort of : experience I had back when I learned about the internals of computers. A friend and I were talking about this the other day. He is hoping the Lego Mindstorms set with the H8 based RCX brick will have some of the same effect. You of course have to shed their software and anything approaching schematics comes from the reverse engineering community but the system is simple enough to understand the whole thing. And it has great hands on opportunities. -Z-Article: 12889
Maxim Golov wrote: > > Simon, > > what surprises me a bit is that we do not see around processors with > embedded FPGA (m.b. small one) on the chip. Or did I miss something? > > Maxim I have seen that discussed by the manufacturers a few times. But I believe that the problem is one of a proliferation of varieties. There are many variations of most processors as well as many members of each family of FPGA. I would guess that the vendor could not find a match of processor and FPGA that would suit a large customer base. The only way to meet diverse requirements would have been to have a range of processors matched against a range of FPGAs which would have driven way up the number of components to be inventoried. Another issue is one of support. An FPGA company won't want to create a product requiring a totally new and different set of support requirements. A CPU manufacturer has the same problem if they don't already make FPGAs. But even if they do, this product will require a level of coordination that neither department will be used to. If I remember correctly, Motorola was going to come out with a DSP or CPU with their FPGA on board (I forget the name). But they decided to kill the line of FPGAs and the combo chip died with it. This was just a few months ago if my memory is correct. Perhaps someone else will recognize the inherent advantages of a combination device and pick up the torch. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12890
Rickman wrote:
> 1) CAT, PET and NMR scanners and X-ray crystallography machines do not
> have anywhere near the resolution to view the near micron dimensions
> that these devices are made of.
the thickness of an ono antifuse is on the order of 100 angstroms. the
programmed width is definitely submicron. an article by chiang, et. al,
mentions a diameter of a few hundred nm. see 92 symposium on vlsi technology
digest of papers.
---------------------------------------------------------------------
> Since the antifuses connect metal traces together,
<snip>
until the recent SX family, the antifuse connections were made between the
substrate and polysilicon. the SX is their first where they used a
"metal-to-metal" configuration. that is also the configuration used by
quicklogic and utmc. lockheed-martin uses the diffision-poly connections on
an actel-derived
antifuse.----------------------------------------------------------------------
rk
Article: 12891
In article <71nlti$ail$1@relay1.dsccc.com>,
Mike McCarty <jmccarty@sun1307.spd.dsccc.com> wrote:
>I did not ask the question "Why would anyone create such a thing as a
>uController in an FPGA?" I asked "Why should I use this chip?" And so
>far it looks like the answer is "You shouldn't."
(1) do you mean microcontroller or microprocessor?
(2) If the former, it's because "you can customise the I/O more than you
can with a single-chip microcontroller".
(3) If the latter, it's because "You can add a bit of RAM and I/O and turn
into a single-chip microcontroller, see (2)".
The final answer is, to cut down the part count for a custom project.
Same reason you might use Forth instead of C (small or otherwise).
--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
`-_-' "Heb jij vandaag je wolf al geaaid?"
'U`
"Tell init(8) to lock-n-load, we're goin' zombie slaying!"
Article: 12892In article <2992940395@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > I haven't seen anyone dispute the claim that this is the only public > domain CPU design. Unless such a claim arises, the Trailing Edge is > in a field of one, and therefore has an absolute technical advantage. Well, Joseph's CPU isn't in the public domain. It is copylefted. There are other cpus available under similar types of licenses out there as well, ranging from clones of an 8051 to the simplified MIPS used in H&P's computer architecture text. > I've been wondering for some time how to give a child the same sort > of experience I had back when I learned about the internals of > computers... > I beleive that I got an incredible good grounding from this, but it is totally > impossible to approach a modern PC or Mac in the same way. They are far, far > more complex machines. In my opinion, it is reasonable to treat a PC this way, modulo the grottiness of many aspects of the "design" (maybe a lesson on how not to design a system...) The main problem is documentation--it's available, but scattered and it can be moderately expensive to build up a technical library on all the hardware aspects of a PC. Sam Paik -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12893
Actually, the header is parsable: You look for the 'a' which is at a fixed location (0x0E), and the word following gives an offset forward from the current position: following the 'a', you have the word (0x000D). If you seek +0x000D+0x01 in the file, then you get to a 'b' character. Repeat again, seeking +0x000C+0x01, and you come to a 'c'. Get the pattern yet? Keep this up and you will then come to an 'e'. This gives a seek of +0x0001+0x01, which drops you onto the FF 20. These are the beginnings of the bitstream. The 'FF' is a fill byte, the '2' is the preamble code, the '0' and 'A3' and '21' make up the 24 bit length count, etc. (These are in the Xilinx data books) Hope this helps Matthew Robinson [Opinions stated in this message are solely mine, and may not represent those of my employer.] Philip Freidin wrote in message ... --snip-- >00 00 09 0F F0 0F F0 0F F0 0F F0 00 00 01 61 00 0D a >10 73 72 61 6D 74 65 73 74 2E 6E 63 64 00 62 00 0C sramtest.ncd b >20 34 30 32 38 65 78 68 71 32 34 30 00 63 00 09 39 4028exhq240 c 9 >30 38 2F 30 35 2F 32 30 00 64 00 09 31 34 3A 32 31 8/05/20 d 14:21 >40 3A 33 36 00 65 00 01 46 43 FF 20 A3 21 1F 5F F7 :36 e FC ! _ >50 EF DE F7 EF 7D FD EF 7E F7 EF 7D FD FB DF B5 FB } ~ } --snip--Article: 12894
Wasn't there an 8051 derivative with programmable logic posted here only a couple of weeks ago? Regards, Saddle (In the land of OZ) Maxim Golov wrote in message <363F3F98.97AB128B@lucent.com>... >Simon, > >what surprises me a bit is that we do not see around processors with >embedded FPGA (m.b. small one) on the chip. Or did I miss something? > >Maxim > >msimon@tefbbs.com wrote: >> >> The advantage the FPGA gives you is the ability to get EXACTLY the >> processor you want to solve a given problem. >> >> Say you don't need as many registers as a standard design but a 32bit >> Real Time Clock counter would be handy. No problemo. >> >> In a design as done today you got to add the counters externally if >> the on chip ones don't meet your needs plus some glue logic. >> >> I was recently faced with this problem with a 68332. I would have >> loved to trade some of the TPU logic for a 32 bit atomic counter >> (latches all 32 bits at once for readout. With the counter clock gated >> so I could start a number of them simultaneously). Instead I had to do >> an expensive (in CPU time) interrupt driven counter (10,000 interrupts >> a second). >> >> We met spec but there is no design margin. OTOH the system is designed >> to fail gracefully. >> >> Simon >> ============================================================ >> tgg@hpl.hp.com () wrote: >> >> ?How does it compare with the MicroChip PIC devices. My personal suspicion is >> ?that the PIC devices are smaller (probably), cheaper (certainly), faster >> ?(probably), more peripherals such as timers/adc/dac/etc (certainly), >> ?more software support (certainly). >> ? >> ?Any corrections to the above suspicions would be welcome. >> >> Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12895
klee@mistress.informatik.unibw-muenchen.de (Herbert Kleebauer) writes: > In article <2992940395@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: > >Subject: Re: New free FPGA CPU > >From: Bruce@hoult.actrix.gen.nz (Bruce Hoult) > >Date: Tue, 3 Nov 1998 12:19:55 +1300 > > >I haven't seen anyone dispute the claim that this is the only public domain CPU > >design. Unless such a claim arises, the Trailing Edge is in a field of one, and > >therefore has an absolute technical advantage. > > >Are you aware of a better design which is public domain? > > > Since 1993 we have a laboratory course at our university, in which > students develop a full 16-bit processor, using one XILINX FPGA (using > WORKVIEW CAD-Software): > > - 128 kByte memory-address > - 128 kByte i/o-address > - 5 Interrupt levels > - 3-address instructions > - 0.3 MIPS > - less than 2000 gate-functions > > Two students have built a complete computer using this prozessor: OK, field of two. Now we're getting there :-) Does the 3-address instructions imply a memory-to-memory architecture? I assume so -- rather than a RISC register-to-register architecture -- because of the lack of mention of number of registers and the slow speed. -- Bruce -- 'We have no intention of shipping another bloated operating system and forcing that down the throats of our Windows customers' -- Paul Maritz, Microsoft Group Vice PresidentArticle: 12896
Maxim Golov wrote:
> Simon,
>
> what surprises me a bit is that we do not see around processors with
> embedded FPGA (m.b. small one) on the chip. Or did I miss something?
>
> Maxim
there have been a number of these announced (add the usual iirc thing)
moto + pilkington ==> {} <-- null set when moto cancelled the fpga thing
siemens + gatefield iirc - mixed in eeprom + eeprom-based
one more, can't remember who, gotta look it up in the notes.
announced, ee times, 10/19, p. 18: triscend corp is making a micro
controller + programmable logic. 8032 type ucontroller that
can be field configured to mimic nearly any 8032 derivative chip.
see article by ron wilson.
rk
Article: 12897
In article <71nq05$7lj@web.nmti.com>,
Peter da Silva <peter@baileynm.com> wrote:
)In article <71nlti$ail$1@relay1.dsccc.com>,
)Mike McCarty <jmccarty@sun1307.spd.dsccc.com> wrote:
)>I did not ask the question "Why would anyone create such a thing as a
)>uController in an FPGA?" I asked "Why should I use this chip?" And so
)>far it looks like the answer is "You shouldn't."
)(1) do you mean microcontroller or microprocessor?
)(2) If the former, it's because "you can customise the I/O more than you
) can with a single-chip microcontroller".
)(3) If the latter, it's because "You can add a bit of RAM and I/O and turn
) into a single-chip microcontroller, see (2)".
)
)The final answer is, to cut down the part count for a custom project.
)
)Same reason you might use Forth instead of C (small or otherwise).
It's bad enough that people are responding without carefully reading the
posts they are responding to, now some are responding without reading
the posts at all or even knowing what the general subject matter is.
A guy posted that he had designed a uController on an FPGA. It would
cost about $15, and does not seem optimized for any particular
application, and is missing several things that most uControllers have.
I have used specialized uControllers made on FPGAs, and ASICs before,
but see no advantage to this one. In fact, regular uControllers which
are lower in price seem better suited to do most of the things a
uController would do.
So I asked why I should use this particular uController. What is its
supposed forte?
A bunch of people are answering unrelated questions like
Why would anyone design a special purpose uController?
Why did this guy design *this* uController?
etc.
You have joined the list of such responders.
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
Article: 12898In article <71o7cr$s3p$1@relay1.dsccc.com>, jmccarty@sun1307.spd.dsccc.com (Mike McCarty) wrote: > In article <71nq05$7lj@web.nmti.com>, > Peter da Silva <peter@baileynm.com> wrote: > )In article <71nlti$ail$1@relay1.dsccc.com>, > )Mike McCarty <jmccarty@sun1307.spd.dsccc.com> wrote: > )>I did not ask the question "Why would anyone create such a thing as a > )>uController in an FPGA?" I asked "Why should I use this chip?" And so > )>far it looks like the answer is "You shouldn't." > )(1) do you mean microcontroller or microprocessor? > )(2) If the former, it's because "you can customise the I/O more than you > ) can with a single-chip microcontroller". > )(3) If the latter, it's because "You can add a bit of RAM and I/O and turn > ) into a single-chip microcontroller, see (2)". > ) > )The final answer is, to cut down the part count for a custom project. > ) > )Same reason you might use Forth instead of C (small or otherwise). > > It's bad enough that people are responding without carefully reading the > posts they are responding to, now some are responding without reading > the posts at all or even knowing what the general subject matter is. > > A guy posted that he had designed a uController on an FPGA. It would > cost about $15, and does not seem optimized for any particular > application, and is missing several things that most uControllers have. > I have used specialized uControllers made on FPGAs, and ASICs before, > but see no advantage to this one. In fact, regular uControllers which > are lower in price seem better suited to do most of the things a > uController would do. > > So I asked why I should use this particular uController. What is its > supposed forte? > > A bunch of people are answering unrelated questions like > > Why would anyone design a special purpose uController? > Why did this guy design *this* uController? > etc. > > You have joined the list of such responders. > > Mike Are you deliberately trying to piss people off? I seriously doubt that anyone has responded to this thread "without reading the posts at all". It might have occurred to you that, perhaps, just perhaps, there is an honest misunderstanding involved -- and it might even be on your part. I've avoided getting into this discussion because I'm not particularly expert in processor design or FPGAs. However, it's gone on for a while without anyone making what I think is the key point, so here goes. The purpose of the design in question is not (I assume) to be a finished product, but rather a starting point. It is a microcontroller implemented on an FPGA. Because it is implemented on an FPGA, it can be customized in various ways: adding specialized instructions, incorporating peripherals, etc. The base design is not customized for any particular application, so it is not suprising that it does not serve any particular application better than a commodity chip. What makes it interesting is that the source code is publicly available, allowing anyone to modify the design, so that it would then be well suited to a particular application. (Not to mention its potential use as an educational tool, and other "side uses".) So, why should you use this design in a system? You shouldn't, any more than you should place a block of raw clay in your entrance hall. The clay can be sculpted into an interesting form, and the chip (design) can be customized into an application-optimized component. This might, or might not, be a good approach for any particular need you, or any other system designer, might have. I would have thought that was obvious, but perhaps not. Now, quite possibly there are better solutions, based on FPGAs, ASICs, or commodity parts, for particular problems that you face in your work. As may be. If so, then feel free to use them -- I don't think anyone singled you out and suggested that you must start using this design now. It may even be the case that better generic "starting points" (FPGA- based microcontroller implementations) exist, although many of the posters in this group do not seem to have been aware of any. But I think the "supposed forte" of this processor design is pretty clear, namely: it is a reasonably powerful general-purpose processor which is implemented in a form (FPGA) and published in a form (open source / copyleft) that allows it to be customized for particular applications. -- Steve Newman snewman@acm.remove...this.orgArticle: 12899
Paul Walker <paul@walker.demon.co.uk> wrote: > 4: Find a way to simulate it with the separate clocks and no reports of > violated setup and hold times. These violations are inevitable, and the > simulator is right to report them. Modelsim allows turning off all the > timing checks (thanks Stuart), but I'd really prefer to define the small > number of synchronising flip-flops as synchronisers. These synchronisers > would have zero setup time and a longer propagation delay to allow for > the very rare but statistically non-zero metastability recovery time. > That way the timing checks can stay and find the real problems. > > I've asked Xilinx if there is a way of tweaking the SDF file, or better > still of defining the flop as a synchroniser in the schematic. So far I > just have a holding response. Any suggestions? Since the SDF file looks like LISP, I've use LISP to read it in a big expression and manipulate it to set certain FF's setup and hold times to 0. Let me know if you want my code. Thanks, -- Bill Warner Silicon Graphics wtw@sgi.com
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