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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 10375

Article: 10375
Subject: Re: Neural Network implementation
From: Markus Rossmann <rossmann@luzi.e-technik.uni-dortmund.de>
Date: Fri, 15 May 1998 16:15:14 +0200
Links: << >>  << T >>  << A >>
Hej Sergio,

  we have a webpage related to On-Line Learning with the Hebbian 
algorithm. See http://www-be.e-technik.uni-dortmund.de/~rossmann/work
But there are a lot of other researchers on this field, too.
Too many to mention all. Just have a look via a search machine.

Greetings
Markus

Sergio A. Cuenca Asensi wrote:
> 
> Hello, I'm very interested in neural network implementation using
> FPGA/CPLD.
> Does somebody know a specific URL or site, available papers or thesis?
> Thank you in advanced.
> 
> Sergio
> --
> ===================================================================
> Sergio A. Cuenca Asensi
> Dept. Tecnologia Informatica y Computacion
> Escuela Politecnica Superior, Campus de San Vicente
> Universidad de Alicante
> email   : sergio@dtic.ua.es
> ===================================================================

-- 
******************************************************************************
    Dipl.-Ing. Markus Rossmann
    Department for Electrical Engineering - Microelectronics
    University of Dortmund - Germany
    
    e-mail: rossmann@luzi.e-technik.uni-dortmund.de
    www   : http://luzi.e-technik.uni-dortmund.de/~rossmann
    phone : (+49) (0)231 - 755 - 2667
    fax   : (+49) (0)231 - 755 - 4450
******************************************************************************
Article: 10376
Subject: Re: Minimal ALU instruction set.
From: Bernd Paysan <bernd.paysan@remove.muenchen.this.org.junk>
Date: Fri, 15 May 1998 16:30:43 +0200
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> I thought about top of stack machines as well, but it's not workable.  I've
> found that it's slower than the equivalent register machine, and bigger,
> because it requires more complex disjoint instruction sequences.

I've some difficulties to follow this statement. If you do a small stack
machine, you would do it like a stripped down F21. Let's assume that you
use a format with 16 instructions (this is relatively comfortable, the
F21 has 32 opcodes, with about 20 of them actually used), so you can
load two instructions per memory cycle. Since memory is the bottleneck,
you can throw as much as 4 stack instructions into the game, where you
could previously execute one ALU instruction (two bytes - two read
accesses - I assume the data memory accesses don't change much). So even
if stack codes need more instructions to achieve the same job, it should
be faster. Well, this is academic, I haven't tried.

The register resources (8*16 bit) would be (bare minimum): PC, TOS, NOS,
A, and registers for deeper stacks as useful, perhaps two for
returnstack, two for data stack. Note that the stack elements are not
meant as memory stack - if it's full, data is lost (as with the
transputer).

-- 
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/
Article: 10377
Subject: Re: Minimal ALU instruction set.
From: "Jeffrey S. Dutky" <dutky@Glue.umd.edu>
Date: Fri, 15 May 1998 10:49:50 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
> How about we change the criterion to make this discussion a little more
> meaningful: what's the best possible general purpose processor you could
> make given: one XC5202-6PC84C FPGA (64 configurable logic blocks; each with
> four flip-flops.  equiv. to about ~3000 gates.  $7.40 each from DIGIKEY),
> one 128Kx8 RAM (85ns), preloaded with the program to be run (total cost:
> ~$14.35).

<BIG snip>

> (a bunch of talk about putting flags into the low order IP bits) One
> possibility is to service interrupts only for every other instruction
> (when the PC is evenly divisible by 4), and use the two least significant
> bits for the flags.  This is almost workable- the only problem is that
> interrupts are delayed when you have a long sequence of branches to
> odd word boundaries, which is unlikely but possible.

Just require that all branch destinations be on four-byte boundries. You
would only waste, on average, one byte per jump in the code, and you
could
put your flags into the IP. While you're at it, shift the immediate
value
used on branches two bits left, this gives you a longer "short branch"
as
well as preventing misaligned branches.

- Jeff Dutky
Article: 10378
Subject: Re: Minimal ALU instruction set.
From: albaugh@agames.com (Mike Albaugh)
Date: 15 May 1998 16:03:26 GMT
Links: << >>  << T >>  << A >>
Joseph H Allen (jhallen@world.std.com) wrote:
(Making a telling observation about "gate equivalents", albeit apparently
 inadvertantly)

: How about we change the criterion to make this discussion a little more
: meaningful: what's the best possible general purpose processor you could
: make given: one XC5202-6PC84C FPGA (64 configurable logic blocks; each with
: four flip-flops.  equiv. to about ~3000 gates.  $7.40 each from DIGIKEY),

: When limited to the XC3020, the old 6502, sans the X register (since
: (z-page,x) "preindex indirect" mode is not as useful as (z-page),y "post
: index indirect" mode) and the BCD logic (although I've seen it used for
: floating point libraries), plus bank switching for the RAM is close to the
: best that you can do, but probably won't fit because of the complex control
: logic (there are about 16 instruction sequences).


	I don't know how many "gate equivalents" the smaller chip has, but
