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 39700

Article: 39700
Subject: Re: Xilinx Virtex XCV300
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 16 Feb 2002 13:59:49 +0100
Links: << >>  << T >>  << A >>
"Salman Sheikh" <sheikh@pop500.gsfc.nasa.gov> schrieb im Newsbeitrag
news:ee74dea.0@WebX.sUN8CHnE...
> All,
>
> I am getting the following message on my place and route.
>
> WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net
>    fsync1/CPUINTERFACE_0/loop13_un187_cpu_addr is sourced by a
combinatorial
>    pin. This is not good design practice. Use the CE pin to control the
loading
>    of data into the flip-flop.

In general, gated clock should not be used within FPGAs. But the code below
creates a LETCh (not a FlipFlop), where the gate signal is created by a
combinatorical logic. No good.

>
> I believe its due to this code:
> ---
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.STD_LOGIC_UNSIGNED.all;
> use IEEE.STD_LOGIC_ARITH.all;
> use WORK.PIFSTYPES.all;
>
> entity CPUWRTGEN is
>   port
>     (CPU_ADDR   :in     BIT11;
>      WRT        :out    BIT31);
> end CPUWRTGEN;
>
> architecture BEHAVIOR of CPUWRTGEN is
>
> signal CPU_ADDR_INT :  INT63;
>
> begin
>
> CPU_ADDR_INT <= conv_integer(CPU_ADDR(5 downto 0));
>
>    process(CPU_ADDR, CPU_ADDR_INT)
>     begin
>      for I in 39 downto 9 loop
>       if  CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
>        WRT(I-9) <= '0';
>       else
>        WRT(I-9) <= '1';
>       end if;
>      end loop;
>    end process;
>
> end BEHAVIOR;
> --------
> I also get a complaints in Synplify when synthesizing, like so:
>
> Found clock
fsync1.CPUINTERFACE_0.CPUWRTGEN_0.loop37_un19_cpu_addr_inferred_clock with
period 1000ns
>
> Now my question is how can I change my code so that I can eliminate these
warnings, as its not a good design practice.

In general, you should better design synchronous. This means, you system has
a clock signal. So is could be rewritten as

  process(clk)            -- depends only on CLK
   begin
      if clk='1' and clk'event then            -- this is the rising edge of
you clock signal

        for I in 39 downto 9 loop
         if  CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
          WRT(I-9) <= '0';
         else
          WRT(I-9) <= '1';
         end if;
        end loop;
       end if;                                    -- end of clocked process
    end process;

 end BEHAVIOR;

--
MfG
Falk




Article: 39701
Subject: Re: wild teen sex scenes and CPLDs
From: Frank Vorstenbosch <frank@kingswood-consulting.co.uk>
Date: Sat, 16 Feb 2002 16:48:52 +0000
Links: << >>  << T >>  << A >>
Hallo!

usgoxy@yahoo.com wrote:

> ake a look at this great soft porn site !!


I've been looking at this site, and now I'm confused.  What is the 
difference between the MAX3000A series and MAX7000A (or AE) series?
Both seem to come in similar densities, packages and speeds.

Where would one get small quantities (in the UK, preferably) of these
devices?  Some varieties seem to be stocked by Farnell and RS but they
seem to be only obsolete devices (and stupid prices) -- a bit like those
ISA parallel printer interface cards you can buy from their catalogues
at $200 apiece.


Frank

-- 
------------------------------------------------------------------------
Frank A. Vorstenbosch   <SPAM_ACCEPT="NONE">    Phone:  +44-7976-430 569
Wimbledon, London SW19                  frank@kingswood-consulting.co.uk


Article: 39702
Subject: Handel-C, System-C, Formal verification ???
From: Phil Hays <spampostmaster@attbi.com.com>
Date: Sat, 16 Feb 2002 18:20:42 GMT
Links: << >>  << T >>  << A >>

My current employer has an application where I might want to use one of the "C
for hardware" type languages.  Basically, there is a sizable chunk of ANSI-C
code that might need to be put into hardware to improve system performance. 
Before this needs to be started, and it is not clear yet if it truly does need
to be done, I'd like to learn more.  Methods for doing this might might be to
convert this C code into hardware-c (Handel-C or System-C), or to hand convert
the C into VHDL, and then verify the conversion by simulation (read lots of
effort) or to hand convert the C into VHDL and then verify the conversion by
some "formal verification" method.

