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 73875

Article: 73875
Subject: Re: FPGAs as a PCI (target) controller
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 30 Sep 2004 09:43:24 -0700
Links: << >>  << T >>  << A >>

Hi,

> You'd have to worry about bus loading, though.

That is correct, and having two device pins touch
one signal is a compliance violation.  If you are
careful what you do, though, it will work.

Eric

Article: 73876
Subject: Re: FPGAs as a PCI (target) controller
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 30 Sep 2004 09:46:30 -0700
Links: << >>  << T >>  << A >>
Sorry for the redundant post.  I tried to cancel
my first one, after reading the subsequent response
but apparently did not succeed!  And now, to make
matters worse, I've posted this third time...

Eric

Eric Crabill wrote:
> 
> Hi,
> 
> > You'd have to worry about bus loading, though.
> 
> That is correct, and having two device pins touch
> one signal is a compliance violation.  If you are
> careful what you do, though, it will work.
> 
> Eric

Article: 73877
Subject: Re: Spartan-3 VCCIO ramp up time
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 30 Sep 2004 17:02:55 GMT
Links: << >>  << T >>  << A >>
Bulk capacitance on the regulator output will slow the ramp rate for either
switching regulators or current-limited linear regulators (that turn on from
a fixed voltage rather than ramping up with its input voltage).

If you're trying to enable a regulator that doesn't include a current limit
from a supply that's already steady, bulk capacitance won't provide the
predictable ramp rate.


"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message
news:415c3101$0$22074$ba620e4c@news.skynet.be...
> Hi
>
> Austin Lesea wrote:
>
> > Just ramp on slower than that indicated in the data sheet, and
> > everything is fine.
>
> May sound like a stupid question to experts but I'm more a sw/fw guy :
>
> How do you make it ramp slower ? Is there any obvious trick ?
>
> Looking at my regulator datasheet, doesn't even specify ramp rate ...
>
>
>
> Sylvain



Article: 73878
Subject: Re: Spartan-3 VCCIO ramp up time
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Sep 2004 10:10:19 -0700
Links: << >>  << T >>  << A >>
Sylvain,

Ramp on time is deterimined by the size of the filter capacitor, and the 
current capability of the power source.

So, for example, if the supply can't output more than 10 amperes, and 
you have 1,000 uF of filtering, then using I=CdV/dt, and solve for dt,

dt = CdV/I

or .001F * 3.3V/10A = 330 us.

Now you would need a LOT of capacitance to slow this down to 3.3 mS, 
basically 10,000 uF instead of 1,000 uF.

If the supply was current limited at 1 ampere, then 1,000 uF would be 
just fine.  Typically we suggest at least 4 470uF for the core, and a 
similar number for the Vcco, so that would closer to 2,000 uF, and life 
would be good all around unless the current output is so great that the 
voltage rises faster than the spec sheet allows.

Austin

Sylvain Munaut wrote:
> Hi
> 
> Austin Lesea wrote:
> 
>> Just ramp on slower than that indicated in the data sheet, and 
>> everything is fine.
> 
> 
> May sound like a stupid question to experts but I'm more a sw/fw guy :
> 
> How do you make it ramp slower ? Is there any obvious trick ?
> 
> Looking at my regulator datasheet, doesn't even specify ramp rate ...
> 
> 
> 
> Sylvain

Article: 73879
Subject: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: "CraigR" <craigra@pacbell.net>
Date: Thu, 30 Sep 2004 17:16:29 GMT
Links: << >>  << T >>  << A >>
In reviewing a specific requirement, my design team is debating the benefits 
of in-field hardware upgradability.  In the communications space, wondering 
if most system developers require and use ICR in production when 
implementing FPGA (instead of ASIC)?

Craig 



Article: 73880
Subject: Re: EDK FSL Example
From: "Roger Planger" <ernte23@gmx.at>
Date: Thu, 30 Sep 2004 18:20:07 +0100
Links: << >>  << T >>  << A >>
Unfortunately I didnt get the files yet, therefore I ask again, if it would 
be possible that somebody sends me the
Files

