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 90100

Article: 90100
Subject: Systolic array architectures
From: timotoole@gmail.com
Date: 4 Oct 2005 15:42:56 -0700
Links: << >>  << T >>  << A >>
Systolic array architectures are commonly used for image/video
compression hardware blocks (e.g. convolution filters, motion
estimation,
etc).  I loosely have an idea that this is because they are efficient
at
reusing the data, and thus reduce memory accesses in comparsion to say
a
custom designed high throughput singular processing element. Would this
be generally considered the princicpal benefit and are there other
benefits?

I have read that they are considered "i/o bandwidth efficient", I guess
thats just another way of saying what I've just outlined above?

Is there ever scenario's where the area and switching overhead of a
systolic array would warrant a less bandwidth efficient, more serial
approach - or is that just plain ridulous to consider?
For example could you hope to trade less switching in the datapath for
increased switching in the memory accesses but still make an overall
reduction in switching?


Looking forward to any comments/flames/rants  :-)


Article: 90101
Subject: Re: How to make XST understand to pack mux(A,B,A+B) in a single level ?
From: quark01@gmail.com
Date: 4 Oct 2005 16:22:00 -0700
Links: << >>  << T >>  << A >>
>
> .                            cout
> .                            _|_
> .                        ,--/___\ CYMUX
> .                        |   | |
> .                ______  |   | |
> . a(b) ---------|      | |   | |     ____  XORCY
> . b(n) ------x--| LUT4 |-x----------\\   \_____
> . pt_n ---x--|--|      |     | x----//___/
> . sel  ---|--|--|______|     | |
> .         |  |              /  |
> .         |  |       __    /   |
> .         |  '------|  \ _/    cin
> .         '---------|__/
> .                  MULT_AND

I wanted something similar but could not get the
synthesis tool to generate the circuit, so I instantiated
my own.. here it is, you can change the INIT values of the
LUT to get what you want.

-----------------------------------------------------------
-- MUX_ADD_VECTOR - when ADD = '1' add O = A + B else O = C
-----------------------------------------------------------
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 MUX_ADD_VECTOR is

    generic (WIDTH : integer := 32;
             SLICE : integer := 1);

    port (A   : in  std_logic_vector (WIDTH-1 downto 0);
          B   : in  std_logic_vector (WIDTH-1 downto 0);
          C   : in  std_logic_vector (WIDTH-1 downto 0);
          ADD : in  std_logic;
          O   : out std_logic_vector (WIDTH-1 downto 0));

end MUX_ADD_VECTOR;

architecture XILINX_virtex of MUX_ADD_VECTOR is
    component LUT4_L
        generic(INIT : bit_vector);
        port   (LO   : out STD_ULOGIC;
                I0   : in  STD_ULOGIC; I1 : in STD_ULOGIC;
                I2   : in  STD_ULOGIC; I3 : in STD_ULOGIC);
    end component;

    component MUXCY_L
        port(LO : out STD_ULOGIC; CI : in STD_ULOGIC;
             DI : in  STD_ULOGIC; S  : in STD_ULOGIC);
    end component;

    component XORCY
        port(O  : out STD_ULOGIC;
             CI : in  STD_ULOGIC; LI : in  STD_ULOGIC);
    end component;

    component MULT_AND
        port(LO : out STD_ULOGIC;
             I0 : in  STD_ULOGIC; I1 : in  STD_ULOGIC);
    end component;

-------------------------------------------------------
--                            Input mapping for LUTs
-------------------------------------------------------
--              I0      -> A (i)
--              I1      -> ADD
--              I2      -> B(i)
--              I3      -> C(i)
--              LO      -> otemp(i)
-------------------------------------------------------
--      C(i)    B(i)    ADD     A(i)   LO -> Output
-------------------------------------------------------
--      X       0       1       0      INIT[2,A] -> 0
--      X       0       1       1      INIT[3,B] -> 1
--      X       1       1       0      INIT[6,E] -> 1
--      X       1       1       1      INIT[7,F] -> 0
--      0       X       0       X      INIT[0,1,4,5] -> 0
--      1       X       0       X      INIT[8,9,C,D] -> 1
--------------------------------------------------------------
--      INIT            F E D C - B A 9 8 - 7 6 5 4 - 3 2 1 0
--                      0 1 1 1   1 0 1 1   0 1 0 0   1 0 0 0   -->
X"7B48"
--------------------------------------------------------------

    signal otemp : std_logic_vector (WIDTH-1 downto 0);
    signal mando : std_logic_vector (WIDTH-1 downto 0);
    signal carry : std_logic_vector (WIDTH   downto 0);

    attribute BEL : string;