The first alternative brings up a bunch of issues.  The tools are fairly new: it
seems slightly unlikely to me that "pushing the envelope" type hardware could be
built.  Is this true?  I sat in a Celoxica sales pitch, and the examples given
were running at 40 MHz or so.  Sorry, but that's not impressive: the parts can
easily do 66MHz+ with very little detailed effort, with a high level VHDL (or
Verilog) design and almost push-button flow, and 133Mhz, while it does take more
effort just isn't that hard.  The tools don't appear have features needed to
push the design to higher speeds, such as a schematic viewer to quickly answer
the question, what did my code build into?  I don't know what sort of support in
any of the "hardware-C" tools for physical design, is there any?  The users (me
for example) don't understand the whole process: I can read C and eventually
understand what it's doing, I've written some C code, but I don't have
experience in translating ANSI-C into hardware-C or in writing hardware C.  How
hard is this to learn?  How hard is this to learn to do well?  Meaning how hard
is it to produce close to minimum sized hardware that runs fast?

Then there is the question of the different variations of hardware-C.  Opinions
on which is best?  (Cue in the VHDL vs Verilog flame war part 2)

The second alternative I understand how to do, it is just work, and there is
absolutely nothing wrong with that if it's the best option, yet I'd rather do it
faster and easier, or faster and fewer bugs...

The third alternative is formal verification.  I have no experience in such
tools, so does anyone have experience, opinions (or both) on the question of
would this help to produce FPGA hardware that matches the original C?


-- 
Phil Hays

Article: 39703
Subject: Speaking of ORCA...
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 16 Feb 2002 19:26:12 -0000
Links: << >>  << T >>  << A >>
Are they still in business?  Who owns them now?

Are they worth considering for new designs?
If so, why don't they get mentioned here more often?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 39704
Subject: Re: FPGA choices and questions
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 16 Feb 2002 19:48:05 -0000
Links: << >>  << T >>  << A >>
>- I have worked with Texas' DSPs boards before. In that, I load
>programs and debug the application with JTAG interface. I understand
>Virtex devices have the same interface. Is software provided by these
>people similar in this way to DSP's software? Is it possible to write
>a program and inmediately load it in FPGA?

In general, using JTAG on FPGAs is very similar to using it
on DSPs.  The key idea is that you don't have to take your
code over to a ROM blaster and swap in a fresh ROM on your
debugging setup.

But you might not use the term "inmediately" if you have
a complicated FPGA design.  It can take hours to "compile"
your program.  Hand tweaking to help the placer/router is
often required.  Usually you can make minor changes without
having to rework/repeat much of that.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 39705
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 16 Feb 2002 22:19:28 +0000
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> Rick Filipkiewicz <rick@algor.co.uk> wrote:
> > Is it possible to use 4.1i speed files when building with 3.3i ? e.g. for an
> > XCV600E I could just copy over the %XILINX%/virtexe/data/v600e.spd from my 4.1i
> > installation to my 3.3i one ?
>
> No, you'll get error messages about the file format version numbers
> being different. (I tried it.)
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Oh b******s! So its back to the ``exposed butt'' position or use 4.1i.



Article: 39706
Subject: Re: FPGA choices and questions
From: ikauranen@netscape.net (ikauranen)
Date: 16 Feb 2002 15:38:30 -0800
Links: << >>  << T >>  << A >>
"FPGA/IC" <wagain@21cn.com> wrote:
> when I use verilog for the entry design, do I need to write the tester code
> respectively for pre-simulation and postlayout simulation? That means two
> different test codes?

No. The same code. Please refer to 
http://www.model.com/resources/appnotes/fpga_flow.asp

--IK

Article: 39707
Subject: Re: Handel-C, System-C, Formal verification ???
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 17 Feb 2002 00:10:22 GMT
Links: << >>  << T >>  << A >>
Phil Hays <spampostmaster@attbi.com.com> writes:

>My current employer has an application where I might want to use one of the "C
>for hardware" type languages.  Basically, there is a sizable chunk of ANSI-C
>code that might need to be put into hardware to improve system performance. 
>Before this needs to be started, and it is not clear yet if it truly does need
>to be done, I'd like to learn more.  Methods for doing this might might be to
>convert this C code into hardware-c (Handel-C or System-C), or to hand convert
>the C into VHDL, and then verify the conversion by simulation (read lots of
>effort) or to hand convert the C into VHDL and then verify the conversion by
>some "formal verification" method.

Personally, I don't believe in the C to hardware idea.  All the algorithms
that I would think of doing it for are coded completely different in
hardware than software.  For example iterative or recursive algorithms 
in software might be systolic arrays in hardware.  

If you are going to completely rewrite the algorithm, it doesn't seem
that it will help your problem.  

If you could give a basic idea of what kind of algorithm it is,
that would help.  

-- glen