Thanks a lot

Cheers
R 



Article: 73881
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: nkavv@skiathos.physics.auth.gr (Uncle Noah)
Date: 30 Sep 2004 10:23:34 -0700
Links: << >>  << T >>  << A >>
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0409290048.63a5a067@posting.google.com>...
> "Antti Lukats" <antti@case2000.com> wrote in message news:<cjbrus$csk$02$1@news.t-online.com>...
> > Hi All
> > 
> > finally today the project maintainer at opencores uploaded the verilog
> > design files for MicroBlaze compliant IP-Core. Download is available at
> > opencores.com - as project aeMB !!
> 
> How long before Xilinx try to get them to remove it do we reckon?
> 
> Cheers,
> Jon

If Xilinx can establish a case against aeste (the developer of aeMB is
working for that company) it will be removed. The question is how much
information he had in his possession so that he produced  a
(reportedly) successful MB implementation.

If he didn't infringe any of Xilinx hardware patents, he should be OK.
BTW is the MicroBlaze instruction set patented??? If it is, it is very
sad, this can be prohibit you from e.g. implementing a GPL'ed
simulator???

Regards

Nikolaos Kavvadias

Article: 73882
Subject: FPGA vs ASIC area
From: totallyadmin <totallyadmin.1deq4n@info@totallychips.com>
Date: Thu, 30 Sep 2004 12:35:07 -0500
Links: << >>  << T >>  << A >>

I was just wondering *roughly* how much area is required for a design
targetted to an fpga in comparsion to a standard cell asic? I'm really
looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area
requirements? (I undersatand its heavily dependant on the particular
design)


-- 
totallyadminwww.totallychips.com  - VHDL, Verilog &amp; General Hardware Design discussion Forum


Article: 73883
Subject: Re: Looking for a Design for a Small FPGA Board
From: daragoth@kuririnmail.com (Daragoth)
Date: 30 Sep 2004 10:48:00 -0700
Links: << >>  << T >>  << A >>
news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0409161122.4470a33f@posting.google.com>...
> That's what I really love about this newsgroup, people recommeding
> products of their direct competitors.
> Kudos to you, Tony!
> 
> I designed the Trenz board. It is layouted in a way that you can cut
> it in stripes without interrupting the power supply. For a dongle
> product.
> At 42mm x 30mm x 3.5mm it will give you 60 FPGA I/O plus configuration
> and power supply, at 42mm x 20mm x 3.5mm you will have to solder every
> IO to the board yourself. Are you sure that you can not squeeze it in
> with these additional 2mm?
> 
> You can cut away these 2mm but it will interrupt the main power
> supply, you could fix that with a wire, but this will result in a
> really ugly looking board afterwards.
> 
> BTW: Can you tell us what it is that you want to build the board into?
> 
> Also, does anybody know about a source for generic usb dongle cases?
> Our quantities are not large enough to have a custom case molded.
> 
> Kolja Sulimma

This sounds like it really might work... the only concern I have is
the height of 20 mm.  I noticed there was a pushbutton on the board,
is it this that's causing the height.  If so, would it be possible to
remove it easily?  Thanks for your help.

-Darien

Article: 73884
Subject: Re: Spartan-3 VCCIO ramp up time
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 30 Sep 2004 17:51:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com> wrote:
: Hi

: Austin Lesea wrote:

: > Just ramp on slower than that indicated in the data sheet, and 
: > everything is fine.

: May sound like a stupid question to experts but I'm more a sw/fw guy :

: How do you make it ramp slower ? Is there any obvious trick ?

: Looking at my regulator datasheet, doesn't even specify ramp rate ...

