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
2017JanFebMarApr2017

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 9575

Article: 9575
Subject: Re: Synthesizable 8B/10B Encoder/Decoder wanted
From: Rick Carmichael <rcarmichael@intellistor.com>
Date: Tue, 24 Mar 1998 11:12:56 -0700
Links: << >>  << T >>  << A >>
Patrick Mueller wrote:
> 
> I am searching for a synthesizable 8B/10B Encoder/Decoder for a
> FibreChannel Project.
> Has anybody VHDL or AHDL code for that?
> 
> Thanks
> 
> Patrick Mueller
> 
> email: no_spam_pbmuelle@stud.ee.ethz.ch ( remove no_spam_ )

Hi Patrick,

Seagate used to support a VHDL FCAL template design which they
provided to fibre channel designers for free. I am uncertain
where (if) that code is located on the web. If you can't locate 
the code, and no-one else can provide it for you send me an 
e-mail - I probably have 8B/10B RTL at home on my PC somewhere.

If you opt to design the 8B/10B yourself, "Fibre Channel Gigabit
Communications and I/O for Computer Networks" by Alan F. Benner
from McGraw-Hill has an excellent section on implementation as
partitioned into 5B/6B and 3B/4B submodules. If I remember
properly, the implementation is not that difficult, testing it
may be the real challenge ;-)

Warm Regards,
rickc
Article: 9576
Subject: Altera FPGA prototype / development board
From: Brian_Carlson@ena-east.ericsson.se (Brian Carlson)
Date: Tue, 24 Mar 1998 18:40:39 GMT
Links: << >>  << T >>  << A >>
I am in the market for a stand alone development board for a FLEX6000
part.  All I can find are FLEX 10K boards, does anyone know if there
is a FLEX6000 based board out there?

Brian Carlson
Staff Engineer
Ericsson Inc.
Article: 9577
Subject: Best solution
From: jamil.khatib@pemail.net (J. Khatib)
Date: Tue, 24 Mar 1998 19:19:56 GMT
Links: << >>  << T >>  << A >>
Please  I want some hints and guidelines for selecting FPGA or pDSP
for some applications and the trade-offs involved ( ie power
consumption, speed, design flexibility ,etc)

thanks in advance
Article: 9578
Subject: Re: New radix-4 CORDIC for computing sine and cosine
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Tue, 24 Mar 1998 13:12:36 -0700
Links: << >>  << T >>  << A >>
Thanks.  Yes, I've written a paper about it and submitted it to ICCD '98 a few
days ago.  I'll send you a copy via email.  I just didn't want to send a paper
to a newsgroup.

James Stine wrote:

> 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: 9579
Subject: Re: Orca Floorplanning tools
From: husby@fnal.gov (Don Husby)
Date: Tue, 24 Mar 1998 21:37:48 GMT
Links: << >>  << T >>  << A >>
ems@see_signature.com (ems) wrote:
> 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?

I am using Orca and not Xilinx.
I avoided mentioning this in the bitstream discussion to avoid
taking an additional branch in the thread.  I kind of considered
"xilinx" to be a generic term for LUT-based FPGAs.  The
same way "kleenex" is often a generic term for facial tissue. 

Lucent is just as protective of its bitsream as Xilinx.

I'm not opposed to using Xilinx, but have found that Orca is almost
always better for my applications.  The only major complaint I have about
Orca chips is the lack of I/O registers.  In order to get predictable Tco, 
setup and hold times, I sometimes have to do hand-optimized mapping
and placement.

This is an example of why it would be helpful to have access to software
internals.  If I had access to the Orca mapping algorithm I could probably
hack it to make the I/O optimizations.

Also, the Orca preference file format leaves a lot to be desired.  Xilinx
has (had?) a much better way to specify timing constraints.  (I think xilinx
is now using the same Neocad-based system as Lucent.)
It wouldn't take too much hacking to fix this either.  Just adding wild cards
would be a good first step.



