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 28875

Article: 28875
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip multiprocessor!
From: erika_uk@my-deja.com
Date: Fri, 26 Jan 2001 21:23:18 GMT
Links: << >>  << T >>  << A >>


hello,

what about us in europe ?

Erika

In article <G9kc6.1332$23.181745@dfiatx1-snr1.gtei.net>,
  "Jan Gray" <jsgray@acm.org> wrote:
> Yesterday's XtremeDSP Simulcast was excellent. Well, what do you
know -- the
> promised "...delicious plate ... of goodies ... " was not just
hyperbole.
> Here are some impressions and speculations.
>
> 1. We FMAP'ing/RLOC'ing dinosaurs shouldn't feel so bad. We may soon
be
> joined by the Verilog/VHDL dinosaurs.
>
> 2. There are a ton of compelling applications of 100K logic cells and
100s
> of multipliers. Time to crack open a signal processing textbook.
>
> 3. With the new buffered programmable interconnect, that graph of
number of
> net loads, to ns delay, was pretty darn flat...
>
> 4. There were a couple of hints that there might be another tier of
on-chip
> RAM coming -- perhaps suitable for storing an entire frame. Great --
but
> multiported, or at least multibanked would be nice -- and please,
don't
> count such a RAM as a zillion system gates. :-)
>
> 5. XCITE is awesome. I looked around our downlink site and 'most every
> attendee was grinning and/or nodding (though not quite high-fiving).
In some
> circumstances you can even use the XCITE controlled impedance
technology to
> parallel terminate inputs from other unterminated drivers.
>
> 6. Erich Goetting, Xilinx VP, revealed the forthcoming Virtex-II with
> PowerPC and multiple 3.125 Gbps links will be called Virtex-II Pro.
>
> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
> interface to.
>
> 8. I loved the hypothetical (?) die layout diagram of a Virtex-II Pro
part
> with *four* embedded PowerPC cores. Coooool. Here I was thinking that
soft
> cores might be relevant as chip-multiprocessors
> [http://www.fpgacpu.org/usenet/soft.html] -- but perhaps not if the
world
> embraces hard core chip-multiprocessors embedded in the programmable
logic
> fabric.
>
> Very nice work, Xilinxers!
>
> With a multi-hundred-million-transistor budget to play with, it will
be
> quite fascinating to see what Virtex-II 'immerses' next. I can think
of
> several interesting hard cores.
>
> Jan Gray, Gray Research LLC
> FPGA CPU News: www.fpgacpu.org
>
>


Sent via Deja.com
http://www.deja.com/

Article: 28876
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Jan 2001 21:31:58 GMT
Links: << >>  << T >>  << A >>


Jan Gray wrote:
> 
> Yesterday's XtremeDSP Simulcast was excellent. Well, what do you know -- the
> promised "...delicious plate ... of goodies ... " was not just hyperbole.
> Here are some impressions and speculations.
> 
> 1. We FMAP'ing/RLOC'ing dinosaurs shouldn't feel so bad. We may soon be
> joined by the Verilog/VHDL dinosaurs.

ROTFL!!!!

> 
> 2. There are a ton of compelling applications of 100K logic cells and 100s
> of multipliers. Time to crack open a signal processing textbook.

At least for the deep pocketed.  I thought the multipliers were a little
misrepresented.  The data book
indicates about 140 Mhz max for the 18x18.  The 200+ numbers they were showing
were for 4x4 and maybe the 8x8s.  
In the smaller devices, you don't have that many of them to play with.  Still, a
nice feature that will make
hardware DSP applications more accessible to the systems and software DSP types.

> 
> 3. With the new buffered programmable interconnect, that graph of number of
> net loads, to ns delay, was pretty darn flat...

The active interconnect is a definite plus.  Plain Virtex is way too sensitive
to loading,
especially for control signals leading into carry chains using mux_ands.  I
don't remember
the 4K loading as being nearly as sensitive.  Hopefully this is NOT and excuse
to do
away with floorplanning once again.

> 
> 4. There were a couple of hints that there might be another tier of on-chip
> RAM coming -- perhaps suitable for storing an entire frame. Great -- but
> multiported, or at least multibanked would be nice -- and please, don't
> count such a RAM as a zillion system gates. :-)
> 
> 5. XCITE is awesome. I looked around our downlink site and 'most every
> attendee was grinning and/or nodding (though not quite high-fiving). In some
> circumstances you can even use the XCITE controlled impedance technology to
> parallel terminate inputs from other unterminated drivers.

