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
I really mis-stated what it was I wanted to say....so I'll try to correct it here... Austin Franklin <darkroo3m@ix.netcom.com> wrote in article <01bd7e9b$8488f240$27a8b8cd@drt1>... > > I thought that the PCI spec intentionally gave enough time after reset > > to allow for booting of slow reconfigurable logic (like the Xilinx > > chips). My understanding (for what it is worth) is that a device has to > > be able to not clobber the bus after some short time, but doen't have to > > respond to a command for a much longer time, like many ms. This may be > > an addition in the 2.1 version of the spec. But I am sure I saw this > > discussed on the PCI-SIG mailing list. I don't know enough to post > > there, but I like to lurk. There is nothing like this in the PCI 2.1 specification. > The PCI reset spec is: Reset Active Time After Power Stable' of 1ms MIN. > So 1ms is all your guaranteed > > For any information on PCI reset timing, see section 4.3.2, page 139+ in > the PCI 2.1 spec. and table 4-5 on p. 134, section 4.2.3.2. > > For a Xilinx, FAST configuration can be up to 12MHz per bit, so > configuration time is 83ns/bit. 1ms/83ns = 12048 bit configuration. So, a > 4010 barely makes this spec, and a 4103 doesn't. > > The spec in the data book is actually a range of 4MHz to 10MHz for FAST, > and .5MHz to 1.25MHz for slow. Doesn't look too good for any Xilinx part > to make the actual PCI spec's reset time. > > In truth, most systems hold reset for seconds, instead of 1ms, so you > really are safe, just not within spec. In fact, how long the reset is active (low) for is not consequential to the configuration, unless it is hooked to the /INIT pin of a 4k, or the /INIT or /RESET of a 3k. If it is, then configuration begins after reset is released, if not, configuration begins when the Xilinx 'thinks' power is good. Then you have until the BIOS tries to configure the PCI bus. This duration of time is NOT in the PCI spec. Just be aware that the BIOS usually doesn't do configuration of the other cards until it has brought up the video, done the memory tests etc. so you should really have plenty of time to configure the part...theoretically, though no one can guarantee it. You can always hook a logic analyzer up to the PCI bus and check out how long it takes to issue the config cycles to your slot from when /RES goes inactive. Austin Franklin darkroom@ix.netcom.comArticle: 10351
Austin Franklin wrote: > > Rickman <spamgoeshere1@yahoo.com> wrote in article > <3559EFFD.4975C166@yahoo.com>... > > Austin Franklin wrote: > > > The PCI reset spec is: Reset Active Time After Power Stable' of 1ms > MIN. > > > So 1ms is all your guaranteed > > ...snip... > > > Austin Franklin > > > darkroom@ix.netcom.com > > > > -- > > You are quoting the time that the RESET signal must be asserted. I > > believe there is another spec that allows a board to take some > > additional time after the removal of RESET before it will respond to > > commands on the bus. I don't know where it is in the spec, but as I > > said, I saw this discussed on the PCI-SIG mailing list. > > Nope. That does not exist in the PCI 2.1 spec. that I have found. If you > can find it, page or section, then I'll stand corrected. PCI signals can > commence immediately after reset is released. > > Austin -- We are still not on the same note. I didn't say that all boards MUST wait some period of time before beginning to operate or even start commands on the bus. But I read people discussing in the PCI-SIG group, how a given board does not have to immediatly respond to commands following reset. I dug around in my old email, (I am a serious packrat) and found what I was talking about. You are right, that this is not in the spec. But it is an ECN that may/will be in the next rev of the spec. See below. ************** if you read the ECN, it says that no PCI accesses will occur within 5 clocks of RST# deasserted on any device. it further says that the device that was reset will not be accessed until 2^25 clocks have occurred. one of the intents of the change was to allow FPGA's adequate time to be programmed. since no FPGA's can be programmed within 5 clock cycles, they simply must ensure that they are tristated within 5 clocks after reset. the second change (2^25 clocks) allows the FPGA time to load it's program. if a configuration access occurs before the FPGA is programmed, it will not respond and the configurator will assume that there is no device there. ************** Of course, I know nothing about this myself. I am simply passing on this email from the PCI-SIG mailing list. Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10352
Chuck Shinn wrote: > > Steven K. Knapp (sknapp@optimagic.com) wrote: > : Does anybody know where I might find an Ultra 2 SCSI core? > > Contact Symbios in Ft Collins, CO. I believe they have this core as > part of their IP offerings. Of course you'll have to book the > fabing with them. > > Chuck Shinn > Hewelett Packard > Boise, Idaho Symbios can get you not only the core, but design-proven Ultra2 SCSI I/O pads as well (not a trivial feat). See www.symbios.com for more information, or send me email at mike.mcmanus@symbios.com and I can put you in touch with the right people (it's not me...). Mike McManus Symbios, Ft. Collins COArticle: 10353
There's been an update! See what's new on The Programmable
Logic Jump Station, including 1997 programmable logic market data
and upcoming seminars and conferences.
http://www.optimagic.com/
The Programmable Logic Jump Station is a comprehensive set of
links to nearly all matters related to programmable logic.
Featuring:
---------
--- Frequently-Asked Questions (FAQ) ---
Programmable Logic FAQ - http://www.optimagic.com/faq.html
A great resource for designers new to programmable logic.
--- FPGAs, CPLDs, FPICs, etc. ---
Recent Developments - http://www.optimagic.com
Find out the latest news about programmable logic.
Device Vendors - http://www.optimagic.com/companies.html
FPGA, CPLD, SPLD, and FPIC manufacturers.
Device Summary - http://www.optimagic.com/summary.html
Who makes what and where to find out more.
Market Statistics - http://www.optimagic.com/market.html
Total high-density programmable logic sales and market share.
--- Development Software ---
Free and Low-Cost Software - http://www.optimagic.com/lowcost.html
Free, downloadable demos and evaluation versions from all the major
suppliers.
Design Software - http://www.optimagic.com/software.html
Find the right tool for building your programmable logic design.
Synthesis Tutorials - http://www.optimagic.com/tutorials.html
How to use VHDL or Verilog.
--- Related Topics ---
FPGA Boards - http://www.optimagic.com/boards.html
See the latest FPGA boards and reconfigurable computers.
Design Consultants - http://www.optimagic.com/consultants.html
Find a programmable logic expert in your area of the world.
Research Groups - http://www.optimagic.com/research.html
The latest developments from universities, industry, and
government R&D facilities covering FPGA and CPLD devices,
applications, and reconfigurable computing.
News Groups - http://www.optimagic.com/newsgroups.html
Information on useful newsgroups.
Related Conferences - http://www.optimagic.com/conferences.html
Conferences and seminars on programmable logic.
Information Search - http://www.optimagic.com/search.html
Pre-built queries for popular search engines plus other
information resources.
The Programmable Logic Bookstore - http://www.optimagic.com/books.html
Books on programmable logic, VHDL, and Verilog. Most can be
ordered on-line, in association with Amazon.com
. . . and much, much more.
Bookmark it today!
Article: 10354On 14 May 1998 01:14:43 GMT, "Austin Franklin" <darkroo3m@ix.netcom.com> wrote: >> The circuit has to be seperated from the PCI bus with 100-ohm series >> resistors on each signal (placed close to where the PCI bus routes to the >> FPGA), so as to try to not violate the load limit. > >I don't want to belabor this with you, but I believe that violates PCI >spec. If this method were acceptable, then we would not need PCI to PCI >bridge chips. AFAIK, it's standard practice on m'boards/backplanes to do precisely this to generate the IDSEL signals (i've done it myself, anyway). this is covered somewhere (including the note on p138 of the spec), but i wouldn't make a habit of it. evan (ems@nospam.riverside-machines.com)Article: 10355
On 13 May 1998 18:36:34 GMT, "Austin Franklin" <darkroo3m@ix.netcom.com> wrote: >> The FPGA configuration data downloading program can only be >> available after the system is fully up, but without a configured FPGA >> the device under development is not going to be detected. > >The only thing the BIOS detection does is program the configuration spaces >on the card, and creates a table of what resources are used indexed by >device IDs. This way a driver just looks through this table and finds out >what the resources for its card are. it's *much* more complex than this. your reply also went to the vxd newsgroup, so i expect you'll get lots of extra irrelevant detail (if anyone's still awake there). >> Does anyone have a good solution for this? >> Is there a way to >> re-invoke the device detecting process after the FPGA is configured? > >Yes. Sometimes when developing a PCI FPGA I download the bit stream via >the serial download cable, after the system is booted (or during boot...), >as I assume you are suggesting. Then I run a program (available with many >PCI extender cards, or one that we developed) to write the configuration >space on the card under test. > >There are calls in the OS to get the boot PCI configuration information, >and yes, you can add to the configuration table. You just have to know >what resources are available for you to use (obviously, you can't use one >that is already allocated). hang on.... again, its much more complex than this. what do you write to the configuration space? how do you tell the card what its physical memory address is? you don't have a physical address, since the OS hasn't given you one. you can't add to the 'configuration table'; there's no configuration table concept in a vxd. and there's no way to re-invoke the 'device detecting process'. even if you managed to find an unused region of physical memory, there's no guarantee that the OS wouldn't screw you up at a later time. in short, you've got to write a device driver. george's original problem was: >> Does anyone have a good solution for this? if you mean not having a prom on a production card, then there is no simple/'good' solution. this was exactly joseph hallen's problem, which was discussed at length in the vxd newsgroup. if, however, you mean that you don't have a prom on your *development* card, but that you intend to put one on your production card, then the best solution is to put a prom on your development card. if you don't, you'll have to rewrite your driver for the production card. >> Is there a way to re-invoke the device detecting process after >> the FPGA is configured? no, for a PCI card. is this what you have? evan (ems@nospam.riverside-machines.com)Article: 10356
"Austin Franklin" <darkroo3m@ix.netcom.com> writes:
> I really mis-stated what it was I wanted to say....so I'll try to correct
> it here...
>
> Austin Franklin <darkroo3m@ix.netcom.com> wrote in article
> <01bd7e9b$8488f240$27a8b8cd@drt1>...
> > > I thought that the PCI spec intentionally gave enough time after reset
> > > to allow for booting of slow reconfigurable logic (like the Xilinx
> > > chips). My understanding (for what it is worth) is that a device has to
> > > be able to not clobber the bus after some short time, but doen't have
> to
> > > respond to a command for a much longer time, like many ms. This may be
> > > an addition in the 2.1 version of the spec. But I am sure I saw this
> > > discussed on the PCI-SIG mailing list. I don't know enough to post
> > > there, but I like to lurk.
>
> There is nothing like this in the PCI 2.1 specification.
>
If I remember correctly, that is one of the problems with v 2.1 that
will be corrected to v 2.2. There's an ECN on it.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 10357If you REALLY need fast config, you might check out the Express mode offered in the EX parts. -- Ed McCauley Bottom Line Technologies Inc. Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, (908) 996-0817 FAX: (908) 996-0817Article: 10358
ems <ems@see_sig.com> wrote in article <355ab586.259944163@news.dial.pipex.com>... > On 14 May 1998 01:14:43 GMT, "Austin Franklin" > <darkroo3m@ix.netcom.com> wrote: > > >> The circuit has to be seperated from the PCI bus with 100-ohm series > >> resistors on each signal (placed close to where the PCI bus routes to the > >> FPGA), so as to try to not violate the load limit. > > > >I don't want to belabor this with you, but I believe that violates PCI > >spec. If this method were acceptable, then we would not need PCI to PCI > >bridge chips. > > AFAIK, it's standard practice on m'boards/backplanes to do precisely > this to generate the IDSEL signals (i've done it myself, anyway). this > is covered somewhere (including the note on p138 of the spec), but i > wouldn't make a habit of it. Yes it is, for the AD/IDSEL lines ONLY, and for INPUT only. Putting a resistor on any other PCI signal does not change the loading characteristics to make it PCI compliant.Article: 10359
Magnus Homann <d0asta@palver.dtek.chalmers.se> wrote in article <lt3eedb454.fsf@palver.dtek.chalmers.se>... > "Austin Franklin" <darkroo3m@ix.netcom.com> writes: > > > I really mis-stated what it was I wanted to say....so I'll try to correct > > it here... > > > > Austin Franklin <darkroo3m@ix.netcom.com> wrote in article > > <01bd7e9b$8488f240$27a8b8cd@drt1>... > > > > I thought that the PCI spec intentionally gave enough time after reset > > > > to allow for booting of slow reconfigurable logic (like the Xilinx > > > > chips). My understanding (for what it is worth) is that a device has to > > > > be able to not clobber the bus after some short time, but doen't have > > to > > > > respond to a command for a much longer time, like many ms. This may be > > > > an addition in the 2.1 version of the spec. But I am sure I saw this > > > > discussed on the PCI-SIG mailing list. I don't know enough to post > > > > there, but I like to lurk. > > > > There is nothing like this in the PCI 2.1 specification. > > > > If I remember correctly, that is one of the problems with v 2.1 that > will be corrected to v 2.2. There's an ECN on it. You are correct!Article: 10360
Hi ! We are using XC4000E FPGA's. According to the Data Book, when configurating the FPGA's, the devices sample the data on the rising edge of the logical product CS0n and WRn. A configuration problem (INITn went always done after the first set of datas) lead us to observe the DOUT pin. We found out that the data going out on this pin was the previous byte present on the data bus BEFORE the microprocessor write operation. Does anybody have a solution for us ? Do we make a mistake (The setup time of 60ns is respected) ? Thank you for your help, Have a nice day, Yves Vandervennet. E-Mail : yves@elmitel.ulb.ac.beArticle: 10361
ems <ems@see_sig.com> wrote in article
<355ab5bb.259997464@news.dial.pipex.com>...
> On 13 May 1998 18:36:34 GMT, "Austin Franklin"
> <darkroo3m@ix.netcom.com> wrote:
>
> >> The FPGA configuration data downloading program can only be
> >> available after the system is fully up, but without a configured FPGA
> >> the device under development is not going to be detected.
> >
> >The only thing the BIOS detection does is program the configuration
spaces
> >on the card, and creates a table of what resources are used indexed by
> >device IDs. This way a driver just looks through this table and finds
out
> >what the resources for its card are.
>
> it's *much* more complex than this. your reply also went to the vxd
> newsgroup, so i expect you'll get lots of extra irrelevant detail (if
> anyone's still awake there).
Er, no, it's not much more complex than I said. We do it all the time.
One can make it more complex than that, but it doesn't have to be. Windows
programmers are used to things being more complicated than they need to be,
so they, sometimes, have trouble recognizing a simple solution (sorry,
couldn't resist ;-).
> >> Does anyone have a good solution for this?
> >> Is there a way to
> >> re-invoke the device detecting process after the FPGA is configured?
> >
> >Yes. Sometimes when developing a PCI FPGA I download the bit stream via
> >the serial download cable, after the system is booted (or during
boot...),
> >as I assume you are suggesting. Then I run a program (available with
many
> >PCI extender cards, or one that we developed) to write the configuration
> >space on the card under test.
> >
> >There are calls in the OS to get the boot PCI configuration information,
> >and yes, you can add to the configuration table. You just have to know
> >what resources are available for you to use (obviously, you can't use
one
> >that is already allocated).
>
> hang on.... again, its much more complex than this. what do you write
> to the configuration space? how do you tell the card what its physical
> memory address is? you don't have a physical address, since the OS
> hasn't given you one.
The OS doesn't assign the resources, the BIOS does. It's not rocket
science to pick an unused region. The PCI card isn't going to be in the
same space as system memory. You can read the configuration space of all
the other PCI cards in the system, and find an unused region. It's really
just not that hard to do if you understand how it works.
> you can't add to the 'configuration table';
> there's no configuration table concept in a vxd.
There are BIOS calls, having nothing to do with what OS you have.
> and there's no way to
> re-invoke the 'device detecting process'. even if you managed to find
> an unused region of physical memory, there's no guarantee that the OS
> wouldn't screw you up at a later time. in short, you've got to write a
> device driver.
Yes there is. You can re-invoke device detection by hitting the reset
button. Re-invoking device detection is different than configuring the
board though, as you don't necessarily need to re-invoke device detection
to configure the board.
Also, you don't have to write anything to get the board configured even
after the O/S has booted. You can just buy an extender card that comes
with the configuration utility that runs under 95/NT/3.1/DOS etc.
Geeze, sounds like you want to keep software programmers employed doing the
same thing that hundreds of others have done previously. Yes, no do need a
driver to integrate the card into the O/S, but you need that anyway...
> george's original problem was:
>
> >> Does anyone have a good solution for this?
>
> if you mean not having a prom on a production card, then there is no
> simple/'good' solution. this was exactly joseph hallen's problem,
> which was discussed at length in the vxd newsgroup.
Yes, there is. I believe you're over complicating this.
> if, however, you mean that you don't have a prom on your *development*
> card, but that you intend to put one on your production card, then the
> best solution is to put a prom on your development card. if you don't,
> you'll have to rewrite your driver for the production card.
Downloading as I outlined in my other posts (and below) works fine. You do
not need to use a PROM for development.
> >> Is there a way to re-invoke the device detecting process after
> >> the FPGA is configured?
>
> no, for a PCI card. is this what you have?
The answer is yes.
You, and I suspect others, are making this much more complicated than it
needs to be. Again, I do this every day as I design PCI cards for a
living.
1) power the system down
2) plug in the board under test
3) power the system on
4) hit 'DEL' to bring up the BIOS config utility
5) download the FPGA
6) exit from the BIOS config utility
7) you will see (depending on your BIOS, and if your board works) the board
listed
in the PCI device list the BIOS prints on the screen, after configuring
the PCI devices
This is the simplest method to configure via download an FPGA used for a
PCI interface. Using the config routine that comes with most PCI extender
cards is equally as simple, and it, too, works just fine.
We use an ASUS T2P4 Pentium System Board for our PCI debugging.
Instead of belaboring the point, why don't you just try it?
Austin Franklin
darkroom@ix.netcom.com
Article: 10362> > >> The circuit has to be seperated from the PCI bus with 100-ohm series > > >> resistors on each signal (placed close to where the PCI bus routes to > the > > >> FPGA), so as to try to not violate the load limit. > > > > > >I don't want to belabor this with you, but I believe that violates PCI > > >spec. If this method were acceptable, then we would not need PCI to PCI > > >bridge chips. > > > > AFAIK, it's standard practice on m'boards/backplanes to do precisely > > this to generate the IDSEL signals (i've done it myself, anyway). this > > is covered somewhere (including the note on p138 of the spec), but i > > wouldn't make a habit of it. > > Yes it is, for the AD/IDSEL lines ONLY, and for INPUT only. > > Putting a resistor on any other PCI signal does not change the loading > characteristics to make it PCI compliant. P.S. the IDSEL resistor is done on the system board, and it is assured that it will only be done once on any signal. To do it on an expansion card can not assure the same. AustinArticle: 10363
Hi. Would anyone have a working project for a small standalone vga pattern generator...!Article: 10364
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: 10365
Is this possilbe to implement a design by creating modules using the
FPGA Express
(assign I/O pads - off) and then using the Schematic editor to connect
all the modules together
in the top level design? Here are the errors that I get :
1. When I connect an ouput port from the module to the output pad
(OPAD):
WARNING:basnu:130 - output pad net "ER" is not driven by an output
symbol
WARNING:basnu:140 - output pad net "ER" has no legal driver
ERROR:basnu:142 - output pad net "ER" has an illegal connection
2. When I connect the output port from the module to an Output buffer
(OBUF) then to the output pad (OPAD):
ERROR:basnu:115 - logical net "ER" has both active and tristate
drivers
FPGA express report that the design inferred an ER_reg flip-flop for
the ER port.
If it is possible then what am I doing wrong? Please help.
Thanks in advance,
Luong
Article: 10366William L. Bahn wrote in message <6j37rs$73h$1@newman.pcisys.net>... >I have been working with a XC3142-3PP132 FPGA. I am using Xilinx's >Foundation Basic (Schematic Capture design entry) design tools and am >configuring the Xilinx using an Atmel AT17C128 Serial EPROM in the Master >Serial Mode. > >My problem is that nearly everytime I burn a new program into the PROM I get >different results. <snip> Many thanks to everyone that has posted and/or e-mailed suggestions and comments. A few of them have pointed out some things that are issues, although they turned out not to be relevent to THIS particular problem. For those that are interested, it turns out that the Foundation Basic tools which I have do not support the XC3100 family of devices, just the XC3100A/L families. BUT, the tools allow you to SELECT devices in this family without any problems - that appears to be a bug in the software. As a result, it appears that the bit stream being generated is for an XC3142A (or an L?) and not the XC3142 that I am using. My guess is that most of the bit stream data is mapped identically between the two devices but that some things are not - hence the hit and miss behavior of even direct in-out circuits. I ordered some XC3142A parts and they work beautifully. About 40 hours of really frustrating effort down the drain, but that's the way it goes. Again, thanks for all of the input - I'm sure I'll have many more questions for you all to ponder.Article: 10367
Hi, I build one -- it produces vertical color bars. I can post the schematics, but there is one little problem. I've built it in the ALTERA FPGA EPM7032LC44. Unless you have access to the programmer, which can program this chip it is of liitle use. If anyone is interested -- send me an e-mail rudolfl@icpdd.neca.nec.com.au I do not post it now, because I do not have the disk with me right now. Rudolf mulmon@hotmail.com wrote in message <355b2ebd.8162686@news.indigo.ie>... >Hi. Would anyone have a working project for a >small standalone vga pattern generator...!Article: 10368
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. Thanks. 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: 10369
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]]);}
Article: 10370In 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: 10371
Hi, I build one -- it produces vertical color bars. I can post the schematics, but there is one little problem. I've built it in the ALTERA FPGA EPM7032LC44. Unless you have access to the programmer, which can program this chip it is of liitle use. If anyone is interested -- send me an e-mail rudolfl@icpdd.neca.nec.com.au I do not post it now, because I do not have the disk with me right now. Rudolf mulmon@hotmail.com wrote in message <355b2ebd.8162686@news.indigo.ie>... >Hi. Would anyone have a working project for a >small standalone vga pattern generator...!Article: 10372
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 newsreadingArticle: 10373
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 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 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 TweedArticle: 10374
Hi Check with the HP HCLT1100 motion control IC. I might give you some ideas on what to implement in your ASIC. http://www.hp.com/HP-COMP/motion/hctl1100.html Tom Hauri, FHW, Switzerland > 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. > > Thanks. > > 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