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 14625

Article: 14625
Subject: Re: VHDL synthesis
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Sun, 07 Feb 1999 00:13:53 +0000
Links: << >>  << T >>  << A >>

Thanks for the explanation. But I still think the synthesis tools
would be more clever. It is very hard for someone with a software
background to develop an HDL code suitable for synthesis. It is
necessary to have a good knowledge not only of hardware, but also
of how synthesizers work. I don't want to offend the synthesizer
developers. I know it is a complex problem, but I hope one day
we would be able to develop hardware in the same way as software.

Thanks again

Eduardo.

ems@riverside-machines.com.NOSPAM wrote:
> 
> Think hardware. You're asking the synthesiser to produce a clocked
> element, which has (a) two clocks (one of which has a higher priority
> than the other), (b) one output which is loaded on both clocks, and
> (c) another output which is loaded on only the second clock, but only
> if there's no edge on the first clock. Your synthesiser doesn't create
> new clocked elements - stick with the hardware in your technology
> library.
> 
> Evan
Article: 14626
Subject: Board for XC4085XL
From: "Sanjeev" <nospam@nospam.net>
Date: Sat, 6 Feb 1999 20:46:14 -0500
Links: << >>  << T >>  << A >>
I am looking for a good project board that will take a Xilinx XC4085XL (PGA
559) FPGA. Anyone have any good suggestions?

Thanks


Article: 14627
Subject: Re: dual port RAM on XC4000
From: "Austin Franklin" <austin@dark9room.com>
Date: 7 Feb 1999 02:17:55 GMT
Links: << >>  << T >>  << A >>

> The only mention of dual-port I could find on the Xilinx site was
> in XC4000E and later devices -- I'm using XC4000, the suffix-less,
> disowned version.

You should be using the libraries FOR that part.....see if the library has
the RAM elements.  I seem to remember they do have RAM in the non E parts. 
It was the not really released 4010D that was not supposed to have any
RAM....

Austin

Article: 14628
Subject: Thank You
From: John Larkin <jjlarkin@worldnet.att.net>
Date: 7 Feb 1999 06:04:05 GMT
Links: << >>  << T >>  << A >>
Your Name wrote:
> 
> If you really have invented something useful then patent it!  Otherwise,
> stop whinning!
> 
>

Thank you, Your Name, for your thoughtful and professional advice.