I'd note that a _real_ 6502 is "about 3200 transistors". It also cost,
last time I checked, <$2. Western Design Center is reportedly selling
a synthesizable version, although I don't know at what price. As another
sample point, a 32-bit RISC can be implmented in about 28K transistors.
("can be", as in, "I was on a team that did one, and several are currently
running code within a hundred feet of me, although those systems are
getting old", not "my estimates suggest")

	Anyway, what is it about gate utilization that makes a ~~3K
transistor CPU too large for a ~~3K gate FPGA? Will this change any
time soon, or do we just get used to "YMMV" attached to "equivalent
gate" counts? BTW: as much as I hate the "Please email because I don't
read this group", not that this is cross-posted. _I_ read comp.arch pretty
regularly, but I don't read ..fpga, primarily because I am now officially
a "software guy", with no access to FPGA tools, and no interest in buying
a Wintel machine, and one of the "cheap" packages just to fool around with
them in "my spare time". I'm interested in the re-invention of "lean"
machines, and hope to follow this in comp.arch, but comments specifically
directed at "the error of my ways" in re FPGAs should be emailed.

	Side note 2: I think if you spent much time doing Forth on a
6502, you'd have a better appreciation for indirect-X :-) Most of the
rest looks plausible, but I wonder about:

: You don't have to save the interrupt enable flag during
: interrupts, but you do have to save carry and overflow.

	No direct access to the interrupt flag can make programming "safe"
multitasking, er, _interesting_.

: is that interrupts are delayed when you have a long sequence of branches to
: odd word boundaries, which is unlikely but possible.

	Such "unlikely but possible" gotchas are the absolute bane of
folks trying to write reliable software. Just say no.

	In general, I'd second the other post which mentioned doing
something more like a PDP-11, with the "registers" in a dedicated RAM
area. The 6502 was never particularly friendly to the sort of "Stepchild
of Algol" languages which are still the rage for embedded systems, and
if you really want to sell this beast, difficulty of software support
will be a big issue. OTOH, the most popular smallish machines (8051
and PIC) are not easy targets for such HLLs either. OTOOH, they are
a darn-sight cheaper than anything you could do with an FPGA :-)

						Mike
| albaugh@agames.com, speaking only for myself
Article: 10379
Subject: Re: Minimal ALU instruction set.
From: Landon Dyer <landon@shell9.ba.best.com>
Date: 15 May 1998 17:07:40 GMT
Links: << >>  << T >>  << A >>
In comp.arch David Tweed <dtweed@aristech.com> wrote:
:>For one thing, limiting yourself to an 8-bit memory with an 85-ns access time
:>is going to limit your memory bandwidth to about 10 MBps, plus you have 17-bit
:>addresses to deal with. The FPGA should be capable of clocking at somewhere
:>around 30-40 MHz, so why not spring for 15 to 20 nS memory and organize it as
:>64K x 16? Then 16-bit registers is a natural fit for both data and addresses,
:>and you can make four accesses (e.g., two instruction fetches and two data
:>accesses) in the time that it takes the 8-bit memory to fetch one byte. This
:>would make the core a serious contender in many embedded applications.

  hmm... didn't someone do an ECL version of the 6502, back in the
late 80s?  for the time, i understand, it was a screamer

  some guys in a lab at mostek had had too many beers one friday
evening, and i'm informed that the world's record for a stock 6502
(circa 1982) was something like 24mhz before the enabling smoke leaked
out.  tough little fella


-- 

landon@best.com

  "Sundial with a great hand, sweeping dust across the floor,
     Puts a strain on a sane man, 'til he knows what he's looking for."
       -- Kim Carnes
Article: 10380
Subject: Re: Xilinx Foundation and Linux
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 15 May 1998 17:28:19 GMT
Links: << >>  << T >>  << A >>
Phil Ptkwt Kristin <ptkwt@user1.teleport.com> wrote in article
<6iqsij$sie$1@user1.teleport.com>...
> 
> If you want the Xilinx software (or any other EDA software for that
> matter) running on Linux then you have to make some noise.  Call up
Xilinx
> (or send'em e-mail) and demand a Linux version.  If enough people
do this
> they'll start to get the idea. 
> 

Hmmmm...users making enough noise so a tool vendor will release
software or add features?

Maybe if enough people YELL at Model Technology, they'll add a
fargin' FILE|PRINT function to their ModelSim software. 

We paid $4K for the package and it's in a 4.x release and yet they
STILL use the silly "write to Postscript" function rather than just
adding real print capability.

 Sheesh!

-andy

Article: 10381
Subject: Re: Minimal ALU instruction set.
From: Rickman <spamgoeshere1@yahoo.com>
Date: Fri, 15 May 1998 13:34:09 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
> How about we change the criterion to make this discussion a little more
> meaningful: what's the best possible general purpose processor you could
> make given: one XC5202-6PC84C FPGA (64 configurable logic blocks; each with
> four flip-flops.  equiv. to about ~3000 gates.  $7.40 each from DIGIKEY),
> one 128Kx8 RAM (85ns), preloaded with the program to be run (total cost:
> ~$14.35).  You must be able to handle interrupts.
-- 
I'm not sure why you want to invent a CPU from a $7 chip when there are
so many out there for $2, but here is my two cents worth. 

Your goals are not clear. Are you shooting for minimal price, maximum
performance, some optimal trade off, or is this just a method of
entertainment? 

There has always been a trade off between accessing registers vs. memory
in instructions. Registers are fast and allow instruction size to be
kept small, but the number of registers are limited and they slow the
machine when you need to save context. 

Your CPU-on-an-FPGA most likely will not run a lot faster than the SRAM
attached, so you don't get a lot of speed improvement by having
registers on chip. One way to optimize this trade off in such a case is
to have registers in memory pointed to by a single internal register. TI
did this in their 9900 series of 16 bit processors. A "Workspace
Pointer" was the only on board register other than the PC and status (I
think) and pointed to R0 with R1 through R15 following in memory. This
was very slow compared to a RISC machine, but you won't be getting near
RISC speeds with a small Xilinx based architecture anyway. The
instructions can still be kept small with register based addressing and
context switches are fast; only the three internal registers need to be
saved. 