begin  -- XILINX_virtex

    carry(0) <= '0';

    mux_add: for i in 0 to WIDTH-1 generate
        constant row : integer := (WIDTH/2) - i/2 - 1;
        attribute INIT of mux_add_lut4_inst : label is "7B48";
    begin

        mux_add_lut4_inst : LUT4_L
            generic map (INIT => X"7B48")
            port map (I0 => A(i), I1 => ADD,
                      I2 => B(i), I3 => C(i),
                      LO => otemp(i));

        mux_add_mand_inst : MULT_AND
            port map (I0 => A(i), I1 => ADD, LO => mando(i));

        mux_add_mxcy_inst : MUXCY_L
            port map (DI => mando(i), CI => carry(i),
                      S  => otemp(i), LO => carry(i+1));

        mux_add_xorc_inst : XORCY
            port map (CI => carry(i), LI => otemp(i), O  => O(i));
    end generate mux_add;

end XILINX_virtex;

Quark....


Article: 90102
Subject: Re: EasyPath, demystified
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 04 Oct 2005 16:36:39 -0700
Links: << >>  << T >>  << A >>
Adam,

The "stuck at fault" testing is extremely high:  we carefully examine 
test patterns for their IC design shcematic coverage.

Even the generic FPGA flow test coverage is much better than an ASIC.

Austin


> Er, really?  I thought you had to pay extra for the 100% tested ones.
> Does Xilinx really test every net on every chip for (say) stuck-at
> faults before shipping?
> 
>   - a
> 

Article: 90103
Subject: Re: EasyPath, demystified
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 04 Oct 2005 16:43:03 -0700
Links: << >>  << T >>  << A >>
Ben,

-snip-
> 
> 
> So, can I then summarize that EasyPath is basically a standard Virtex II/4
> but with less time on the testbed (only the cells and routing used by the
> customer are tested) in order to reduce cost?

There is a basic 1's, 0's, shorts, leakage, etc test done to all parts, 
EasyPath or no.

And then, for EasyPath, only those features used by the customer are 
tested (with the addition of any LUT pattern for the CLBs they use, and 
any IO strength for th IOB standard they use, which allows for the two 
most common ECO requests we got after we shipped).  The difference in 
test time between as close as we can get to 100% testing for any 
possible use, and as close as we can get to 100% testing for one use is 
SIGNIFICANT.

As well, the test yield to one test program is also SIGNIFICANTLY HIGHER 
than for many thousands of test programs (which is potentially what it 
takes to have an acceptable AQL).

Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower 
Prices to customer.

Austin

Article: 90104
Subject: I'm desperate... EDK project simulation
From: mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille)
Date: Tue, 04 Oct 2005 19:16:46 -0500
Links: << >>  << T >>  << A >>
Hello!

I have a system implemented in hardware and I prototyped it in
VIrtex-II Pro platform with a testbench. I analyzed the signals using
chipscope and it worked the same as in simulation. After this, I
created a project in EDK and substituted the testbench by a
Microblaze processor. The project stopped working. Now, I need to
debug the harwdare in order to find the problem, ut I don't know how
to do this. I'm trying to use ModelSim.
In fact, I generated the simulation files and created the testbench
file to stimulate my system. However, this testbench just generates
the clock and reset, so I need instanciate my software in order to
generate the other stimulus. Is it possible? What do I have to do in
order to incorporate my software in simulation? Does anyone can help
me? 

Thank you! 

Melissa


Article: 90105
Subject: Re: EasyPath, demystified
From: "johnp" <johnp3+nospam@probo.com>
Date: 4 Oct 2005 17:32:24 -0700
Links: << >>  << T >>  << A >>
Ben -