Article: 39708
Subject: Re: Handel-C, System-C, Formal verification ???
From: Kelly Hall <hall@priest.com>
Date: Sun, 17 Feb 2002 00:14:18 GMT
Links: << >>  << T >>  << A >>
Phil Hays <spampostmaster@attbi.com.com> writes:

> Methods for doing this might might be to convert this C code into
> hardware-c (Handel-C or System-C), or to hand convert the C into
> VHDL, and then verify the conversion by simulation (read lots of
> effort) or to hand convert the C into VHDL and then verify the
> conversion by some "formal verification" method.

You might want to review the offering from Proceler
(www.proceler.com).  They advertise a system that automatically
partitions your C code into hardware and software, targetting the
hardware to an FPGA and the software to a CPU.

Kelly

Article: 39709
Subject: Re: Speaking of ORCA...
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Sat, 16 Feb 2002 21:23:11 -0600
Links: << >>  << T >>  << A >>
I heard that Agere (a spin off from Lucent) sold their still profitable
FPGA business to Lattice recently.
Agere inherited a lot of debt from Lucent, so I guess they figured
selling their FPGA business will help pay some of their debt.
However, I also read an EE Times article a few months ago that Lattice
has its own internal FPGA development program, which sounds like they
inherited from Vantis.
Before Lattice bought Vantis, Vantis had an FPGA called VF1, so I
presumably think this internal project is a follow-on of VF1.



Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)




Hal Murray wrote:
> 
> Are they still in business?  Who owns them now?
> 
> Are they worth considering for new designs?
> If so, why don't they get mentioned here more often?
> 
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

Article: 39710
Subject: Re: FPGA choices and questions
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Sat, 16 Feb 2002 21:41:29 -0600
Links: << >>  << T >>  << A >>
I am not paid to say this, but if you want to get started with FPGAs, I
recommend that you start with Xilinx FPGAs.
The reason I recommend Xilinx over Altera or other vendors is that
Xilinx's free ISE WebPACK comes with a decent synthesis tool (XST) and a
starter version of ModelSim XE.
The starter version of ModelSim XE has a 500 lines code limitation, but
fortunately, the simulation only gets slow after 500 lines, and you can
still simulate your design beyond 500 lines.
For development boards, Insight Electronics has some development boards,
but other vendors like Avnet or NuHorizon also have some development
boards.

http://208.129.228.206/solutions/kits/xilinx/


The reason I will not recommend Altera devices will be that Altera
doesn't offer a free version of ModelSim like Xilinx, their tools
(MAX+PLUS II-BASELINE or Quartus II 1.1 Web Edition) are buggy compared
to Xilinx ISE WebPACK, and I haven't seen many low cost development
boards with Altera FPGAs (Low cost means < $200.).
I am sure Altera fans of this newsgroup won't be happy of what I wrote,
but that is my opinion.




Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)




Dani Guzman wrote:
> 
> Hi,
> I have no experience using FPGA. I have to choose some family, from
> Altera or Xilinx. I suppose both should have a family that suits my
> needs, but I need some advice considering what I have to do:
> 
> - I have to do a PCB w/FPGA logic. Main requirement is to include
> in-system reconfiguration, I mean, to change code loaded in FPGA
> without desoldering the device. I have learned that a configuration
> PROM is in charge of this, or even a JTAG interface. Is it correct? Do
> I need a CPU to control FPGA as well?
> 
> - I have worked with Texas' DSPs boards before. In that, I load
> programs and debug the application with JTAG interface. I understand
> Virtex devices have the same interface. Is software provided by these
> people similar in this way to DSP's software? Is it possible to write
> a program and inmediately load it in FPGA?
> 
> - Which family should be best choice considering I have to design a
> PCB w/reconfiguration capability?
> 
> - I'm thinking in buying a demo board to achieve experience w/FPGA
> programming, which one is convenient, considering I have to implement
> a PCB ? Is it a good choice to think in a demo board or it's better to
> study and design the PCB right now?
> 
> Thanks in advance.
> 
> -Dani-

Article: 39711
Subject: Re: Handel-C, System-C, Formal verification ???
From: "z.karim" <z.karim@attbi.com>
Date: Sun, 17 Feb 2002 04:44:19 GMT
Links: << >>  << T >>  << A >>
Formal verification is generally used to verify gate level netlists
are equivalent and is used when designing ASICs.  I think of
formal verification at the HDL level as doing simulation equivalence
checks.  If you are converting an algorithm written for a CPU to a
hardware algorithm, I would look at the size of the design as the
determining factor.  As for all projects, budget, schedule, manpower
all are taken into consideration.