John
Article: 14629
Subject: Re: dual port RAM on XC4000
From: Hamish Moffatt <hamish@rising.com.au>
Date: 7 Feb 1999 10:19:26 GMT
Links: << >>  << T >>  << A >>
Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On 6 Feb 1999 09:40:53 GMT, Hamish Moffatt <hamish@rising.com.au> wrote:
>>The only mention of dual-port I could find on the Xilinx site was
>>in XC4000E and later devices -- I'm using XC4000, the suffix-less,
>>disowned version.
>>
> Why not duplicate a single-port memory? 
> (Which is pretty much what the dual-port RAM cell does internally, so
> you won't be losing any efficiency)

Trying to save resources. There isn't enough room in the 4010 to duplicate
the RAM and the rest of the design which uses it. 

Hamish
-- 
Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au

Rising Software Australia Pty. Ltd. 
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
Internet: http://www.rising.com.au/
Article: 14630
Subject: Re: dual port RAM on XC4000
From: Hamish Moffatt <hamish@rising.com.au>
Date: 7 Feb 1999 10:20:00 GMT
Links: << >>  << T >>  << A >>
Austin Franklin <austin@dark9room.com> wrote:
>> The only mention of dual-port I could find on the Xilinx site was
>> in XC4000E and later devices -- I'm using XC4000, the suffix-less,
>> disowned version.

> You should be using the libraries FOR that part.....see if the library has
> the RAM elements.  I seem to remember they do have RAM in the non E parts. 
> It was the not really released 4010D that was not supposed to have any
> RAM....

It has RAM -- no problem there, but single port only.


thanks,
Hamish
-- 
Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au

Rising Software Australia Pty. Ltd. 
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
Internet: http://www.rising.com.au/
Article: 14631
Subject: RE: dual port RAM on XC4000
From: Alexander Sherstuk <Sherstuk@amsd.com>
Date: Sun, 7 Feb 1999 13:21:06 +0300
Links: << >>  << T >>  << A >>



I used to use XC4000A and XC4000 (non-E) 5 years ago.
This kind of chips has the only type of built-in
memory: asynchronous single-port memory: RAM16X1, ..., RAM16X8.
I implemented dual-port memory inside XC4000 by means of time-divided
multiplexing. 
Address bus and the input data bus of the RAM16X8 element were switched
between two 
memory requestors by a Finite State Machine.
Memory output data bits were triggered into two separate registers (each
one - for
a separate memory user).
Special care should be taken, to issue memory write strobe with
sufficient time gap from the moment of switching. So, it is reasonable
to allocate 3 clock cycles for the memory write action, while the memory
read
can be done in 1 cycle.

Regards,
  Alex Sherstuk
  Sherstuk@amsd.com
       AMSD Company


-----Original Message-----
From: Hamish Moffatt [mailto:hamish@rising.com.au]
Posted At: Saturday, February 06, 1999 4:53 AM
Posted To: comp.arch.fpga
Conversation: dual port RAM on XC4000
Subject: dual port RAM on XC4000


Is it possible to do dual-port RAM in an XC4000 (no E)? I want two read
ports, rather than read and write (it's not for a FIFO). I assume not,
since there's nothing at Xilinx's web site about it, but you never know.


thanks,
Hamish

-- 
Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au

Rising Software Australia Pty. Ltd. 
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free:
1-888-667-7839
Internet: http://www.rising.com.au/



Article: 14632
Subject: Re: DES in VHDL for FPGAs
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: 07 Feb 1999 16:54:55 +0000
Links: << >>  << T >>  << A >>
"Matthias D. Kistler" <recomp@satie.ee.ethz.ch> writes:

> I am looking for the VHDL sources for a DES implementation suitable for
> an FPGA.

Have a look at http://www.yordas.demon.co.uk/crypto  You'll find a 
pipelined version in VHDL plus a version which uses Xilinx Select-RAM 
to reduce the size of the S-boxes.

Chris
-- 
Chris Eilbeck                         mailto:chris@yordas.demon.co.uk


Article: 14633
Subject: Re: VHDL synthesis
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Sun, 07 Feb 1999 17:40:20 +0000
Links: << >>  << T >>  << A >>

ems@riverside-machines.com.NOSPAM wrote:
> 
> Think hardware. You're asking the synthesiser to produce a clocked
> element, which has (a) two clocks (one of which has a higher priority
> than the other), (b) one output which is loaded on both clocks, and
> (c) another output which is loaded on only the second clock, but only
> if there's no edge on the first clock. Your synthesiser doesn't create
> new clocked elements - stick with the hardware in your technology
> library.
> 

Using your comments (with some changes), my FIFO, listed below, has:

(a) two clocks one of which (WR_NEG_IN) has a higher priority
    than the other (RD_NEG_IN ),

(b) one output (COUNT) which is loaded on both clocks,

(c) two outputs (LAST and MEM_FIFO_HF) that are loaded only on the
    first clock ,

(d) one output (FIRST) which is loaded only on the second clock, but
    only if there's no edge on the first clock,

In this implementation I could identify only two main differences
from the first one:

1 - The RESET_NEG_IN signal

2 - Both clocks are rising edge.

And the synthesizer produced exactly what I had asked for. What is
the explanation?

Regards

Eduardo


-- Package SVAL_PKG
library IEEE;
   use IEEE.std_logic_1164.all;

package SVAL_PKG is
   constant WORD_LENGTH_FIFO_HF_C : integer := 5;
   constant FIFO_HF_SIZE_C        : integer := 7;          --255;
   constant FIFO_HALF_FULL_HF_C   : integer := 4;          --128;
   constant ZERO_FIFO_HF_C        :
std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0) := "00000";
   type     RAM_FIFO_HF_TYP is array(FIFO_HF_SIZE_C downto 0) of
std_logic_vector(WORD_LENGTH_FIFO_HF_C-1 downto 0);

   constant ZERO_C                : std_logic_vector(WORD_LENGTH_C-1
downto 0) := "00000000";
end SVAL_PKG;

--
-- FIFO starts here
--
library ieee;
   use ieee.std_logic_1164.all;
   use IEEE.std_logic_arith.all;
   use IEEE.std_logic_unsigned.all;
   use work.SVAL_PKG.all;

entity FIFO_HF is

   port ( RESET_NEG_IN   : in  std_logic;   -- '0' -> reset FIFO
          RD_NEG_IN      : in  std_logic;   -- '0' -> read FIFO
          WR_NEG_IN      : in  std_logic;   -- '0' -> write FIFO
          DATA_IN        : in  std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
          DATA_OUT       : out std_logic_vector(WORD_LENGTH_FIFO_HF_C-1
downto 0);
          FIFO_HALF_OUT  : out std_logic;   -- '1' when FIFO is > half
full
          FIFO_EMPTY_OUT : out std_logic;   -- '1' when FIFO is empty
          FIFO_FULL_OUT  : out std_logic    -- '1' when FIFO is full
        );

end FIFO_HF;

architecture FIFO_HF_BEH of FIFO_HF is

   -- FIFO pointers
   signal LAST, FIRST         : DATA_SIZE_TYP;
   signal COUNT               : std_logic_vector (8 downto 0);
   signal LAST_IDX, FIRST_IDX : DATA_SIZE_TYP;
   -- FIFO memory
   signal MEM_FIFO_HF         : RAM_FIFO_HF_TYP;

begin

   FIFO_PRO: process(RESET_NEG_IN, WR_NEG_IN, RD_NEG_IN )
   begin

      if RESET_NEG_IN = '0' then
         LAST           <= ZERO_C;
         FIRST          <= ZERO_C;
         COUNT          <= "000000000";
      elsif WR_NEG_IN'event and WR_NEG_IN = '0' then  -- write to FIFO
         if COUNT <= FIFO_HF_SIZE_C then
            COUNT <= COUNT + 1;
            if LAST = FIFO_HF_SIZE_C then
               LAST <= ZERO_C;
            else
               LAST <= LAST + 1;
            end if;
            MEM_FIFO_HF(conv_integer(LAST_IDX)) <= DATA_IN;
         end if;
      elsif RD_NEG_IN'event and RD_NEG_IN = '0' then  -- read from FIFO
         if COUNT > 0 then
            COUNT <= COUNT - 1;
            if FIRST = FIFO_HF_SIZE_C then
               FIRST <= ZERO_C;
            else
               FIRST <= FIRST + 1;
            end if;
         end if;
      end if;

   end process FIFO_PRO;

   LAST_IDX       <= LAST;
   FIRST_IDX      <= FIRST;

   DATA_OUT       <= MEM_FIFO_HF(conv_integer(FIRST_IDX));
   FIFO_HALF_OUT  <= '1' when COUNT > FIFO_HALF_FULL_HF_C else
                     '0';
   FIFO_EMPTY_OUT <= '1' when COUNT = 0                   else
                     '0';
   FIFO_FULL_OUT  <= '1' when COUNT > FIFO_HF_SIZE_C      else
                     '0';

end FIFO_HF_BEH;
Article: 14634
Subject: Board for XC4085XL?
From: "Sanjeev" <nospam@nospam.net>
Date: Sun, 7 Feb 1999 15:49:48 -0500
Links: << >>  << T >>  << A >>
I'm looking for a development board that will take a Xilinx XC4085XL (PGA
559) FPGA. Anyone know of any good boards?