Although I haven't used Xilinx' EasyPath product, it makes a fair
amount
of sense.  I've used V2Pro parts for a while, but I don't care about
or use the PowerPC processor I get in the the part.  EasyPath would
let me get cheaper parts in volume for 2 reasons -

a) Xilinx doesn't even have to test the PPC core in parts they would
ship
to me.  They save dollars because of chip test time saving.

b) Xilinx could send me parts with dead PPC cores since I don't use
that feature.  I assume the PPC core takes a reasonable amount of
silicon area, so it would have a reasonable chance of having a
defect.  Those 'dead' chips are currently lost revenue to Xilinx, the
incremental cost to sell them to me is fairly low.

I don't know how the EasyPath cost compares to the Altera HardCopy2,
but it sure makes sense that EasyPath could offer nice savings for
the volume user and additional profit for Xilinx.  A win-win situation.

John Providenza


Article: 90106
Subject: Re: Avoiding meta stability?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 05 Oct 2005 01:30:12 GMT
Links: << >>  << T >>  << A >>
Peter - 

A few comments:

 - You can run your design at only 24 MHz?  And you have an extra 3ns?
Luxury!

 - A circuit may fail only once every billion years, but the failure
will always occur when the customer is present.

 - You can forget about metastability, but metastability will never
forget about you.

Take care,
Bob Perlman
Cambrian Design Works

On 4 Oct 2005 13:21:55 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>"Metastability" is a popular word to scare inexperienced designers.
>
>If you run a 1.8 MHz clock (even with a similar asynchronous data
>rate), your chance of having a 3 ns extra metastable delay is once per
>billion years (at 24 MHz it would be only 5 million years).
>For every additional ns of acceptable settling time, the
>mean-time-between-failure increases at least a million times. (see
>XAPP094 on the Xilinx website)
>The probability of your flip-flop failing during the life of this
>universe (even if you do nothing) with more than 10 ns of
>unaccounted-for delay is so minute it is practically zero.
>There are more important things to worry about, forget metastability...
>Peter Alfke, Xilinx Applications (who actually has created quantitative
>data about metastability)


Article: 90107
Subject: Re: Floating point multiplication on Spartan3 device
From: "codejk" <codejk@gmail.com>
Date: 4 Oct 2005 19:35:46 -0700
Links: << >>  << T >>  << A >>
Thank you for your interest.
I want to get the result on each 80 ns.
(pipeline can be used.)
Sorry but since I have worked with xilinx devices several years,
I have no experience about MicroBlaze.
So could you plz recommend some materials about MicroBlaze?


Article: 90108
Subject: Re: EasyPath, demystified
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Tue, 04 Oct 2005 19:51:31 -0700
Links: << >>  << T >>  << A >>

Austin Lesea <austin@xilinx.com> writes:
> Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower
> Prices to customer.

I'm assuming it's mostly "better yield", though, right?  I mean,
Atmel's chips can 100% test themselves (they'll even give you the
bitstream that does it), and I'd bet that the XC6200 could've (or
probably even did).

Isn't the test time just a matter of "assembly line latency" rather
than "assembly line throughput"?  It shouldn't be like an ASIC where
you need a separate, active device to test it and those devices are in
short supply.

Forgive me if this sounds stupid.  My knowledge gets pretty fuzzy down
at the fabrication/process level.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Article: 90109
Subject: XMD and xilmfs help
From: "Joseph" <joeylrios@gmail.com>
Date: 4 Oct 2005 20:28:49 -0700
Links: << >>  << T >>  << A >>
Hello,

I have a board with 256M of RAM and a V2P30.  Designed a simple system
in EDK with the RAM partitioned into 2 equal parts.  Compiled a .elf to
live in one half and want to use the other half for a filesystem.  The
.elf runs fine in the sense that I get the "Usage: " message from it
via the UART when it realizes it doesn't have any input files.  I have
trouble when I try and incorporate the filesystem.  I am using xilmfs
so I generated a .mfs with a couple dummy files in it.  Now if I use
XMD to first download the elf, it works fine (as described above -- I
can run it over and over again)  but when I download the .mfs, it
ceases to work ('run' produces nothing via stdout -- I think it is
spinning somewhere in a few lines of code).  I am careful about the
address supplied to the 'dow' command and am using the -data flag.  A
wierd effect of the .mfs download is that the pc is reset to 0x0000cfd4
instead of to 0xfffffffc when I type 'run' at XMD prompt.  Trying to
set the pc manually doesn't help ('rwr' then 'con').  I get the feeling
that the .elf is getting stomped by the .mfs even though it really
doesn't know anything about that region of memory (I am pretty sure I
got the linker script right).