Go to the Website of Regulator suppliers, like National Semiconductors or
TI. They have application notes for FPGA supplies. E.g. TI has a Family of
fast regulators. To limit the ramp up, they use a MOSFET. Look e.g at
http://www-s.ti.com/sc/techlit/slva175.pdf

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 73885
Subject: Re: FPGA vs ASIC area
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 30 Sep 2004 17:56:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
totallyadmin <totallyadmin.1deq4n@info@totallychips.com> wrote:

: I was just wondering *roughly* how much area is required for a design
: targetted to an fpga in comparsion to a standard cell asic? I'm really
: looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area
: requirements? (I undersatand its heavily dependant on the particular
: design)

And on technology...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 73886
Subject: Xilinx SRL16 example
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 30 Sep 2004 10:58:44 -0700
Links: << >>  << T >>  << A >>

Works now thanks. This code initiates the SRL16 with some sort of pattern,
then loops it around continuously in a 10 bit cycle, and outputs to a pad
where it can be seen with a scope.  Not sure what the translate on/off or
generic stuff is all about.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity srltest is
 port(
  clk : in std_ulogic;
  q   : out std_ulogic );
end srltest;

architecture Behavioral of srltest is

 component SRL16
 -- synthesis translate_off
 generic (
 INIT: bit_value:= X"6626");
 -- synthesis translate_on
 port (Q : out STD_ULOGIC;

 A0 : in STD_ULOGIC;
 A1 : in STD_ULOGIC;
 A2 : in STD_ULOGIC;
 A3 : in STD_ULOGIC;
 CLK : in STD_ULOGIC;
 D : in STD_ULOGIC);
 end component;
 -- Component Attribute specification for SRL16
 -- should be placed after architecture declaration but
 -- before the begin keyword
 -- Enter attributes in this section
 -- Component Instantiation for SRL16 should be placed
 -- in architecture after the begin keyword

 attribute init: string ;
 attribute init of SRL16_INSTANCE_NAME: label is "6626";

 signal feedback : std_logic;

begin

 SRL16_INSTANCE_NAME : SRL16
 -- synthesis translate_off
 generic map(
 INIT => "6626" )
 -- synthesis translate_on
 port map (
 Q => feedback,
 A0 => '1',
 A1 => '0',
 A2 => '0',
 A3 => '1',
 CLK => clk,
 D => feedback );

 q <= feedback;

end Behavioral;



Article: 73887
Subject: Re: Xilinx SRL16 test
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 30 Sep 2004 10:59:37 -0700
Links: << >>  << T >>  << A >>
Works now thanks. This code initiates the SRL16 with some sort of pattern,
then loops it around continuously in a 10 bit cycle, and outputs to a pad
where it can be seen with a scope.  Not sure what the translate on/off or
generic stuff is all about.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity srltest is
 port(
  clk : in std_ulogic;
  q   : out std_ulogic );
end srltest;

architecture Behavioral of srltest is

 component SRL16
 -- synthesis translate_off
 generic (
 INIT: bit_value:= X"6626");
 -- synthesis translate_on
 port (Q : out STD_ULOGIC;

 A0 : in STD_ULOGIC;
 A1 : in STD_ULOGIC;
 A2 : in STD_ULOGIC;
 A3 : in STD_ULOGIC;
 CLK : in STD_ULOGIC;
 D : in STD_ULOGIC);
 end component;
 -- Component Attribute specification for SRL16
 -- should be placed after architecture declaration but
 -- before the begin keyword
 -- Enter attributes in this section
 -- Component Instantiation for SRL16 should be placed
 -- in architecture after the begin keyword

 attribute init: string ;
 attribute init of SRL16_INSTANCE_NAME: label is "6626";

 signal feedback : std_logic;

begin

 SRL16_INSTANCE_NAME : SRL16
 -- synthesis translate_off
 generic map(
 INIT => "6626" )
 -- synthesis translate_on
 port map (
 Q => feedback,
 A0 => '1',
 A1 => '0',
 A2 => '0',
 A3 => '1',
 CLK => clk,
 D => feedback );

 q <= feedback;