Thanks in advance,

Sanjeev.



Article: 14635
Subject: Re: Xilinx de-compiler
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Sun, 07 Feb 1999 22:08:09 GMT
Links: << >>  << T >>  << A >>
Your Name wrote:
> 
> If you really have invented something useful then patent it!  Otherwise,
> stop whinning!
> 

not a very usefull answer, to get a patent you'll need money and 
you'll have to reveal everything about how it works, and the 
patent isn't much more worth than the amount af laywers you can 
afford to protect it .... 

--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 14636
Subject: Re: Xilinx de-compiler
From: John Larkin <jjlarkin@worldnet.att.net>
Date: 7 Feb 1999 23:09:38 GMT
Links: << >>  << T >>  << A >>
Lasse Langwadt Christensen wrote:
> 
> Your Name wrote:
> >
> > If you really have invented something useful then patent it!  Otherwise,
> > stop whinning!
> >
> 
> not a very usefull answer, to get a patent you'll need money and
> you'll have to reveal everything about how it works, and the
> patent isn't much more worth than the amount af laywers you can
> afford to protect it ....
> 
> --Lasse
> --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
> Lasse Langwadt Christensen, MSEE (to be in 1999)
> Aalborg University, Department of communication tech.
> Applied Signal Processing and Implementation (ASPI)
> http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org