If the algorithm is large and you can afford to purchase a
software package like Handel-C, I would go for it.  It is a cost effective
way of getting what you need.  It does have the capability of spitting
out VHDL so you can simulate your result; don't expect to be able
decipher what hardware was generated by looking at the VHDL code.
The one nice thing we noticed using the Handel-C was that we
could do a heck of a lot more architecture modifications in the same
amount of time it would have taken in VHDL.  Also, we were able to
convert the ANSI-C to Handel-C in 1/30th the time it took to go to VHDL.

As far as determining what speed at which the design runs,
you have to place and route the design immediately to get the speed at
which it will run.  Handel-C has all the constructs to allow you to dictate
the architecture; it just takes a couple days to get the feel for how it
generates hardware.  I have used it and have been happy with the
results: easily passing 100MHz in Spartan II and 200MHz in Virtex II.

We have used SystemC before also, but just for modeling and not
for hardware generation.  It was simple to use also, but we didn't want
to buy the synthesizers from Adelante or Synopsys.  Again though, it
was a heck of a lot easier converting the C algorithms to usable
code rather than converting it to VHDL.

good luck

"Phil Hays" <spampostmaster@attbi.com.com> wrote in message
news:3C6EA440.ED3E96D3@attbi.com.com...
>
> My current employer has an application where I might want to use one of
the "C
> for hardware" type languages.  Basically, there is a sizable chunk of
ANSI-C
> code that might need to be put into hardware to improve system
performance.
> Before this needs to be started, and it is not clear yet if it truly does
need
> to be done, I'd like to learn more.  Methods for doing this might might be
to
> convert this C code into hardware-c (Handel-C or System-C), or to hand
convert
> the C into VHDL, and then verify the conversion by simulation (read lots
of
> effort) or to hand convert the C into VHDL and then verify the conversion
by
> some "formal verification" method.
>
> The first alternative brings up a bunch of issues.  The tools are fairly
new: it
> seems slightly unlikely to me that "pushing the envelope" type hardware
could be
> built.  Is this true?  I sat in a Celoxica sales pitch, and the examples
given
> were running at 40 MHz or so.  Sorry, but that's not impressive: the parts
can
> easily do 66MHz+ with very little detailed effort, with a high level VHDL
(or
> Verilog) design and almost push-button flow, and 133Mhz, while it does
take more
> effort just isn't that hard.  The tools don't appear have features needed
to
> push the design to higher speeds, such as a schematic viewer to quickly
answer
> the question, what did my code build into?  I don't know what sort of
support in
> any of the "hardware-C" tools for physical design, is there any?  The
users (me
> for example) don't understand the whole process: I can read C and
eventually
> understand what it's doing, I've written some C code, but I don't have
> experience in translating ANSI-C into hardware-C or in writing hardware C.
How
> hard is this to learn?  How hard is this to learn to do well?  Meaning how
hard
> is it to produce close to minimum sized hardware that runs fast?
>
> Then there is the question of the different variations of hardware-C.
Opinions
> on which is best?  (Cue in the VHDL vs Verilog flame war part 2)
>
> The second alternative I understand how to do, it is just work, and there
is
> absolutely nothing wrong with that if it's the best option, yet I'd rather
do it
> faster and easier, or faster and fewer bugs...
>
> The third alternative is formal verification.  I have no experience in
such
> tools, so does anyone have experience, opinions (or both) on the question
of
> would this help to produce FPGA hardware that matches the original C?
>
>
> --
> Phil Hays



Article: 39712
Subject: Re: Trivial (?) problem with Xilinx - System Generator (tristate port pin)?
From: asicbaba@rediffmail.com (sharat babu)
Date: 16 Feb 2002 21:02:16 -0800
Links: << >>  << T >>  << A >>
hello Mr.Bernhard Holzmayer

the solution for your problem is declare the port as 
std_logic__vectorthen you can directly asssign it as "zzzzzz".

sharat babu

"Bernhard Holzmayer" <Holzmayer.Bernhard@foerstergroup.de> wrote in message news:<a4fu7f$1f2fr7$1@ID-131763.news.dfncis.de>...
> Hello.
> 
> While doing my first steps with Xilinx System Generator (V2.1), I
> hit a
> (maybe trivial) problem:
> 
> I have a port / pin, which is both, input and output.
> It must be written depending on a flag's state, being high-Z
> otherwise.
> In VHDL it would be something like the following:
> ...
> ...process(flag, data)
> begin
>   if (flag = '1') then
>     port <= "ZZZZZZZZ";
>   else
>     port <= data;
>   end if;
> end process;
> 
> Help me: how can I set this port into the high-Z state using SysGen?
> Does anyone know this ???
> 
> Bernhard

Article: 39713
Subject: Re: Spartan-II becomes Vertex.
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 00:43:04 -0500
Links: << >>  << T >>  << A >>
Marc,