TI did not have a stack pointer. You had to implement that in software
yourself. They normally used one of the registers as a "link" register.
You save your return address in R11 as you do a call after loading a new
workspace pointer. But each call was two words long, one for the call
address, one for the new workspace pointer. Another way to do this would
be to treat the workspace pointer as a stack pointer. Increment it by N
each time you call a subroutine. The subroutine can increment it by M
for local storage. 

A scheme similar to this may be the optimal approach given your
scenario. 



Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 10382
Subject: "Inferred" I/O flip-flops in XC4000E
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 15 May 1998 17:35:10 GMT
Links: << >>  << T >>  << A >>
The Xilinx app notes et. al. mention that if you want to use VHDL and
I/O flip flops, there are two methods.  One is to instantiate the I/O
flip-flop directly using library components.  The other way is to
tell the mapper to use I/O flip flops.  I prefer the second way,
simply because my VHDL looks cleaner.

My question is:

How do I know if the mapper actually used I/O flip flops and not the
flops in the CLBs?

-andy

-- 
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
apeters@noao.edu.NOSPAM
Article: 10383
Subject: Re: Minimal ALU instruction set.
From: jhallen@world.std.com (Joseph H Allen)
Date: Fri, 15 May 1998 17:46:04 GMT
Links: << >>  << T >>  << A >>
In article <6jhp0e$a31$1@void.agames.com>,
Mike Albaugh <albaugh@agames.com> wrote:
>Joseph H Allen (jhallen@world.std.com) wrote:
>(Making a telling observation about "gate equivalents", albeit apparently
> inadvertantly)

>: How about we change the criterion to make this discussion a little more
>: meaningful: what's the best possible general purpose processor you could
>: make given: one XC5202-6PC84C FPGA (64 configurable logic blocks; each with
>: four flip-flops.  equiv. to about ~3000 gates.  $7.40 each from DIGIKEY),

>: When limited to the XC3020, the old 6502, sans the X register (since
>: (z-page,x) "preindex indirect" mode is not as useful as (z-page),y "post
>: index indirect" mode) and the BCD logic (although I've seen it used for
>: floating point libraries), plus bank switching for the RAM is close to the
>: best that you can do, but probably won't fit because of the complex control
>: logic (there are about 16 instruction sequences).

>	I don't know how many "gate equivalents" the smaller chip has, but
>I'd note that a _real_ 6502 is "about 3200 transistors". It also cost,
>last time I checked, <$2. Western Design Center is reportedly selling
>a synthesizable version, although I don't know at what price. As another
>sample point, a 32-bit RISC can be implmented in about 28K transistors.
>("can be", as in, "I was on a team that did one, and several are currently
>running code within a hundred feet of me, although those systems are
>getting old", not "my estimates suggest")

Well if you want to buy a $60 XC4006 FPGA you can pretty easily fit a MIPS
clone (2-cycles per instruction, 8-cycle pipeline, no barrel shifter
(1-cycle per bit shift), no cache, 32-cycle multiply and divides).  They
claim that it's a 6000 gate device, but architecture differences have a huge
impact.  Namely you can use the CLBs as 32x1 rams to implement the register
file.  Of course this hopelessly uncompetitive compared to a real CPU (IDT
R3000 clones cost $15 and include 2KB cache).

>	Anyway, what is it about gate utilization that makes a ~~3K
>transistor CPU too large for a ~~3K gate FPGA?

The 3020 is just too small (they claim 2000 gates), but the 2 FFs per clb
and lack of carry logic are a big problem:

binary alu: 16 clbs (it has no carry logic, so it's 8 clbs for the xors and 8
clbs for a ripple carry).  The carry logic can do left shift.
bcd corrector: 8 clbs
right shifter: 4 clbs
a, x, y, lo, hi, s, p, pcl, pch, ir : 44 clbs.
input register, output register, address register: 0 clbs (use io-pads).
~16 3-cycle sequences done with one-hot bit encoding: 24 clbs.
Instruction decoding, alu & etc. recoding: 10 clbs.

Total: ~106 clbs.  The 3030 has 100 clbs, so maybe.  The XC3020A cost 10.35
and the XC3030A cost $10.88.  These were the previous bottem end chips, but
now the XC5202 is out ($7.40)- it is much better for CPUs: 4 FFs per CLB
plus dedicated carry logic (but no FFs in the pads).  It is still only 3000
gates, but should pretty easily fit the 6502.

>Will this change any time soon, or do we just get used to "YMMV" attached
>to "equivalent gate" counts? BTW: as much as I hate the "Please email
>because I don't read this group", not that this is cross-posted. _I_ read
>comp.arch pretty regularly, but I don't read ..fpga, primarily because I am
>now officially a "software guy", with no access to FPGA tools, and no
>interest in buying a Wintel machine, and one of the "cheap" packages just
>to fool around with them in "my spare time".

Sheesh you're no fun!  The "cheap" packages are actually pretty cheap: I
found The Xilinx "student edition" tools for XC4000 series devices for $150
at Quantum Books in Cambridge, MA.  

>	Side note 2: I think if you spent much time doing Forth on a
>6502, you'd have a better appreciation for indirect-X :-) Most of the
>rest looks plausible, but I wonder about:

I'm sure you can find some use for it, but (z-page,x) mode is still much
less useful than (z-page),y.

>: You don't have to save the interrupt enable flag during
>: interrupts, but you do have to save carry and overflow.

>	No direct access to the interrupt flag can make programming "safe"
>multitasking, er, _interesting_.

Well you can still set or clear the flag.  It just doesn't get saved during
interrupts.  Instead, when you get an interrupt, it is set so that
interrupts are disabled.  You got the interrupt, so you know that interrupts
had been previously enabled- so it's ok to reenable interrupts at the end of
the interrupt handler.

>	In general, I'd second the other post which mentioned doing
>something more like a PDP-11, with the "registers" in a dedicated RAM
>area. The 6502 was never particularly friendly to the sort of "Stepchild
>of Algol" languages which are still the rage for embedded systems, and
>if you really want to sell this beast, difficulty of software support
>will be a big issue. OTOH, the most popular smallish machines (8051
>and PIC) are not easy targets for such HLLs either. OTOOH, they are
>a darn-sight cheaper than anything you could do with an FPGA :-)