end Behavioral;




Article: 73888
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: "Rotund Phase" <rotund_phase@hotmail.com>
Date: Thu, 30 Sep 2004 11:32:39 -0700
Links: << >>  << T >>  << A >>
Are you also guys@altera.com? From the 'NV on-chip memory' thread?
"CraigR" <craigra@pacbell.net> wrote in message
news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com...
> In reviewing a specific requirement, my design team is debating the
benefits
> of in-field hardware upgradability.  In the communications space,
wondering
> if most system developers require and use ICR in production when
> implementing FPGA (instead of ASIC)?
>
> Craig
>
>



Article: 73889
Subject: Re: Quartus II annoyance
From: sdatta@altera.com (Subroto Datta)
Date: 30 Sep 2004 11:50:02 -0700
Links: << >>  << T >>  << A >>
hpa@terminus.zytor.com (H. Peter Anvin) wrote in message news:<cjd1mj$aef$1@terminus.zytor.com>...
> For the Altera people in this group...
> 
> One of the things I find really annoying with Quartus II is that
> whenever it gives resource counts, like in the final synthesis report
> or in the SignalTap configurator, it gives "bits of memory."

Hi Peter,

The Memory Bits are provided in the Flow Summary section of the Report
File to give a brief design overview, while inside the Report there is
much more detailed information.  The Fitter Resource Usage Summary
section probably gives what you are looking for, breaking out exactly
how many M512s, M4Ks and M-RAMs are required.  Note that there is a
detailed RAM Summary Report in both the Analysis and Synthesis section
of the report and the Fitter section.  These give the details on each
hierarchical block, how many bits they use and how many of each block
type are used.

An important note is that the Fitter RAM Summary may show more blocks
being used than the user would expect.  This is because Quartus can
spread the slices of a RAM across multiple blocks if it helps the
design's timing.  This is a feature, and if the device memory fills
up, Quartus will pack them as tightly as possible, but is a cause for
some confusion.  In the future there will be a message added to the
report clarifying this.

The upcoming release of Quartus will contain improvements in the
reporting of the memory blocks used as part of the Signal Tap II
configuration.

Hope this helps.

- Subroto Datta
Altera Corp.

