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 149800

Article: 149800
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Wed, 24 Nov 2010 11:33:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On 24 nov, 10:40, Petter Gustad <newsmailco...@gustad.com> wrote:
> jc <jcappe...@optimal-design.com> writes:
> > A great way to test your ram limits, as I found out, is to run Xilinx'
> > SmartXplorer. It will run on as many processor cores as you specify,
>
> I did run something which was an earlier version of SmartXplorer on
> Solaris probably 10 years ago. In addition to running P&R's on a
> multicore CPU you could also run on multiple hosts (actually to run on
> multicore you specified the machine name multiple times using
> different casing). I ran the tool mostly across multiple machines as
> it scaled better in terms of memory cost. It was much cheaper to fit a
> set of smaller machines with a smaller amount of memory than to
> upgrade the big servers.
>
> I haven't used SmartXplorer so I don't know if you can run on multiple
> hosts.
>
> > in several hours (not days). In my search for a memory upgrade, I
> > realize that this particular system is limited to 16G ram because of
> > the OS (Windows 7 Home Premium 64-bit). From what kkoorndyk stated
>
> According tohttp://www.xilinx.com/ise/ossupport/index.htm
> Windows 7 will not be fully supported until ISE 13.
>
> > about Xilinx recommendations, I'm going to need an OS upgrade if I
> > want to handle semi-packed V6 designs completely in ram. Sigh.
>
> Upgrade to Linux...
>
> Petter
> --
> .sig removed by request.

Do you have a suggestion for Linux? For example, can we use Ubuntu or
should we stick with the "Xilinx-approved" linux flavors?

Article: 149801
Subject: Re: cool BGA pattern
From: rickman <gnuarm@gmail.com>
Date: Wed, 24 Nov 2010 11:38:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 6:09=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 15/11/2010 19:21, rickman wrote:
>
> My gut feeling here is that you are not going to get significant
> resonance between the power plane and the bypass capacitors, especially
> if the power "plane" is actually just a polygon, and therefore fairly
> small, while the capacitors are large. =A0The power "plane" is then far
> too small in comparison to have a noticeable effect on the bypass
> capacitor, and therefore the bypass capacitor will work as expected.
> The power "plane" (viewed as a capacitor) is mainly for bypassing very
> high frequencies - these will be isolated from the bypass capacitors by
> the capacitors' inductance and ESR, thus it will also continue to work
> as expected.

I have no idea why your gut feels the way it does.  All you need to do
is gin up a simple spice circuit and check its response vs.
frequency.... at high frequencies, say 100 MHz to 5 GHz.  You will see
this clearly.  The idealized circuit does perform worse than a real
circuit because this is one of the times when the parasitic effects
can help you.  The ESR of the cap prevents it from having a sharp Q
and a very high impedance at resonance.  But it will have a resonance
and it can easily create a problem at some specific frequency.

The seat of the pants analysis you gave has nothing to do with the
resonance effect.  In fact, you seem to think the inductance of the
bypass caps "isolate" them from a resonance effect while it is this
inductance that *creates* the resonance when coupled with the power
planes capacitance.


> And again the disclaimer - I haven't worked with this sort of thing in
> practice (the fastest card I have made was about 200 MHz), nor have I
> studied the theory or the maths here in detail. =A0My theories are based
> on reading articles and guides, thinking about how things work, reading
> c.a.f., etc. =A0I am posting here to ask and learn, and perhaps also to
> make the experts here think.

Please do some searches on power supply decoupling and resonance
effects.  I am sure Lee Ritchey is not the only person who knows about
this.  I heard it from others before him, but didn't take it
seriously.

One thing about power supply system design and decoupling... it is not
hard to make one that works.  But to know that it will work before you
build it, that takes some knowledge.  The old rule of thumb of adding
a cap per power pin is pretty useless.  So too are all the other
"guidelines" that aren't based on theory, simulation and testing...
all three.  There are lots of things that may sound good until you
actually verify them.  The single most surprising fact I got from the
high speed digital design course was that not only are much fewer caps
needed than expected, but they don't need to be especially close to
the power and ground pins of the chip!