Yep, in fact people were more excited about this than the guy who won the bike
at
our location seemed to be about the winning the bike.  This is a way cool
feature,
coming from a guy that is tired of explaining why his customer has to leave an
area on
the board larger than the chip for "stupid" resistors.

> 
> 6. Erich Goetting, Xilinx VP, revealed the forthcoming Virtex-II with
> PowerPC and multiple 3.125 Gbps links will be called Virtex-II Pro.
> 

Erich looked like he was battling indigestion during his talk.  I dunno why, it
seems to 
be a solid product.  Should we all empty out our pencil drawers of any spare
Rolaids and send them to him?


> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
> interface to.

Does anybody have details on the serial interface.  Is there clock recovery
built in, so maybe it can be 
used for HDTV?

> 
> 8. I loved the hypothetical (?) die layout diagram of a Virtex-II Pro part
> with *four* embedded PowerPC cores. Coooool. Here I was thinking that soft
> cores might be relevant as chip-multiprocessors
> [http://www.fpgacpu.org/usenet/soft.html] -- but perhaps not if the world
> embraces hard core chip-multiprocessors embedded in the programmable logic
> fabric.
> 
> Very nice work, Xilinxers!
> 
> With a multi-hundred-million-transistor budget to play with, it will be
> quite fascinating to see what Virtex-II 'immerses' next. I can think of
> several interesting hard cores.
> 
> Jan Gray, Gray Research LLC
> FPGA CPU News: www.fpgacpu.org

-- 
-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  or http://www.fpga-guru.com

Article: 28877
Subject: Re: looping and ranges
From: Paul Campbell <paul@verifarm.com>
Date: Fri, 26 Jan 2001 21:54:02 +0000
Links: << >>  << T >>  << A >>
Rick Collins wrote:

>
> But now I want to do the same thing on the receive side where we need to
> use the bit vector on the left side and the byte vector on the right. So
> how do I do that without driving the compiler nuts?
> 
> output [53*8-1:0] bar;
> 
> reg[7:0] foo[1:13];
> 
> always @(bar)
>   for (j=1; j<14; j=j+1)
>      bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];
> 
> I can't do this, and I can't concatenate BAR into a byte. So am I only
> left with the original method of individual explicit byte assignments?
> 

