Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 12875

Article: 12875
Subject: Re: New free FPGA CPU
From: msimon@tefbbs.com
Date: Tue, 03 Nov 1998 15:04:15 GMT
Links: << >>  << T >>  << A >>
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.htm
Article: 12876
Subject: Re: New free FPGA CPU
From: brian@shapes.demon.co.uk (Brian Drummond)
Date: Tue, 03 Nov 1998 15:35:25 GMT
Links: << >>  << T >>  << A >>
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...

- Brian
Article: 12877
Subject: Re: New free FPGA CPU
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 3 Nov 1998 16:16:56 GMT
Links: << >>  << T >>  << A >>
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: 12878
Subject: Re: Design security again - the Actel solution
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 03 Nov 1998 11:36:32 -0500
Links: << >>  << T >>  << A >>
Steve 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
Subject: Xilinx bit file format question
From: "Dan Kuechle" <dan_kuechle@i-tech.com>
Date: 3 Nov 1998 17:05:32 GMT
Links: << >>  << T >>  << A >>
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.

Thanks
Article: 12880
Subject: Xchecker cable NT problem
From: Dunstan Power <101527.1217@CompuServe.COM>
Date: Tue, 03 Nov 1998 12:14:10 -0500
Links: << >>  << T >>  << A >>
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 Power
Article: 12881
Subject: Re: New free FPGA CPU
From: "Manfred Kraus" <mkraus@xxcesys.com>
Date: Tue, 3 Nov 1998 18:15:23 +0100
Links: << >>  << T >>  << A >>
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 Kraus



Article: 12882
Subject: Re: New free FPGA CPU
From: klee@mistress.informatik.unibw-muenchen.de (Herbert Kleebauer)
Date: Tue, 3 Nov 1998 09:16:11
Links: << >>  << T >>  << A >>
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: 12883
Subject: Re: Digital Sine Generator
From: "Manfred Kraus" <mkraus@xxcesys.com>
Date: Tue, 3 Nov 1998 18:18:10 +0100
Links: << >>  << T >>  << A >>
Hallo Jürgen,

Have you looked at Don Lancasters's MAGIC SINEWAVES?
Check out http://www.tinaja.com/magsn01.html


Manfred



Article: 12884
Subject: Re: Xilinx bit file format question
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 3 Nov 1998 17:26:06 GMT
Links: << >>  << T >>  << A >>
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.
>
>Thanks


Article: 12885
Subject: Re: New free FPGA CPU
From: Maxim Golov <mgolov@lucent.com>
Date: Tue, 03 Nov 1998 18:38:32 +0100
Links: << >>  << T >>  << A >>
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.htm
Article: 12886
Subject: Re: New free FPGA CPU
From: jmccarty@sun1307.spd.dsccc.com (Mike McCarty)
Date: 3 Nov 1998 19:27:32 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: New free FPGA CPU
From: jmccarty@sun1307.spd.dsccc.com (Mike McCarty)
Date: 3 Nov 1998 19:35:14 GMT
Links: << >>  << T >>  << A >>
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: 12888
Subject: Re: New free FPGA CPU
From: zalman@netcom.com (Zalman Stern)
Date: Tue, 3 Nov 1998 19:38:23 GMT
Links: << >>  << T >>  << A >>
Bruce 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
Subject: Re: New free FPGA CPU
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 03 Nov 1998 14:48:25 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Design security again - the Actel solution
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 03 Nov 1998 15:21:41 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: New free FPGA CPU
From: peter@baileynm.com (Peter da Silva)
Date: 3 Nov 1998 20:44:53 GMT
Links: << >>  << T >>  << A >>
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: 12892
Subject: Re: New free FPGA CPU
From: paik@webnexus.com
Date: Tue, 03 Nov 1998 22:18:43 GMT
Links: << >>  << T >>  << A >>
In 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 Own    
Article: 12893
Subject: Re: Xilinx bit file format question
From: "Matthew Robinson" <NOSPAMmprREMOVE@dolby.com>
Date: Tue, 3 Nov 1998 15:06:30 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: New free FPGA CPU
From: "Saddle" <saddle@bigpond.com>
Date: Wed, 4 Nov 1998 10:10:02 +1100
Links: << >>  << T >>  << A >>
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.htm


Article: 12895
Subject: Re: New free FPGA CPU
From: Bruce@hoult.actrix.gen.nz (Bruce Hoult)
Date: Wed, 4 Nov 1998 12:29:42 +1300
Links: << >>  << T >>  << A >>
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 President
Article: 12896
Subject: Re: New free FPGA CPU
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 03 Nov 1998 18:35:19 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: New free FPGA CPU
From: jmccarty@sun1307.spd.dsccc.com (Mike McCarty)
Date: 4 Nov 1998 00:33:31 GMT
Links: << >>  << T >>  << A >>
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: 12898
Subject: Re: New free FPGA CPU
From: snewman@acm.no.spam.org (Steve Newman)
Date: Tue, 03 Nov 1998 17:38:37 -0800
Links: << >>  << T >>  << A >>
In 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.org
Article: 12899
Subject: Re: Q: fifo flags
From: Bill Warner <wtw@sepulcher.engr.sgi.com>
Date: 4 Nov 1998 01:39:50 GMT
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search