--
Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
Fermi National Accelerator Lab                      Fax: 630-840-5406
Batavia, IL 60510
Article: 9580
Subject: Re: Lowest POWER FPGAs???
From: z80@ds2.com (Peter)
Date: Tue, 24 Mar 1998 22:09:09 GMT
Links: << >>  << T >>  << A >>

I can't give you the answers you are looking for, but here are some
general comments based on my experience of doing similar low power
designs in Xilinx FPGAs, also running at very slow clocks:

First, there is the static Icc and there is the dynamic Icc. I assume
you must know this, but not all FPGAs are fully CMOS. The full-CMOS
ones should draw only microamps statically. The others will draw
milliamps, or more.

Next, on the dynamic Icc front, BY FAR the biggest factor is whether
you can gate clocks. If you design your FPGA in the "recommended" way
(i.e. use the global clock net for everything that might be clocked,
and use clock-enable inputs to decide what actually gets clocked) then
your Icc will be perhaps 10x or 50x higher than it will be if you can
do things the "obvious" way, and feed a clock only to those circuits
which actually need it. This is a simple fact in VLSI design and there
is no way around it. The problem with gating clocks in FPGAs is that
the delays in the various muxes etc can skew the clock enough to screw
things up.

I once did a XC3064 design whose static Icc was about 100uA and whose
dynamic Icc varied between about 2mA and about 30mA, according to how
much of the internal circuit was clocked. I was doing a lot of clock
gating, including doing a virtual "sleep mode" by gating the inputs to
the ACLK and GCLK global clock drivers. As I say above, I had some
problems with gating the clocks not producing a reliable design but
since this was a prototype for an ASIC (in which you can gate clocks
as much as you want, provided you don't do stupid things) this didn't
matter.

Next, ripple counters draw much less power than the "doing it
properly" sync counters one is supposed to use in an FPGA; the reason
is obvious if you look at what gets clocked at what frequency.

Next, and other things being equal, smaller geometry should give you a
smaller dynamic Icc, per MHz, and of course so will a lower supply
voltage. So a newer, faster, device should draw less mA per MHz.

Finally, you have your output pin capacitance to charge and discharge.
You can easily calculate how much power this will cost you. Waggling
70 PCB tracks at 2MHz might be very expensive.

>Alright all you FPGA reps. I would really like some hard comparison
>numbers on
>power consumption of FPGAs. I know these are design dependent, but there
>have to be some comparison numbers out there somewhere. I would really
>like to see some numbers on SRAM vs. ACTEL and Quick Logic.
>
>I am doing a design I would like to keep in a 5K gate device. The
>highest clock is 2Mhz, and I wil be wiggling maybe 70 lines. The device
>will be burst processing and only will be on for perhaps 25% of the
>time. There are perhaps 10 16 bit counters internal to the device. The
>design will all be 3.3V
>
>What kind of power numbers can I expect from
>
>ACTEL:
>Quick Logic:
>Lucent:
>XILINX:
>ATMEL:
>Altera:


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: 9581
Subject: Want to share room at FCCM'98?
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 24 Mar 1998 15:22:29 -0800
Links: << >>  << T >>  << A >>
Dear all,

I've reserved a double for two nights, 15 & 16. Is anyone interested
in sharing the room and save $55 per night ?

-Arrigo
-- 
Arrigo Benedetti          o         e-mail: arrigo@vision.caltech.edu
Caltech, MS 136-93	 < >			phone: (626) 395-3695
Pasadena, CA 91125	 / \			fax:   (626) 795-8649
Article: 9582
Subject: Need Your Help Reviewing The SNUG'98 / OVI/VIUF'98 Conferences
From: jcooley@world.std.com (John Cooley)
Date: Tue, 24 Mar 1998 23:42:10 GMT
Links: << >>  << T >>  << A >>

  HELP!

  Over the next two days I'm putting together one of those Trip Reports
  for the recent SNUG'98 and IVC/VIUF'98 conferences.  And, as usual, I
  like to write these reports as collaborative efforts.  So I'd like to
  ask your help.  Could you please e-mail me what you thought about
  either or both conferences?  What was hot?  What was not?  What's
  the best quote you (over)heard from someone there?  (Please say
  who said what and in what context.)  What's the most interesting
  paper, talk, panel, hallway conversation you partook in & why was
  it so interesting/useful?  What was the best/worst/most interesting
  product announcement or secret NDA thing you heard?

  If you wrote a trip report, could you e-mail me a copy of it, please?

  OF COURSE, as always, I'll keep all sources anonymous; what I'm
  interested in is sharing common useful information.  I go to great
  lengths "clean up" anything I get that might give away who told
  me what -- it's the info/opinions/ideas that are useful -- not
  who said/has them.

  Please, tell me what you saw and your reactions so I can do my job
  as an EDA consumer advocate.  It's personally important to me that
  my Trip Reports reflect what you're really experiencing as an
  engineer trying to design chips with today's EDA tools.  Thanks.  :^)

                                     - John Cooley
                                       the ESNUG guy

============================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 6000+ other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."
Article: 9583
Subject: Partially reconfigurable FPGA
From: Scott Bronson <sbronson@opentv.com>
Date: Tue, 24 Mar 1998 16:09:10 -0800
Links: << >>  << T >>  << A >>
I'd like to make an ISA add-in card based on an FPGA.  It will include a
small state machine to watch for data patterns on some lines (i.e., when
0x5F is immediately followed by 0x4C, then process the next five
characters, etc.)  However, from time to time I'd like to be able to
dynamically upload a new, completely different state machine from the
computer.

Does anybody make a device that will support this partial
reprogramming?  I've heard that Altera has some rudimentary support in a
few of their FPGAs, but that it's seriously difficult to work with. 
Thanks to their symmetry, I'd think that CPLDs with good interconnect
would make this easy (as long as I leave a few CLBs unused, to be filled
in later).  With all the reconfigurable computing research lately,
there's got to be something...?

Thanks for any leads,

	- Scott			NOsSPAMbronson@opentv.com

(either follow up to this newsgroup or repair my E-mail address
(sbronson) to reply.  Spammers are a real nuisance).
Article: 9584
Subject: Re: Orca Floorplanning tools
From: Rick Collins <redsp@writeme.com>
Date: Tue, 24 Mar 1998 21:14:16 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:

> ...snip...

> Also, the Orca preference file format leaves a lot to be desired.  Xilinx
> has (had?) a much better way to specify timing constraints.  (I think xilinx
> is now using the same Neocad-based system as Lucent.)
> It wouldn't take too much hacking to fix this either.  Just adding wild cards
> would be a good first step.
>
> --
> Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
> Fermi National Accelerator Lab                      Fax: 630-840-5406
> Batavia, IL 60510

I am just now working with file based timing constraints on the Xilinx M1
(Neocad) software and it does take wildcards. They use * for any number of chars
and ? for any one char.

I also like the Orca parts. I have done one design with them pre-Neocad. The ODS
tools did a fair job of routing, but the manual design editor was unusable. Not
that I would ever use if for anything other than viewing. But one of my biggest
frustrations with all of these tools is the inability to gain visbility into what
the tools have done. The only useable design analysis tools is the timing
analyser. And that only tells you that something is wrong, not much about what is
wrong with it.


Rick Collins

redsp@writeme.com




Article: 9585
Subject: Digital Diplexers Exist?
From: "Jon Cummings" <cflat@monumental.com>
Date: 25 Mar 1998 03:07:55 GMT
Links: << >>  << T >>  << A >>
Am looking for a software configurable diplexer for use
in radio transceivers.

Have not seen articles or publications outlining FPGA
or ASIC devices that can be used as diplexers in radio
transceivers.

If you know of such a device, please respond to
jcummXing@alexandria.adroit.Ycom
Please delete the X and Y from this address.

Sure would appreciate any information on this.

Jon Cummings
Article: 9586
Subject: Re: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: muzok@pacbell.net (muzo)
Date: Wed, 25 Mar 1998 03:31:23 GMT
Links: << >>  << T >>  << A >>
I am currently doing a USB implementation in Altera 10K. Actually USB can be
implemented with a state machine instead of a microcontroller. And yes there is a
higher speed clock in the design in that the bit detection needs to resolve a +-
.25 bit jitter and that means the clock/data recovery needs to be done at 48 MHz
but that section of the circuit is very small. Most of the design can be in 12
MHz.

Rick Collins <redsp@writeme.com> wrote:
>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
>
>

muzo

WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>
Article: 9587
Subject: Re: Cypress ISR
From: "Bill Brown" <PhantomWAB@aol.com>
Date: 25 Mar 1998 03:39:56 GMT
Links: << >>  << T >>  << A >>
Rob,
I have 2 Cypress ISR devices on my board.  About 3 months ago when we
started the programming process we could only use a 386 or some 486
computers to program the devices.  It turned out to be the ISR cable.  The
local Cypress FAE replaced the cable and the computers we've tried so far
program the parts ok.   We created simple configuration files for the ISR
program to do the following:
program part one and read part two,
read part one and program part two,
program both part,
read both parts.

This is do to the 100 times programming limit, we only program the part we
need to change.  Overall I am happy with the performance of the part and
the new ISR cable.

Bill Brown

Rob Semenoff <robert_semenoff@phoenix.com> wrote in article
<01bd52b7$26e6e1c0$cd037a86@rsemenoff.phoenix.com>...
> 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. 
> One thing I have found is that the error messages from the programming
> software are 
> innaccurate, but I won't be able to try programming a device until I can
> get a 
> prototype board built - and I don't want to commit to the cypress part in
> my design
> if it turns out their system is flaky.
> 
> Any comments appreciated,
> 
> -Rob
> 
Article: 9588
Subject: CMOS or TTL?
From: Ho Siu Hung <eg_hsh@stu.ust.hk>
Date: Wed, 25 Mar 1998 11:46:28 +0800
Links: << >>  << T >>  << A >>
Hello,

I am currently doing a project with an XC4000E interfacing with PC
parallel port.  Inside the M1 tools there are options for CMOS or TTL.
What should I choose when interfacing with an old type, SPP parallel port?

Regards,
David Ho

Article: 9589
Subject: Lowest POWER FPGAs???
From: Richard Schwarz <aps@associatedpro.com>
Date: Tue, 24 Mar 1998 23:07:15 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7FD492498504514E57BD8E1E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alright all you FPGA reps. I would really like some hard comparison
numbers on
power consumption of FPGAs. I know these are design dependent, but there
have to be some comparison numbers out there somewhere. I would really
like to see some numbers on SRAM vs. ACTEL and Quick Logic.

I am doing a design I would like to keep in a 5K gate device. The
highest clock is 2Mhz, and I wil be wiggling maybe 70 lines. The device
will be burst processing and only will be on for perhaps 25% of the
time. There are perhaps 10 16 bit counters internal to the device. The
design will all be 3.3V

What kind of power numbers can I expect from

ACTEL:
Quick Logic:
Lucent:
XILINX:
ATMEL:
Altera:


--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


--------------7FD492498504514E57BD8E1E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Schwarz
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Richard Schwarz
n:              Schwarz;Richard
org:            Associated Professional Systems
adr:            3003 Latrobe Court;;;Abingdon;MD;21009;USA
email;internet: aps@associatedpro.com
title:          President
tel;work:       410.569.5897
tel;fax:        410.661.2760
tel;home:       410.515.3883
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------7FD492498504514E57BD8E1E--

Article: 9590
Subject: Re: To Richard Schwarz of APS
From: Richard Schwarz <aps@associatedpro.com>
Date: Tue, 24 Mar 1998 23:12:57 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------C6B34283B1B33A63E87009F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

No problem at all Paul. Thanks again for your understanding. :-)

