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
In article <355b2ebd.8162686@news.indigo.ie>, mulmon@hotmail.com says... > >Hi. Would anyone have a working project for a >small standalone vga pattern generator...! I build one based on a PIC16C54, very small (3x5cm including vga connector). It is limited to one pattern and only 640x480. YvesArticle: 10401
Check out the low cost solutions at http://www.associatedpro.com you can get FPGA development boards as well as VHDL software and routers all for as low as 349.00!! rajesh@comit.com wrote: > On Sun, 10 May 1998 12:27:08 -0400, Neil Horman <nrhorman@eos.ncsu.edu> wrote: > > > Hello there all! > > > I'm trying to get started in some hardware design. I've done alot > > > in school, and now that I'm graduating I'd like to continue doing some > > > fpga design at home. Can anyone suggest an affordable eda environment > > > that would run under windows NT or Linux on a DEC Alpha based machine? > > > Thanks! > > > -Neil Horman > > > > > I used Quicklogic tools which contains silos verilog simulator > > Synplify synthesis tool and quicklogic place and route tool > > budled together. I heard that whole package costs around > > $3000 > > They have 30 evaluation kit. Visit > > http://www.quicklogic.com/products/pctools/ > > to get more information. I guess other vendors might also > > be having simillar products. I heard Xilinx tools and book > > for $90 for students. I am not aware of exact functionality > > Xilinx also has "Foundation express" tool with Synopsys FPGA Express > > and place and route tool. You need to check pricing from > > their marketing guys. > > Hope this helps. > > Rajesh > > -- > > Rajesh Bawankule | Checkout http://www.comit.com/~rajesh/verilog/ > > Hardware Engineering Manager | for Verilog FAQ > > Comit Systems Inc. | > > 3375, Scott Blvd, #330 | Phone : (408)-988-2988 > > Santa Clara, CA 94054 | Fax : (408)-988-2133 > > ----------------------------------------------------------------------------- > > -------------------------------------------------------------------- > Posted using Reference.COM http://WWW.Reference.COM > FREE Usenet and Mailing list archive, directory and clipping service > -------------------------------------------------------------------- -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 10402
mulmon@hotmail.com wrote: > > Hi. Would anyone have a working project for a > small standalone vga pattern generator...! In our OEM product range, we have a VGA-232 Product. This is a VGA card, RS232/485 Input, with inbuilt Scaleable FONT, and simple LINE vector capability, Supports 640 x 400 pixel VGA, mixed text and Graphics, at 16 colours. It is intended for OEM apps, using low cost remote VGA displays, as an alternative to the expensive/short design life Graphic LCD modules. Does this fit your requirements ? - jg -- ======= Manufacturers of OEM Modules and Tools for uC and PLD ========= = Specialists in Development tools for C51 cored controllers = Leaders in Rapid Application Development SW for C51 uC = Ask for our Controller & Tools selector Guides = mailto:DesignTools@xtra.co.nz Subject : Selc51ToolsArticle: 10403
David Tweed wrote: > I think you should take a look at the architecture of the PDP-11. You might > need to substitute compiler-generated sequences for some of the fancier > addressing modes, but in general it sounds like a good fit for what you're > trying to do. 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". Of course, discrete TTL and FPGAs have different constraints. John Rible did an interesting minimal CPU, the QS2 (see the citations in my paper -- I don't know if it's on the web anywhere). -- Brad Rodriguez, T-Recursive Technology bjaa@aazetetics.com Email address spoofed to block spam. Remove "aa" from name & domain. Embedded software & hardware design... http://www.zetetics.com/recursiv See the new CamelForth page at........ http://www.zetetics.com/camelArticle: 10404
Thanks to all who have sent me info regarding the vga gen. Regards and best wishes MartinArticle: 10405
Try contacting Dr.Errol Tez at Loughborough University, I did a Masters project for him on just that subject and he holds the rights to the design. He's a nice guy and will talk technical if required, but he is hard to track down. e.s.tez@lboro.ac.uk Tel: +44 1509 234779 Fax: +44 1509 234777 Okay ? Jason Nunn Smartscan Ltd Industrial Safety Control Consultants & Manufacturers leslie.yip@asmpt.com wrote in message <6jirmp$h5$1@nnrp1.dejanews.com>... >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 newsreadingArticle: 10406
Brad Rodriguez wrote:
>
> <snip>
>
> Of course, discrete TTL and FPGAs have different constraints. John
> Rible did an interesting minimal CPU, the QS2 (see the citations in my
> paper -- I don't know if it's on the web anywhere).
>
It's not, but I'll send an MSword6 description of it to email requests. I'm
using it for a course at UCSC Extension, where students add features in a
10-week design project. It's a 16-bit 'baby-RISC' with 8 registers in about 4k
QuickLogic gates.
John Rible \ SandPiper Technology voice: 408-458-0399
\ hardware, software and so forth... fax: 408-471-0175
jrible@sandpipers.com \ 317 California Street, Santa Cruz, CA 95060-4215
Article: 10407
In fact, a fine poster paper about a small FPGA-based processor
was given at FCCM last month. I'm so inspired by it, and by the
new availability of cheap FPGAs and tools, that I'm developing
a little minimum-cost FPGA+SRAM board and a similar little
processor design for it. I'm hoping to make it available by
the end of the year. (This is strictly a personal hobby effort
on my part, for fun, experimental and educational purposes.)
The poster paper is "A FPGA based Forth microprocessor", by
P.H.W. Leong, P.K. Tsang and T.K. Lee, of the Chinese U. of
Hong Kong. They developed a small 16-bit stack processor,
in VHDL, which synthesized into 150 CLBs of a Xilinx XC4013E-3.
The data and return stacks, 16 words deep each, are in CLB
RAM. It uses 4-bit (zero-operand) instructions, packed four to
a word, except for a 16-bit call instruction. It runs at 10 MHz
= 10 MIPS. They targeted a public domain Forth metacompiler
called SOD32 to it. Most of the 4013 is left over for other
hardware. Neat!
Three years ago at FCCM '95, Philip Frieden showed us his
16-bit minicomputer (in a real box with lights and switches!)
that fit into part of an XC4005. So a small GP processor
certainly can be programmed into an FPGA with great success.
But with the FPGA we can extend the processor's functions
in application-specific ways, even dynamically on demand,
to get higher performance than hard-wired CPUs and ASICs, or
to get the same perfomance at lower cost. That's
reconfigurable computing.
Both Altera and Xilinx have recently made substantial FPGAs
and tools available cheaply. Altera's FLEX 6016 is $20 in
single quantities. It has 1320 LEs (LE = 4-LUT+FF), good for 8K
gates or more, and 117 I/Os in the cheap 144-pin TQFP package.
The full set of tools is free for that part from their web
site. No RAMs in the FLEX 6K, though, sigh. Xilinx's
Spartan series, which is similar to the XC4000 family,
is also low priced, and they are selling tools for $95,
or less included in that textbook. These are real, mainstream
FPGA architectures with real tools, that are finally available
at prices that individual experimenters and students can afford.
Finally, after all these years!
So I'm working up a little Altera 6016 + SRAM board. Now there
are fast registered/synch 1 Mbit SRAMs, at $9 in singles, thanks
to PC motherboard caches. Synchronous SRAMs are far more sensible
to deal with in an FPGA system, since there is no need to shape
a WE pulse mid-cycle that meets all the specs. It's damned hard
to do that and still go fast while observing worst-case specs, as
was recently discussed in comp.arch.fpga. With the synch SRAM,
your address, data in and WE just need to setup and hold around
a clock edge. So I'm hitching a 64K by 16 synch SRAM to the 6016.
Plus a parallel port connection for programming the 6016 and for
fast PC I/O, a serial line driver/rcvr, and a clock can, some
headers connected to uncommitted I/Os, and some buttons and blinky
lights. It will also plug onto a little hex keyboard and 64x2 LCD
module, a motor driver module, etc., that my partner in all this
already makes and sells for his 68HC11 robotics controller boards.
<http://www.teleport.com/~raybutts> This little board will be
a minimum stand-alone reconfigurable computer. I'm calling
it KIM-RC for 'Keep It Minimum' Reconfigurable Computer.
I'm developing a small 16-bit stack CPU design, using the
SRAM for code, data and stacks, and leaving most of the
FPGA for custom-configured instructions, and reconfigurable
computing facilities in general. And then port a little compiler
or two to the instruction set. This is easier than it sounds
in Forth; many Forths are designed for extreme portability
by being all written in Forth except for a few primitive words.
Some small C compiler could also be targeted to the board.
Or of course it could just be used directly as an FPGA+SRAM
module for whatever, too.
I would include the source design for the stack CPU with the
board, under the GPL, to encourage its use as a base for
reconfigurable computing. Others could add their own custom
stuff, I hope, and likewise put it out there under the GPL.
If all this works out, I'd like to do a second board, with
a flash RAM and a PLD, so many configurations can be stored
in the flash and loaded on demand by the FPGA, which would
save its state first in the SRAM. (Yes, Steve, I already
thought of that too... ;-) This would also provide some
non-volatility, so the little board could stand alone in
embedded apps.
But for starters, it will be plenty if we can just get the
little FPGA+SRAM board together and running by the end of
the year. The real trick will be hand-soldering the 20-mil
TQFPs to the board! We'd like to make KIM-RCs available to
students and experimenters for a low price, if it all
works out. I'll post progress reports, if people are
interested.
--Mike
Article: 10408>Ah well, out with the backups, restore the original project directory >and normal service is resumed. Fortunately when I did the upgrade I put >a new disk in to the PC, and put NT4 and the series 1.4 tools on to it, >leaving me with an intact WfW3.11 installation on the C drive that I can >still boot and use. I find it MUCH safer to install the upgrade on a different computer until you're sure you like it, and how it's going to behave. Tim Olmstead email : timolmst@cyberramp.net Visit the unofficial CP/M web site. MAIN SITE AT : http://cdl.uta.edu/cpm MIRROR AT : http://www.mathcs.emory.edu/~cfs/cpmArticle: 10409
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 ParityArticle: 10410
Mike, Please keep us informed on your progress. Thanks, Fitz Mike Butts wrote: > In fact, a fine poster paper about a small FPGA-based processor > was given at FCCM last month. I'm so inspired by it, and by the > new availability of cheap FPGAs and tools, that I'm developing > a little minimum-cost FPGA+SRAM board and a similar little > processor design for it. I'm hoping to make it available by > the end of the year. (This is strictly a personal hobby effort > on my part, for fun, experimental and educational purposes.) > > The poster paper is "A FPGA based Forth microprocessor", by > P.H.W. Leong, P.K. Tsang and T.K. Lee, of the Chinese U. of > Hong Kong. They developed a small 16-bit stack processor, > in VHDL, which synthesized into 150 CLBs of a Xilinx XC4013E-3. > The data and return stacks, 16 words deep each, are in CLB > RAM. It uses 4-bit (zero-operand) instructions, packed four to > a word, except for a 16-bit call instruction. It runs at 10 MHz > = 10 MIPS. They targeted a public domain Forth metacompiler > called SOD32 to it. Most of the 4013 is left over for other > hardware. Neat! > > Three years ago at FCCM '95, Philip Frieden showed us his > 16-bit minicomputer (in a real box with lights and switches!) > that fit into part of an XC4005. So a small GP processor > certainly can be programmed into an FPGA with great success. > But with the FPGA we can extend the processor's functions > in application-specific ways, even dynamically on demand, > to get higher performance than hard-wired CPUs and ASICs, or > to get the same perfomance at lower cost. That's > reconfigurable computing. > > Both Altera and Xilinx have recently made substantial FPGAs > and tools available cheaply. Altera's FLEX 6016 is $20 in > single quantities. It has 1320 LEs (LE = 4-LUT+FF), good for 8K > gates or more, and 117 I/Os in the cheap 144-pin TQFP package. > The full set of tools is free for that part from their web > site. No RAMs in the FLEX 6K, though, sigh. Xilinx's > Spartan series, which is similar to the XC4000 family, > is also low priced, and they are selling tools for $95, > or less included in that textbook. These are real, mainstream > FPGA architectures with real tools, that are finally available > at prices that individual experimenters and students can afford. > Finally, after all these years! > > So I'm working up a little Altera 6016 + SRAM board. Now there > are fast registered/synch 1 Mbit SRAMs, at $9 in singles, thanks > to PC motherboard caches. Synchronous SRAMs are far more sensible > to deal with in an FPGA system, since there is no need to shape > a WE pulse mid-cycle that meets all the specs. It's damned hard > to do that and still go fast while observing worst-case specs, as > was recently discussed in comp.arch.fpga. With the synch SRAM, > your address, data in and WE just need to setup and hold around > a clock edge. So I'm hitching a 64K by 16 synch SRAM to the 6016. > Plus a parallel port connection for programming the 6016 and for > fast PC I/O, a serial line driver/rcvr, and a clock can, some > headers connected to uncommitted I/Os, and some buttons and blinky > lights. It will also plug onto a little hex keyboard and 64x2 LCD > module, a motor driver module, etc., that my partner in all this > already makes and sells for his 68HC11 robotics controller boards. > <http://www.teleport.com/~raybutts> This little board will be > a minimum stand-alone reconfigurable computer. I'm calling > it KIM-RC for 'Keep It Minimum' Reconfigurable Computer. > > I'm developing a small 16-bit stack CPU design, using the > SRAM for code, data and stacks, and leaving most of the > FPGA for custom-configured instructions, and reconfigurable > computing facilities in general. And then port a little compiler > or two to the instruction set. This is easier than it sounds > in Forth; many Forths are designed for extreme portability > by being all written in Forth except for a few primitive words. > Some small C compiler could also be targeted to the board. > Or of course it could just be used directly as an FPGA+SRAM > module for whatever, too. > > I would include the source design for the stack CPU with the > board, under the GPL, to encourage its use as a base for > reconfigurable computing. Others could add their own custom > stuff, I hope, and likewise put it out there under the GPL. > > If all this works out, I'd like to do a second board, with > a flash RAM and a PLD, so many configurations can be stored > in the flash and loaded on demand by the FPGA, which would > save its state first in the SRAM. (Yes, Steve, I already > thought of that too... ;-) This would also provide some > non-volatility, so the little board could stand alone in > embedded apps. > > But for starters, it will be plenty if we can just get the > little FPGA+SRAM board together and running by the end of > the year. The real trick will be hand-soldering the 20-mil > TQFPs to the board! We'd like to make KIM-RCs available to > students and experimenters for a low price, if it all > works out. I'll post progress reports, if people are > interested. > > --MikeArticle: 10411
Andy Peters <apeters.NOSPAM@noao.edu.NOSPAM> wrote in article > > Just checked the map report...no I/O flops or latches > used...hmmm...Looks like the mapper didn't do it. > Back when I was using 4000E parts, we had to manually instantiate each I/O block if we wanted to use the I/O flip flops. We were using FPGA Express 1.2 so I don't know if the later versions fixed this problem. -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 10412
Hi Folks At the company I work for, we use the Xilinx 5200 family quite extensively, and consequently, up till a month or so ago, were using either Viewlogic or Foundation design entry with the XACT 6.0.1 generation place and route tools. We finally received the Foundation 1.4 series updates that allowed us to move to NT4 and the supposedly newer and better 'M series' place and route tool. As a familiarisation exercise, after installing the new tools and the patches for them from the Xilinx FTP site, I took a couple of my current designs and moved them over to the Foundation 1.4 tool. The conversion worked fine, no problems (or so I thought), but I was suprised when I came to build them that one design wouldn't route while the other wouldn't even place - these are designs in XC5204s that use about 75-80% of the CLB logic resources and 70% of the available flipflops and I/O pins, but both build fine in XACT 6.0.1 with place=3 route=4 options in PPR. I passed the problem over to Xilinx tech support, and they were able to get the design to place by replacing all the IFD and OFD macros with IBUF/FD and FD/OBUF elements - these are what the macros contain anyway, but the placer seemes to be able to handle them better as individual elements than as OFD or IFD macros. However I still have trouble routing the designs. On an overnight multipass compile run, I did 100 builds, starting at cost code = 1 and working right through the whole list. 16 hours later, only two of those builds actually fully routed. (and one of those wasn't saved - I had told the tool to save only the top ten builds, and nine that had unrouted connections were prefered to a fully routed build). Has anyone else tried to migrate existing XC5200 designs to the new tools and what sort of success have you had ? By the way, I found out subsequently that the 'copy project' option in the Foundation 1.4 Design Manager Files menu doesn't quite do what I expected. It does create a new copy of the project, of sorts, but also seems to mess with the user defined libraries back in the original project directories. In the course of the 'project copy' a message appears advising that the libraries are in an 'old format' and do I want to convert them. Assuming that they were being copied to the new project structure I clicked ok. I then found, some time later, that when I went to make a modification to one of the designs using the XACT 6 tools, all my own macro elements had been lost. The schematic files for the macros still exist and seem to be undamaged, but when I open the top level schematic for the design, the design manager reports that it is unable to find any of the macros in that top level schematic. It appears that the user defined library elements are left in the original directory, but are converted to some new format. Ah well, out with the backups, restore the original project directory and normal service is resumed. Fortunately when I did the upgrade I put a new disk in to the PC, and put NT4 and the series 1.4 tools on to it, leaving me with an intact WfW3.11 installation on the C drive that I can still boot and use. All in all so far I am less than impressed with the series 1.4 "upgrade". Jeff Graham MAS Technology Ltd Lower Hutt New Zealand jgraham@mas.co.nzArticle: 10413
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.
Simon
---------------------------------------------------------------------------------------------------------------------------------------
jhallen@world.std.com (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.
>
>Including an EPROM would be make this even more realistic, but I don't want
>a harvard architecture machine with the ROM and RAM being used in parallel.
>I choose 128K of RAM because you should deal with the fact that 64K is never
>enough memory in practice. Keep in mind that you are going to be the one to
>program this thing, so annoying banking/segmenting schemes may not be what
>you want to have to deal with.
>
>I had originally thought of this problem with the XC3020, but then the
>XC5202 came out, which happens to be both cheaper and better (it has twice
>as many FFs per CLB, plus dedicated carry logic).
>
>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.
>
>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). There are also schemes
>with no indexing (like the 8080), but as a programmer I want to be able to
>access data structures efficiently, so I tried to avoid them. The trick
>with the 6502 is that the pointer to your data structure is in z-page, and
>the 8-bit Y register contains the offset. This ends up being about twice as
>fast, compared to having to do the explicit double-precision add yourself.
>
>What I think might fit is to get rid of the 8-bit Y register and 8-bit stack
>pointer and instead reserve the first 16 bytes of RAM as base registers. So
>the processor only has an 8-bit accumulator, a 16-bit program counter, the
>carry flag, overflow flag and interrupt enable flag. You don't need zero or
>negative flags, since the branch intructions can just test the accumulator
>contents. You don't have to save the interrupt enable flag during
>interrupts, but you do have to save carry and overflow. If you make all
>instructions two-bytes long, you can then require them to be aligned and use
>the LSB of the PC for one flag (like on the ARM chip). I'm just itching to
>get rid of the overflow flag too, but it just sucks too much if you don't
>have it. 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.
>
>Most instructions have the format: |5-bit op-code|3-bit reg|8-bit offset|,
>and the standard addressing mode is base-reg plus offset. Base reg 6 always
>returns zero, so you also get zero-page direct. When the base reg is 7, the
>offset is instead an immediate value for accumulator/immediate instructions.
>Conditional branch intructions use the reg field for the condition code.
>There is also a format for the jump and link instruction:
>|2-bit op-code|14-bit direct addresss|. The direct address is shifted left
>twice before being transfered to the program counter. The old program
>counter and flags are stored in base register 6. Interrupts cause the jump
>and link instruction to be invoked, but store the program counter and flags
>in register 7 instead. There is a jump and link register instruction (with
>the normal instruction format), which if used with register 6 or 7 cause a
>return from subroutine or interrupt (so the pc to register transfer has to
>be a swap). You can use the z-page direct mode to access register 6 or 7,
>in case you want to save the values on a stack (perhaps with register 5).
>
>This is pretty nice: only six instruction sequences: read/modify/write (for:
>clr, inc, dec, cry (add carry), brw (subtract carry), rol, ror, lsl, lsr,
>asr, sta); accumulator/memory and accumulator/immediate (add, adc, sub, sbc,
>and, or, xor, lda); branch on condition; jump and link and jump and link
>register. There are really only four sequences because the immediate modes
>are the same as the memory modes with steps left out. The implementation
>requires one temporary 16-bit register, the address register, the
>instruction register, and data input/output registers in addition to the
>program counter, accumulator and flags. You can use the ALU to increment
>the PC, but you have to insert extra cycles when you cross page boundaries
>(since the ALU is only 8 bits).
>
>Total size alu+shift left (16 clbs), shift right on b-input of alu (4 clbs),
>accumulator (4 clbs), temporary register (8 clbs), program counter (8 clbs),
>intstruction register (4 clbs), address register (0: use registers in
>io-pads), data registers (0: use registers in io-pads), address register mux
>(16 clbs): gives 56 clbs. Hmm... might just fit in an XC3020 if I replace
>part of the address register mux with tri-state buffers.
>
>The XC5202 changes things: you might be able to have 16 8-bit registers on
>chip, and use 24-bit wide program counters and address pointers. Best of
>all, you can make it a load-store machine, limit all instructions to two
>memory accesses, and use pipelining (so all instruction execute in 2
>cycles).
>
>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.
>
>Anyway it would be cool to finish this project and see if anyone wants to
>buy the core, or make a 'basic stamp' like module which contains optional
>other logic in the FPGA, such as video, serial ports, IDE interface, video,
>etc.
>
>--
>/* 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]]);}
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Article: 10414Brad 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).Article: 10415
In article <355C7C91.7288E58B@yahoo.com>,
Rickman <spamgoeshere1@yahoo.com> wrote:
>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?
Well... the priority is entertainment (of course), followed by price and
then performance.
>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.
This scheme is pretty nice because the workspace pointer can be relatively
small. A trick, if you want to allow 1/2 overlapping workspaces without
requiring an additional adder, is to precompute the workspace base address
and the base address plus 1/2 the number of registers. The most significant
register select bit could then select between the two base addresses.
--
/* 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: 10416
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).
Someone mentioned trying to have two 4-bit instructions per fetch, but I
don't think it's really workable. You would not have space for swap, over,
or multiple word sizes for ! and @- which makes the block copy loop even
worse.
If I were using the XC4000 series they might be workable because of the
relatively large stack cache. But if I'm going to assume an XC4000, I might
as well assume wider memory paths, implement a MIPS or ARM clone and then
have GCC available for it.
As for Java engines... well I have just two words: "code generator". It's
difficult to see how a Java engine could possibly compete with a modern RISC
processor and Java with a real code generator tacked on to it.
--
/* 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: 10417Dear everybody I am trying to switch off the turbo bit in my Altera 7128E circuit, but I can't make it work. I try to set the global settings under "Global project logic synthesis" and here I choose the "define synthesis style". No matter how I set the turbo bit it is not switched off. Either I get the warning "Project has conflicting defaults for turbo bit and slow slew rate. My problem is that I want to reduce the switching speed, because they might cause some problems in my design. Thank you for taking the time for reading this. FlemmingArticle: 10418
>As a familiarisation exercise, after installing the new tools and the >patches for them from the Xilinx FTP site, I took a couple of my current >designs and moved them over to the Foundation 1.4 tool. The conversion >worked fine, no problems (or so I thought), but I was suprised when I >came to build them that one design wouldn't route while the other >wouldn't even place - these are designs in XC5204s that use about 75-80% >of the CLB logic resources and 70% of the available flipflops and I/O >pins, but both build fine in XACT 6.0.1 with place=3 route=4 options in >PPR. >I passed the problem over to Xilinx tech support, and they were able to >get the design to place by replacing all the IFD and OFD macros with >IBUF/FD and FD/OBUF elements - these are what the macros contain anyway, >but the placer seemes to be able to handle them better as individual >elements than as OFD or IFD macros. >However I still have trouble routing the designs. On an overnight >multipass compile run, I did 100 builds, starting at cost code = 1 and >working right through the whole list. 16 hours later, only two of those >builds actually fully routed. (and one of those wasn't saved - I had >told the tool to save only the top ten builds, and nine that had >unrouted connections were prefered to a fully routed build). > >Has anyone else tried to migrate existing XC5200 designs to the new >tools and what sort of success have you had ? > I had exactly the same experience with a 5206 design. On Xact 6.0.1, the full design (about 70%) routed in about 10mins on a Sun Sparc 10. I tried to route it on a PII 266 with M1.4 and it could not come up with a solution in 4 hours routing, so I gave up and I gave the design to Xilinx, and after numerous tries with several costtables, they found one to have it routed in about 20 hours. They admitted this was not acceptable and could only recommend me to keep using Xact 6.0.1 So, I am equally less than impressed with M1.x for 5K series. BrunoArticle: 10419
John Eaton wrote: > 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. That's why I suggested 30-40 MHz for a realizable CPU core of the type we're talking about. > This makes FPGA's the ideal candidate for a CPU design using serial logic. I really should have thought of this myself. I once did an FPGA design that had to do about 4-5 add/subtract operations on integers that were around 15-20 bits wide, 386000 times per second. Since my oscillator ran at 6.176 MHz, I had 16 clocks available per calculation whether I used them or not. I designed a 2-bit wide data path that turned out to be an excellent fit architecturally for the Actel FPGA that I was using at the time. -- David TweedArticle: 10420
Sorry for being late in this thread, but we've been accidentally cut off from news the past few weeks. Tom Meagher wrote: > Synplify 3.0b still uses the clock enable inputs willy nilly, I believe that Synplify 3.0c uses CE exactly the way you want with the workaround code you submitted. Regards, Jonas -- +---------------------------------------------------------------+ | Jonas Nilsson | | HARDI Electronics AB Phone : +46-40-59 29 00 | | Derbyvagen 6B Fax : +46-40-59 29 19 | | SE-212 35 MALMO E-mail: jonas@hardi.se | | SWEDEN WWW: http://www.hardi.se | +---------------------------------------------------------------+Article: 10421
On Sun, 17 May 1998 15:10:33 GMT, dave@dave-ltd.co.uk.NOSPAM (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 > <<snip equations>> I suggest you try breaking up your parity equations into even smaller pieces; e.g. make each parity equation have only one exclusive-or operator. It takes more equations, but it gives XABEL less opportunity to un-optimize the result. Russ May russmay@tfs.net (at home) russmay@ditmco.com (at work)Article: 10422
If you click on the warning message and click on "Help on Message" in Max+plus II, it will tell you that for 7000E device, there is only 1 bit which controls slow slew rate/turbo hit. Hence, either slow slew rate or turbo bit (not both) needs to be enabled. By the way, Global Project Logic Synthesis will affect the whole design; use Logic option if you want to do it pin by pin. Regards, Ying ying@csua.berkeley.edu In article <355FFCF3.4BF41553@cern.ch>, Flemming JENSEN <Flemming.Jensen@cern.ch> wrote: >Dear everybody > >I am trying to switch off the turbo bit in my Altera 7128E circuit, but >I can't make it work. I try to set the global settings under "Global >project logic synthesis" and here I choose the "define synthesis style". >No matter how I set the turbo bit it is not switched off. Either I get >the warning "Project has conflicting defaults for turbo bit and slow >slew rate. > >My problem is that I want to reduce the switching speed, because they >might cause some problems in my design. > >Thank you for taking the time for reading this. > >FlemmingArticle: 10423
I don't know the technical reasons, but XOR optimization is a
resource-intensive problem and difficult for many optimization tools. The
36-bit parity function is really a 36-input XOR gate.
A couple of potential solutions (based on ignorance of XABEL):
* Break the 36-bit parity into smaller, maybe as 4-input XORs. Create new
nodes for the intermediate values. Combine the results with an XOR tree,
again creating new nodes.
POSSIBLE HINT:
- Take the 36 inputs in four groups of nine
- For each group:
- Create a node and XOR the first 4 inputs together
- Create a node and XOR the second 4 inputs together
- Create a note and XOR the ninth input with the nodes from the
previous 4-input XORs. Call this the 'group' node
- Combine the 'group' nodes using a final 4-input XOR
- This might result in optimal partitioning, though some tools
do not use the 'H' function generator in the XC4000/Spartan
devices.
* There may be an option within XABEL that provides for better XOR
optimization, or there may even be a way to flag the specific parity output
for XOR optimization.
* As a final option, use a schematic tool to create the parity function. A
36-bit parity function should require no more than five XC4000/Spartan logic
blocks and two levels of logic. Four logic blocks each take nine of the 36
inputs to create an intermediate value. A 9-input XOR/Parity function
easily fits into one CLB. The 9-input parity function uses two 'F' function
generators connected to an 'H' function generator. Then take the four
intermediate values and combine them with a final XOR, which requires half a
logic block.
Hope this helps.
-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail: sknapp@optimagic.com
Web: http://www.optimagic.com
-----------------------------------------------------------
David Knell wrote in message <6jmuv5$2p2$1@alpha.ftech.net>...
>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
>
>
Article: 10424On Sun, 17 May 1998 15:10:33 GMT, dave@dave-ltd.co.uk.NOSPAM (David Knell) wrote: just a thought - is xabel turning the whole thing into a sum-of-products? is there some way to specify an xor architecture? it presumably isn't generating an SOP for all 36 inputs, since it would take (by a quick calculation) about 10**13 bytes just to write it down. but even the 8-input intermediates have 128 terms, so it's possible that the optimiser is falling over. incidentally, i had a lot of problems some time ago with xabel coding big counters, which took up at least five times as much space as expected (possibly for the same reason). the solution i used was to recode in vhdl. evan (ems@riverside-machines.com)
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z