Article: 73890
Subject: Re: Quartus and VDHL misbehavior
From: hjones1380@hotmail.com (pjjones)
Date: 30 Sep 2004 12:09:34 -0700
Links: << >>  << T >>  << A >>
Ben Twijnstra <btwijnstra@chello.nl> wrote in message news:<pMa6d.144318$C7.84061@amsnews05.chello.com>...
> Hiya,
> 
> > I'm working on a quadrature decoder to interface with a rotation
> > sensor.  My thought was to have an asynchronous process that operates
> > on the A and B signals, and then have the 'state' variable synchronous
> > with the clock in a seperate process.  The following vhdl works as
> > expected in one simulation tool, but produces garbage when I use
> > Quartus.
> > 
> > begin
> > process(A_in, B_in)
> > begin
> > state(3) <= state(1);
> > state(2) <= state(0);
> > state(1) <= A_in;
> > state(0) <= B_in;
> > end process;
> > state_out <= state;
> > direction <= ( (not state(3)) and (not state(0)) ) or ( state(3) and
> > state(0)) ;
> > end a;
> > 
> > I expect that 'state' will always be of the form XXYY where XX is the
> > old state, and YY is the current state of the inputs A and B (for
> > example, 0001, 0111, 1110 etc).  With one simulation tool I have, it
> > works exactly as expected.  With Quartus, the 'state' variable is
> > always 0000, 0101, 1111, or 1010.
> > 
> > Is there something wrong with the way I'm trying to implement this?
> > Any suggestions on a better way?
> 
> The way you have written this code will make sure that Modelsim only
> 'schedules' the process if A_in or B_in changes. In a synthesized design, a
> process is always dependant on all its inputs, so also its internal state -
> er - register (which you don't have here).
> 
> If you synthesize this with Quartus (or any synthesis tool for that matter)
> you will get warnings that state(1) and state(0) should also be on the
> sensitivity list. The synthesis tool will subsequently simply generate a
> wire between state(1) and state(3) and one between state(0) and state(2)
> 
> What you should do here is work synchronously, something like
> 
> process(clk)
>   signal tA, tB : std_logic;
> begin
>   if rising_edge(clk) then
>     if (A_in /= tA) or (B_in /= tb) then
>       tA <= A_in;
>       tB <= B_in;
>       state(3) <= state(1);
>       state(2) <= state(0);
>       state(1) <= A_in;
>       state(0) <= B_in;
>     end if;
>   end if;
> end process;
> 
> state_out <= state;
> direction <= ( (not state(3)) and (not state(0)) ) or ( state(3) and
> state(0)) ;
> 
> Even though I hate using the /= operator on a std_logic.
> 
> Best regards,
> 
> 
> Ben


Thanks for the reply.  I incorporated the component into a synchronous
process and it works fine now.  However, I still have a few questions
just so I can get a better understanding of what was going on.

> The way you have written this code will make sure that Modelsim only
> 'schedules' the process if A_in or B_in changes. 

That was my intention.  I wanted the output to change *only* when one
of the two inputs changed.  I see what you mean that the 'internal
states' were not counted as inputs though.  So, how would you go about
making this component so that it will change state only when the input
changes?

> If you synthesize this with Quartus (or any synthesis tool for that matter)
> you will get warnings that state(1) and state(0) should also be on the
> sensitivity list. 

In fact, Quartus gives the following message:  "Design
top_quadrature_decoder: Netlist extraction and synthesis were
successful. 0 errors, 0 warnings"

> Even though I hate using the /= operator on a std_logic.

Is this just a personal preference?  or is there a reason one should
avoid the /= operator?


thanks,
Phillip

Article: 73891
Subject: Re: Spartan-3 VCCIO ramp up time
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 15:30:12 -0400
Links: << >>  << T >>  << A >>
"Steven K. Knapp" wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:4159BB3B.10CC935B@yahoo.com...
> > Brian Davis wrote:
> 
> [snip]
> >
> > I don't think this is a problem.  The ramp speed issue in only of
> > concern at a voltage threshold around 0.8~1.0 volts.  As it was
> > explained to me, when the part powers up, there are a lot of transistors
> > which are turned on initially.  Once Vcc gets above about 1.0 volts,
> > everything is biased and the transistors that need to be off are off.
> > But the part draws a lot of current in the meantime as the voltage
> > ramps.  If the voltage ramps too fast, the PS can max out on current and
> > for some reason, this will disturb the part and it will not initialize
> > correctly to the point that a power down must be done to correct the
> > problem.
> >
> > So the problem is that you must let the part draw as much current as it
> > needs as the voltage ramps up.  The spec is to let you know how much
> > current you will need for a given ramp rate.  Keep the ramp rate slower
> > than the worst case spec and the part will be happy with the current
> > spec'd in the data sheet.  After the voltage rises above about 1.0 volts
> > this is no longer an issue regardless of how the spec is written (or
> > interpreted).
> 
> The problem that you described is a completely different phenomena from much
> older FPGA families.  This phenomena does not exist on any of the modern
> FPGA architectures like Virtex-II, Virtex-II Pro, Spartan-3, and Virtex-4.

Are you sure you should include Virtex-II and Virtex-II Pro in this
list?  When I read the data sheet it still lists a minimum power up
current of up to 1.1 Amps.  If this is not the same issue as the Virtex
and Spartan II parts, then what exactly is this current about?  

Or maybe my copies of the data sheets are old???  

--

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: 73892
Subject: Re: Xilinx Timing Constraints
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 15:37:42 -0400
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> 
> OK well how do you apply a restraint to a path then?

I indicated that in my other post.  You specify sets of starting points
(which can be FFs, SRLs, any other synchronous elements or IOB inputs)
and a set of end points (FFs SRLs, any other synchronous elements or IOB
outputs).  Timing constraints are applied between the starting points
and the ending points.  

A signal connects two objects which can include LUTs and other logic
elements.  These objects are connected by signals.  But specing the time
for a given signal is typically not useful since that is only a part of
a path between timing end points.  

Does that make more sense?  I was around when Xilinx first introduced
this method of timing constraints.  It seemed counter intuitive at
first.  But I learned that it was the only practical way to specify
timing.  So think in terms of paths between timing end points, not
signals.  

-- 

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: 73893
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 15:45:53 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> In article <2s0j7fF1c0cu3U1@uni-berlin.de>,
> Symon <symon_brewer@hotmail.com> wrote:
> >Google says:-
> >Pricing and Availability
> >
> >The Synplify 7.7 and Amplify 3.7 software are available now. Pricing for the
> >Synplify software starts at $9,500 (U.S.) and pricing for the Amplify
> >Physical Optimizer(TM) software starts at $29,000 (U.S.). For more
> >information visit Synplicity's Web site at http://www.synplicity.com.
> >
> >Pro used to cost about double Synplify regular.
> 
> Thanks, but I recall there being a cheaper Xilixn only verson or
> sometihng.  And a press release won't due for the budget info I need.

Like Ken said, you might qualify for an educational discount.  But the
Xilinx only version is sold by Xilinx the last time I checked.  It was
$995, IIRC.  It is pretty limited, like the free version with webpack,
but at a higher number of lines of code. So if your project is pretty
large, it may not be the right choice.  I also recommend that you
contact your local sales rep for Synplicity.   


-- 

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: 73894
Subject: Wang Nam
From: mike_treseler@comcast.net (Mike Treseler)
Date: 30 Sep 2004 13:09:40 -0700
Links: << >>  << T >>  << A >>
Hi, mike

I am a student of University of louisiana, I am beginner for Xilinx ISE 5.2I ,
seems you have a lot of experience on that, since you answer some questions in
the FPGA group, I wonder if you can help me in some of the problem. 
When I am implement a counter in ISE, and after I set up the testbench
waveform, and try to get the result of the simulatin, it give me error as :
ERROR:
  Model Technology's ModelSim executable cannot be found by Project
Navigator.
  Please go to the 'Edit' menu, select 'Preferences' and then select
the 'Partner Tools'
  tab. Using this dialog select the ModelSim executable that you wish
to use for
  simulation. Then re-start Project Navigator and try this process
again.
I try everything but it still not work, would please tell me how to solve it
if you have faced with the similar problem. 

Thank you in advance


Nan

______________________

Try reinstalling from the CD.
The files you need are vcom.exe and vsim.exe
You don't really need the rest of
Xilinx ISE until you have completed simulation.

           -- Mike Treseler

Article: 73895
Subject: Re: Spartan-3 VCCIO ramp up time
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Sep 2004 13:11:03 -0700
Links: << >>  << T >>  << A >>
Rick,

We left the 'minimum power on current' in the data sheet so that folks 
would always be able to turn them on.

The minimum current is not so much different now from the maximum leakage.

So to turn a V2, V2P, etc on at 100C at Vccint(abs max) might require a 
bit more current than at room temp.

That is what that table (specification)is all about.

Austin

rickman wrote:
> "Steven K. Knapp" wrote:
> 
>>"rickman" <spamgoeshere4@yahoo.com> wrote in message
>>news:4159BB3B.10CC935B@yahoo.com...
>>
>>>Brian Davis wrote:
>>
>>[snip]
>>
>>>I don't think this is a problem.  The ramp speed issue in only of
>>>concern at a voltage threshold around 0.8~1.0 volts.  As it was
>>>explained to me, when the part powers up, there are a lot of transistors
>>>which are turned on initially.  Once Vcc gets above about 1.0 volts,
>>>everything is biased and the transistors that need to be off are off.
>>>But the part draws a lot of current in the meantime as the voltage
>>>ramps.  If the voltage ramps too fast, the PS can max out on current and
>>>for some reason, this will disturb the part and it will not initialize
>>>correctly to the point that a power down must be done to correct the
>>>problem.
>>>
>>>So the problem is that you must let the part draw as much current as it
>>>needs as the voltage ramps up.  The spec is to let you know how much
>>>current you will need for a given ramp rate.  Keep the ramp rate slower
>>>than the worst case spec and the part will be happy with the current
>>>spec'd in the data sheet.  After the voltage rises above about 1.0 volts
>>>this is no longer an issue regardless of how the spec is written (or
>>>interpreted).
>>
>>The problem that you described is a completely different phenomena from much
>>older FPGA families.  This phenomena does not exist on any of the modern
>>FPGA architectures like Virtex-II, Virtex-II Pro, Spartan-3, and Virtex-4.
> 
> 
> Are you sure you should include Virtex-II and Virtex-II Pro in this
> list?  When I read the data sheet it still lists a minimum power up
> current of up to 1.1 Amps.  If this is not the same issue as the Virtex
> and Spartan II parts, then what exactly is this current about?  
> 
> Or maybe my copies of the data sheets are old???  
> 
> --
> 
> 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: 73896
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: "CraigR" <craigra@pacbell.net>
Date: Thu, 30 Sep 2004 20:11:29 GMT
Links: << >>  << T >>  << A >>
Nope.  I did see that posting though.  I am weighing cost benefits of ASIC 
for field upgradability.


"Rotund Phase" <rotund_phase@hotmail.com> wrote in message 
news:2s31qkF1furbmU1@uni-berlin.de...
> Are you also guys@altera.com? From the 'NV on-chip memory' thread?
> "CraigR" <craigra@pacbell.net> wrote in message
> news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com...
>> In reviewing a specific requirement, my design team is debating the
> benefits
>> of in-field hardware upgradability.  In the communications space,
> wondering
>> if most system developers require and use ICR in production when
>> implementing FPGA (instead of ASIC)?
>>
>> Craig
>>
>>
>
> 



Article: 73897
Subject: Re: NV on-chip memory?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 16:12:45 -0400
Links: << >>  << T >>  << A >>
Guy wrote:
> 
> Let me first say thank you for your responses.
> To address some of the questions / comments:
> I realize that not everyone will extract the same application or value
> from the on-chip NV memory, however, since it has the potential to
> provide or support different applications, general enough value may be
> justified for inclusion.
> Answers / Comments for Jim and Hal:
> a.  bad bits:  built in ECC would make bad bit transparant to the user
> 
> b.  speed = assume approximately 25ns access time
> 
> c.  width = flexible, 16/32/64 bit
> 
> d.  secure code storage would come by two assumptions:  i) on-chip
> processor preventing external need to access the memory. ii) readback
> via JTAG etc of Memory would be programmed as disabled by the user
> 
> e.  on-chip charge pumps require no special external voltage supply
> 
> f.  user application would be able to log/write data to NV memory for
> storage
> 
> g.  external applications could read NV data too, but you obviously
> loose security
> 
> h.  OTP = nonerasable

