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 10425

Article: 10425
Subject: Re: XC5200s and Foundation 1.4
From: root@127.0.0.1 (Graham Eastwood)
Date: Mon, 18 May 1998 19:33:02 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: ++ TMS320C6x DSP info website ++
From: William Marble <marble_william@htc.honeywell.com>
Date: Mon, 18 May 1998 15:33:24 -0500
Links: << >>  << T >>  << A >>
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, Switzerland



Article: 10427
Subject: HOT NEW FPGA Position Available!
From: amaraju@onramp.net
Date: Mon, 18 May 1998 15:39:16 -0500
Links: << >>  << T >>  << A >>

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.com
Article: 10428
Subject: Re: Minimal ALU instruction set.
From: Keith Wootten <Keith@wootten.demon.co.uk>
Date: Mon, 18 May 1998 23:12:36 +0100
Links: << >>  << T >>  << A >>
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 Wootten
Article: 10429
Subject: Re: XC5200s and Foundation 1.4
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 18 May 1998 22:23:24 GMT
Links: << >>  << T >>  << A >>
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.

-andy


Article: 10430
Subject: Re: Minimal ALU instruction set.
From: daveb@iinet.net.au (David R Brooks)
Date: Mon, 18 May 1998 22:54:06 GMT
Links: << >>  << T >>  << A >>
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 servers
Article: 10431
Subject: Re: XABEL problem
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Mon, 18 May 1998 23:24:36 GMT
Links: << >>  << T >>  << A >>
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.
 
Stuart
Article: 10432
Subject: Re: Minimal ALU instruction set.
From: Rickman <spamgoeshere2@yahoo.com>
Date: Mon, 18 May 1998 21:37:58 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: XC5200s and Foundation 1.4
From: Rickman <spamgoeshere2@yahoo.com>
Date: Mon, 18 May 1998 21:41:24 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: XC5200s and Foundation 1.4
From: Rickman <spamgoeshere2@yahoo.com>
Date: Mon, 18 May 1998 21:41:34 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: XABEL problem
From: Rickman <spamgoeshere2@yahoo.com>
Date: Mon, 18 May 1998 21:49:10 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Minimal ALU instruction set.
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 19 May 1998 02:02:43 GMT
Links: << >>  << T >>  << A >>
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: 10437
Subject: XABLE
From: John <jsmeltze@columbus.rr.com>
Date: Mon, 18 May 1998 23:08:36 -0400
Links: << >>  << T >>  << A >>


I 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
Subject: Re: Altera 3.3V and 5V
From: Yashinovsky Benny <s1127741@isaac.cs.technion.ac.il>
Date: Tue, 19 May 1998 09:31:25 +0300
Links: << >>  << T >>  << A >>
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
Subject: Re: Minimal ALU instruction set.
From: Bernd Paysan <bernd.paysan@remove.muenchen.this.org.junk>
Date: Tue, 19 May 1998 09:40:50 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Minimal ALU instruction set.
From: Keith Wootten <Keith@wootten.demon.co.uk>
Date: Tue, 19 May 1998 09:28:23 +0100
Links: << >>  << T >>  << A >>
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: 10441
Subject: Re: XABEL problem
From: dave@dave-ltd.co.uk.NOSPAM (David Knell)
Date: Tue, 19 May 1998 08:44:25 GMT
Links: << >>  << T >>  << A >>
Hi 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,

Dave


Article: 10442
Subject: Building signal delays inside an FPGA
From: Alfredo Rosado <alfredo.rosado@uv.es>
Date: Tue, 19 May 1998 11:01:43 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: XC5200s and Foundation 1.4
From: "Bruno Fierens" <bruno.fierens@barco.com>
Date: Tue, 19 May 1998 11:03:50 +0200
Links: << >>  << T >>  << A >>
>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
Subject: Re: Building signal delays inside an FPGA
From: Ed McCauley <edmccauley@bltinc.com>
Date: Tue, 19 May 1998 08:23:16 -0400
Links: << >>  << T >>  << A >>
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.es
Article: 10445
Subject: German only: Neues FPGA-Kochbuch
From: Markus.Wannemacher@FernUni-Hagen.De (Markus Wannemacher)
Date: 19 May 1998 13:44:48 GMT
Links: << >>  << T >>  << A >>

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: 10446
Subject: Re: Minimal ALU instruction set.
From: z80@ds1.com (Peter)
Date: Tue, 19 May 1998 14:05:36 GMT
Links: << >>  << T >>  << A >>

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: 10447
Subject: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: Mike Butts <mbutts@realizer.com>
Date: Tue, 19 May 1998 15:51:48 +0000
Links: << >>  << T >>  << A >>
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: 10448
Subject: Re: Building signal delays inside an FPGA
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 19 May 1998 16:36:41 GMT
Links: << >>  << T >>  << A >>
You 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
Subject: Re: Minimal ALU instruction set.
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Tue, 19 May 1998 09:48:03 -0700
Links: << >>  << T >>  << A >>
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:
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