I hate to sound dumb, but that does not make any sense to me. If Xilinx
claims that there may be differences in the bit streams required to
program two families, then why would they not give them distinct JTAG
IDs? I am especially surprised that the XCVe and the XC2Se families use
the same IDs since they DEFINITLY have different bit streams due to the
different block memory counts. Isn't the point of having IDs to be able
to tell the different parts from one another??? 

Rick Collins


Marc Baker wrote:
> 
> There are variable amounts of don't care bits in the bitstream that account for
> slight variations in counting the total bitstream length.  The Spartan-II data
> sheet has been updated a couple times since the 3/3/2000 version, with the
> current one from March 2001 indicating the same bitstream length as the XCV100:
> 781,216, which is the current bitstream length created by the Xilinx development
> system.
> 
> Bitstreams created for one family may work in another, but Xilinx does not test
> the parts that way and cannot guarantee that they will work.  We strongly
> recommend creating the bitstream for the target device.
> 
> The Spartan-II and Virtex families share the same JTAG family ID code, as do the
> Spartan-IIE and Virtex-E families.  The software ignores any variations in
> revision, so it cannot differentiate between Virtex and Spartan devices of the
> same CLB matrix.
> 
> Kevin Brace wrote:
> 
> > That is not true.
> > According to Virtex datasheet dated 1/28/2000, the configuration bit
> > length for XCV100 is 781,216.
> > However, according to Spartan-II datasheet dated 3/3/2000, the
> > configuration bit length for XC2S100 is 781,248.
> >
> > Kevin Brace (Don't respond to me directly, respond within the
> > newsgroup.)
> >
> > Ray Andraka wrote:
> > >
> > > The bitstreams for virtex and spartanII for same size device are the same.
> > >
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin Franklin, 1759
> 
> --
> Marc Baker
> Xilinx Applications
> (408) 879-5375

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39714
Subject: Re: Altera's new family Stratix
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 01:20:19 -0500
Links: << >>  << T >>  << A >>
The way you made your comment did not bother me at all. I assume you are
using your sense of humor with comments like these. 

But I don't see how System Ace helps me at all. I looked at Ace a long
time ago when it was first announced and realized that it was a way for
designers of large systems to add huge configuration memories to their
designs. I not trying to find a way to facilitate the selective
downloading of hundreds of different designs. I am trying to find a way
to eliminate the need for hundreds (or even thousands if we are very
successful) of different designs. 

I know I have posted about this before, and the answer has always been,
"We don't currently have a partial reconfiguration option, but have you
looked at JBITS?" JBITS seems to be a good way to punt the problem off
to the customers and leaves a lot to be desired in the way of design
verification.  But on the off chance that there has been some progress
made in the last three months, I will explain in detail again. 

I am designing a very small DSP board which will use even smaller
daughter modules to provide various types of IO. On the first iteration
of this design we had two daughter module sites and used two FPGAs (one
each) to provide the interface functionality to a common board bus to
memory. This allowed us to check the ID of each daughter module at reset
and load the FPGA with the design (bit stream) corresponding to the
daughter module. Perfect! 

Now we are using four daughter modules per DSP board in the same amount
of space. But we just don't have the space to use four FPGAs. In fact,
we have less space due to the increased memory size and the relocation
of a few parts that were in the locations of the two new daughter
modules. So we have combined the former three FPGAs into one and added
two more interfaces. This is going to make the number of FPGA bit
streams jump to enormous numbers if we allow any module to be plugged
into any site. 

Example: if we have just 3 different modules (which is our goal by the
end of the year) we will need to support up to 3**4 = 81 different
designs. Of course we can pare this down enormously by requiring only to
support fixed locations for each combination (ie AABB and not ABAB or
BABA...). But that still makes for 15 combinations. When we add three
more new daughter module types next year, we will have an even larger
number of designs to support. 

So the problem could be dealt with quite easily if we could use a
modular design where the FGPA could be thought of as having blocks for
each design and loading the corresponding interface into its own block.
Even if we had to design four different designs for each module type,
that would be 4*N rather than some geometric progression. 

As it is we expect that part of selling a board set to a customer will
include the possibility of having to do a P&R of the modules along with
a full qualification of that P&R including temperature testing. This
will not be cheap and will significantly affect our business model. 

Any chance this can change your business model and find a way to support
partial reconfiguration? This is not reconfiguration on the fly. Perhaps
a better term would be modular design and configuration? 