How about something like:


        bar = {foo[1], foo[2], foo[3] .....



        Paul Campbell
        paul@verifarm.com


Article: 28878
Subject: Re: 6845
From: Reinoud <dus@casema.net>
Date: Fri, 26 Jan 2001 23:32:48 +0100
Links: << >>  << T >>  << A >>
net9147@yahoo.com wrote:
> 
> Vanted 6845 CGA crt controler in VHDL or etc...

http://www.opencores.org/cores/crtc6845/

- Reinoud

Article: 28879
Subject: Re: Foundation FPGA Editor hard macros in VHDL
From: Neil Franklin <neil@franklin.ch.remove>
Date: 26 Jan 2001 23:51:50 +0100
Links: << >>  << T >>  << A >>
mrandelzhofer@my-deja.com writes:

> I loved the old xact 6.xx fpga editor, which was originally better than
> the neocad editor.
> our team has done lots of successful xc3000/xc4003 designs just at the
> chip level.

Just like many people did successful programming at assembly language
level. HLLs may be faster, but assembly level works. Same HDLs may be
faster, but CLB level works.


> now xilinx enhanced the fpga editor, and i'd like to experience some
> small virtex designs just in the lowest design level.

You look like a candidate for JBits, mail jbits@xilinx.com to order (free).

Note that this is not an editor, but it is an Java library with an API
to modify Virtex (and equivalent size Spartan-II) bitstreams CLB by CLB,
feature by feature. That included bitstreams read direct from an powered
up but not yet configured chips. So the default interface is Java code,
but an graphical display and editor could be written.


> (No doubt, the
> high level design strategy is the more efficient way for higher
> integrated devices).

If you are prepared to take work time inefficiecy to experience low
level control, you may contemplate taking JBits as base and buidling
your ideal Virtex editor on top of it. This could even have an
real-time on-line mode, where "open" reads out an chip and "save"
writes the modification to an chip. JBits even allows run-time
reloading of CLB columns.


> - all the device specific stuff can be used, or used easier as in any
> hdl.

Only if the tool writer adds it.


> but e.g.  if you want access to all of the carry outputs of an alu in
> vhdl, you can spend hours or days to find a solution.

A.k.a. rope pushing.


> also for testing in the lab, its often helpful to know everything about
> the fpga-editor, so you don't need to recompile the design.

Just load chip and modify.


> an appnote about all these fpga pip, net, block, etc hackings would be
> great !

It is in the JBits documentation. Actually just an intro and then an
detailled list of all the parameters that can be inserted into the
modifying functions.

My JBits-docs-derived preliminary/partial CLB surrounding PIPs layout
diagram sketch is at:

http://neil.franklin.ch/Projects/PDP-10/Virtex-CLB-PIPs

(You need an very wide browser window (or scroll horizontally), and an
fixed width font for ASCII/plain text)


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng FH/BSc, Sysadmin, Roleplayer, LARPer, Mystic

Article: 28880
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 26 Jan 2001 23:40:34 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
>> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
>> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
>> interface to.
>
>Does anybody have details on the serial interface.  Is there clock recovery
>built in, so maybe it can be 
>used for HDTV?

They have to have clock recovery. Putting just the IO cells just
doesn't make any sense. It must come with CR and SER/DES to 8 or 16
bits so that you can manage the data at a reasonable speed.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 28881
Subject: Re: RAM reset question - Xilinx Virtex
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 26 Jan 2001 15:52:51 -0800
Links: << >>  << T >>  << A >>
Philip is of course correct in his explanation.

But let me fill you in about the background.
There is a reason why RAMs in general do not have a parallel reset:
It is too expensive. It would add one extra transistor to each cell, plus a lot of
connectivity.
For that reason, there are (practically) no RAMs in the whole industry with a Reset
input. Even our LUT-RAMs must be cleared sequentially.
Global reset is not sequential, so it cannot reset any LUT or BlockRAM.
But, since configuration is a sequential operation, it is a golden opportunity to
stuff any predefined information into LUTs and BlockRAMs.

(There is a Reset pin in some BlockRAM library symbols, but that means: Reset the
output latches, not the memory content)

I thought this might clarify things. I find it beneficial when I know not only
"what", but also "why"!

Peter Alfke, Xilinx Applications
======================================
Philip Freidin wrote:

> On Fri, 26 Jan 2001 11:39:30 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com>
> wrote:
> >Hello experts;
> >
> >I have a question about block and distributed RAM in the Virtex. When using
> >coregen, you can specify initial values for the memory. If not specified,
> >for example when RAM is inferred in synthesis, the initial values are 0. My
> >question is, under what conditions are those values loaded?
> >
> >- After configuration? Yes, I'm pretty sure of this.
>
> Yes, it is part of the configuration bitstream
>
> >- After a global reset using the startup block? I think so, but I'm not
> >sure.
>
> No. initial state is no longer available. Will retain contents of RAM
> prior to reset.
>
> >- After a non-global reset? Probably not, but again I don't know.
>
> No. Same reason and result.
>
> >
> >Since Virtex came out, Xilinx has been recommending against use of the
> >global reset logic. I'm wondering now if that doesn't affect initialisation
> >of memory components. If I do require my memories to be re-initialised,
> >could I simply hook up my reset line to a manually instantiated startup
> >block, without changing any of my other logic? Or is it an all or nothing
> >decision?
> >
> >Your input is appreciated!
> >
> >Regards,
> >Jamie
> >
>
> Philip Freidin
> Fliptronics


Article: 28882
Subject: Re: RAM reset question - Xilinx Virtex
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 27 Jan 2001 04:20:37 GMT
Links: << >>  << T >>  << A >>
In response to the original question,

> >- After a global reset using the startup block? I think so, but I'm not
> >sure.

"Philip Freidin" wrote

> No. initial state is no longer available. Will retain contents of RAM
> prior to reset.

Hmm.  Related issues/questions.  Maybe dumb questions.  Please correct me
where/if I'm wrong.

-----
Part 1: Pertaining to coming out of reset after configuration, and the
potential for initialized RAM corruption during DEASSERTION of GSR.

I understand that the GWE (global write enable) signal protects initialized
block RAMs and LUT RAMs both during configuration and when coming out of
configuration mode.

I understand that after configuration, the number of cycles that GWE and
also GSR remain asserted are determined by bitgen options.

I understand that since the GSR net DEASSERTION delay may be greater than
the clock period, some FFs may come out of set/reset before others.

I understand that if some FFs come out of set/reset before others, if care
is not taken, the logic that computes a WE could inadvertently enable a
garbage write to a RAM.  Therefore it seems prudent to gate all WEs to
initialized RAMs with a FF that itself awaits the infamous user-implemented
several-cycle-delayed limited ("state machines only") synchronous reset to
complete.

Question 1.  Right?

-----
Part 2: Pertaining to manually resetting the device by asserting GSR on the
STARTUP_VIRTEX block and the potential for intialized RAM corruption during
initial REASSERTION of GSR.

If, after some time (long after configuration), the GSR input to an
instantiated STARTUP_VIRTEX block is asserted, GSR is asserted throughout
the device, with the effect that the device is reset.  All FFs and block RAM
output registers are set/reset as appropriate.

Question 2. While this GSR input is asserted (asserting the hidden GSR net
throughout the device), is the GWE hidden net also asserted?

Question 3. In light of Philip's statement, "...Will retain contents of RAM
prior to reset....", is it not the case that if the device is reset via the
GSR input to the STARTUP_VIRTEX block, the GSR net will be ASSERTED after
various delays at various FFs, and those FFs throughout the device will all
take their own sweet time setting/resetting, in any order, and if this
occurs near a clock edge, and if some of those FFs are combined in logic to
produce a WE signal for a BRAM or LUT RAM, that a write of random garbage to
the RAM will occur?

Question 4. Isn't it true that if you plan to depend upon your RAM not
getting overwritten during manual reset, you had better consider the worst
case of partial resetting of every subset of the FFs that feed logic that
feed WEs.

For example, if you gate all your WEs with an INITIALIZED flip-flop that is
several cycles delayed from the device coming out of configuration (as
described above), then it could well happen that during manual reset some
FFs are set/reset near a clock edge and before the INITIALIZED flip-flop is
reset...

Thanks for any comments.
Jan Gray, Gray Research LLC




Article: 28883
Subject: Re: RAM reset question - Xilinx Virtex
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 27 Jan 2001 04:36:59 GMT
Links: << >>  << T >>  << A >>
p.s. Shouldn't GWE be called GWE# (e.g. global write inhibit)?

Jan Gray, Gray Research LLC




Article: 28884
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 27 Jan 2001 05:09:35 GMT
Links: << >>  << T >>  << A >>
We will never forget "you in Europe".

Note: The president of Xilinx is Belgian, the Master of Ceremonies was
Indian, one of the technical heavies is Australian, the VP of Engineering
has German parents, and yours truly has his roots in Germany and Sweden. We
are a world-wide company.

As an aside: My personal experience ( many times over the past 30 years)
has been that it is difficult to attract competent UK engineers to attend
such seminars. (I know that they exist in spades, even after we imported so
many ) . Allegedly, management did not allow them to go. Attendance in
France and Germany was often 2 to 5 times higher, ( and the same number in
Israel ! ),  and the Brits cannot really put the blame on a language
problem...
Hoping for a positive surprise this time around ( hint, hint: tell your
colleagues and wake up your management). I am told we reached 3000
engineers in the US and Canada. That's roughly one in 100,000 of the
population. Can we get 500 in the U.K.? I am ready to change my mind !

European cellular telephony claims to be well ahead of the US, and a good
portion of this seminar deals with DSP in advanced cellular telephone
systems ( and video enhancement and compression )...

Peter
==================================

erika_uk@my-deja.com wrote:

> hello,
>
> what about us in europe ?
>
> Erika
>


Article: 28885
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Jan 2001 05:21:27 GMT
Links: << >>  << T >>  << A >>
That is what one would assume, but that doesn't mean they did so...which is the
reason I am asking.  I'm anxious to see the details on the serial interface. 
I've already got applications where I could use it.



Muzaffer Kal wrote:
> 
> Ray Andraka <ray@andraka.com> wrote:
> >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
> >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
> >> interface to.
> >
> >Does anybody have details on the serial interface.  Is there clock recovery
> >built in, so maybe it can be
> >used for HDTV?
> 
> They have to have clock recovery. Putting just the IO cells just
> doesn't make any sense. It must come with CR and SER/DES to 8 or 16
> bits so that you can manage the data at a reasonable speed.
> 
> Muzaffer
> 
> FPGA DSP Consulting
> http://www.dspia.com

-- 
-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  or http://www.fpga-guru.com

Article: 28886
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 27 Jan 2001 05:26:46 GMT
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

>  I thought the multipliers were a little misrepresented.  The data book
> indicates about 140 Mhz max for the 18x18.  The 200+ numbers they were showing
> were for 4x4 and maybe the 8x8s.

There "vill be vaiss" to make it substantially faster.
Also, the present speed files are deliberately quite conservative

>
> >
> > 3. With the new buffered programmable interconnect, that graph of number of
> > net loads, to ns delay, was pretty darn flat...
>

From the center of an XC2V500, you can reach every logic or RAM input in less than
1 ns.

>
>
> Erich looked like he was battling indigestion during his talk.  I dunno why, it
> seems to be a solid product.  Should we all empty out our pencil drawers of any
> spare
> Rolaids and send them to him?

Yes, I have also seen him more lively. But it was his very own brand-new
presentation, and he must have felt the impact of 3000 pairs of eyes on him.
Facing four TV cameras simultaneously has a way of intimidating the best of us. We
all took this event very seriously...

>
>
> > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
> > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
> > interface to.
>
> Does anybody have details on the serial interface.  Is there clock recovery
> built in, so maybe it can be used for HDTV?

of course, and yes! Be our guest.

Peter Alfke



Article: 28887
Subject: Re: looping and ranges
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sat, 27 Jan 2001 00:43:32 -0500
Links: << >>  << T >>  << A >>
Stephen Williams wrote:
> 
> always @(bar)
>   for (j=1; j<14; j=j+1)
>     foo[j] <= bar[423-((13-j)*8):423-((13-j)*8)-7];
> 
> Nope.
> 
> Part selects (that is, ranges of bits) must have constant indices in
> Verilog. Verilog 200? relaxes this constraint. An in addition, you
> cannot address single bits of vector arrays. Verilog 200? relaxes this
> restriction as well.
> 
> However, for what you want to do, you can probably make more use of
> parameter expressions to make the unrolled version more manageable.

Thanks. I ended up using Paul's suggestion of using the loop index to
select individual bits of BAR and concatenating 8 of them into a byte.
Works ok and is a compromise of readability. 

But now I want to do the same thing on the receive side where we need to
use the bit vector on the left side and the byte vector on the right. So
how do I do that without driving the compiler nuts?

output [53*8-1:0] bar;

reg[7:0] foo[1:13];

always @(bar)
  for (j=1; j<14; j=j+1)
     bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];