That makes it much *less* useful.  When a CPU is put into an FPGA, it is
a real encumbrance to use external memory and the internal FPGA memory
is often not large enough for program storage.  Having a hunk of NV
*rewritable* (such as flash) memory would be very useful for this sort
of app.  When are SW programs *ever* mature???  My network router
already has a code update waiting to go into the Flash.  


> i.  no tradeoff with NV and Ram like functionality - it would be a
> standard feature, not swappable block within the silicon family
> 
> j.  yes for non secure, it would enable integration into the FPGA of
> on-board NV data for some applications (mature s/w code for example).
> Realize that also for some applications, you can create a sense of
> "virtual" unlimited multiwrite capability.  To demonstrate what I mean
> by Virtual multi-write, I'll use the following example.  Let's say
> that you know you may need to write 10,000 maximum lifetime events at
> 100 bits data each but do not need to keep history for more than 16
> events.  As a designer, you could buy a tiny block of flash or EEPROM
> of 1.6kbits and keep writing over the older events.  Or, with OTP, you
> could simply purchase enough OTP memory to store the entire lifetime
> worth of events.  Many applications that store NV data can quantify
> the lifetime of storage from a practical specification.  One example,
> Televisions need to store user configuration (like:  color, tint,
> favorite channels etc), and need to provide the user with unlimited
> adjustments of this data.  However if you make some assumption, the
> design can calculate an upper limit of needed storage.  For example,
> lets say 512bits stored, TV life is 20 years.  I would venture to
> guess that if you assumed that data storage would occur Max once a day
> for each of 20 years, you would be happy to remove the $1 EEPROM from
> the board as long as the on-chip cost of the NV block was less.
> 20yr*512b*365days = 7Mbit total
> 
> Any other creative thoughts on how this could be used would be
> appreciated.