Austin Lesea wrote:
> 
> Rick,
> 
> Good points.
> 
> Doesn't System Ace solve some of your problems?  It must be good (as Altera has
> copied it, too!)
> 
> Austin
> 
> rickman wrote:
> 
> > Austin Lesea wrote:
> > >
> > > Rick,
> > >
> > > Seriously, we didn't invent them, we just placed them in a fabric, and
> > > supported them in the FPGA.  And as it turns out, you can get a patent for
> > > just that kind of assembly of non patentable items arranged in a new or
> > > novel way together to perform an improved function.  Altera, and we have
> > > lots of patents, and now that the legal hassling is over, we can apply all
> > > of our efforts to supplying our customers with the best possible products.
> > >
> > > I appeciate all of the comments, and it is absolutely critical that Xilinx
> > > listen to customers, because that is what we did with Virtex, and Virtex II
> > > (and are still doing).
> > >
> > > No time to fiddle around, I have the next two product generations to help
> > > design, document, and support.
> > >
> > > Austin
> >
> > Be careful what you ask for, because you might just get it. You asked
> > for my input, so here it is.
> >
> > I am not a high speed data/telecom vendor and I don't do gigabit IO. I
> > use FPGAs for general purpose system "glue" and data movement
> > operations. There is sometimes a little DSP thrown in for good measure.
> >
> > As it turns out, the single biggest limitation in FPGAs that I am facing
> > is software. I need to be able to design a modular set of interfaces
> > that can be loaded into the chip in different combinations at run time.
> > There is no PC and no platform to run tools such as JBITS. There is a
> > small micro and a sizable hunk of Flash memory. If I could store a dozen
> > interchangable pieces that can be loaded into an FPGA in different
> > combinations, it would save me from having to design perhaps as many as
> > hundreds of different complete designs as distinct bit files.
> >
> > Any progress in this area? Not much point in making the chips bigger and
> > bigger if your software doesn't keep up.
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39715
Subject: Re: Speaking of ORCA...
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 01:38:02 -0500
Links: << >>  << T >>  << A >>
Lucent has always considered the FPGA business as a tool to get comms
oriented ASIC business. If you have ever designed with their schematic
entry you would have seen the common elements they used to facilitate
this. This is also evident in the devices they have brought out over the
last two years. They have all been larger parts many with dedicated
components for comms interfaces. 

The bottom line seems to have been, if you are not a large comms vendor,
they are not going to make an effort to get your business. I know that
Altera and Xilinx also push very heavily to get business from the comms
market, but they don't exclude the rest of the FPGA market in the
process. 

We will see if Lattice does anything to improve or change this picture.
I expect they will. 

BTW, the Lucent parts were originally made as spinoffs from the Xilinx
3K (actually identical) and 4K (the original ORCA parts, ATT1, IIRC).
They continue to use the same basic architecture as Xilinx with LUTs
usable as RAMs and many other features copied (licensed) from Xilinx.
They even were the first in a few areas such as more than 2 LUTs and FFs
in a CLB and a more structured routing pattern. 

I believe the current generation is the OR4C family with the OR2C/T and
the OR3C/T still being offered for new designs. My last DSP board used
the OR2T04 (very inexpensive) and an OR3T30. But the tools may be a
problem. They will give you the back end tools, but you are on your own
for the front end tools, even schematic capture, I believe. But Lattice
may change that as well. 



Hal Murray wrote:
> 
> Are they still in business?  Who owns them now?
> 
> Are they worth considering for new designs?
> If so, why don't they get mentioned here more often?
> 
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39716
Subject: Re: FPGA choices and questions
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 01:46:03 -0500
Links: << >>  << T >>  << A >>
FPGA/IC wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message
> news:3C6D5519.BD2F7E28@yahoo.com...
> > Dani Guzman wrote:
> > >
> > > Hi,
> > > I have no experience using FPGA. I have to choose some family, from
> > > Altera or Xilinx. I suppose both should have a family that suits my
> > > needs, but I need some advice considering what I have to do:
> > >
> > > - I have to do a PCB w/FPGA logic. Main requirement is to include
> > > in-system reconfiguration, I mean, to change code loaded in FPGA
> > > without desoldering the device. I have learned that a configuration
> > > PROM is in charge of this, or even a JTAG interface. Is it correct? Do
> > > I need a CPU to control FPGA as well?
> >
> > First, let me say that in terms of configuration, there is very little
> > real difference between the two vendors you mention. You can use a
> > (EE)PROM to configure the FPGA or you can use a micro. But JTAG is not a
> > viable option for normal operation of your board. JTAG is used during
> > debug to save the trouble of downloading designs to the (EE)PROM or to
> > what ever storage your micro is using.
> 
> Did you mean that Xilinx's FPGA need a PROM for reconfiguration, while
> Atera's dont need, it is directly download in the FPGA? how about Actel's?
> 
> thanks