Richard

Paul wrote:

> Richard,
>
> Whether or not you were referring to me about the numerous complaints
> you've received, I want to apologize now for those two messages that I
> did post. I should have left those issues in the past, where they
> belonged.
>
> From what you've said, my guess is, my experience was a rare one, and
> that usually APS has much better success shipping their product. I
> understand that I asked for a special date for delivery of the APS kit,
> and I asked this around Christmas time, and I realize that this is
> probably what messed things up for everybody. I can tell from the
> frustration of your last message that this is the point you're trying to
> make.
>
> And although this is the first I've heard of it, your offer to refund
> shipping costs I think is a sincere offer, an attempt to set things
> right. The offer's enough for me; I'm not interested in the refund.
>
> I'm just hoping that if you'll accept my public apology for my public
> complaints, that we can put the whole matter behind us.
>
> Sincerely,
> -Paul



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


--------------C6B34283B1B33A63E87009F1
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Schwarz
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Richard Schwarz
n:              Schwarz;Richard
org:            Associated Professional Systems
adr:            3003 Latrobe Court;;;Abingdon;MD;21009;USA
email;internet: aps@associatedpro.com
title:          President
tel;work:       410.569.5897
tel;fax:        410.661.2760
tel;home:       410.515.3883
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------C6B34283B1B33A63E87009F1--