I could easily babble quite a bit more about this, but will leave it
here.  If any further info would help you help me, let me know!  I
appreciate any advice...

Joey


Article: 90110
Subject: Re: Xilinx dev board with high quality video?
From: "Jecel" <jecel@merlintec.com>
Date: 4 Oct 2005 20:37:17 -0700
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
> With every board that is designed you have to make some trade offs
> between peripherals, performance, power and cost.  The ML401/2/3
> boards are loaded with features at a very reasonable price point
> and in order to do that we had to make some compromises in certain
> areas.

Indeed these boards are a great value and far cheaper than what it
would cost me to build something similar, which is not common for
development kits. Thank you for your explanation. I hadn't notice the
15 bit per pixel llimitation of the ML403.

I am still deciding if it is worth doing the extra VGA board - an
alternative is to reduce the vertical refresh to 56 Hz or something
like that.

-- Jecel


Article: 90111
Subject: Re: EasyPath, demystified
From: Ray Andraka <ray@andraka.com>
Date: Tue, 04 Oct 2005 23:47:14 -0400
Links: << >>  << T >>  << A >>
Adam Megacz wrote:

>Austin Lesea <austin@xilinx.com> writes:
>  
>
>>Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower
>>Prices to customer.
>>    
>>
The point is, the easy path parts are not known defects, they are simply 
not tested as rigorously as the non-easy-path parts.  Basically, they 
reduce the test program to test only what your bitstream actually uses 
in the design (and some testing of other unused logic, but not nearly as 
rigorous).  The result is significantly reduced testing time and 
increased yield, which translates into a cost savings.  What they 
guarantee that way is only that it will work with your bitstream.  It 
could be a perfectly good part, or it could have a defect somewhere 
where it doesn't affect your design.  No one knows, because no one 
tested it.

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



Article: 90112
Subject: Re: Xilinx dev board with high quality video?
From: "Jecel" <jecel@merlintec.com>
Date: 4 Oct 2005 20:53:18 -0700
Links: << >>  << T >>  << A >>
Antonio Pasini wrote:
> > I have done the "tie all grounds together" mistake myself, so I know
> > how you feel.
>
> Jecel, could you give me some advice on this ?  Same application; maybe
> using TI THS8133.

This was a long time ago using the original ARM chipset. The video was
only 24MHz, so it was hardly high speed by today's standards. Though I
knew that the analog part should have separate power and ground I was
busy with other things and didn't correct the layout guy when he failed
to do this. The running programs generate a very visible pattern on the
display and even in the speaker. At least this made debugging a little
easier ;-)

If you use all 10 bits available in the THS8133 instead of just 8
(24bpp) then I imagine it is even more important to get rid of the
noise or else you might as well use the cheaper THS8134B instead.

-- Jecel


Article: 90113
Subject: Re: Radiation + CoolRunner2 CPLD?
From: rk <stellare@nospamplease.comcast.net>
Date: Tue, 04 Oct 2005 23:12:56 -0500
Links: << >>  << T >>  << A >>
Perhaps of some interest (subset of this presentation)

"The NSEU Response of Static Latch Based FPGAs"

original title on abstract: "The Continuing Impact of Design and Process 
Hardening on the NSEU Sensitivity of Advanced CMOS PLD Technologies"

Joseph J Fabula and Austin Lesea, Xilinx
2005 MAPLD International Conference
September 7-9, 2005, Washington, D.C.

Abstract:     http://klabs.org/mapld05/abstracts/175_fabula_a_.html
Presentation: http://klabs.org/mapld05/presento/175_fabula_p.pdf

-- rk


Austin Lesea wrote:

> (Real) Bob,
> 
> Thanks for sending to me directly.
> 
> There is an aerospace/defense FAE who will contact you shortly to 
> provide you with what you need (if we have what you need).
> 
> I know we had Coolrunner II in the LANSCE facility in May of this year, 
> as it was my group that set it up, and was there for the testing.
> 
> (surreal) Austin
> 
> Bob wrote:
> 
>> Sorry I don't use (real) info on newsgroups to keep spam to a minimum.
>> I will email you with my (real) contact info.
>> However I have tried before and was told that there was no info on the
>> CoolRunner 2 as it is not intended for radiation and there are other
>> parts that are designed for radiation. However that was last year.
>> I have also searched on the NASA and ERRIC web sites and was
>> unsuccessful in finding data.
>> 
>> 
>> On Tue, 04 Oct 2005 11:55:47 -0700, Austin Lesea <austin@xilinx.com>
>> wrote: 
>> 
>> 
>>>(Not Real) 'Bob',
>>>
>>>If you want an answer to this, why haven't you already contacted our 
>>>Xilinx Aerospace/Defense Field Applications Engineers?
>>>
>>>We have plenty of data that we are willing to share with (Real)
>>>'customers'. 
>>>
>>>If you need a contact, I can send their name to you once you email me 
>>>your (Real) 'Bob' email address (and real affiliation).
>>>
>>>It is Xilinx' interest to be sure that any aerospace/defense application
>>>(as well as any other) of our products uses all of the best information 
>>>that we can provide.
>>>
>>>Austin
>>>
>>>
>>>
>>>Bob wrote:
>>>
>>>
>>>>Hi I know that the CoolRunner2 CPLD TQ144, XC2C256-7TQ144I is not
>>>>designed to be radiation tollerent, but...
>>>>
>>>>I would be interested if anyone reading this has ever radiated a CPLD
>>>>or know of some CPLD radiation data on the web.
>>>>I have google searched but found very little.
>>>>Most ics like 74hc04 parts can take about 10,000 or more rads of total
>>>>dose (Co60).
>>>>I hope to do some total dose testing this month.
>>>>Also as it has a reprogramable memory, it will be suseptible to SEU.
>>>>I wont be able to test for that.
>>>>
>> 
>> 



-- 
rk, Just an OldEngineer
"These are highly complicated pieces of equipment almost as complicated as 
living organisms. In some cases, they've been designed by other computers.  We 
don't know exactly how they work."
-- Scientist in Michael Crichton's 1973 movie, Westworld

Article: 90114
Subject: Re: Avoiding meta stability?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 4 Oct 2005 21:23:59 -0700
Links: << >>  << T >>  << A >>
Bob, I agree with everything you wrote, but the original posting
mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a
typical modern design...
I think we would agree that such a slow design will, almost inevitably,
have a few ns slack to accomodate a possible metastable delay.
If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data
stream, the problem is much more real.
I am so happy that we went to the trouble of measuring the delays on
real (V2Pro) silicon, same as we had done with XC4000 years before.
That gives us quantitative data. Less arm-waving.

The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...
Peter Alfke


Article: 90115
Subject: Where to get informations about Virtex 4 FX Engineering Samples
From: Peter Rauschert <usenet@rauschert-online.de>
Date: Wed, 05 Oct 2005 08:10:05 +0200
Links: << >>  << T >>  << A >>
Hi!

I just asked my distributor for availiable Xilinx XC4VFX devices and
found an XC4VFX20-10FF672CES2. 

Since I guess that ES means "Engineering sample", I was looking for
informations about its limitations compared to the final device. But
unluckily I failed.

Maybe someone can give me a hint where to get these informations?

Since I was inititally looking for a XC4VFX40, I figured out that this
is not available currently. Is this right? Does someone know when this
device gets available?

Thank you very much,
Peter

Article: 90116
Subject: Re: I'm desperate... EDK project simulation
From: Zara <yozara@terra.es>
Date: Wed, 05 Oct 2005 06:17:16 GMT
Links: << >>  << T >>  << A >>
On Tue, 04 Oct 2005 19:16:46 -0500,
mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille) wrote:

>Hello!
>
>I have a system implemented in hardware and I prototyped it in
>VIrtex-II Pro platform with a testbench. I analyzed the signals using
>chipscope and it worked the same as in simulation. After this, I
>created a project in EDK and substituted the testbench by a
>Microblaze processor. The project stopped working. Now, I need to
>debug the harwdare in order to find the problem, ut I don't know how
>to do this. I'm trying to use ModelSim.
>In fact, I generated the simulation files and created the testbench
>file to stimulate my system. However, this testbench just generates
>the clock and reset, so I need instanciate my software in order to
>generate the other stimulus. Is it possible? What do I have to do in
>order to incorporate my software in simulation? Does anyone can help
>me? 
>
>Thank you! 
>
>Melissa

For me, the best way to debug hardware with a microblaze inside is to
instantiate a ChipSocpe icon and ila inside the design, connected to
the secondary bscan port of an opb_mdm connected to the microblaze.
This way, you may debug hardware or software (not simultaneously)
easily.


Article: 90117
Subject: Re: I'm desperate... EDK project simulation
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 05 Oct 2005 08:20:07 +0200
Links: << >>  << T >>  << A >>
Melissa Vetromille wrote:
> Hello!
> 
> I have a system implemented in hardware and I prototyped it in
> VIrtex-II Pro platform with a testbench. I analyzed the signals using
> chipscope and it worked the same as in simulation. After this, I
> created a project in EDK and substituted the testbench by a
> Microblaze processor. The project stopped working. Now, I need to
> debug the harwdare in order to find the problem, ut I don't know how
> to do this. I'm trying to use ModelSim.
> In fact, I generated the simulation files and created the testbench
> file to stimulate my system. However, this testbench just generates
> the clock and reset, so I need instanciate my software in order to
> generate the other stimulus. Is it possible? What do I have to do in
> order to incorporate my software in simulation? Does anyone can help
> me? 
> 
> Thank you! 
> 
> Melissa
> 


If your tb entity name is Test_sim and if your EDK system instance is
UUT, add this to your testbech :

configuration tb_conf of Test_sim is
        for testbench_arch
                for UUT: system
                        use configuration work.system_conf;
                end for;
        end for;
end tb_conf;


Also, simulate the tb_conf configuration and not just your test bench
entity. (when selecting what to simulate).
EDK will also create a system.do or a .do to load everything needed IIRC.



	Sylvain

Article: 90118
Subject: Re: Where to get informations about Virtex 4 FX Engineering Samples
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 5 Oct 2005 08:28:34 +0200
Links: << >>  << T >>  << A >>
"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag
news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com...
> Hi!
>
> I just asked my distributor for availiable Xilinx XC4VFX devices and
> found an XC4VFX20-10FF672CES2.
>
> Since I guess that ES means "Engineering sample", I was looking for
> informations about its limitations compared to the final device. But
> unluckily I failed.
>
> Maybe someone can give me a hint where to get these informations?
>
> Since I was inititally looking for a XC4VFX40, I figured out that this
> is not available currently. Is this right? Does someone know when this
> device gets available?
>
> Thank you very much,
> Peter

Hi,

Talk more to your disti, they should be able to get you shipping date (we
did) for FX40 (no ES), another thing if you will happy with that. As of
today all FX parts that may be available are ES. Again pressure your disti,
Xilinx may be able to ship the parts you need, even if they dont show as
available by the disti-first look

Antti



Article: 90119
Subject: Re: EasyPath, demystified
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 05 Oct 2005 08:33:41 +0200
Links: << >>  << T >>  << A >>
Hi Austin,

>> So, can I then summarize that EasyPath is basically a standard Virtex
>> II/4 but with less time on the testbed (only the cells and routing used
>> by the customer are tested) in order to reduce cost?
> 
> There is a basic 1's, 0's, shorts, leakage, etc test done to all parts,
> EasyPath or no.

Of course. The global die specs must be met.

> And then, for EasyPath, only those features used by the customer are
> tested (with the addition of any LUT pattern for the CLBs they use, and
> any IO strength for th IOB standard they use, which allows for the two
> most common ECO requests we got after we shipped).  The difference in
> test time between as close as we can get to 100% testing for any
> possible use, and as close as we can get to 100% testing for one use is
> SIGNIFICANT.