No, I thought I made that clear when I said that "First, let me say that
in terms of configuration, there is very little real difference between
the two vendors you mention."

Both vendors support several options including loading from a serial
(EE)PROM, loading from a parallel (EE)PROM (on mostly older chips),
loading from a micro either serial or parallel and finally loading via
JTAG. My point about JTAG is that this needs a PC to run the software.
It may be possible to drive a JTAG port from a micro, but you will have
to write your own software, if I understand it correctly. 

So normally, JTAG is only usable while debugging a system when you have
a PC around. In an embedded system, you will need to load via a micro or
a PROM of some form. 

If I am familiar with Actel's parts, they are fuse programmable and are
only programmed once. To change their programming, you need a soldering
iron and a new part. This is a special subset of ISP that most vendors
don't offer  ;)

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39717
Subject: Re: FPGA choices and questions
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 01:51:37 -0500
Links: << >>  << T >>  << A >>
Ulf Samuelsson wrote:
> 
> > I have no experience using FPGA. I have to choose some family, from
> > Altera or Xilinx. I suppose both should have a family that suits my
> > needs, but I need some advice considering what I have to do:
> >
> > - I have to do a PCB w/FPGA logic. Main requirement is to include
> > in-system reconfiguration, I mean, to change code loaded in FPGA
> > without desoldering the device. I have learned that a configuration
> > PROM is in charge of this, or even a JTAG interface. Is it correct? Do
> > I need a CPU to control FPGA as well?
> >
> Hi Dani, You can check out the Atmel AT17 family of In System Programmable
> Configurators.
> Atmel has an interesting chip, the FPSLIC which combines a processor and
> a 5k/10k/40k gate FPGA
> There will in a couple of months be a JTAG version, and hopefully it
> should be possible to download the FPGA AND CPU over JTAG using the standard
> AVR controller JTAG-ICE.

Does that mean that the JTAG-ICE will support debug with the device in a
scan chain? I am interested in using the AVR ATmega64 or 128 in a design
with boundary scan and a couple of FPGAs. But I am being told even
though the ATmega chips support boundary scan and JTAG debug, the
software doesn't support JTAG debug with the chip in a scan chain!!!
Boundary scan without a scan chain does not make a lot of sense. 

It would make some sense that when they change the software to handle
the two devices in one chip, they might fix the software to handle a
chip in a scan chain as well... 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39718
Subject: Re: FPGA choices and questions
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 02:02:25 -0500
Links: << >>  << T >>  << A >>
There are a lot of different opinions about whether you need to run post
layout simulation or not. There are two main schools of thought. One
says that there can be subtle errors introduced that a simulation MIGHT
be able to catch. The other says that the errors are primarily timing
errors and should be caught in a static timing analysis which all back
end tools (Place and Route) support. 

I am from the static timing analysis school. If you keep your design
synchronous and don't use any "tricks", you will find that static timing
analysis will check your design 100%, provided that you specify your
timing constraints correctly. Correct timing constraints are the main
fly in the ointment for this process. The vendors have provided good
tools for applying your timing constraints, but have come up with
virtually NO tools to verify that your timing constraints are correct or
to even help you verify how your timing constraints are being
interpreted. 

The post layout simulation school applies the same simulation to the
design after P&R. This can find timing and possibly other errors (but I
don't know what they would be in a synchronous design). But there is no
guaranty at all that your simulation will check very much of the design
(this is called coverage). The timing analysis in a post route design is
not even very good since it has to work with a single set of timing
numbers (normally the slowest). Many timing problems that would not be
caught with static timing analysis would require either the fastest or a
mix of fastest and slowest timing data. So post route simulation has a
poor chance of finding anything but gross timing errors. They also flag
a lot of problems that are not problems having to do with metastability
and startup conditions. 


FPGA/IC wrote:
> when I use verilog for the entry design, do I need to write the tester code
> respectively for pre-simulation and postlayout simulation? That means two
> different test codes?
> 
> thanks.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39719
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 02:14:41 -0500
Links: << >>  << T >>  << A >>
Ray, 

I would like to draw on your experience if I can. I am looking at doing
a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an
idea of what speed grade I will need. Turns out that the DSP chip will
only support up to 100 MHz on the memory bus so I won't have to push the
speed much. Will this be easy on the slowest speed grade which seems to
be a -6? Since there only seem to be two speed grades at this time, I
don't expect to see that much difference (and no industrial in the -7).
I can't tell from the data sheet as it does not have data for the -7 yet
(even though I can buy the parts). 

From your experience will a 100 MHz SDRAM interface be easy in a
XC2S200E-6 ? 



Ray Andraka wrote:
> 
> Venu wrote:
> 
> > Hi,
> >
> >  I am planning to implement a SDRAM Controller to run at 133MHz and I am
> >  targetting Virtex-II device. It would be of great help to me if people
> >  can let me know their experiences in this regard . More specifically I
> >  am looking for some inputs on the following:
> >
> >  a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a Virtex-II
> >     device
> 
> Should be very easy to hit 133 Hz in VII.  Of course, it depends on your design
> expertise, which is why I said "should" not "is".
> 
> >
> >  b) What is the Max frequency that Xilinx claims in their application-notes
> >     for SDRAM Controller using Virtex-II
> >
> > Thanks
> > Venu
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39720
Subject: Re: APEX-II vs VIRTEX-II
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 02:17:15 -0500
Links: << >>  << T >>  << A >>
I see that this question has met with no reply after two weeks. I guess
that is the answer...