I can't do this, and I can't concatenate BAR into a byte. So am I only
left with the original method of individual explicit byte assignments? 

-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 28888
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Jan 2001 05:49:31 GMT
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> 
> Ray Andraka wrote:
> 
> >  I thought the multipliers were a little misrepresented.  The data book
> > indicates about 140 Mhz max for the 18x18.  The 200+ numbers they were showing
> > were for 4x4 and maybe the 8x8s.
> 
> There "vill be vaiss" to make it substantially faster.
> Also, the present speed files are deliberately quite conservative

As expected.  I sure hope those multipliers will go alot faster.  I'd certainly
like to see the 
numbers for the pipelined modes.

> 
> >
> > >
> > > 3. With the new buffered programmable interconnect, that graph of number of
> > > net loads, to ns delay, was pretty darn flat...
> >
> 
> From the center of an XC2V500, you can reach every logic or RAM input in less than
> 1 ns.
Now that's cookin!  So it should be about 2ns across the die.  How well do these
numbers hold up on a full design?
I've also heard that loading does not effect the delays as much as it did in
Virtex.  Any truth to that?

> 
> >
> >
> > Erich looked like he was battling indigestion during his talk.  I dunno why, it
> > seems to be a solid product.  Should we all empty out our pencil drawers of any
> > spare
> > Rolaids and send them to him?
> 
> Yes, I have also seen him more lively. But it was his very own brand-new
> presentation, and he must have felt the impact of 3000 pairs of eyes on him.
> Facing four TV cameras simultaneously has a way of intimidating the best of us. We
> all took this event very seriously...