Yeah, but the FPGA can have many more peripheral options.  Also the PIC may
be cheaper, but the 8051 probably isn't.  Have you seen recent PICs?  They
have 8-pin SOIC verions... I'm waiting for the 6-pin SOT version.

There's got to be some story with those PICs.  They are not new processors
at all: The General Instrument 1650 is listed in my Osborne 4&8 bit
processor handbook from 1981.  I think that 'basic stamp' marketing thing
must have done it.  Or maybe it happened when they came out with EPROM
versions.  Anyway now they're everywhere.
-- 
/*  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: 10384
Subject: Re: Minimal ALU instruction set.
From: johne@vcd.hp.com (John Eaton)
Date: 15 May 1998 18:58:16 GMT
Links: << >>  << T >>  << A >>
David Tweed (dtweed@aristech.com) wrote:
: Joseph H Allen wrote:

: For one thing, limiting yourself to an 8-bit memory with an 85-ns access time
: is going to limit your memory bandwidth to about 10 MBps, plus you have 17-bit
: addresses to deal with. The FPGA should be capable of clocking at somewhere
: around 30-40 MHz, so why not spring for 15 to 20 nS memory and organize it as
: 64K x 16? Then 16-bit registers is a natural fit for both data and addresses,
: and you can make four accesses (e.g., two instruction fetches and two data
: accesses) in the time that it takes the 8-bit memory to fetch one byte. This
: would make the core a serious contender in many embedded applications.
: -- 
: David Tweed

Many FPGA's tout speeds up into the 100 Mhz's. It sounds great until you you realize
and the only design that will actually run that fast is a shift register. This makes
FPGA's the ideal canidate for a CPU design using serial logic. With serial logic all
registers are serial shift registers and you can load anyone with a single bit mux.
A 8 bit Full adder is simply a one bit full adder stage and one carry flip flop.
It a great speed/logic trade off.


John Eaton


Article: 10385
Subject: Re: "Inferred" I/O flip-flops in XC4000E
From: Randy Robinson <randyr@xilinx.com>
Date: Fri, 15 May 1998 13:27:29 -0600
Links: << >>  << T >>  << A >>
The beginning of the M1 map report looks like this.  IOB FFs
are explicitly listed.

RR

Design Summary
--------------
   Number of errors:        0
   Number of warnings:      1
   Number of CLBs:              9 out of   196    4%
      CLB Flip Flops:       0
      CLB Latches:          0
      4 input LUTs:        17
      3 input LUTs:         6
   Number of bonded IOBs:      21 out of    79   26%
      IOB Flops:            0
      IOB Latches:          0


Andy Peters wrote:
> 
> The Xilinx app notes et. al. mention that if you want to use VHDL and
> I/O flip flops, there are two methods.  One is to instantiate the I/O
> flip-flop directly using library components.  The other way is to
> tell the mapper to use I/O flip flops.  I prefer the second way,
> simply because my VHDL looks cleaner.
> 
> My question is:
> 
> How do I know if the mapper actually used I/O flip flops and not the
> flops in the CLBs?
> 
> -andy
> 
> --
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatories
> apeters@noao.edu.NOSPAM

-- 
************************************************************
*  Randy Robinson           Field Applications Engineer    *
*  Xilinx, Inc.             Longmont, Colorado             *
*  office (303) 774-1175    fax (303) 774-1198             *
*  mailto:randy.robinson@xilinx.com                        *
*                                                          *
*  Technical hotline - (800) 255-7778                      *
*  World Wide Web    - http://www.xilinx.com               *
*  Solutions - http://www.xilinx.com/support/searchtd.htm  *
************************************************************
Article: 10386
Subject: Re: Xilinx FGA Express
From: Randy Robinson <randyr@xilinx.com>
Date: Fri, 15 May 1998 13:29:31 -0600
Links: << >>  << T >>  << A >>
There is currently no way to hit the synthesize button in
the HDL editor and invoke FPGA-Express instead of Metamor. 
Wish there was.

You will need to save the VHDL source file, then bring it
into Express manually.  This will be the method until the
Foundation 1.5 release.  At that time, the Express tool will
be called from Foundation automagically.

RR

satish_me@hotmail.com wrote:
> 
> In article <3559D581.557B0172@ibas.no>,
>   thorj@ibas.no wrote:
> >
> > Hi,
> >
> > I've just installed Foundation Express and have a question:
> >
> > Is it possible to use the Synopsis VHDL compiler in place
> > of the XVHDL compiler?
> >
> > I would like to use the Synopsis compiler in conjunction
> > with top-level schematic entry, such that i could include
> > VHDL source files in my hierarchy _without_ exporting/importing.
> > (The imported macro becomes a primitive element in the schematic)
> >
> > In other words I would like to set the synthesis tool in the VHDL
> > editor to Synopsis instead of XVHDL.
> >
> > mvh.
> >
> > --
> > Thor Arne Johansen
> > Ibas Laboratories, Norway
> > http://www.ibas.no
> >
> 
> Yes It is possible to use any VHDL with Xilinx package.
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/   Now offering spam-free web-based newsreading

-- 
************************************************************
*  Randy Robinson           Field Applications Engineer    *
*  Xilinx, Inc.             Longmont, Colorado             *
*  office (303) 774-1175    fax (303) 774-1198             *
*  mailto:randy.robinson@xilinx.com                        *
*                                                          *
*  Technical hotline - (800) 255-7778                      *
*  World Wide Web    - http://www.xilinx.com               *
*  Solutions - http://www.xilinx.com/support/searchtd.htm  *
************************************************************
Article: 10387
Subject: Re: Minimal ALU instruction set.
From: peter@nmti.com (Peter da Silva)
Date: 15 May 1998 19:42:49 GMT
Links: << >>  << T >>  << A >>
In article <EszIuq.2yB@world.std.com>,
Joseph H Allen <jhallen@world.std.com> wrote:
> I've thought about this problem for quite some time and it has given me a
> greater appreciation of the old 8-bit processors.  The basic problem is that
> RISC does not work quite as well as a concept for narrow data paths, but
> CISCish control logic takes up a huge amount of space.

Have a look at the 1802. 16 register-pairs (or 32 registers, depending on
whether you consider the hi/lo bit in the instruction nybble to be part of
the register number). There's no subroutine call, just an instruction
that switches which register-pair is the PC. There's some quirks in the
1802 you probably want to avoid, but you could design quite a nice system
using it as a model.

	GLO	Rn			AC <- Rn.0
	GHI	Rn			AC <- Rn.1
	PLO	Rn			Rn.0 <- AC
	PHI	Rn			Rn.1 <- AC
	SEP	Rn			Rn becomes PC
	SEX	Rn			Rn becomes stack
	LDN	Rn			AC <- *Rn
	STN	Rn			*Rn <- AC
	INR	Rn			Rn++
	DCR	Rn			Rn--
	LDA	Rn			AC <- *Rn++
	LDI		VALUE		AC <- following byte
	LDX				AC <- *SP
	STX				*SP <- AC
	LDXA				AC <- *SP++
	STXD				AC <- *SP--
	ADD				AC <- AC + *SP
	SUB				etc...
	MUL
	etc...

Downsides: 8-bit AC, memory fetch for arithmetic, SP postdecrement (so
you keep writing code to explicitly increment or decrement the register
you know is the SP).

There's a lot of stack instructions, but if you had two accumulators you
could replace SEX with a STD instruction that stored an decremented through
a register (predecrement) and get rid of the SP altogether.

Giving you:

	{GLO, GHI, PLO, PHI, LDN, LDA, STN, STD, SEP, JMP} Rn
	LDI, XCHG, ADD, SUB, MUL etc...
-- 
%!PS
/c{{64 sub}forall curveto}def 312 192 translate 24 24 scale 1 -2 moveto(B;>;?>)
c fill 1 0 moveto(JIJNJP)c(JRGU@U)c(9U6R6P)c(6N6I?@)c gsave stroke grestore .9
setgray fill showpage % I'm getting serious propane withdrawal.
Article: 10388
Subject: Re: Minimal ALU instruction set.
From: albaugh@agames.com (Mike Albaugh)
Date: 15 May 1998 19:58:42 GMT
Links: << >>  << T >>  << A >>
Joseph H Allen (jhallen@world.std.com) wrote:
: In article <6jhp0e$a31$1@void.agames.com>,
: Mike Albaugh <albaugh@agames.com> wrote:

: >sample point, a 32-bit RISC can be implmented in about 28K transistors.
: >("can be", as in, "I was on a team that did one, and several are currently
: >running code within a hundred feet of me, although those systems are
: >getting old", not "my estimates suggest")

: Well if you want to buy a $60 XC4006 FPGA you can pretty easily fit a MIPS
: clone (2-cycles per instruction, 8-cycle pipeline, no barrel shifter
: (1-cycle per bit shift), no cache, 32-cycle multiply and divides).  They
: claim that it's a 6000 gate device, but architecture differences have a huge
: impact.  Namely you can use the CLBs as 32x1 rams to implement the register
: file.  Of course this hopelessly uncompetitive compared to a real CPU (IDT
: R3000 clones cost $15 and include 2KB cache).

	Yes, well the 28K-transistor RISC I mentioned did have a barrel-
shifter, no MUL/DIV but software MUL was 3..4 cycles/bit, div 5..6. (IIRC)
1 CPI other than ld/st, (no cache or separate I-bus, so LD/st took 2, no
load/use penalty) 4-stage pipe, but double-clocked, so it looked like
two... $6.21 in 1991. I know, apples and oranges, but we are still looking
at an order of magnitude in price/performance, and 7 years of progress.

: >now officially a "software guy", with no access to FPGA tools, and no
: >interest in buying a Wintel machine, and one of the "cheap" packages just
: >to fool around with them in "my spare time".

: Sheesh you're no fun!  The "cheap" packages are actually pretty cheap: I
: found The Xilinx "student edition" tools for XC4000 series devices for $150
: at Quantum Books in Cambridge, MA.  

	Yeah, $150 for the software, $600 _minimum_ for a machine that
will run it (unless you think it will run under MacOS on the kids
2ci, or Irix on my work Indy) plus another couple-hundred for a decent
monitor, $1K is a bit past my "fooling around" budget. _and_ I've lately
had to have more contact with Windows that I ever expected or wanted,
and just don't see spending more such time as "relaxing" in any non-
sarcastic sense of the term...

: >	No direct access to the interrupt flag can make programming "safe"
: >multitasking, er, _interesting_.

: Well you can still set or clear the flag.  It just doesn't get saved during
: interrupts.  Instead, when you get an interrupt, it is set so that
: interrupts are disabled.  You got the interrupt, so you know that interrupts
: had been previously enabled- so it's ok to reenable interrupts at the end of
: the interrupt handler.

	If you can't read it, you end up as so many novice RTOSes do,
with seprate versions of routines that manipulate shared data structures,
one to be called "if you are in an interrupt routine (where disabling
is not needed and enabling is deadly) and one when you are not (where
disabling around the critical section is deadly, and enabling mandatory).
Of ciourse, any routine which _calls_ those routine must pick the righht
one, and if _it_ can't "see" the interrupt flag, it also must come
in two flavors, ad nauseum. You run out of that 128K code space pretty
quickly with all that duplication. OK, if you code as if on a multi-
processor (single-writer rule etc) you can do a bit better, but it
still sucks.

					Mike
| albaugh@agames.com, speaking only for myself
Article: 10389
Subject: Re: Minimal ALU instruction set.
From: z80@ds1.com (Peter)
Date: Fri, 15 May 1998 20:10:28 GMT
Links: << >>  << T >>  << A >>

>	Anyway, what is it about gate utilization that makes a ~~3K
>transistor CPU too large for a ~~3K gate FPGA? 

CPUs tend to be decoder-rich, and FPGAs are very poor for doing
decoders.

FPGAs are very good for doing register-intensive stuff, and it is
difficult to do a CPU which fits that. 

Modern CPUs tend to be microcoded, which is obviously the last thing
you want to do in an FPGA. Some older ones, e.g. Z80, Z8000, were
hand-crafted state machines and that is a better fit but you still
have a lot of decoding.

Finally, a "3k transistor" CPU goes back to the days when these chips
were being designed by the most brilliant logic designers who ever
lived, at transistor level, using every trick in the book and not in
the book, e.g. dynamic storage elements - you name it.


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: 10390
Subject: Re: Minimal ALU instruction set.
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 15 May 1998 20:11:09 GMT
Links: << >>  << T >>  << A >>
In article <6ji388$4dc@wwproxy.vcd.hp.com>,
John Eaton <johne@vcd.hp.com> wrote:
>David Tweed (dtweed@aristech.com) wrote:
>: -- 
>: David Tweed
>
>Many FPGA's tout speeds up into the 100 Mhz's. It sounds great until you you realize
>and the only design that will actually run that fast is a shift register. This makes


I do not know what was the latest FPGA you used but your statement is not true
specially if using a XC4000XL-09 part.              
A shift register design will run at speeds greater than 200MHZ when carefully
foorplanned. You can get it to run for sure more than 150MHZ by only adding
timing constraints.


Any intelligent designer should be able to implement design running at more
than 120MHZ if pipelining is an option and has good knowledge of the 
architecture he is targetting.


 


>FPGA's the ideal canidate for a CPU design using serial logic. With serial logic all
>registers are serial shift registers and you can load anyone with a single bit mux.
>A 8 bit Full adder is simply a one bit full adder stage and one carry flip flop.
>It a great speed/logic trade off.
>
>
>John Eaton
>
>


Article: 10391
Subject: Re: Minimal ALU instruction set.
From: Steve Casselman <sc@vcc.com>
Date: Fri, 15 May 1998 13:16:39 -0700
Links: << >>  << T >>  << A >>
Rickman wrote:

> Joseph H Allen wrote:
> >
> > How about we change the criterion to make this discussion a little
> more
> > meaningful: what's the best possible general purpose processor you
> could
> > make given: one XC5202-6PC84C FPGA (64 configurable logic blocks;
> each with
> > four flip-flops.  equiv. to about ~3000 gates.  $7.40 each from
> DIGIKEY),
> > one 128Kx8 RAM (85ns), preloaded with the program to be run (total
> cost:
> > ~$14.35).  You must be able to handle interrupts.
> --
> I'm not sure why you want to invent a CPU from a $7 chip when there
> are
> so many out there for $2, but here is my two cents worth.
>
> Your goals are not clear. Are you shooting for minimal price, maximum
> performance, some optimal trade off, or is this just a method of
> entertainment?

You might want to consider a scenario where you add a little flash
and a small pal. You would then have your pal boot the CPU design
into the FPGA form the flash and as you went along you might have some
compute intensive task to perform so the CPU/FPGA tells the flash
to reconfigure into say a DSP to grind away then switch back again
when your done with that task.  Now your $7 FPGA + $4 Flash and $1
pal = $2 CPU + $20 DSP.  Since xc5202 takes only 5302 bytes for a
configuration you could fit quite a few "chips" in a 64k flash. In fact
why not spend $2 for the CPU and have it do the configuration?

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 10392
Subject: Re: Xilinx Foundation and Linux
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Fri, 15 May 1998 20:17:18 GMT
Links: << >>  << T >>  << A >>
On 15 May 1998 17:28:19 GMT, "Andy Peters"
<apeters.NOSPAM@noao.edu.NOSPAM> wrote:

>Maybe if enough people YELL at Model Technology, they'll add a
>fargin' FILE|PRINT function to their ModelSim software.
>
>We paid $4K for the package and it's in a 4.x release and yet they
>STILL use the silly "write to Postscript" function rather than just
>adding real print capability.

I know, it's a pain. However, I'm told it's on it's way for 5.0, along
with EE floating licenses on UNIX & NT. Yippee!

Stuart
Article: 10393
Subject: Re: "Inferred" I/O flip-flops in XC4000E
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Fri, 15 May 1998 20:18:22 GMT
Links: << >>  << T >>  << A >>
On 15 May 1998 17:35:10 GMT, "Andy Peters"
<apeters.NOSPAM@noao.edu.NOSPAM> wrote:

>The Xilinx app notes et. al. mention that if you want to use VHDL and
>I/O flip flops, there are two methods.  One is to instantiate the I/O
>flip-flop directly using library components.  The other way is to

Yuk, no-one should do this.

>tell the mapper to use I/O flip flops.  I prefer the second way,
>simply because my VHDL looks cleaner.

Amen.

>How do I know if the mapper actually used I/O flip flops and not the
>flops in the CLBs?

I think your synthesis tool has to infer these.

1
search the edif / xnf netlist for OFF, OFDXI IFF, etc.

2
look in XDE / EPIC and see if the ff's are used in the IOB's.

3
check your clk2q. If it's bad/wrong, then you're not using output
flipflops.

Stuart
Article: 10394
Subject: Re: Xilinx Foundation and Linux
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 15 May 1998 20:49:38 GMT
Links: << >>  << T >>  << A >>
Stuart Clubb <s_clubb@die.spammer.netcomuk.co.uk> wrote in article
<355ca261.14727827@nntp.netcruiser>...
> 
> I know, it's a pain. However, I'm told it's on it's way for 5.0,
along
> with EE floating licenses on UNIX & NT. Yippee!
> 

I'll believe it when I see it...

Oh wait, floating licenses?  You mean with the Flex-LM nonsense? 
Turns out that I spoke to a Xilinx support tech who told me that
Xilinx was strongly considering going away from the Flex-LM to
something else...she wasn't sure what, tho'.  All I can say is that I
hope it doesn't suck as much as Flex-LM.  Whatta pain.

-andy

Article: 10395
Subject: Re: Motion Controller design for DC motor wanted
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 15 May 1998 20:56:08 GMT
Links: << >>  << T >>  << A >>
leslie.yip@asmpt.com wrote in article
<6jgmg2$r3h$1@nnrp1.dejanews.com>...
> Dear Everybody
> 
> I would like to design a ASIC of motion controller for DC motor.
Would anyone
> have any ideas or any materials suggested, especially the timings
and
> operation description.
> 

I started to work on just such a device (an FPGA, actually) to
control stepper motors.  I abandoned the idea rather quickly, and
bought an off-the-shelf solution.  Why?

The easy parts:
1) Reading incremental rotary encoders to determine position
2) Writing the proper output pulses to an amplifier to drive the
motors

The hard parts:
1) Acceleration/Deceleration curves
2) Keeping the motors from stalling
3) What about hard limits?
4) What about the output amplifiers, anyway?
5) etc. etc.

There are people who spend their entire lives trying to make motors
run properly and I just don't have the time to reinvent the wheel.

Just buy the controller from someone like Oregon Microsystems or
Compumotor!

-andy


Article: 10396
Subject: Re: "Inferred" I/O flip-flops in XC4000E
From: "Andy Peters" <apeters.NOSPAM@noao.edu.NOSPAM>
Date: 15 May 1998 21:08:11 GMT
Links: << >>  << T >>  << A >>
Randy Robinson <randyr@xilinx.com> wrote in article
<355C9721.E2844332@xilinx.com>...
> The beginning of the M1 map report looks like this.  IOB FFs
> are explicitly listed.
> 
> RR
> 
> Design Summary
> --------------
>    Number of errors:        0
>    Number of warnings:      1
>    Number of CLBs:              9 out of   196    4%
>       CLB Flip Flops:       0
>       CLB Latches:          0
>       4 input LUTs:        17
>       3 input LUTs:         6
>    Number of bonded IOBs:      21 out of    79   26%
>       IOB Flops:            0
>       IOB Latches:          0
> 
> 

Randy:

Just checked the map report...no I/O flops or latches
used...hmmm...Looks like the mapper didn't do it.

Here's one place where it's supposed to happen.  Obviously this is a
clone of a '373 latch for the 8051 address/data bus:

	address_latch : process (hale, had) is
	begin
		if (hale = '1') then
			haddr(7 downto 0) <= had;
		end if;
	end process address_latch;

This is in the top-level entity, and had is a port declared as
STD_LOGIC_VECTOR(7 downto 0); and hale is a port declared as
STD_LOGIC.  haddr is declared in the architecture as
STD_LOGIC_VECTOR(7 downto 0);

Any ideas?

-andy


Article: 10397
Subject: Re: "Inferred" I/O flip-flops in XC4000E
From: Brian Philofsky <brianp@xilinx.com>
Date: Fri, 15 May 1998 16:24:19 -0700
Links: << >>  << T >>  << A >>


Also, if you are interested in seeing the rules as to which FFs Map will
merge into the I/O and which will not, see
http://www.xilinx.com/techdocs/2207.htm for an explanation.

Another thing I want to add is that many synthesis tools can and do
automatically infer FFs into the I/O if possible.  Depending on which
synthesis tool you are you are using, you may not need to do anything to
automatically infer FFs into IOBs.  There is some added informormation on
this subject in the "Synthesis and Simulation Design Guide" Chapter 4
availible at http://www.xilinx.com/appnotes/hdl_dg.pdf


--  Brian Philofsky


Randy Robinson wrote:

> The beginning of the M1 map report looks like this.  IOB FFs
> are explicitly listed.
>
> RR
>
> Design Summary
> --------------
>    Number of errors:        0
>    Number of warnings:      1
>    Number of CLBs:              9 out of   196    4%
>       CLB Flip Flops:       0
>       CLB Latches:          0
>       4 input LUTs:        17
>       3 input LUTs:         6
>    Number of bonded IOBs:      21 out of    79   26%
>       IOB Flops:            0
>       IOB Latches:          0
>
> Andy Peters wrote:
> >
> > The Xilinx app notes et. al. mention that if you want to use VHDL and
> > I/O flip flops, there are two methods.  One is to instantiate the I/O
> > flip-flop directly using library components.  The other way is to
> > tell the mapper to use I/O flip flops.  I prefer the second way,
> > simply because my VHDL looks cleaner.
> >
> > My question is:
> >
> > How do I know if the mapper actually used I/O flip flops and not the
> > flops in the CLBs?
> >
> > -andy
> >
> > --
> > Andy Peters
> > Sr. Electrical Engineer
> > National Optical Astronomy Observatories
> > apeters@noao.edu.NOSPAM
>
> --
> ************************************************************
> *  Randy Robinson           Field Applications Engineer    *
> *  Xilinx, Inc.             Longmont, Colorado             *
> *  office (303) 774-1175    fax (303) 774-1198             *
> *  mailto:randy.robinson@xilinx.com                        *
> *                                                          *
> *  Technical hotline - (800) 255-7778                      *
> *  World Wide Web    - http://www.xilinx.com               *
> *  Solutions - http://www.xilinx.com/support/searchtd.htm  *
> ************************************************************



--
-------------------------------------------------------------------
 / 7\'7 Brian Philofsky   (brian.philofsky@xilinx.com)
 \ \ `  Xilinx Applications Engineer             hotline@xilinx.com
 / /    2100 Logic Drive                         1-800-255-7778
 \_\/.\ San Jose, California 95124-3450          1-408-879-5199
-------------------------------------------------------------------



Article: 10398
Subject: Re: Xilinx Foundation and Linux
From: lharold@mrc.uidaho.edu (Len Harold)
Date: 16 May 1998 00:35:32 GMT
Links: << >>  << T >>  << A >>
Andy Peters (apeters.NOSPAM@noao.edu.NOSPAM) inspired us with the words:
> Stuart Clubb <s_clubb@die.spammer.netcomuk.co.uk> wrote in article
> <355ca261.14727827@nntp.netcruiser>...
> > 
> > I know, it's a pain. However, I'm told it's on it's way for 5.0,
> > along with EE floating licenses on UNIX & NT. Yippee!
>
> I'll believe it when I see it...

We have been running this way for almost a year now.

> Oh wait, floating licenses?  You mean with the Flex-LM nonsense? 
> Turns out that I spoke to a Xilinx support tech who told me that
> Xilinx was strongly considering going away from the Flex-LM to
> something else...she wasn't sure what, tho'.  All I can say is that I
> hope it doesn't suck as much as Flex-LM.  Whatta pain.

I have seen a couple of dozen licensing systems and flexlm is the
best I have seen so far.  I hope they don't move to something else
and stick with the standard.


Len
--
  ___     ___    ___  ________  ______
 /|  |   /\  \  /|  \|\   _   \/\   __\      Len Harold
| |  |   \ \   - |   \ \  \_\ /_ \  \_/      Systems Engineer
| |   \   \ \  \ _|\  \ \   _   \ \  \___    Phone: 208-555-7034
| |    \   \ \__\/\ \__\ \__\ \__\ \_____\   Fax:   208-555-6840
| |*    |   \/__/  \/__/\/__/\/__/\/_____/   Email: len*@*mrc.uidaho.edu
|/\     |/\                                  Web:   www.mrc.uidaho.edu
 \/        \_/\
 /|            |   Microelectronics Research
| |            |   and Communications Institute
| |____________|   at the University of Idaho
|/____________/
Article: 10399
Subject: Design/document/reference of motion encoder interface wanted
From: leslie.yip@asmpt.com
Date: Sat, 16 May 1998 01:55:37 GMT
Links: << >>  << T >>  << A >>
Dear everybody

I would like to design a FPGA/ASIC to have a interface for optical Shack
encoder that provides position information to the servo controller. To improve
the efficiency and reliability in obtaining the position information from the
encoder, a new peripheral ASIC chip, Motion Control Peripheral (MCP) is
proposed to provide hardware interface with opto-encoder to the servo
processor.

It should have
· Encoder Interface (Triggers/Strobes)
· 16-bit counter or 32-bit counter in cascade
· Host Interface
· Status Register and Control Register
· Position Pattern Generator (PPG) with FIFO


Thanks in advance !

Leslie Yip
leslie.yip@asmpt.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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