Article: 9591
Subject: Re: "CORE Competency" ???
From: Rick Collins <redsp@writeme.com>
Date: Tue, 24 Mar 1998 23:33:49 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> 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

The framing is just a shift register with a comparator attached. When the right
combination of bits occures, the comparator signals the event. A small state
machine coupled with the frame counter indicates if you are in sync or out of
sync. The shift register may need to be a large number of bits though.

I believe the sync pattern is the first 4 bits from each frame which goes
through a repetitive pattern. One algorithm would use just a 4 bit shift
register with counters. You shift all incoming bits through until you see the
frame 1 pattern. You then count bits to the next frame and see if you have the
frame 2 pattern. If yes, you repeat for the 3rd frame, 4th frame... If you don't
have the correct pattern at any point you start over with the first frame
pattern. When you see the complete master frame pattern several times, you
asssume that you are in sync. Any misses in the pattern and you are out of sync
and start over hunting.

This will not give you a minimum lockup time, but the hardware is minmal; 4 bit
shift register and comparator, 8 bit bit counter, 4 bit frame counter and a
small state machine. I believe that most chips take a second or so to lockup to
the sync pattern. So they may be doing exactly this.

Is there a better way to do this?

Rick Collins

redsp@writeme.com



Article: 9592
Subject: Re: Dual port
From: Rick Collins <redsp@writeme.com>
Date: Tue, 24 Mar 1998 23:49:03 -0500
Links: << >>  << T >>  << A >>
Philip Freidin wrote:

> 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.

This is how it appears to the user, but obviously both ports are written at the
same time. Otherwise you can't read a RAM that you have never written to. The
only way to allow reads and writes without contention is to design the RAM with
dual access to each location. This requires a lot more real estate than a simple
RAM. Your comment about a delay on write on one port and read on the other is
not clear. If I can read write one port simultaneously, why can't I read write
different ports simultaneously? What does the universe have to do with this?

> >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.

The only advantage I can see with the addressing scheme they used is that it
does not require an extra multiplexer in the address path. But then I don't
think the details of the block diagrams that Xilinx publishs are accurate enough
to allow you to tell what impact this would have.

> 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.

I am curious as to what it does have. Obviously it must duplicate the decoding.
Other than the storage cells, what else is there?

> 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.

I am not clear as to why one design would be bit stream compatible and the other
not. My point about the memory cell is that the function generator that has
different read and write address ports MUST already be a fully dual port memory.
Why not make them both fully dual port and have it be two bits wide?

> for further info, you could look up patent 5631577, on the IBM patent
> server http://patent.womplex.ibm.com

What does this patent cover, dual port memory or its use in an FPGA?

> >Rick Collins
> >redsp@writeme.com
>
> Philip Freidin



Article: 9593
Subject: Re: Dual port
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 25 Mar 1998 07:24:20 GMT
Links: << >>  << T >>  << A >>
In article <6f8gd7$eib$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes:
>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.

