Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 9550

Article: 9550
Subject: Re: Dual port, new Altera FLEX 10KE EABs
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Sun, 22 Mar 1998 23:34:07 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Dual port
From: z80@ds2.com (Peter)
Date: Mon, 23 Mar 1998 08:39:16 GMT
Links: << >>  << T >>  << A >>

>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
Subject: Re: The case for Linux and EDA
From: N.J.Bailey@leeds.ac.uk (Nick Bailey)
Date: Mon, 23 Mar 1998 10:04:20 +0000 (GMT)
Links: << >>  << T >>  << A >>
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.html



Article: 9553
Subject: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: z80@ds2.com (Peter)
Date: Mon, 23 Mar 1998 16:25:23 GMT
Links: << >>  << T >>  << A >>
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
Subject: AHDL to Verilog conversion (Q)
From: zeev@cadence.com (Zeev Yelin)
Date: Mon, 23 Mar 1998 18:18:14 GMT
Links: << >>  << T >>  << A >>
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
Zeev
Article: 9555
Subject: Re: Dual port
From: Paul Walker <paul@walker.demon.co.uk>
Date: Mon, 23 Mar 1998 19:56:02 +0000
Links: << >>  << T >>  << A >>
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      566253
Article: 9556
Subject: Orca Floorplanning tools
From: husby@fnal.gov (Don Husby)
Date: Mon, 23 Mar 1998 20:08:15 GMT
Links: << >>  << T >>  << A >>
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: 9557
Subject: Re: "CORE Competency" ???
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Mon, 23 Mar 1998 23:14:31 GMT
Links: << >>  << T >>  << A >>
On 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)

Stuart
Article: 9558
Subject: Re: Cypress ISR
From: mess@pc-20342.on.rogers.wave.ca (Mess at Cabot)
Date: 24 Mar 1998 02:47:02 GMT
Links: << >>  << T >>  << A >>
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)

Meng
Article: 9559
Subject: New radix-4 CORDIC for computing sine and cosine
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Mon, 23 Mar 1998 20:20:41 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Dual port
From: Rick Collins <redsp@writeme.com>
Date: Mon, 23 Mar 1998 23:16:38 -0500
Links: << >>  << T >>  << A >>
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.com


Article: 9561
Subject: Re: "CORE Competency" ???
From: Rick Collins <redsp@writeme.com>
Date: Mon, 23 Mar 1998 23:26:16 -0500
Links: << >>  << T >>  << A >>
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.com



Article: 9562
Subject: Re: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: Rick Collins <redsp@writeme.com>
Date: Mon, 23 Mar 1998 23:32:51 -0500
Links: << >>  << T >>  << A >>
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.com



Article: 9563
Subject: Re: Strange Xilinx question?
From: Rick Collins <redsp@writeme.com>
Date: Mon, 23 Mar 1998 23:46:48 -0500
Links: << >>  << T >>  << A >>
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: 9564
Subject: Re: New radix-4 CORDIC for computing sine and cosine
From: dgy@rtd.com (Don Yuniskis)
Date: 24 Mar 1998 04:52:22 GMT
Links: << >>  << T >>  << A >>
In 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...

--don
Article: 9565
Subject: Re: Dual port
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 24 Mar 1998 04:53:03 GMT
Links: << >>  << T >>  << A >>
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 Freidin


Article: 9566
Subject: Re: New radix-4 CORDIC for computing sine and cosine
From: Marc Daumas <Marc.Daumas@ENS-Lyon.Fr>
Date: Tue, 24 Mar 1998 08:41:12 +0100
Links: << >>  << T >>  << A >>
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 80
Article: 9567
Subject: Re: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: z80@ds2.com (Peter)
Date: Tue, 24 Mar 1998 12:06:44 GMT
Links: << >>  << T >>  << A >>

>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
Subject: Re: Orca Floorplanning tools
From: ems@see_signature.com (ems)
Date: Tue, 24 Mar 1998 13:20:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: New radix-4 CORDIC for computing sine and cosine
From: James Stine <jes6@lehigh.edu>
Date: Tue, 24 Mar 1998 09:35:34 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Dual port
From: husby@fnal.gov (Don Husby)
Date: Tue, 24 Mar 1998 14:36:38 GMT
Links: << >>  << T >>  << A >>
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 60510
Article: 9571
Subject: Re: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: "Austin Franklin" <dar4kroom@ix.netcom.com>
Date: 24 Mar 1998 15:39:04 GMT
Links: << >>  << T >>  << A >>
> 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.com

Article: 9572
Subject: Re: Dual port
From: Paul Walker <paul@walker.demon.co.uk>
Date: Tue, 24 Mar 1998 16:05:30 +0000
Links: << >>  << T >>  << A >>
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      566253
Article: 9573
Subject: Re: Dual port, new Altera FLEX 10KE EABs
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Tue, 24 Mar 1998 08:13:53 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: "CORE Competency" ???
From: Magnus Homann <d0asta@palver.dtek.chalmers.se>
Date: 24 Mar 1998 17:37:01 +0100
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search