His presentation was good.  It just seemed he wasn't quite himself.
> 
> >
> >
> > > 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice eye
> > > diagrams) are driven at 32-bits at 78 MHz. That looks easy enough to
> > > interface to.
> >
> > Does anybody have details on the serial interface.  Is there clock recovery
> > built in, so maybe it can be used for HDTV?
> 
> of course, and yes! Be our guest.

Good news.  I expected that answer, but I hadn't seen it anywhere.

> 
> Peter Alfke

-- 
-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  or http://www.fpga-guru.com

Article: 28889
Subject: Re: looping and ranges
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sat, 27 Jan 2001 01:02:26 -0500
Links: << >>  << T >>  << A >>
Paul Campbell wrote:
> 
> Rick Collins wrote:
> 
> >
> > But now I want to do the same thing on the receive side where we need to
> > use the bit vector on the left side and the byte vector on the right. So
> > how do I do that without driving the compiler nuts?
> >
> > output [53*8-1:0] bar;
> >
> > reg[7:0] foo[1:13];
> >
> > always @(bar)
> >   for (j=1; j<14; j=j+1)
> >      bar[423-((13-j)*8):423-((13-j)*8)-7] <= foo[j];
> >
> > I can't do this, and I can't concatenate BAR into a byte. So am I only
> > left with the original method of individual explicit byte assignments?
> >
> 
> How about something like:
> 
>         bar = {foo[1], foo[2], foo[3] .....

FOO is already a byte as shown above in the reg declaration. BAR is the
bit array. 

I tried {bar[1],bar[2]...} <= foo[1]; and the compiler barfed. I guess
this is like VHDL where you can not use an agregate on the left side of
an equation (IIRC). 


-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 28890
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Sat, 27 Jan 2001 12:24:19 -0000
Links: << >>  << T >>  << A >>
If you follow the source for this technology down to www.hotrail.com
it looks as if the key feature is quite a fancy clock recovery/centering
scheme.

"Ray Andraka" <ray@andraka.com> wrote in message
news:3A725BAD.76940D93@andraka.com...
> That is what one would assume, but that doesn't mean they did
so...which is the
> reason I am asking.  I'm anxious to see the details on the serial
interface.
> I've already got applications where I could use it.
>
>
>
> Muzaffer Kal wrote:
> >
> > Ray Andraka <ray@andraka.com> wrote:
> > >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice
eye
> > >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough
to
> > >> interface to.
> > >
> > >Does anybody have details on the serial interface.  Is there clock
recovery
> > >built in, so maybe it can be
> > >used for HDTV?
> >
> > They have to have clock recovery. Putting just the IO cells just
> > doesn't make any sense. It must come with CR and SER/DES to 8 or 16
> > bits so that you can manage the data at a reasonable speed.




Article: 28891
Subject: Re: Synthesizing Virtex Block Memories with Leonardo v1999.1i = Slooow
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Sat, 27 Jan 2001 15:58:14 +0000
Links: << >>  << T >>  << A >>
On Thu, 25 Jan 2001 20:32:33 GMT, Newsbrowser@Newsbrowser.com
(Newsbrowser) wrote:

>This compilation takes a loooooooooooong time. 
>
>It stalls at  the compilation of a dual port 2048x12 sram. 
>
>I have a feeling that this software is going through creating this
>memory 1 cell at a time. 

It does, apparently after an earlier version made assumptions about
inferring memory and could be caught out. I was told, at the time, they
were going to fix it in a later release, but I'm not up to date on that.

The other way, of course, is to black box the memory and use (Xilinx)
CoreGen or (other) to instantiate it. When I do this, I have a wrapper
around the memory (using Renoir) so that except at the lowest level of
the hierarchy, the design is still technology independent. (And one can
substitute the VHDL module for the black box, if desired)

One of the guys (Stuart Clubb?) at their UK distributor, Saros
Technology, http://www.saros.co.uk was preparing an app note about this.

- Brian


Article: 28892
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Jan 2001 20:45:45 GMT
Links: << >>  << T >>  << A >>
Yes the feedback I've gotten privately indicates that this is a very sexy
interface, and very well planned.  I can't wait to get my hands on one.

Simon Bacon wrote:
> 
> If you follow the source for this technology down to www.hotrail.com
> it looks as if the key feature is quite a fancy clock recovery/centering
> scheme.
> 
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3A725BAD.76940D93@andraka.com...
> > That is what one would assume, but that doesn't mean they did
> so...which is the
> > reason I am asking.  I'm anxious to see the details on the serial
> interface.
> > I've already got applications where I could use it.
> >
> >
> >
> > Muzaffer Kal wrote:
> > >
> > > Ray Andraka <ray@andraka.com> wrote:
> > > >> 7. The Virtex-II Pro's Conexant-licensed 3.125 Gbps links (nice
> eye
> > > >> diagrams) are driven at 32-bits at 78 MHz. That looks easy enough
> to
> > > >> interface to.
> > > >
> > > >Does anybody have details on the serial interface.  Is there clock
> recovery
> > > >built in, so maybe it can be
> > > >used for HDTV?
> > >
> > > They have to have clock recovery. Putting just the IO cells just
> > > doesn't make any sense. It must come with CR and SER/DES to 8 or 16
> > > bits so that you can manage the data at a reasonable speed.