In these devices, the dual port is done as 1 read port, and 1 write port. 
This allows for a 32x4 memory in a PFU with eight 4-input LUTS. This
certainly is an improvement if you want to build FIFO's or uni-directional
mailboxes. It does not work for the multiple read port requirements of 
things like register files in CPU type data paths, or mailboxes, where 
you want to look at the content that you have written. You can obviously 
write the data into two such RAMs, and use independent read addresses, in 
which case the dual port bits per LUT is just like the XC4000E type products.

>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. 

Xilinx has added blocks of dual port SRAM sepparate, and additional to 
the LUT base SRAM in their new Virtex family, which you can read about
in their Q1 98 XCELL magazine.

>Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
>Fermi National Accelerator Lab                      Fax: 630-840-5406
>Batavia, IL 60510

Philip Freidin
Article: 9594
Subject: Re: Orca Floorplanning tools
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 25 Mar 1998 07:31:24 GMT
Links: << >>  << T >>  << A >>
In article <6f9939$40k$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes:
>
>I am using Orca and not Xilinx.
> .....
>I'm not opposed to using Xilinx, but have found that Orca is almost
>always better for my applications.  The only major complaint I have about
>Orca chips is the lack of I/O registers.  In order to get predictable Tco, 
>setup and hold times, I sometimes have to do hand-optimized mapping
>and placement.
>
>This is an example of why it would be helpful to have access to software
>internals.

Or have tools that just let you specify the requirements in your
design source. Xact and M1 let you do this.

>  If I had access to the Orca mapping algorithm I could probably
>hack it to make the I/O optimizations.
>
>Also, the Orca preference file format leaves a lot to be desired.  Xilinx
>has (had?) a much better way to specify timing constraints.  (I think xilinx
>is now using the same Neocad-based system as Lucent.)

The code that Xilinx and Lucent are using branched when Xilinx acquired
Neocad 3 years ago. The result for Xilinx is now called M1 (for merged
release 1), and it has the advantages of both tool sets. M1 supports all
the TimeSpec language of the Xact sw, together with several quite nice new
features. 

>Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
>Fermi National Accelerator Lab                      Fax: 630-840-5406
>Batavia, IL 60510

Philip Freidin

Article: 9595
Subject: Re: USB bus interface (12 mbit/sec) in an FPGA - how difficult?
From: "Rune Baeverrud" <rb@acte.no>
Date: Wed, 25 Mar 1998 08:45:23 +0100
Links: << >>  << T >>  << A >>
I'm considering USB support for a hardware project I'm currently doing, but
I'm not sure where to look for the information I need.

I would appreciate if anyone could point me in the right direction - like:

What tools do I need to do the programming on the PC side?

Also - what kind of size of the USB core could you expect for a FLEX10K
implementation, when a secondary CPU is available to share the workload?

Regards,
Rune Baeverrud


muzo wrote in message <351979c3.89867021@news1.walltech.com>...
>I am currently doing a USB implementation in Altera 10K. Actually USB can
be
>implemented with a state machine instead of a microcontroller. And yes
there is a
>higher speed clock in the design in that the bit detection needs to resolve
a +-
>.25 bit jitter and that means the clock/data recovery needs to be done at
48 MHz
>but that section of the circuit is very small. Most of the design can be in
12
>MHz.
>
>Rick Collins <redsp@writeme.com> wrote:
>>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
>>
>>
>
>muzo
>
>WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>


Article: 9596
Subject: Re: Dual port
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 25 Mar 1998 08:14:50 GMT
Links: << >>  << T >>  << A >>
In article <35188CBE.2DD97143@writeme.com> redsp@writeme.com writes:
>Philip Freidin wrote:
>> 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.
>
>This is how it appears to the user, but obviously both ports are written at the
>same time.

Think of it this way: there is a LUT RAM (16 x 1), and it has a write
address decoder, and a read address decoder. The address input lines of
the two decoders are tied together. You can therefore only read or write
one location at a time, and when you write to an address, the read decoder
will be reading from the same location, so when the memory cell changes to
the new value, it is already being read, so the output will update to the
new value. An acurate model of this for the XC4000E would be 16 flip 
flops, with the outputs all going to a 16 to 1 mux (the read decoder), 
and the D and CLK inputs all tied together, and the write address goes to 
a 4 line to 16 line decoder, these 16 decoded signals going to the CE 
inputs of the flip flops. When the clock comes along, only one of the 
flip flops is updated. This is how single port RAM is implemented.