Rick

Article: 149802
Subject: Verilog preprocessor macro syntax
From: "currentsource" <vikram.godbole@n_o_s_p_a_m.gmail.com>
Date: Wed, 24 Nov 2010 13:50:39 -0600
Links: << >>  << T >>  << A >>
I'm trying to define a macro for a simple two-flop synchronizer in an ISE
project:

`define XCLK_SYNC_2DFF(q, d, clk)     \
reg __sync__``q;                      \
always @(posedge clk)                 \
    begin                             \
        __sync__``q <= d;             \
        q <= __sync__``q;             \
    end                               \  

XST errors out on this; I believe the `` is SystemVerilog syntax which XST
doest not support. But the following doesn't work either:

`define XCLK_SYNC_2DFF(q, d, clk)       \
reg sync;                               \
always @(posedge clk)                   \
    begin                               \
        sync <= d;                      \
        q <= sync;                      \
    end                                 \  


Limited though the utility of such a macro may be, shouldn't the
preprocessor just dump the lines above, substituting for q, d and clk
wherever it sees a `XCLK_SYNC_2DFF invocation in the source? Does
Verilog-2001 specifically forbid creation of temp regs/wires within macros?


Is there any way to code this macro while keeping XST happy? Or should I
just create a separate module/inline the code?


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149803
Subject: Re: PlanAhead
From: "Roger" <rogerwilson@hotmail.com>
Date: Wed, 24 Nov 2010 20:11:15 -0000
Links: << >>  << T >>  << A >>


"Chris Maryan"  wrote in message 
news:6092db29-96e8-45ce-8870-9069272dc561@o4g2000yqd.googlegroups.com...

On Nov 23, 5:00 pm, "Roger" <rogerwil...@hotmail.com> wrote:
> The latest Xilinx PlanAhead seems to do everything that a project needs 
> from
> VHDL input to bit stream. So what's ISE for now?
>
> Thanks,
> Rog.

My understanding is that the plan is for PlanAhead to replace ISE.
Though I'm not sure at what point this will happen.

Chris

Chris,

Thanks for the reply. I suspected this might be the case. Did you hear this 
from Xilinx?

Rog. 


Article: 149804
Subject: Re: Atom 6000C perspective, anyone?
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 24 Nov 2010 14:18:41 -0600
Links: << >>  << T >>  << A >>
On 11/24/2010 07:01 AM, gnirre wrote:

>
> So Stellarton is basically a product that is the optimal choice for
> almost no application, almost always too small, or too expensive.
>
> So why did Intel have this one built? Who ordered it? Which is the One
> Single App where an Atom E and 60 000 fpga gates is the optimal
> combination?
Well, I sort of have one.  I make some boards that interface to X86 
systems through the parallel port, and generate signals to run stepper 
or servo drives.  I currently use a Xilinx Spartan IIE 50K gate part,
and have to add several voltage regulators and a bunch of voltage level 
translators.  I definitely don't want to get into CPU board design, the 
high data rates to memory, etc. make any design somewhat speculative, 
and I really want to avoid multiple revisions.  Also, I'm not set up to 
do anything finer than 0.4 mm lead pitch on leaded parts, no BGA 
capability.  If there were a board that brought out the necessary number 
of pins, then I'd still need to supply the level translator chips.

So, really, the only benefit is a better interface between CPU and the 
FPGA, as opposed to the parallel port in EPP mode.  So, while it would 
be possible to use this platform, I'm not sure it buys me anything.  I 
can get an Atom mini-ITX motherboard with memory, power supply and SSD
for a little over $100, and it still had an EPP parallel port.

Oh, the application is a CNC motion control program called EMC2, it runs
under Linux with RTAI.

Jon

Article: 149805
Subject: Re: Verilog preprocessor macro syntax
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 24 Nov 2010 21:00:30 +0000
Links: << >>  << T >>  << A >>
On Wed, 24 Nov 2010 13:50:39 -0600, "currentsource" wrote:

>I'm trying to define a macro for a simple
>two-flop synchronizer in an ISE project:
>
>`define XCLK_SYNC_2DFF(q, d, clk)     \
>reg __sync__``q;                      \
>always @(posedge clk)                 \
>    begin                             \
>        __sync__``q <= d;             \
>        q <= __sync__``q;             \
>    end                               \  
>
>XST errors out on this; I believe 
>the `` is SystemVerilog syntax 

