Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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: 10376Joseph 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
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 DutkyArticle: 10378
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
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: 10380Phil 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! -andyArticle: 10381
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
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.NOSPAMArticle: 10383
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: 10384David 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 EatonArticle: 10385
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: 10386There 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
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
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> 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
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
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.comArticle: 10392
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! StuartArticle: 10393
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. StuartArticle: 10394
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. -andyArticle: 10395
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! -andyArticle: 10396
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? -andyArticle: 10397
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
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
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:
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