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
Ray Andraka wrote in message <3515F73D.5864@ids.net>...
>Contrasted with the memories in other FPGAs, such as the EAB in the
>altera, this is a better set-up IMHO. ALtera EABs get 'dual porting' by
>cycle splitting...that means that you get half the memory bandwidth, and
>more importantly no simultaneous read/write at different locations.
Ah, but Altera just announced the new 10KE family. See
http://www.altera.com/html/mktg/10ke-intro.html. Whereas the 10K(A) family
had single ported RAM via 256x8 EABs, the 10KE family apparently _will_ have
("first device shipments beginning in June") dual ported RAM (one write
addr/data port, one read addr/data port) via 256x16 EABs.
(Perhaps someone from Altera can explain the table on
http://www.altera.com/html/mktg/10ke-1.html which shows different speeds for
16x32, 32x32, ..., 256x32 FIFOs, when presumably they are using two 256x16
EABs in each case, shouldn't they all be 150 MHz?)
Based on their marketing info, it appears 10KE family EABs will provide
twice the storage and four times the dual port bandwidth of the 10KA
family -- true dual porting plus twice as many bits wide per EAB. Of course
this assumes there will be adequate interconnect resources to get all these
address and data bits to/from the EAB from/to the LABs.
With this development I may have to reconsider some things I wrote last
fall, in my comparison of the suitability of the Xilinx XC4000 and Altera
FLEX 10K architectures to implement RISC processor datapaths (attached
below). I am delighted to see Altera has addressed my concerns regarding
the need for faster multiple port access and the need for x16 organization
of the EABs. I can't help but wonder if my posting contributed to this
product announcement...
I still prefer an array chock full of distributed select-RAMs, over large
central EAB RAM blocks, but better still would be to have both.
"This is a great time to be us". With the new 10KE family, the new ORCA 3C
family, and, sooner or later, the new Xilinx Virtex family, we have many
interesting projects ahead of us...
Jan Gray
(http://www3.sympatico.ca/jsgray/homebrew.htm)
------
attachment: old comparison of Altera vs Xilinx architectures for CPU
datapaths:
Article: 9551>At least some of the dual port memories, such as Integrated Devices >Technology (IDT) have a busy signal that locks out simultaneous writes >to the same location. The other operations are simultaneously allowed. >Quite useful in high speed data transmission between main processors and >I/O processors. Some of the Dual port memories also implement hardware >mailbox functions with interrupts automatically generated You have to be extremely careful there. I have used a lot of the IDT 7132-type parts myself. It is obvious that the outcome of a truly concurrent *write* (to the same address) is going to be undefined. What is not obvious is that one cannot do concurrent *reads* either, from the same address. The device generates a BUSY signal on a simple address match, without taking into account whether it is a read or a write. They apparently do this to get the BUSY signal generated early enough to be usable. Once upon a time, I was designing a product which relied on concurrent reads being possible. I checked with IDT and the engineer told me it was. He said the device returns BUSY but in fact the data which is read is valid. This would make sense. But it was wrong - the data seen by one side is usually valid, but data seen by the other side is usually not valid. The invalid data appears very rarely so the problem may not surface; it depends on the probability of a concurrent read. I wrote down his name and the conversation in my notebook. Later, when I discovered that he told me nonsense, IDT denied a person of that name ever worked for them... This cost a fair bit of money, in PCB redesign. I had to do a work-around, using a flag byte in the DPRAM to control access. 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: 9552
Mikhail Matusov wrote: > I would recommend everybody interested to visit http://www.linuxeda.com > and in particularly http://www.linuxeda.com/~freehdl > > Mikhail Matusov This page is very exciting and I do recommend people have a look at it! One of the points that seems to have been missed in the commercially-oriented discussions is that the availablilty of open software (not necessarily free) must be good for users as it will at least force commercial competitors to reduce their prices. The big plus for Linux (or Unix in general) is that is has stability: anybody who has tried maintaining code for Win. will I am sure be annoyed at how many rewrites or major patches have been required over the last few years. In a stable environment, open applications can grow. Emacs. LaTeX. xv. Linux itself. There are many examples. This must be good for hardware vendors as they sell more chips. It might be bad for software vendors, but isn't it true that more can be achieved by cooperation than competition? I know it's hard to believe if your first prioroity is your shareholders' dividends, but /it might just be true/. Consider also that a zero-cost software option on inexpensive hardware is a must for people like me to teach my students and industry's future employees about HDLs in general. Now, 40K/seat, or free? You choose. For the courses I already run (using Ocean amongst others), I find the maintenance issue of a lab full of Windows machines all totally hackable by any undergraduate user too much of a nightmare to contemplate. Using MS Operating Systems => /Work Will Be Lost!!/. Been there, done that 8-) OK , so we could have NT, but that would mean upgrading all our PCs in both RAM and Disk. We have better things to spend our money on, esp when there are better solutions for most of our problems, at less expense. Nick. -- Dr. N.J.Bailey----------------------------------------------- Lecturer in Electronic and Electrical Engineering University of Leeds, Woodhouse Lane, Leeds, LS2 9JT. UK.------------------------------------------------- http://www.elec-eng.leeds.ac.uk/staff/een6njb/N.J.Bailey.htmlArticle: 9553
Hello, There are two speeds in USB: 1.5mbit/sec and 12 mbit/sec. There are lots of quite cheap chips for the slow speed - these are (or will be) used in mice, keyboards, and such. There are a lot fewer solutions for the high speed version, and I wonder just how hard this is to do in an FPGA. Xilinx XC4000 devices are finally, after all these years, getting cheap enough in 100+ quantities to be used for this sort of thing in production. I want to make a USB peripheral device, not a hub. The FPGA would be talking to a fast and cheap 8/16-bit CPU with DMA, e.g. a Z180. I have seen some "IP" (trendiest word right now) cores for USB, in a recent Xilinx publication, but having seen some of the pricing in this market, this is likely to be expensive. And I have mislaid the book. Has anyone who can talk about it done this? 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: 9554
I am working on a proposal to convert a design project (involving some Flex7k devices) from Altera AHDL to Verilog. RTL mainly, can anybody share experience or point to tools/text processing scripts that do it? Thanks in advance ZeevArticle: 9555
In article <3515B9E9.3D4B2192@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> writes >Dual-port memories are ideal >for implementing FIFOs and communications mailboxes between asynchromous >systems. Yes. But can anyone explain why some of Xilinx competitors provide genuine dual-port RAM and then insist that both ports are clocked by the same clock? Yet these same chips provide for multiple clocks and so are presumably intended for asynchronous systems. For IEEE 1355, which you can think of as a collection of 100 Mbit/s UARTs, we need small FIFOs, 9/18/36 bits wide, with separate clocks on the two ports. The circuits are so small that several ports can go on one chip, and there is a simple routing protocol for packet switching between the ports. Xilinx is ok on this. The new QuickLogic pASIC3R parts, which are promised later this year, seem also to have got their dual-port RAMs right. They've also got the width right and the granularity not too coarse. Does anyone know of any others that allow dual-port, dual clock access, to a reasonable number of separate memories per chip? Paul -- Paul Walker 4Links phone/fax paul@walker.demon.co.uk P O Box 816, Two Mile Ash +44 1908 http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253Article: 9556
I've hacked together some tools for floorplanning Orca chips.
You can get them at
http://www-ese.fnal.gov/eseproj/trigger/floorplan.zip
An excerpt from the readme file is included here.
------------------------------------------------------------------------
Orca Floorplanning tools. Allows you to disassemble a .ncd file into
block descriptions. The block placement can be manipulated graphically using
Microsoft Excel, and then written back to the .prf file. Also allows script-
based placement which you can specify placement in terms of patterns,
equations, and Mapping tables.
The following files are included:
NCD2EQ.exe
converts NCD files to equation and placement text. See ncd2eq.man for
details.
XPLACE.exe
Updates a .prf file using an .xpl script. Allows placement to be specified
in terms of patterns, equations, and maps. See xplace.man for more details.
Orca.xls
Contains Microsoft Excel macros to read an equation file and display it as a
chip map. Blocks can be placed in the chip, and then written to an .xpl
file.
exmpl*
Example design. See example below.
registry.reg
Registry commands to register .eqn, .ncd, and .xpl file types.
--
Don Husby <husby@fnal.gov> Phone: 630-840-3668
Fermi National Accelerator Lab Fax: 630-840-5406
Batavia, IL 60510
Article: 9557On Sun, 22 Mar 1998 04:59:17 GMT, bk&dontyabespamminme&willi@smart.net (Bryan Williams) wrote: >Funny, I was digging through the Xilinx AllianceCORE products on their >website, I was dumbfounded seeing a T1 framer there. Trick is, it's a >_single_ framer, has NO elastic stores (according to the block diagram >in the datasheet at least), and it takes 1236 or so CLBs, meaning it >won't fit in anything smaller than a XC4036EX and apparently uses all >the CLB's in a 4036. I checked the price of the device it is tailored >to, it's about $500 in single units, add to that the $6000 cost of the >core design. <big snip> >So, is there some logic behind providing a $2000 solution to an $83 >problem, or what? Perhaps the issue is that many FPGA vendor advertised COREs are written in HDL and were originally written/targetted for the ASIC marketplace. Now being written in HDL isn't bad per-se, but being written without the target in mind is. Thus, a core vendor may throw the HDL through some tools, spin it through the vendors tools to get a maximum frequency and hence say "Yeah sure, it works". As the two largest vendors seem to have a fairly "hands-off" approach to their third party cores, there is perhaps little control as to what is actually relevant, or indeed what might actually work or even exist. At least it means people can shout about how many "cores" they have. As the tailor said: "Never mind the quality, feel the width" Quite what use many such cores are, except for ASIC customers wishing to prototype in FPGA is beyond me. But hey, don't worry, the vendors will soon be selling 160K gate FPGAs at $1 for every 5K gates, so your cost should drop to $32 for that quad framer implementation. (ROTFL) With regard to a quad T1/E1, check out Lucent for parts like the T7630 and T7631. For the Quad LIU alone, the T7698 is quite nice, or T7690/3, and the 7 channel T7693 should be nice for your space constraints (100 pin QFP on 19.7 mil pitch) StuartArticle: 9558
Rob Semenoff (robert_semenoff@phoenix.com) wrote: : Hi, : I would like to know if anyone else has been using the cypress ISR : (in-circuit reprogrammable) CPLDs and would have any comments on their : download cable : device programmer and programming the devices in general. : Any comments appreciated, I don't have any personal experience with the Cypess parts, but I have done many designs with Lattice's CPLD's and never had a problem with their ISP programming whatsoever. I highly recommend their parts (assuming they fit your requirements) MengArticle: 9559
I believe I have a new radix-4 CORDIC algorithm for computing sine and cosine. Unlike previously known algorithms, mine doesn't need extra iterations and doesn't involve non-constant multiplicative factors. However, it does require a slow iteration on rare occasions. I also designed a Xilinx-based prototype of the new part of the circuit. Please contact me if interested.Article: 9560
Ray Andraka wrote: > Don Labriola wrote: > > > > Ed McCauley wrote: > > > > > > Dale E. Redford wrote: > > > > > > > > Dual port memory has two sets of address and data lines. It can be accessed > > > > by two different systems simultaneously except for the case of > > > > writing/reading to the same exact memory address. If this occurs, an > > > > arbitration is done to inhibit one side and sometimes this arbitration > > > > circuitry is built into the memory device. > > The xilinx dual port memory has dual port read access, but only single > port write access. With these memories, you can simultaneously read two > locations or be writing one while reading another (or the same one). > Since the second port is read only, there is no inherent need for > arbitration. > > Contrasted with the memories in other FPGAs, such as the EAB in the > altera, this is a better set-up IMHO. ALtera EABs get 'dual porting' by > cycle splitting...that means that you get half the memory bandwidth, and > more importantly no simultaneous read/write at different locations. I have looked at the data book for the dual port RAM feature and I don't completely understand how it is intended to work or why they only implement one bit in a CLB instead of two. The architecture shows two address inputs. One is the write address to both F/G generators and the read address to the F generator. The other address input is just for read on the F generator. They share a clock, WE signal and data input, while they have separate data outputs. So the question is: if you can read and write at the same time, then why do you need two function generators to implement a single bit? When you write, you must always write to BOTH function generators. So to have simultaneous reads and writes, the G function generator must internally support simultaneous reads and writes with the read data appearing at the output during the entire write cycle (unless the same address is being accessed so that the output data will change just after the clock edge). So, why bother with the F generator doing a parallel read? Why not make the CLB a TWO bit ram block instead of a one bit ram block? Is it a routing issue somehow? Is it too hard to route both addresses to both ram blocks? Are there not enough inputs to allow two data bits in? What was the limitation? Surely it would have been better to have a two bit dual port ram than a single bit dual port ram? Rick Collins redsp@writeme.comArticle: 9561
Bryan Williams wrote: > Funny, I was digging through the Xilinx AllianceCORE products on their > website, I was dumbfounded seeing a T1 framer there. Trick is, it's a > _single_ framer, has NO elastic stores (according to the block diagram > in the datasheet at least), and it takes 1236 or so CLBs, meaning it > won't fit in anything smaller than a XC4036EX and apparently uses all > the CLB's in a 4036. I checked the price of the device it is tailored > ...snip... > So, is there some logic behind providing a $2000 solution to an $83 > problem, or what? > > I don't work for any of the makers of the previously mentioned > products. Interesting observation. I did a partial E1 interface in an XC5204 last year and it only took about half the part. I didn't need to detect the framing bits. That was external, but I had to build the shift registers, the frame and time slot counters and even handle the tristate buffering for the half time slot of the signalling data. And of course I had to have an interface for the DSP which was talking to this chip. I would assume that you were looking at a very bad design which was done without a proper understanding of the problem. Or as some others had suggested, it was done using an HDL (and a poor job at the same time). Rick Collins redsp@writeme.comArticle: 9562
Peter wrote: > Hello, > > There are two speeds in USB: 1.5mbit/sec and 12 mbit/sec. > > There are lots of quite cheap chips for the slow speed - these are (or > will be) used in mice, keyboards, and such. > > There are a lot fewer solutions for the high speed version, and I > wonder just how hard this is to do in an FPGA. Xilinx XC4000 devices > ...snip... > Has anyone who can talk about it done this? > > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to zX80@digiYserve.com but > remove the X and the Y. Forgive me if I am speaking outside of my knowledge base, but from what I have read about USB, the interface is not too complicated. But rather the internal micro which some chips use is what makes them a little expensive. From my experience, doing a design at 12 MHz is a snap in most any Xilinx part these days. Do you know if the design would have to run at a higher rate to be able to process any part of the bit stream in hardware? Or could the design be done at a 12 MHz clock rate? Rick Collins redsp@writeme.comArticle: 9563
Larry Doolittle wrote:
> Nick Hartl ("nhartl[nospm]"@earthlink.net) wrote:
>
> : You can by Foundation Base for $95 bucks. It contains all that you need for
> : design. Schematic capture, simulation and Place and Route.
>
> Don't the Xilinx (et al.) apologists get tired of saying this?
> I personally cannot stomach binary-ware.
> I will not run it,
> I will not use it,
> I can't support it,
> Sam I am.
> If it's not source code, it's not software. If I can't copy it,
> port it, fix it, modify it, it's just so many useless bits on a disk.
> So no, Foundation Base is _not_ "all that you need".
>
> : > In particular I have XC2018, XC2064, XC3020 and XC3064 parts.
>
> : Now this is a problem. XC2ks are no longer supported also the versions of
> : 3ks that you name are not in the new Foundation box. Now if one could find a
> : Foundation Xact 6.01 then you would be all set.
>
> My point. If the "nearly free" ($95 binary-ware) were truly free,
> or if those old parts actually had a programming spec, this problem
> would be inherently tractable.
>
> Time to crawl back in my hole. Maybe someday a hardware company will
> have the guts to tell its users how to program the chip. Oops, Intel
> already did that back in the '70s, and look how far it got them.
>
> - Larry Doolittle <ldoolitt@jlab.org>
>
> [ sorry for the posting delay, our news server croaked,
> and it took me a while to find a backup ]
I think I understand what you are saying, but I don't know how truly useful it
would be in the development of FPGAs. As for the XC2K obsolesence issue, they are
not supported, because they are not sold. I believe that Xilinx no longer sells
XC2000 parts to anyone. And if you need those tools to support existing boards,
then you certainly have the older software (or can get it). It is only the new
software that doesn't support the older parts.
As for modifying the development tools through the source. I doubt very seriously
if you would find much in the way of cost effective changes you could make to the
code that you wouldn't need to toss out every six months when Xilinx comes out with
a new version which supports all the new parts. Keep in mind that they increase the
size of their parts FASTER than Moore's law (2x every 18 months). If you tried to
keep up with that, you would need to be a dozen programmers working full time, I'm
sure.
This is a little different from the compiler community where there is a vested
interest in reusing the instructions set of a line of processors for as long as
possible (>10 years or more).
So I doubt that anyone could get much utility out of the source code of FPGA
development tools other than the chip manufacturer (or a third party tool vendor
company).
Rick Collins
redsp@writeme.com
Article: 9564In article <35172689.1B5086C@computer.org>, Vitit Kantabutra <vkantabu@computer.org> wrote: >I believe I have a new radix-4 CORDIC algorithm for computing sine and >cosine. Unlike previously known algorithms, mine doesn't need extra >iterations and doesn't involve non-constant multiplicative factors. From my foggy memory :> CORDIC only needed "double iterations" for some of the hyperbolic and *inverse* circular functions. sin() and cos() converge without the need for extra iterations. >However, it does require a slow iteration on rare occasions. I also >designed a Xilinx-based prototype of the new part of the circuit. Please >contact me if interested. If you have this written as a software algorithm or in VHDL, I'd be interested in taking a peek... --donArticle: 9565
In article <351733A5.EAEB3FA0@writeme.com> redsp@writeme.com writes: > >I have looked at the data book for the dual port RAM feature and I don't >completely understand how it is intended to work or why they only >implement one bit in a CLB instead of two. I believe that it works just as it is documented. One port has both read and write capability, the other port is read only. Absolutely simultaneous reads and writes are possible. There is no contention on address match. There is no interference on read timing between the two ports. There is a delay from write on one port to read on the other of the same address, which is both expected and unavoidable due to the reality of the way the universe works. >The architecture shows two address inputs. One is the write address to >both F/G generators and the read address to the F generator. The other >address input is just for read on the F generator. They share a clock, WE >signal and data input, while they have separate data outputs. The underlying hardware is two LUT/RAMs, each is 16 x 1, and they have separate read and write address decoders. The write decoders are slaved together for dual port mode. The read decoders are kept sepparate. >So the question is: if you can read and write at the same time, then why >do you need two function generators to implement a single bit? When you >write, you must always write to BOTH function generators. So to have >simultaneous reads and writes, the G function generator must internally >support simultaneous reads and writes with the read data appearing at the >output during the entire write cycle (unless the same address is being >accessed so that the output data will change just after the clock edge). Here's a better way of looking at it. Given that you start with LUTs that are basically loaded at config time, and are ROMs, what minimal hardware must you add to make them writeable during FPGA operation. Answer is XC4000. Given that you have LUTs that can be used as RAM, what minimal hardware can you add so that the write is synchronous. Answer is XC4000E. Given that you are tearing up the guts of the CLB anyway to make the RAM write synchronous, what other features that would be valuable to customers could be added, yet require almost no other hardware, and by-the-way, must still be backward compatible to the XC4000 bitstream. The answer is dual port the CLB RAM, by joining the address lines for the write decoder (when in dual port mode), while keeping the read decoders still connected to their respective address pins. In traditional dual port RAMS (like IDT, Cypres, TI, ...) there tends to be a single decoder that is used for both reading and writing, and it uses a structure that involves bit lines, word lines, and sense amplifiers. To dual port this type of memory, you duplicate everything except the actual storage cell. The dual port RAMs I am describing here (in the XC4000E/EX/XL/XV) start off with separate read and write decoders, and dont have bit lines, word lines, or sense amps. Note that the ORCA product copied this architecture. >So, why bother with the F generator doing a parallel read? Why not make >the CLB a TWO bit ram block instead of a one bit ram block? Is it a >routing issue somehow? Is it too hard to route both addresses to both ram >blocks? Are there not enough inputs to allow two data bits in? What was >the limitation? Surely it would have been better to have a two bit dual >port ram than a single bit dual port ram? What it basically comes down to is that there are constraints such as bit-stream compatibility with prior generations, together with a very different basic memory cell and read/write topology onto which dual port was added. for further info, you could look up patent 5631577, on the IBM patent server http://patent.womplex.ibm.com >Rick Collins >redsp@writeme.com Philip FreidinArticle: 9566
Vitit Kantabutra wrote: > I believe I have a new radix-4 CORDIC algorithm for computing sine and > cosine. Unlike previously known algorithms, mine doesn't need extra > iterations and doesn't involve non-constant multiplicative factors. > However, it does require a slow iteration on rare occasions. I also > designed a Xilinx-based prototype of the new part of the circuit. Please > contact me if interested. I would also be interested in a article/implementation of your design. -- Marc Daumas - Charge de recherches au CNRS (LIP - ENS de Lyon) mailto:Marc.Daumas@ENS-Lyon.Fr - http://www.ens-lyon.fr/~daumas ENS de Lyon - 46, allee d'Italie - 69364 Lyon Cedex 07 - FRANCE Phone: (+33) 4 72 72 83 52 - Fax: (+33) 4 72 72 80 80Article: 9567
>Forgive me if I am speaking outside of my knowledge base, but from what I >have read about USB, the interface is not too complicated. But rather the >internal micro which some chips use is what makes them a little expensive. >From my experience, doing a design at 12 MHz is a snap in most any Xilinx >part these days. Do you know if the design would have to run at a higher >rate to be able to process any part of the bit stream in hardware? Or >could the design be done at a 12 MHz clock rate? No idea yet. I am at a very early stage of looking into this. The actual data rate, 12 mbits/sec, is easy of course. 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: 9568
On Mon, 23 Mar 1998 20:08:15 GMT, husby@fnal.gov (Don Husby) wrote: >I've hacked together some tools for floorplanning Orca chips... > (etc). on an unrelated point, i recall from another post that you're using a lot of xilinx parts in your application. i would have thought that orca would be a significantly better choice, particularly for a 1000-device system. can you tell us why you chose xilinx over orca? evan (ems@nospam.riverside-machines.com)Article: 9569
Hi, It sounds like you have an intersting idea. You should write a paper about it This way, your peers can read your material and use it to aid in the development of the field. Take care. james stine jes6@lehigh.edu Vitit Kantabutra wrote: > I believe I have a new radix-4 CORDIC algorithm for computing sine and > cosine. Unlike previously known algorithms, mine doesn't need extra > iterations and doesn't involve non-constant multiplicative factors. > However, it does require a slow iteration on rare occasions. I also > designed a Xilinx-based prototype of the new part of the circuit. Please > contact me if interested.Article: 9570
fliptron@netcom.com (Philip Freidin) wrote: > Note that the ORCA product copied this architecture. Also note that they seem to have done better in their next generation (OR3Txxx) which uses all of the LUT bits for RAM instead of 1/2 the bits. Their new PFU can be eight 4LUTS, or four 5LUTS, or a 32x4 memory. Apparently this chip is now available http://www.lucent.com/micro/fpga/3ctxx.html I can't remember if Xilinx also fixed this in their new generation, and can't seem to find any literature at their web site. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9571
> There are two speeds in USB: 1.5mbit/sec and 12 mbit/sec. > > There are lots of quite cheap chips for the slow speed - these are (or > will be) used in mice, keyboards, and such. > > There are a lot fewer solutions for the high speed version, That is contrary to what I found...I believe almost all the chips do both the high and low speed. > and I > wonder just how hard this is to do in an FPGA. Xilinx XC4000 devices > are finally, after all these years, getting cheap enough in 100+ > quantities to be used for this sort of thing in production. > > I want to make a USB peripheral device, not a hub. The FPGA would be > talking to a fast and cheap 8/16-bit CPU with DMA, e.g. a Z180. Ah, there's the rub! Almost all USB chips are PCI peripherals (actually, I couldn't find one that wasn't PCI when I looked 6-8 months ago). You will probably be hard pressed to find ones that are not PCI. > I have seen some "IP" (trendiest word right now) cores for USB, in a > recent Xilinx publication, but having seen some of the pricing in this > market, this is likely to be expensive. And I have mislaid the book. The ones I inquired about were greedily expensive, and their actual details were sketchy.... > Has anyone who can talk about it done this? I would strongly suggest you look at the CMD 0670 USB controller to try to fully understand what you need to do. It is pretty much the standard in USB controllers. We concluded that since the USB chips are so cheap, and they include a PCI interface already (which we had available on the board all ready due to the need for CardBus), that was the better alternative for our application. Austin Franklin darkroom@ix.netcom.comArticle: 9572
In article <3515B9E9.3D4B2192@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> writes >Dual-port memories are ideal >for implementing FIFOs and communications mailboxes between asynchromous >systems. > Yes. But can anyone explain why some of Xilinx competitors provide genuine dual-port RAM and then insist that both ports are clocked by the same clock? Yet these same chips provide for multiple clocks and so are presumably intended for asynchronous systems. For IEEE 1355, which you can think of as a collection of 100 Mbit/s UARTs, we need small FIFOs, 9/18/36 bits wide. The circuit are like U*A*RTS (A for Asynchronous, in fact autobauding between very slow and 100Mbits/s) with separate clocks on the two ports. The circuits are so small that several ports can go on one chip, and there is a simple routing protocol for packet switching between the ports. Xilinx are ok on this. The new QuickLogic pASIC3R parts, which are promised later this year, seem also to have got their dual-port RAMs right. They've also got the width right and the granularity not too coarse. Does anyone know of any others that allow dual-port, dual clock access, to a reasonable number of separate memories per chip? Paul (Apologies to anyone who may have received this twice. Original posting went to all the newsgroups except comp.arch.fpga.) -- Paul Walker 4Links phone/fax paul@walker.demon.co.uk P O Box 816, Two Mile Ash +44 1908 http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253Article: 9573
Jan Gray wrote in message <6f53s7$ctu$1@usenet49.supernews.com>...
>Ah, but Altera just announced the new 10KE family. See
>http://www.altera.com/html/mktg/10ke-intro.html. Whereas the 10K(A) family
>had single ported RAM via 256x8 EABs, the 10KE family apparently _will_
have
>("first device shipments beginning in June") dual ported RAM ... "
Ah, but over on http://www.edtn.com/scribe/design/pld/pldp.htm, Murray
Disman writes "Altera's first 0.25-micron part will be the EPF10K100B, which
is scheduled to become available in June 1998. This is a straight shrink of
the EFP10K100 and does not contain any improvements in the memory block. ...
Parts with the improved memory blocks, the FLEX 10KE, will begin shipping
during 4Q98."
Jan Gray
Article: 9574
Rick Collins <redsp@writeme.com> writes:
> Interesting observation. I did a partial E1 interface in an XC5204 last
> year and it only took about half the part. I didn't need to detect the
> framing bits. That was external, but I had to build the shift registers,
> the frame and time slot counters and even handle the tristate buffering
> for the half time slot of the signalling data. And of course I had to have
> an interface for the DSP which was talking to this chip.
Excuse me, but I would think the framing was the absolute hardest part
of the interface chip.
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
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