Lasse,

Since he's rude and illogical, I conclude that he's probably just a
lawyer... and lawyers are about the only people who actually benefit
from patents.

John


-- 

********************************************************************h

John Larkin, President            phone 415 753-5814   fax 753-3301
Highland Technology, Inc
320 Judah Street                          jjlarkin@worldnet.att.net
San Francisco, CA 94122           http://www.highlandtechnology.com
Article: 14637
Subject: Re: dual port RAM on XC4000
From: Peter Alfke <peter@xilinx.com>
Date: Sun, 07 Feb 1999 15:58:04 -0800
Links: << >>  << T >>  << A >>
Brian Drummond wrote:

> >
> >The only mention of dual-port I could find on the Xilinx
> site was
> >in XC4000E and later devices -- I'm using XC4000, the
> suffix-less,
> >disowned version.
> >
> Why not duplicate a single-port memory?
> (Which is pretty much what the dual-port RAM cell does
> internally, so
> you won't be losing any efficiency)
>  

  Not quite: The XC4000E and all later flavors (EX, XL, XV,
XLA) in dual-port mode apply a common write address (F) to
both LUTs inside the CLB, but let you read-address the G-LUT
idependently. See the drawing on page 4-16 in the Xilinx
data book. It is accurate ( I drew it ).
You cannot really achieve the same result with external
multiplexing. The dual port scheme  writes to both LUTs and
lets you read asynchronously and simultaneously by means of
the G address.

The XC4000E is a more modern, better and faster superset of
the XC4000, and it costs less than half of the old XC4000.
No reason to decry the lack of features in the old part.

Peter Alfke, Xilinx applications

Peter Alfke

Article: 14638
Subject: Re: dual port RAM on XC4000
From: "Austin Franklin" <austin@dark9room.com>
Date: 8 Feb 1999 04:31:45 GMT
Links: << >>  << T >>  << A >>
I used to use XC4000A and XC4000 (non-E) 5 years ago.
This kind of chips has the only type of built-in
memory: asynchronous single-port memory: RAM16X1, ..., RAM16X8.
I implemented dual-port memory inside XC4000 by means of time-divided
multiplexing. 
.....
So, it is reasonable
to allocate 3 clock cycles for the memory write action, while the memory
read
can be done in 1 cycle.

----------------------------------------------

Writes can be done in 1 if you gate the WE with the clock.  It is best if
you control the placement and routing in order to make the timing 'work'.

Austin

Article: 14639
Subject: xc4000 obselete to xc4000e
From: Hamish Moffatt <hamish@rising.com.au>
Date: 8 Feb 1999 08:29:04 GMT
Links: << >>  << T >>  << A >>
If have a design in XC4000 done in Mentor using
the obselete libraries, which I want to port to 4000E, can this be done
automatically? The process described in XAPP 062 works if you're already
on the unified libraries for XC4000 -- does it work from obselete?


thanks

Hamish
-- 
Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au

Rising Software Australia Pty. Ltd. 
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
Internet: http://www.rising.com.au/
Article: 14640
Subject: PLX9050 Dev. Software
From: John Chambers <johnc@ihr.mrc.ac.uk>
Date: Mon, 08 Feb 1999 10:53:43 +0000
Links: << >>  << T >>  << A >>
I'm trying to develope software to access memory on the PCI bus through
the PLX9050.  Does anyone have any examples of how to initialise the
chip and read/write to the memory?  Ideally I don't want to spend more
money on a device driver developement toolkit - there must be some 'C'
code for DOS out there somewhere that I can use to get an idea of what
needs to be done.  Any code or book references welcome.

John

johnc@ihr.mrc.ac.uk
Article: 14641
Subject: Re: Xilinx de-compiler
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Mon, 08 Feb 1999 08:54:05 -0500
Links: << >>  << T >>  << A >>
While it is probably possible to reverse compile the bit stream, it
would be very unlikely that someone would go to that amount of effort.
By reverse compiling the bitstream, they only know how each CLB and net
connection is routed and would then have to translate that back into
readable form. Would probably take more resources than it would to
develop their own digital PLL.

 John Larkin wrote:
 
> Hi,
>
> I think I've invented a neat circuit for a specialized digital PLL, and
> of course I want to keep it proprietary. So if I make a product using a
> Xilinx FPGA, the config bitstream can't be hidden from a competitor who
> gets his greedy hands on one. I assume that an outright copy is a
> copyright violation, so I'm not too worried about that. So here's the
> issue: Is it feasible that someone could decompile the stream and
> recover the circuit CONCEPT? Are there any tools to help them do this?
> Would it be easy, or an enormous task?
>
-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 14642
Subject: Re: dual port RAM on XC4000
From: brian@shapes.demon.co.uk (Brian Drummond)
Date: Mon, 08 Feb 1999 14:12:57 GMT
Links: << >>  << T >>  << A >>
On Sun, 07 Feb 1999 15:58:04 -0800, Peter Alfke <peter@xilinx.com>
wrote:

>Brian Drummond wrote:
>
>> >
>> >The only mention of dual-port I could find on the Xilinx
>> site was
>> >in XC4000E and later devices -- I'm using XC4000, the
>> suffix-less,
>> >disowned version.
>> >
>> Why not duplicate a single-port memory?
>> (Which is pretty much what the dual-port RAM cell does
>> internally, so
>> you won't be losing any efficiency)
>>  
>
>  Not quite: The XC4000E and all later flavors (EX, XL, XV,
>XLA) in dual-port mode apply a common write address (F) to
>both LUTs inside the CLB, but let you read-address the G-LUT
>idependently. See the drawing on page 4-16 in the Xilinx
>data book. It is accurate ( I drew it ).

Sure. There are differences in detailed operation. We're not disagreeing
here (between "pretty much" and "not quite" :) I just wasn't explicit
enough, relying on context supplied by the original post and the
databook.

>You cannot really achieve the same result with external
>multiplexing. The dual port scheme  writes to both LUTs and
>lets you read asynchronously and simultaneously by means of
>the G address.

But in the context of the original question - two independent read ports
(no simultaneous write) were all that was called for. For this
restricted functionality, others also have pointed out you can mimic
dual-port.

Now you _would_ need (minimal) additional resources to share the address
buses on write, but this is minimal compared to the memory itself.

The major disadvantage of duplicating single-port memory, namely a
halving in the capacity available, is equally true of the dual-port RAM
since you get 16*1 bits per CLB instead of 16*2 or 32*1 per CLB... 
(unless there's been a major update since my 1996 data book?)

It can be done - provided you can accept the hit in resources. And if
you can't, the newer series won't help you.
This was the point I was making, and Hamish subsequently expressed that
resources (not the exact functionality) was his main concern.

>The XC4000E is a more modern, better and faster superset of
>the XC4000, and it costs less than half of the old XC4000.
>No reason to decry the lack of features in the old part.

Unless you had a large supply of them, and no money!
Or maybe your tools only support the old ones, and your support contract
has expired. Or maybe that's whats soldered to the boards you inherited.
Unfortunately, not everyone works for a billion dollar company (yet...)

The quality of support for established users, stuck with older (even
obsolete) product lines, says quite a lot about a company. Especially to
those folks trying to justify a large (and, they hope, long-term)
investment today.

- Brian
Article: 14643
Subject: Re: dual port RAM on XC4000
From: brian@shapes.demon.co.uk (Brian Drummond)
Date: Mon, 08 Feb 1999 14:13:06 GMT
Links: << >>  << T >>  << A >>
On 7 Feb 1999 10:19:26 GMT, Hamish Moffatt <hamish@rising.com.au> wrote:

>Brian Drummond <brian@shapes.demon.co.uk> wrote:
>> On 6 Feb 1999 09:40:53 GMT, Hamish Moffatt <hamish@rising.com.au> wrote:
>>>The only mention of dual-port I could find on the Xilinx site was
>>>in XC4000E and later devices -- I'm using XC4000, the suffix-less,
>>>disowned version.
>>>
>> Why not duplicate a single-port memory? 
>> (Which is pretty much what the dual-port RAM cell does internally, so
>> you won't be losing any efficiency)
>
>Trying to save resources. There isn't enough room in the 4010 to duplicate
>the RAM and the rest of the design which uses it. 
>
In that case you may have the same problem with the dual-port cell,
since its capacity is half the single-port cell (16*1 not 32*1 per CLB).

See my reply to Peter Alfke.

- Brian

Article: 14644
Subject: career
From: wlockhart@atmel.com (Wendy Lockhart)
Date: Mon, 08 Feb 1999 10:13:46 -0800
Links: << >>  << T >>  << A >>
Why don't you send us your resume.
I am the apps manager for Atmel FPGA group, I can pass
it onto micro apps as well. I am always interested in
people who really want to do apps.
Send to fpga@atmel.com
Wendy



*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***
Article: 14645
Subject: Re: routability of FPGA - is this an issue?
From: Endric Schubert <endric@axiscorp.com>
Date: Mon, 08 Feb 1999 10:45:18 -0800
Links: << >>  << T >>  << A >>
hmmm, what i probably should have mentioned: i generate approx. 100
designs/hour. so interactive methods are not at all doable. it has to be
a robust automated method!


Ray Andraka wrote:
> 
> Try doing a little floorplanning.  Also, keep in mind how the design will
> get implemented as you do the design.  Try to avoid routing congestion.
> 
> Now, if you are dealing with partial reconfiguration, you shouldn't be using
> synthesis.  With partial configuration it is important that the pieces of
> the design that are to stay in-place remain untouched...this means
> implementation, placement and routing.  This calls for a structural code,
> and is extremely tedious to do.
> 
> Endric Schubert wrote:
> 
> > i work in the field of reconfigurable computing and i will never get
> > used to the following message from my FPGA back-end tools:
> >
> >         no placement/routing found ...
> >
> > or, if i was lucky enough, the tool found a fit after several hours.
> > but, c'mon, synthesizing the damn thing with a state-of-the-art tool
> > took a couple minutes!
> >
> > so i think its time to post something about this matter and see what the
> > net thinks about it:
> >
> > if you've done some serious FPGA designs, you probably know the facts of
> > routability:
> >
> > 1. re-running P&R doesn't help!
> > some algorithms are non-deterministic, so why not try one more time?
> > since for some FPGAs its worse than winning in a lottery!
> >
> > 2. decreasing device utilization doesn't help!
> > sometimes - especially when you have pin constraints - not even
> > decreasing it to a ridiculously low 50% helps!
> >
> > 3. there are no better P&R tools!
> > unfortunately, there is no 3rd party supply for P&R tools (unlike for
> > synthesis), so you're stuck with the vendors tools. and their tools seem
> > not to be too concerned about routability. hey, they want to sell
> > silicon, and when they get you down to 50% device utilization, they'll
> > suceed! :->
> >
> > 4. you cannot re-synthesize for improved routability!
> > knowing, that no synthesis tool supports "synthesis for routability" (at
> > least i don't know any), all you can do is switch off all the
> > optimizations (you're down at 50% device utilization so what do you care
> > about one more LUT?). or if you've optimized for area (delay), you now
> > optimize for delay (area).
> >
> > as an EDA developer i know that there are algorithms avail, that
> > estimate routability in synthesis, that can improve routability (e.g.
> > thru replication of logic, or running a different decomposition). also,
> > there are more decent P&R algorithms avail, than the ones you get with
> > your vendors P&R tool.
> >
> > all i want is a *robust* FPGA design flow, but why can't i buy any?
> >
> > my explanation is: there is no demand for it!
> >
> > Endric
> >
> > (speaking for himself, not for his employer)
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
Article: 14646
Subject: Re: routability of FPGA - is this an issue?
From: Ray Andraka <randraka@ids.net>
Date: Mon, 08 Feb 1999 14:16:27 -0500
Links: << >>  << T >>  << A >>
Have you looked at using something like javabits?  If you have an idea of what the
logic you are generating is, you should be able to apply at least a little smarts
to the implementation and layout.  Javabits will let you generate implementation
and layout automatically.

Endric Schubert wrote:

> hmmm, what i probably should have mentioned: i generate approx. 100
> designs/hour. so interactive methods are not at all doable. it has to be
> a robust automated method!
>
> Ray Andraka wrote:
> >
> > Try doing a little floorplanning.  Also, keep in mind how the design will
> > get implemented as you do the design.  Try to avoid routing congestion.
> >
> > Now, if you are dealing with partial reconfiguration, you shouldn't be using
> > synthesis.  With partial configuration it is important that the pieces of
> > the design that are to stay in-place remain untouched...this means
> > implementation, placement and routing.  This calls for a structural code,
> > and is extremely tedious to do.
> >
> > Endric Schubert wrote:
> >
> > > i work in the field of reconfigurable computing and i will never get
> > > used to the following message from my FPGA back-end tools:
> > >
> > >         no placement/routing found ...
> > >
> > > or, if i was lucky enough, the tool found a fit after several hours.
> > > but, c'mon, synthesizing the damn thing with a state-of-the-art tool
> > > took a couple minutes!
> > >
> > > so i think its time to post something about this matter and see what the
> > > net thinks about it:
> > >
> > > if you've done some serious FPGA designs, you probably know the facts of
> > > routability:
> > >
> > > 1. re-running P&R doesn't help!
> > > some algorithms are non-deterministic, so why not try one more time?
> > > since for some FPGAs its worse than winning in a lottery!
> > >
> > > 2. decreasing device utilization doesn't help!
> > > sometimes - especially when you have pin constraints - not even
> > > decreasing it to a ridiculously low 50% helps!
> > >
> > > 3. there are no better P&R tools!
> > > unfortunately, there is no 3rd party supply for P&R tools (unlike for
> > > synthesis), so you're stuck with the vendors tools. and their tools seem
> > > not to be too concerned about routability. hey, they want to sell
> > > silicon, and when they get you down to 50% device utilization, they'll
> > > suceed! :->
> > >
> > > 4. you cannot re-synthesize for improved routability!
> > > knowing, that no synthesis tool supports "synthesis for routability" (at
> > > least i don't know any), all you can do is switch off all the
> > > optimizations (you're down at 50% device utilization so what do you care
> > > about one more LUT?). or if you've optimized for area (delay), you now
> > > optimize for delay (area).
> > >
> > > as an EDA developer i know that there are algorithms avail, that
> > > estimate routability in synthesis, that can improve routability (e.g.
> > > thru replication of logic, or running a different decomposition). also,
> > > there are more decent P&R algorithms avail, than the ones you get with
> > > your vendors P&R tool.
> > >
> > > all i want is a *robust* FPGA design flow, but why can't i buy any?
> > >
> > > my explanation is: there is no demand for it!
> > >
> > > Endric
> > >
> > > (speaking for himself, not for his employer)
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14647
Subject: Contract Job in Boston
From: Stephen Swearingen <sasweari@orbitworld.net>
Date: Mon, 08 Feb 1999 13:28:10 -0600
Links: << >>  << T >>  << A >>
Hello Mr. Stan,

Is the job in Boston still available?  I am very interested in contracts
of this type.  I specialize in Xilinx design, especially high speed data
flow (50 MHz - 100 MHz).  I am extremely well versed in Xilinx and have
a large amount of experience with logic placement and routing
optimization.  I feel this is a unique skill/craft that most FPGA
designers lack and would be quite useful for this type of design.
Design experience includes telemetry processing equipment for NASA that
links all of their ground stations together, various R&D projects, and
safety systems..  I have 8+ years experience with all levels of board
design (digital and analog) from concept to finial product.

Thank you for your time and consideration and look forward to you reply.

Regards,
Steve Swearingen
sasweari@orbitworld.net



Article: 14648
Subject: Contract Job in Boston II
From: Stephen Swearingen <sasweari@orbitworld.net>
Date: Mon, 08 Feb 1999 13:38:42 -0600
Links: << >>  << T >>  << A >>
I recently posted an email regarding a contact job to this address by
mistake.  Please accept my apologies.

Steve Swearingen





Article: 14649
Subject: comp.arch.fpga Archives
From: "T. Franklin" <tfrankli_1@nospam.yahoo.com>
Date: Mon, 08 Feb 1999 15:52:29 -0500
Links: << >>  << T >>  << A >>
Where can I find the archives for this newsgroup?

--
To reply please remove the nospam
from the reply address.

regards,

Ted




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