-- 
-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  or http://www.fpga-guru.com

Article: 28893
Subject: Re: XtremeDSP seminar comments -- Virtex-II 4xPowerPC chip multiprocessor!
From: "EKC" <NOSPAMalpha3.1@ix.netcom.com>
Date: Sat, 27 Jan 2001 21:09:02 GMT
Links: << >>  << T >>  << A >>
    Is there an archived version of the XtremeDSP Simulcast available
online? I think many people would be interested in watching it, especially
with the rave reviews the event is getting.

-EKC

Jan Gray wrote in message ...
>Yesterday's XtremeDSP Simulcast was excellent. Well, what do you know --
the



Article: 28894
Subject: Standard Deviation Moving Window
From: javidiaz@my-deja.com
Date: Sun, 28 Jan 2001 00:27:18 GMT
Links: << >>  << T >>  << A >>
Hi, I am student from Puerto Rico:

We are trying to figure out how to implement an algorith that takes a
9*9 matrix (8 bits each element)and do a windowing of 5*5 in a column-
wise and row-wise sliding and calculate for each 5*5 Moving-Window the
Standard Deviation.
Questions:
1. How do I handle the Squared Root of the SD?
2. And Which is better to implement on Xilinx XC4036 a floating-point
or a fix-point approach for the results (another 9x9 matrix)?
3. I need to do a storage of those results: How do I configure the RAM
resources for float-P or Fix-point?
4. Can you provide me good web resources to understand how to implement
floating/fix point on FPGA?