Sounds quite reasonable. So, technologically there's nothing holding Altera
back in investing in a few extra ("standard") device testers and, as an
intermediate price-reduction step, doing same under the hereby trademarked
name "Crippledie" (come to think of it, sounds great as the title of an
ultra-violent FPS game taking place in a hospital or a leper colony too -
I'll have a chat with my local EA Games marketing guy).

I can't imagine that only partially testing an ASIC is patentable - but then
again, one-click-shopping is patentable as well according the USPTO so I
wouldn't be surprised.

Then of course there's HardCopy2, which, like EasyPath, only needs to be
tested with the user design _but also_ is a lot smaller in die size. 

Thus:

Better Yield+Shorter Time+Smaller Area = Even Lower Cost to Altera, which
means even Lower Prices to customer. No ECO and no last-minute changes
though, I'll give you that.

Am I right?

Best regards,



Ben


Article: 90120
Subject: Re: vhdl question
From: "CMOS" <manusha@millenniumit.com>
Date: 5 Oct 2005 00:00:46 -0700
Links: << >>  << T >>  << A >>
what im asking is, we have "clock", which is an input to the entity and
a signal called "clk" declared in the entity. The input "clock" is
mapped to the signal "clk". In all other places only "clk" is used, but
"clock" is never used. What is the difference of doing this from just
using "clock" everywhere and eliminating "clk" altogether? 

CMOS


Article: 90121
Subject: Re: Where to get informations about Virtex 4 FX Engineering Samples
From: Peter Rauschert <usenet@rauschert-online.de>
Date: Wed, 05 Oct 2005 09:49:58 +0200
Links: << >>  << T >>  << A >>
Hi Antti!

I just checked the website of AVNET for availability. Guess its a good
thing to call them.

Do you have informations concerning  the special properties of the
Virtex 4 Engineering Samples?

Peter

>"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag
>news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com...
>> Hi!
>>
>> I just asked my distributor for availiable Xilinx XC4VFX devices and
>> found an XC4VFX20-10FF672CES2.
>>
>> Since I guess that ES means "Engineering sample", I was looking for
>> informations about its limitations compared to the final device. But
>> unluckily I failed.
>>
>> Maybe someone can give me a hint where to get these informations?
>>
>> Since I was inititally looking for a XC4VFX40, I figured out that this
>> is not available currently. Is this right? Does someone know when this
>> device gets available?
>>
>> Thank you very much,
>> Peter
>
>Hi,
>
>Talk more to your disti, they should be able to get you shipping date (we
>did) for FX40 (no ES), another thing if you will happy with that. As of
>today all FX parts that may be available are ES. Again pressure your disti,
>Xilinx may be able to ship the parts you need, even if they dont show as
>available by the disti-first look
>
>Antti
>


Article: 90122
Subject: re:Xilinx ISE WebPACK-7.1i on NetBSD
From: doconnor@gsoft.com-dot-au.no-spam.invalid (Darius)
Date: Wed, 05 Oct 2005 03:15:50 -0500
Links: << >>  << T >>  << A >>
I've found out how to prevent the delays.. If you run rpcbind with the
-i (insecure..) flag, there is no delay. (Well this is with BaseX but
I don't see why it would be any different for WebPack)

Still trying to figure out why my file dialogs complain about long
paths though..


Article: 90123
Subject: Re: vhdl question
From: "Nicolas Matringe" <nic_o_mat@msn.com>
Date: 5 Oct 2005 01:17:25 -0700
Links: << >>  << T >>  << A >>
CMOS wrote:
> what im asking is, we have "clock", which is an input to the entity and
> a signal called "clk" declared in the entity. The input "clock" is
> mapped to the signal "clk". In all other places only "clk" is used, but
> "clock" is never used. What is the difference of doing this from just
> using "clock" everywhere and eliminating "clk" altogether?

I'd ask the question the other way round: why not call the input port
'clk'?

Nicolas


Article: 90124
Subject: Re: Where to get informations about Virtex 4 FX Engineering Samples
From: "zeeman_be" <zeemanbe@gmail.com>
Date: 5 Oct 2005 02:44:43 -0700
Links: << >>  << T >>  << A >>
Hi Peter,

check the page with errata on xilinx-website :
http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-1210882&iLanguageID=1

Best regards,
Bart




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