Right, it's the "token gluing" operator as you've seen.

> But the following doesn't work either:
>
>`define XCLK_SYNC_2DFF(q, d, clk)       \
>reg sync;                               \
>always @(posedge clk)                   \
>    begin                               \
>        sync <= d;                      \
>        q <= sync;                      \
>    end                                 \  
>

Really?  I can easily imagine that it will fail to compile
if you use the macro more than once in the same scope, 
because it will create more than one "reg sync".  But
a single use of it should be OK - provided you DON'T 
put a semicolon on the end of the macro invocation.

Surely it would be easier just to make a module?
That's what they're for, after all.  The extra layer
of hierarchy is completely free in hardware, and has
a negligible impact on simulation performance.  And it
saves all the macro kruft.

Jonathan Bromley

Article: 149806
Subject: Re: Brain Cramps...
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 24 Nov 2010 21:16:19 +0000
Links: << >>  << T >>  << A >>
On Wed, 24 Nov 2010 11:22:33 -0800 (PST), rickman wrote:

> Instead of (rising_edge(clk)) I had used ('1' = clk).
...
>With the way a simulation works,
>comparing the clock to '1' gives exactly the same results as
>rising_edge.  Given the function of the sensitivity list, it seems
>like the rising_edge function should be redundant.

BE CAREFUL!

If there was no asynch reset in your process, then what probably
happened was that the tool saw
  process (clock) begin if clock='1' then...
Not recognizing a standard clocked process, the tool would 
then assume it had a combinational process.  Betcha there
was a warning somewhere in the synth report about automatically
completing the incomplete sensitivity list.  Consequently you
got a pile of transparent latches, enabled (made transparent)
by clock='1'.

On the other hand...

If you have an asynch reset in your sensitivity list, it is
simply not true that rising_edge is redundant.

Consider
  process (clock, reset) begin
    if (reset = '1' then
      do-reset-ish-things;
    elsif clock = '1' then
      do-clocked-things;
    end if;
  end process;

Suppose clock is held at '1', with no edges, and you take
reset from true to false.  The process trips, reset='0' so
the reset action doesn't happen, clock='1' so the clocked
action DOES happen.  Bzzzt! you got a spurious extra clock
action on the trailing edge of reset.

That is why the old-fashioned (pre std_logic_1164) style
of VHDL clocked process, still seen in some dinosaur code
today, looks like this:

  process (clock, reset) begin
    if (reset = '1' then
      do-reset-ish-things;
    elsif clock'event and (clock = '1') then
      do-clocked-things;
    end if;
  end process;

Note the extra clock'event test!  The rising_edge
function includes exactly this test.

This is also the reason why Verilog clocked process
sensitivity lists look like

  always @(posedge clock or posedge reset)

The "posedge reset" often mystifies beginners - hey,
it's a level-sensitive reset, isn't it? - but exactly
the same problem arises of a spurious clock action in
simulation on the trailing edge of reset.  Indeed, it's
even worse in Verilog because you don't test the clock
level (posedge did that for you!) so the spurious action
occurs regardless of the value of clock.

Many synth tools will simply choke on any non-standard
form of clocked process; your tool evidently made the
best it could of it, with appropriately disastrous results.

Sorry to hear about your wasted time.  Sounds to me like 
a good argument for tools NOT to complete the sensitivity
list automatically when they think they've found a
combinational process.
-- 
Jonathan Bromley

Article: 149807
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Wed, 24 Nov 2010 22:22:40 +0100
Links: << >>  << T >>  << A >>
Benjamin Couillard <benjamin.couillard@gmail.com> writes:

> Do you have a suggestion for Linux? For example, can we use Ubuntu or
> should we stick with the "Xilinx-approved" linux flavors?

I would suggest that you use the Xilinx approved ones. However, I've
used mostly Gentoo Linux with both Altera and Xilinx (as well as with
lots of Synopsys software), which have worked quite well. There has
been times where I've hacked some of the scripts which tries to detect
the platform type, mostly it's the installation software which have
caused problems.

I tend to use a script based flow. I only use the GUI occasionally,
hence my usage might be somewhat "nicer" than the typical Windows
user.

But I always keep a Red Hat installation in VirtualBox so that I can
verify any problems before I report them and then say "yes" if I'm
asked if I'm on a supported operating system.

Petter
-- 
.sig removed by request. 

Article: 149808
Subject: Re: Atom 6000C perspective, anyone?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Wed, 24 Nov 2010 22:49:59 +0100
Links: << >>  << T >>  << A >>
gnirre <gnirre@gmail.com> writes:

> So why did Intel have this one built? Who ordered it? Which is the One
> Single App where an Atom E and 60 000 fpga gates is the optimal
> combination?

I don't know which is the one single application for this device. But
it would be nice to use the FPGA to connect to video/audio interfaces
and do image processing, then let the Atom to run the GUI and the
network stack.

Petter
-- 
.sig removed by request. 

Article: 149809
Subject: Re: Atom 6000C perspective, anyone?
From: "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net>
Date: Wed, 24 Nov 2010 14:32:45 -0800
Links: << >>  << T >>  << A >>
On 11/24/2010 3:06 AM, Piotr Wyderski wrote:
> Thomas Entner wrote:

>> - In the past, Hard-Core-CPU + FPGA-combinations from Altera and
>> Xilinx were no success.
>
> I don't think the Virtex family is a failure.

I have heard people at Xilinx say that the embedded PowerPC CPUs in the 
Virtex line were a failure. $ wise.

Article: 149810
Subject: Re: Atom 6000C perspective, anyone?
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 24 Nov 2010 23:58:14 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <nYKdnXW5a-Bi7HDRnZ2dnUVZ_q6dnZ2d@giganews.com>,
Jon Elson  <jmelson@wustl.edu> wrote:
>> So why did Intel have this one built? Who ordered it? Which is the One
>> Single App where an Atom E and 60 000 fpga gates is the optimal
>> combination?
>Well, I sort of have one.  I make some boards that interface to X86 
>systems through the parallel port, and generate signals to run stepper 
>or servo drives.  I currently use a Xilinx Spartan IIE 50K gate part,
>and have to add several voltage regulators and a bunch of voltage level 
>translators.  I definitely don't want to get into CPU board design, the 
>high data rates to memory, etc. make any design somewhat speculative, 
>and I really want to avoid multiple revisions.  Also, I'm not set up to 
>do anything finer than 0.4 mm lead pitch on leaded parts, no BGA 
>capability.  If there were a board that brought out the necessary number 
>of pins, then I'd still need to supply the level translator chips.
>
>So, really, the only benefit is a better interface between CPU and the 
>FPGA, as opposed to the parallel port in EPP mode.

I think two lanes of PCI-E is a qualitatively better interface than
the parallel port in EPP mode (4 gigabit per second each way); on the
other hand you obviously don't need gigabit interface rates to go to
servo motors, and the Atom+Altera chip will be using low-voltage IO
and on aggressive lead-free BGAs so you still have the soldering
issues and need the level translators.

Tom

Article: 149811
Subject: System Verilog 2D input port?
From: John Smith <redditorred@gmail.com>
Date: Wed, 24 Nov 2010 18:46:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Is it acceptable to have 2D input ports using System Verilog?

I know it's not possible in Verilog. The only workaround I could think
of is to 'flatten' out the input port and use it; but that seems to be
messy inside loops. Is there any other workaround?

Article: 149812
Subject: Re: System Verilog 2D input port?
From: unfrostedpoptart <david@therogoffs.com>
Date: Wed, 24 Nov 2010 20:29:57 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 6:46=A0pm, John Smith <redditor...@gmail.com> wrote:
> Is it acceptable to have 2D input ports using System Verilog?

Sure. It allows just about anything: arrays, structures, interfaces
(obviously).  Now, whether your synthesis tool handles these
constructs is another question that needs to be asked of the vendor.

Article: 149813
Subject: tutorial on XPS ethernet MAC lite
From: "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com>
Date: Thu, 25 Nov 2010 00:53:50 -0600
Links: << >>  << T >>  << A >>
Hi

Kindly if there is any tutorial/example available on xilinx XPS ethernet
MAC lite (for Virtex4 PPC), let me know it.

Thanks	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149814
Subject: Re: Atom 6000C perspective, anyone?
From: "Piotr Wyderski" <piotr.wyderski@wp.pl>
Date: Thu, 25 Nov 2010 08:24:41 +0100
Links: << >>  << T >>  << A >>
Andy "Krazy" Glew wrote:

> I have heard people at Xilinx say that the embedded PowerPC CPUs in the 
> Virtex line were a failure. $ wise.

OK -- if *you* say that, I take it for granted.

    Best regards
    Piotr Wyderski


Article: 149815
Subject: Re: Spartan3 device with long availability
From: Philip Herzog <ph1a@arcor.de>
Date: Thu, 25 Nov 2010 10:11:29 +0100
Links: << >>  << T >>  << A >>
On 11/20/2010 10:27, Thomas Heller wrote:
> Which series / package should I choose for long availability?

What's long in your terms?

I'm in the measurement equipment industry, our oldest products have been
on the market for fifteen years and they contain Xilinx FPGAs that have
been introduced about seventeen years ago, which have been discontinued
lately.

Usually, we aim for parts which are targeted at the automotive industry
since they have the tendency to have a longer lifetime.

-   Philip
-- 
Some of the best things in life are total mistakes.
(Rachel Porter)



Article: 149816
Subject: Re: Brain Cramps...
From: Philippe <philippe.faes@gmail.com>
Date: Thu, 25 Nov 2010 02:26:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 8:22=A0pm, rickman <gnu...@gmail.com> wrote:
>
> I wish I had a smart(er) editor that understood VHDL a bit more.

Hi Rick,

You might want to take a look at Sigasi: http://www.sigasi.com
We have a VHDL development environment with a VHDL parser inside. This
way, as you put it, the VHDL editor "understands" what you type.

> I have some search/replace regex strings I copy and paste from one file
> to another which change an entity port list into a port map or a
> signal list. =A0This helps with the tedium of instantiation.

Thirty second screencast on instantiations:
http://www.sigasi.com/screencast/entity-instantiation

kind regards

--
Philippe Faes
Sigasi



Article: 149817
Subject: Re: cool BGA pattern
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 25 Nov 2010 12:51:53 +0100
Links: << >>  << T >>  << A >>
On 24/11/2010 20:38, rickman wrote:
> On Nov 16, 6:09 am, David Brown<da...@westcontrol.removethisbit.com>
> wrote:
>> On 15/11/2010 19:21, rickman wrote:
>>
>> My gut feeling here is that you are not going to get significant
>> resonance between the power plane and the bypass capacitors, especially
>> if the power "plane" is actually just a polygon, and therefore fairly
>> small, while the capacitors are large.  The power "plane" is then far
>> too small in comparison to have a noticeable effect on the bypass
>> capacitor, and therefore the bypass capacitor will work as expected.
>> The power "plane" (viewed as a capacitor) is mainly for bypassing very
>> high frequencies - these will be isolated from the bypass capacitors by
>> the capacitors' inductance and ESR, thus it will also continue to work
>> as expected.
>
> I have no idea why your gut feels the way it does.  All you need to do
> is gin up a simple spice circuit and check its response vs.
> frequency.... at high frequencies, say 100 MHz to 5 GHz.  You will see
> this clearly.  The idealized circuit does perform worse than a real
> circuit because this is one of the times when the parasitic effects
> can help you.  The ESR of the cap prevents it from having a sharp Q
> and a very high impedance at resonance.  But it will have a resonance
> and it can easily create a problem at some specific frequency.
>
> The seat of the pants analysis you gave has nothing to do with the
> resonance effect.  In fact, you seem to think the inductance of the
> bypass caps "isolate" them from a resonance effect while it is this
> inductance that *creates* the resonance when coupled with the power
> planes capacitance.
>

Yes, that is pretty much how I thought - but you have given me cause to 
think again.  I will have to take your advice and try some simulations - 
that's probably the best way for me to see what's happening, where the 
resonances are coming from, and the sort of effect they have.  Until I 
have proved otherwise, I'll take your word over my gut feeling here.

>
>> And again the disclaimer - I haven't worked with this sort of thing in
>> practice (the fastest card I have made was about 200 MHz), nor have I
>> studied the theory or the maths here in detail.  My theories are based
>> on reading articles and guides, thinking about how things work, reading
>> c.a.f., etc.  I am posting here to ask and learn, and perhaps also to
>> make the experts here think.
>
> Please do some searches on power supply decoupling and resonance
> effects.  I am sure Lee Ritchey is not the only person who knows about
> this.  I heard it from others before him, but didn't take it
> seriously.
>

The thing about searching on-line for this sort of thing is that there 
is no consistency in the answers.  Either there are several different 
ways to do good bypassing, or the reality is that it doesn't matter too 
much.  But it's easy to find "experts" (some of whom may actually /be/ 
expert) advocating multiple large power planes, or no power planes, lots 
of capacitors or few capacitors, lots of capacitor values or few 
capacitors, capacitors placed on the backside under the component or 
capacitors just roughly in the neighbourhood.

A bit of spice simulation is what I need here.

> One thing about power supply system design and decoupling... it is not
> hard to make one that works.  But to know that it will work before you
> build it, that takes some knowledge.  The old rule of thumb of adding
> a cap per power pin is pretty useless.  So too are all the other
> "guidelines" that aren't based on theory, simulation and testing...
> all three.  There are lots of things that may sound good until you
> actually verify them.  The single most surprising fact I got from the
> high speed digital design course was that not only are much fewer caps
> needed than expected, but they don't need to be especially close to
> the power and ground pins of the chip!
>

On the boards I have worked on (which were not more than about 200 MHz), 
I didn't have nearly as many as one capacitor per power pin, and I 
scattered them around to a fair extent.  So my "gut feeling" gave me a 
similar result in the end.


Article: 149818
Subject: Re: Synthesis/place and route with Solid-State Drives
From: jc <jcappello@optimal-design.com>
Date: Thu, 25 Nov 2010 05:29:33 -0800 (PST)
Links: << >>  << T >>  << A >>

> Upgrade to Linux...
>
> Petter
>

You won't find me defending windows for its lack of robustness (among
other nuisances), and I understand the impact Linux has had on EDA and
general development environments, but I did notice from the links
kkoorndyk provided that Xilinx' memory recommendations are identical
for Windows and Linux, at least for Virtex-5...
John




Article: 149819
Subject: Re: Brain Cramps...
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 25 Nov 2010 13:59:07 +0000
Links: << >>  << T >>  << A >>
Philippe <philippe.faes@gmail.com> writes:

> On Nov 24, 8:22 pm, rickman <gnu...@gmail.com> wrote:
>>
>> I wish I had a smart(er) editor that understood VHDL a bit more.
>
> Hi Rick,
>
> You might want to take a look at Sigasi: http://www.sigasi.com

Seconded... Although I haven't bought a license (sorry Philippe!), as
during my eval, I still kept ending up back in Emacs, I will be
recommending it to my "less text-based" colleagues :)

And I may still get one for myself for the refactoring tools.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 149820
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Thu, 25 Nov 2010 15:40:10 +0100
Links: << >>  << T >>  << A >>
jc <jcappello@optimal-design.com> writes:

>> Upgrade to Linux...
>>
>> Petter
>>
>
> You won't find me defending windows for its lack of robustness (among
> other nuisances), and I understand the impact Linux has had on EDA and
> general development environments, but I did notice from the links
> kkoorndyk provided that Xilinx' memory recommendations are identical
> for Windows and Linux, at least for Virtex-5...
> John

My comment was out of context. I was thinking about some earlier
message which indicated that it was a cost related to upgrading to
large memory support on the Windows platform. Here Linux would help. I
did not mean that Xilinx SW on Linux requires any less memory than on
Windows.

Petter
-- 
.sig removed by request. 

Article: 149821
Subject: Re: Synthesis/place and route with Solid-State Drives
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 25 Nov 2010 16:35:12 +0100
Links: << >>  << T >>  << A >>
On 24/11/2010 22:22, Petter Gustad wrote:
> Benjamin Couillard<benjamin.couillard@gmail.com>  writes:
>
>> Do you have a suggestion for Linux? For example, can we use Ubuntu or
>> should we stick with the "Xilinx-approved" linux flavors?
>

I have no experience with fpga design in Linux, but if Xilinx approves 
Red Hat, then Fedora, Centos or Scientific Linux would alternatives that 
are pretty close to Red Hat enterprise versions.

I'd avoid SUSE at the moment, even if it's approved by Xilinx - it's 
future is somewhat insecure.


> I would suggest that you use the Xilinx approved ones. However, I've
> used mostly Gentoo Linux with both Altera and Xilinx (as well as with
> lots of Synopsys software), which have worked quite well. There has
> been times where I've hacked some of the scripts which tries to detect
> the platform type, mostly it's the installation software which have
> caused problems.
>
> I tend to use a script based flow. I only use the GUI occasionally,
> hence my usage might be somewhat "nicer" than the typical Windows
> user.
>
> But I always keep a Red Hat installation in VirtualBox so that I can
> verify any problems before I report them and then say "yes" if I'm
> asked if I'm on a supported operating system.
>
> Petter


Article: 149822
Subject: Readback of the Virtex5 configuration
From: Kastil Jan <ikastil@stud.fit.vutbr.cz>
Date: Thu, 25 Nov 2010 16:51:57 +0100
Links: << >>  << T >>  << A >>
Hi all,
I am trying to build external SEU generator for our experimental purposes. 
The basic idea is similar to the SEU generation makro from Xilinx, the 
only difference is that I want to generate SEU through JTAG interface (so 
the generator is not able to damage itself).
The generator requires to readback the configuration frame from the FPGA, 
make some change (only one bit to simulate SEU) and write it back. 
Unfortunatelly, I failed in the first part. I am not able to readback 
anything from the FPGA. I am using the ML506 development board and I am 
sure I missed something essential. I am hoping, that there is someone who 
has any experiences with the readback and is able to tell how I could 
readback something from FPGA (configuration prefferably).
I am trying to use chipscope to readback status register from the FPGA as 
it is described in UG191 table 7-5 (I readed also AppNote138 and 139) but 
I receive only IDcode of the device:

I open the connection to the JTAG and it works (I am able to reconfigure 
device)
set Chain [csejtag_tap autodetect_chain $handle $CSEJTAG_SCAN_DEFAULT] 
;#discover all JTAG chain connected to the cable

    set CFG_IN   "3C5"   ;# define instruction for JTAG controller
    set CFG_OUT  "3C4"
    set DUMMY    "FFFFFFFF"
    #bitstream commands
    set SYNC     "AA995566"
    set NOP      "20000000"
    set READSTAT "2800E001"
    #step1
    csejtag_tap navigate $handle $CSEJTAG_TEST_LOGIC_RESET 5 0 ;# Resets 
JTAG controller
    csejtag_tap navigate $handle $CSEJTAG_RUN_TEST_IDLE 0 0 ;# Resets JTAG 
controller
    csejtag_tap navigate $handle $CSEJTAG_SELECT_IR_SCAN 0 0 ;# Resets JTAG 
controller
    csejtag_tap navigate $handle $CSEJTAG_SHIFT_IR 0 0 ;# Resets JTAG 
controller
    #step2
    csejtag_tap shift_device_ir $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SELECT_DR_SCAN 0 10 $CFG_IN   ;#Loads CFG_IN into the 
configuration register of the JTAG
    csejtag_tap navigate $handle $CSEJTAG_SHIFT_DR 0 0
    #step3
    csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SHIFT_DR 0 32 $SYNC
    csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SHIFT_DR 0 32 $NOP
    csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SHIFT_DR 0 32 $READSTAT
    csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SHIFT_DR 0 32 $NOP
    csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SELECT_IR_SCAN 0 32 $NOP
    csejtag_tap navigate $handle $CSEJTAG_SHIFT_IR 0 0
    #step4
    csejtag_tap shift_device_ir $handle 4 $CSEJTAG_SHIFT_WRITE 
$CSEJTAG_SELECT_DR_SCAN 0 10 $CFG_OUT
    csejtag_tap navigate $handle $CSEJTAG_SHIFT_DR 0 0
    #step5
    set stat [ csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_READ 
$CSEJTAG_SELECT_IR_SCAN 0 32 $DUMMY]
    puts $stat
    puts $DUMMY

Thank you for any help or related comment.
Jan

Article: 149823
Subject: Re: PlanAhead
From: Kastil Jan <ikastil@stud.fit.vutbr.cz>
Date: Thu, 25 Nov 2010 16:57:48 +0100
Links: << >>  << T >>  << A >>
On Wed, 24 Nov 2010, Roger wrote:

>
>
> "Chris Maryan"  wrote in message 
> news:6092db29-96e8-45ce-8870-9069272dc561@o4g2000yqd.googlegroups.com...
>
> On Nov 23, 5:00 pm, "Roger" <rogerwil...@hotmail.com> wrote:
>>  The latest Xilinx PlanAhead seems to do everything that a project needs
>>  from
>>  VHDL input to bit stream. So what's ISE for now?
>>
>>  Thanks,
>>  Rog.
>
> My understanding is that the plan is for PlanAhead to replace ISE.
> Though I'm not sure at what point this will happen.
>
> Chris
>
> Chris,
>
> Thanks for the reply. I suspected this might be the case. Did you hear this 
> from Xilinx?
>
> Rog. 
>
I do not have the experience with the newest PlanAhead but we tried the 
dynamic reconfiguration on the ISE11 with PlanAhead and it was not 
possible to turn RTL project into partial reconfiguration flow. So i 
suspect, that the ISE and planAhead will be moving in different direction. 
But it is just my understanding, maybe it was just a bug.

Jan

Article: 149824
Subject: Re: Atom 6000C perspective, anyone?
From: Michael S <already5chosen@yahoo.com>
Date: Thu, 25 Nov 2010 08:49:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 3:01=A0pm, gnirre <gni...@gmail.com> wrote:
> On Nov 24, 12:03=A0am, Thomas Entner <thomas.ent...@entner-
>
>
>
> So Stellarton is basically a product that is the optimal choice for
> almost no application, almost always too small, or too expensive.
>
> So why did Intel have this one built?

Being cynical, because they have MCM technology.
Unlike current generation, Intel's next generation desktop/laptop
processors are single die so the MCM packaging guys @Intel will have
to go unless there is something new to keep them busy.

> Who ordered it? Which is the One
> Single App

The whole point behind the combo is : Not One App But Many.

> where an Atom E and 60 000 fpga gates is the optimal
> combination?
>
> - Jan T=E5ngring, journalist

~60,000 equivalent logic elements. That's something like 1.5M to 2M
gates just in fabric without counting embedded memory, multipliers,
"hard" PCIe IP block, transceivers etc...
Intel site doesn't tell us which Altera chip they are using, but from
description it looks like EP2AGX65.





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