I hope to have some feedback on this regard,

Javier


Sent via Deja.com
http://www.deja.com/

Article: 28895
Subject: Leonardo -> Xilinx Alliance 3.1i
From: elh@vu-vlsi.ee.vill.edu (Edward L. Hepler)
Date: 27 Jan 2001 22:33:04 -0500
Links: << >>  << T >>  << A >>
I am using the current version of Exemplar Leonardo (v20001b.106)
and the 3.1i version of Xilinx Alliance...

I have synthesized a design and produced an EDIF file.

I am attempting to read this file via "ngdbuild" but errors
are being reported with respect to the EQNs for the LUTs...

In particular, it doesn't seem to like '!' in the equations...

Here is an example:

ERROR:NgdHelpers:403 - The EQN value of "((!I0*!I1*!I2*!I3))", on the LUT4
   symbol "core_notri/mpu/cpu/ix408492", is not a valid equation.
ERROR:NgdHelpers:404 - The above-referenced equation has the following error:
   Unexpected '!'.
ERROR:NgdHelpers:403 - The EQN value of "((I0)+(!I3)+(!I1*!I2))", on the LUT4
   symbol "core_notri/mpu/cpu/ix408493", is not a valid equation.
ERROR:NgdHelpers:404 - The above-referenced equation has the following error:
   Unexpected '!'.