One poster indicated that 128 bits for a unique serial number would be
useful.  We have used Dallas one-wire parts for that sort of thing.  So
that could put a $1 price on providing a bit of NV memory, but the
Dallas parts also have a bit of EEPROM memory, so again the
reprogrammable feature is important.  

Another feature that we look for often is a way to provide a software
configurable board jumper.  This jumper needs to be reprogammable,
control a signal on the board, and be asserted from power up.  Currently
we use a Flash PLD for this.  

-- 

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: 73898
Subject: Re: FPGA vs ASIC area
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Sep 2004 13:23:31 -0700
Links: << >>  << T >>  << A >>
This seemingly simple question does not have a simple answer. There are too
many variables. Modern FPGAs are leaping ahead of ASICs in the use of the
tightest technology ( 90 nm today). Some FPGA structures are inherently as
efficient as in ASICs (BlockRAM, I/O, transceivers, hard microprocessors).
In other respects FPGAs can be far less efficient in their silicon use. But
FPGAs benefit from a very regular and tight chip-layout, and they are
manufactured by the multi-millions (as opposed to most ASICs).
And finally: Silicon is cheap, silicon area is not decisive, the total
manufacturing and distribution cost is!
Don't count the square microns, count the dollars.

Peter Alfke

> From: totallyadmin <totallyadmin.1deq4n@info@totallychips.com>
> Organization: Totallychips
> Newsgroups: comp.arch.fpga
> Date: Thu, 30 Sep 2004 12:35:07 -0500
> Subject: FPGA vs ASIC area
> 
> 
> I was just wondering *roughly* how much area is required for a design
> targetted to an fpga in comparsion to a standard cell asic? I'm really
> looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area
> requirements? (I undersatand its heavily dependant on the particular
> design)
> 
> 
> -- 
> totallyadminwww.totallychips.com  - VHDL, Verilog &amp; General Hardware
> Design discussion Forum
> 


Article: 73899
Subject: Re: embedded linux on FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 16:32:13 -0400
Links: << >>  << T >>  << A >>
hamilton wrote:
> 
> T Lee wrote:
> >
> > Forth is very good for small embedded design.
> >
> > -Tony
> 
> Forth is the perfect hacker language.
> Write it once and no one else will able to read it again.
> 
> Every time I follow up on a forth project, I have to re-write it in C
> so it can be read by future programmers.
> 
> Sorry Tony, I just don't by it.

That is a self-perpetuating prophesy.  There is nothing inherently
incomprehensible about Forth, especially vs. C.  It is a bit like saying
Chinese is hard to learn because you learned English as a small child. 
When people refuse to work in Forth because there aren't many who work
in Forth, you can see how that perpetuates the problem.  

I can see some significant advantages to an interactive language that
you can run on the target without an emulator.  

-- 

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



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