Now take two of these LUT RAMs, and when you want a dual port mode, 
connect the second RAMs write address to the write address of the first 
RAM. Now when you write, the data is written into both SRAMs, and the 
first one (with the read address still connected to write address) will 
read the value out as soon as the memory cell is updated. In the second 
LUT, the read address is independent. It can be watching the same 
address, or some other address.

>Otherwise you can't read a RAM that you have never written to.

Well, you can, but you get junk.

>The only way to allow reads and writes without contention is to design
>the RAM with dual access to each location. This requires a lot more real
>estate than a simple RAM. 

But is inherently what was already there in the XC4000 (in terms of read 
and write decoders), before dual port was added.

>Your comment about a delay on write on one port and read on the other is
>not clear.

I was just referring to the pass through delay. It is about 1 or 2 
nanoseconds from the time the cell has been updated to the new value is 
available on the output of the read port, assuming the read address is 
monitoring the address being written to.

>If I can read write one port simultaneously, why can't I read write
>different ports simultaneously?

Because one port is a read/write port (the address input is used for both)
and the other port is read only, because the writing is done from the 
first port. 

>The only advantage I can see with the addressing scheme they used is that it
>does not require an extra multiplexer in the address path. But then I don't
>think the details of the block diagrams that Xilinx publishs are accurate enough
>to allow you to tell what impact this would have.

The diagram on pagfe 4-185 of the 1/98 Xilinx data book shows the 
structure with sufficient detail.

>> 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.

>I am curious as to what it does have. Obviously it must duplicate the decoding.
>Other than the storage cells, what else is there?

See detailed description at the top of this message.

>> 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.

>I am not clear as to why one design would be bit stream compatible and
>the other not. 

The issue with bitstream compatibility has more to do with how many bits 
of the bitstream are available to activate new functionality, without 
changing the bitstream, rather than with the architecture of dual port. 

Each new function in a CLB requires some config bits to select whether or
not it is activated. One of the most heavy uses of config bits is the
selector muxes that select signals from the routing channels, and feed
them into the CLB. There is no way to add additional input pins (to be
used as dual port address pins) to a CLB without planning for it from the
beginning. One of the goals of the XC4000E product was to be bitstream
compatible with the prior generation products, so additional inputs were 
not an option. 

>My point about the memory cell is that the function generator that has
>different read and write address ports MUST already be a fully dual port
>memory. Why not make them both fully dual port and have it be two bits
>wide? 

As described above, while the read and write structures are separate, 
they share the 4 address signals. To make them independent would require 
4 more inputs to the CLB.

>> for further info, you could look up patent 5631577, on the IBM patent
>> server http://patent.womplex.ibm.com

>What does this patent cover, dual port memory or its use in an FPGA?

Dual Port memory in the XC4000E FPGA

>> >Rick Collins
>> >redsp@writeme.com

Philip Freidin



Article: 9597
Subject: Re: Orca Floorplanning tools
From: husby@fnal.gov (Don Husby)
Date: Wed, 25 Mar 1998 14:38:15 GMT
Links: << >>  << T >>  << A >>
fliptron@netcom.com (Philip Freidin) wrote:

> In article <6f9939$40k$1@info1.fnal.gov> husby@fnal.gov (Don Husby) writes:
> > In order to get predictable Tco, 
> > setup and hold times, I sometimes have to do hand-optimized mapping
> > and placement.
> >
> > This is an example of why it would be helpful to have access to software
> > internals.

> Or have tools that just let you specify the requirements in your
> design source. Xact and M1 let you do this.

You can do this in the Orca software too, but specifying the requirements
doesn't necessarily mean you'll meet them.  Unfortunately, the software 
writers haven't yet implemented the optimization algorithm that would help
in this particular case.  If I had access to the software internals, I could, 
possibly, implement it on my own.