Russell Shaw wrote:
> 
> Guy Schlacter wrote:
> >
> > QuartusII v2.0 just released Friday and has been producing very good
> > results for both this new family and ApexII.
> 
> When is Quartus web edition going to include Acex 1k devices?
> 
> > As far as GATE COUNTING, every vendor and family uses differnet
> > nomenclature.  For the user, you are best off descregarding gate counts
> > and comparing
> > 4input LUTs
> > Available Memory counts
> > Other dedicated Resources Multipliers etc.
> >
> > Best of Luck,
> > Guy Schlacter
> > Altera Corp.
> >
> > "Steve Holroyd" <spholroyd@iee.org> wrote in message
> > news:b623f4cf.0201111039.2a16155@posting.google.com...
> >
> > > I am currently task of recommending the largest, fastest and most
> > > memory FPGA that's readily available the first half of this year for a
> > > FPGA Array Card.
> > >
> > > The choices have been narrowed down to two families Altera's APEX-II
> > > (EP2A70) and XILINX Virtex-II (XC2V6000).
> > >
> > > Which can operate at the highest speed?
> > >
> > > Steve
> >
> > --
> > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
> 
> --
>    ___                                           ___
>   /  /\                                         /  /\
>  /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
> /__/   / Victoria, Australia, Down-Under      /__/\/\/
> \  \  /                                       \  \/\/
>  \__\/                                         \__\/

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39721
Subject: Re: FPGA choices and questions
From: ZhengLin <zdzlin@163.com>
Date: Sat, 16 Feb 2002 23:31:42 -0800
Links: << >>  << T >>  << A >>
Actel's FPGA can be programed only once, or it's prom can only be programed only once, but Xilinx's new part, such as spartan 2, can use a flash to program the fpga, if you don't have much experience in fpga design, I support you'd better not use actel's device for your first design!

Article: 39722
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sun, 17 Feb 2002 12:54:56 -0000
Links: << >>  << T >>  << A >>
rickman wrote

> Ray,
>
> I would like to draw on your experience if I can. I am looking at doing
> a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an
> idea of what speed grade I will need. Turns out that the DSP chip will
> only support up to 100 MHz on the memory bus so I won't have to push the
> speed much. Will this be easy on the slowest speed grade which seems to
> be a -6? Since there only seem to be two speed grades at this time, I
> don't expect to see that much difference (and no industrial in the -7).
> I can't tell from the data sheet as it does not have data for the -7 yet
> (even though I can buy the parts).
>
> From your experience will a 100 MHz SDRAM interface be easy in a
> XC2S200E-6 ?

Depends on how much pipelining is allowed.

It would be easy for Ray :)




Article: 39723
(removed)


Article: 39724
Subject: Re: FPGA choices and questions
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 17 Feb 2002 15:46:17 GMT
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3C6F5581.B301EA21@yahoo.com...
> I am from the static timing analysis school. If you keep your design
> synchronous and don't use any "tricks", you will find that static timing
> analysis will check your design 100%, provided that you specify your
> timing constraints correctly. Correct timing constraints are the main
> fly in the ointment for this process. The vendors have provided good

I agree wholeheartedly with Rick's approach of using a well developed set of
constraints and static timing analysis to verify that there are no timing
issues.  A synchronous design approach allows this methodology to work
properly.
In my experience with FPGAs, I have only once had to do post layout
simulation, and it was to verify that what the synthesizer and PAR tool
generated was the same as the intention of the source code.  It turned out
that a tool vendor had to do a very quick fix!  Since then I have always
been leery about the end result, but I have never been disappointed.  They
must test these tools to the nth degree in order to verify that the end
result is correct.
My reasons for not doing post layout simulation are twofold.  First, it
takes more time.  Second, it promotes synchronous design, which also solves
other problems.
Everyone have a great day!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA





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