I have also tried an older Alliance release with the same results.
I have used this path before, using an older version of leonardo...

Has something changed, or is there now some additional option that
must be set that I have missed?

Any ideas are welcome...

Thanks,

Ed Hepler


Article: 28896
Subject: Re: Leonardo -> Xilinx Alliance 3.1i
From: elh@vu-vlsi.ee.vill.edu (Edward L. Hepler)
Date: 27 Jan 2001 22:55:57 -0500
Links: << >>  << T >>  << A >>
In article <9503tg$rpj@vu-vlsi.ee.vill.edu>,
Edward L. Hepler <elh@vu-vlsi.ee.vill.edu> wrote:
>I am using the current version of Exemplar Leonardo (v20001b.106)
>and the 3.1i version of Xilinx Alliance...
>
>I have synthesized a design and produced an EDIF file.
>
>I am attempting to read this file via "ngdbuild" but errors
>are being reported with respect to the EQNs for the LUTs...
>
>In particular, it doesn't seem to like '!' in the equations...
>
>Here is an example:
>
>ERROR:NgdHelpers:403 - The EQN value of "((!I0*!I1*!I2*!I3))", on the LUT4
>   symbol "core_notri/mpu/cpu/ix408492", is not a valid equation.
>ERROR:NgdHelpers:404 - The above-referenced equation has the following error:
>   Unexpected '!'.
>ERROR:NgdHelpers:403 - The EQN value of "((I0)+(!I3)+(!I1*!I2))", on the LUT4
>   symbol "core_notri/mpu/cpu/ix408493", is not a valid equation.
>ERROR:NgdHelpers:404 - The above-referenced equation has the following error:
>   Unexpected '!'.
>
>
>I have also tried an older Alliance release with the same results.
>I have used this path before, using an older version of leonardo...
>
>Has something changed, or is there now some additional option that
>must be set that I have missed?
>
>Any ideas are welcome...
>
>Thanks,
>
>Ed Hepler
>

Sorry to bother everyone... I figured out that this time I did not
use auto_write, but just wrote out the EDIF...  This gave me some
EDIF that was not Xilinx compatible...

Thanks...



Article: 28897
Subject: Re: can not start coregen
From: "Rune Baeverrud" <fpga@no.spam.iname.com>
Date: Sun, 28 Jan 2001 12:54:52 +0100
Links: << >>  << T >>  << A >>
"JianyongNiu" <cop00jn@sheffield.ac.uk> wrote in message
> My question is: where can I get the Virtex II Device Update CD?

You don't need the Virtex-II Device Update CD unless you need Virtex-II
support. However - if you have a valid software subscription with support
for Virtex-II - you should have received the update CD in the mail by now.
If not - I suggest you contact your local Xilinx representative and I'm
confident they will be able to help.

Rune Baeverrud



Article: 28898
Subject: Re: Xilinx fast carry counter question
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sun, 28 Jan 2001 07:15:03 -0700
Links: << >>  << T >>  << A >>
Jan Gray wrote:
 
> The last time I looked, the loadable binary counter CC16CLE unnecessarily
> used two LUTs per bit.  Xilinx should fix that.  A straight adder should
> also only need one LUT per bit.

There may be hidden buffering or Hardware dependent limitations on the carry
chain is my guess.

-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

Article: 28899
Subject: Actel's FPGA : A54SX32A
From: "jean-francois hasson" <jfhasson@club-internet.fr>
Date: Sun, 28 Jan 2001 17:23:53 +0100
Links: << >>  << T >>  << A >>
Hi,

I am about to use an Actel A54SX32A in a FBGA144I package. I am interested
in people having an experience with Actel's FPGAs and the best would be with
the SX family. I have used up to know either Altera or Xilinx and I have no
experience with Actel. Are there any known problems with these devices ?
Anything specific to look at before starting a design ?
Thank you in advance for your time and information.

J.F. Hasson





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