--
Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
Fermi National Accelerator Lab                      Fax: 630-840-5406
Batavia, IL 60510
Article: 9598
Subject: Architectures, Languages and Patterns (Final Call)
From: P.H.Welch@ukc.ac.uk (phw)
Date: Wed, 25 Mar 98 16:42:37 GMT
Links: << >>  << T >>  << A >>


*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***


       ===========================================================
       |        C A L L   F O R   P A R T I C I P A N T S        |
       ===========================================================
       |                                                         |
       |                       (WoTUG 21)                        |
       |                                                         |
       |          Architectures, Languages and Patterns          |
       |        for Parallel and Distributed Applications        |
       |                                                         |
       |                     5-8 April 1998                      |
       |          University of Kent at Canterbury, UK           |
       |                                                         |
       | <http://www.hensa.ac.uk/parallel/groups/wotug/wotug21/> |
       |                                                         |
       ===========================================================


If you haven't already registered, please check out the WoTUG-21 web site
for the final timetable and academic programme (papers and the Java Threads
Tutorials).

We believe a really strong programme has been put together that should be
of cosiderable interest to all who are working with parallel systems, be
they researchers, developers or users.  Please help us bring this to the
attention of as wide an audience as possible.

Invited speakers now include David May (who kicked these ideas into life),
Peter Thompson (Chair of the 1355 Association), Graham Nice (Alex Computer
Systems, Montreal, Canada) and Roger Gook (Embedded Solutions Ltd.).

Industrial applications include the use of occam (on a DSP chip) for
radar-based fluid level monitoring in oil tankers worldwide (Norway),
concurrent graphics engines programmed in Java (Deutsche Telekom) and
fault-tolerant avionics in satellites (Brazil).

There are a clutch of papers from Oxford on new extensions and models for CSP,
some specifically for hardware specification and design, plus a new tool for
verification support.  There is Handel-C, an occam derived language for
hardware/software co-design (also from Oxford), backed up with Industrial
support.

Another hot topic is the efficient construction of future parallel hardware
just using commodity processors (like the Alpha, SPARC, Pentium and SHARC)
and commodity interconnect (like Fast Ethernet and High-Speed 1355 links and
routers).  This seems to be an idea whose time has come, given the independent
work reported from CERN, Nottingham-Trent, Southampton and Twente ... and
the disappearance of most proprietary parallel architecture.

There's an extensive review of a number of parallel system design environments
(from Russia).  And finally, occam lives on on modern architectures, both in
the JavaPP ideas presented in the tutorials and in the ever more efficient
targetings to modern processors (including SMP and NoW architectures) being
reported formally and informally in the late-nite sessions.

Why not be there?  On-line registration from the web-site is available now!

Many thanks,

Peter Welch.

*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***
*** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL *** FINAL CALL ***

Article: 9599
Subject: Re: Looking for space qualified FPGAs/ASICs
From: "Dave Hawkins" <dwh@ovro.caltech.edu>
Date: Wed, 25 Mar 1998 09:47:26 -0800
Links: << >>  << T >>  << A >>
Try www.spec.com they are a company working under an
SBIR (small business innovation and research (?)) grant.
They supply radiation hardened FPGAs ... but I would
imagine that it is at a price.

I have no affiliation with these guys, just found them on the
web one day while looking for ECL gate arrays. (They
are supplied by www.dyna.com if you're interested.)

Regards,

Dave
dwh@ovro.caltech.edu


Stephen King wrote in message
<01bd5324$d36ff5e0$1d3872c1@sk_ii.crl.co.uk>...
>We are looking to encode a complicated algorithm onto either an FPGA or
>ASIC for space applications.
>
>We are interested to know of any space qualified:
>
>1.) FPGAs,
>
>2.) Low volume ASIC processes (e.g. laser programmable, shared wafer etc),
>
>3.) Conventional ASIC processes.
>
>Thanks for you help in this matter.
>
>--
>Stephen King
>CRL
>sking@crl.co.uk




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
2017JanFebMarApr2017

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