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 73575

Article: 73575
Subject: Re: Xpower - Clock Power
From: Dominik Gawlowski <D.M.Gawlowski@tue.nl>
Date: Fri, 24 Sep 2004 14:26:06 +0200
Links: << >>  << T >>  << A >>
HI

I would like to confirm that my flow is correct.
I am checking the Power consumption of some final state machines.
The begining is the kiss file with the state machine, next I am encoding 
and synthetizing it with SIS (berkeley university product) tool. After 
that I am receiving the blif file.
Using our own tool I am converting this blif to edif which is full 
yrecognizable by the ISE tool.
I am making mapping of this edif, generating testbench
simulating it with modelsim and when I hav .vcd file from model sim I am 
  using the xpower tool.
The results for this files are mostly resonable or inaccurate.

When I checked the same flow with our own tool most of the results is 
accurate and only some of them is inaccurate.

Do you when can be the problem??
If my explanation is not full just let me know, then I will highlight 
the points which are not clear.

thank you in advance

regrads

Dominik Gawlowski

Brendan Cullen wrote:
> Hi Mukesh,
> 
> Mukesh wrote:
> 
> 
>>Before using xpower for my design, I decide to check for a simple
>>design of fibonacci series. I am facing following issues:
>>
>>I am running xpower with vcd generated with post par simulation and
>>during parsing I encounter the following warnings:
>>
>>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP/IBUFG to
>>741.84Mhz.
>>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP to
>>741.84Mhz.
>>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP/IBUFG to
>>741.84Mhz.
>>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP to
>>741.84Mhz.
>>...
>>
>>The frequency for signals in data view shows some values inthe range
>>of 2-9% in all cases except CLK_BUFGP/IBUFGP and CLK_BUFGP.. Any
>>attempts to change this value results in power:91 warnings as above.
>>
>>The confidence level shows Accurate. I am confused as the report shows
>>zero power for clock/ logic nets and still the confidence level is
>>accurate.
>>The report summary is :
>>
>>Total estimated power consumption:               439
>>Peak Power consumption:                      1081711
>>                               ---
>>                      Vccint 1.50V:       65       98
>>                      Vccaux 3.30V:      100      330
>>                      Vcco33 3.30V:        3       11
>>                               ---
>>                           Clocks:        0        0
>>                           Inputs:        0        0
>>                            Logic:        0        0
>>                          Outputs:
>>                             Vcco33       2        8
>>                          Signals:        0        0
>>                               ---
>>           Quiescent Vccint  1.50V:       65       98
>>           Quiescent Vccaux  3.30V:      100      330
>>           Quiescent Vcco33  3.30V:        1        3
>>
>>Whats going wrong here? Anybody encountered similar problems?
>>Feedback/ help from Xilinx folks please.
>>
>>--
>>Mukesh
> 
> 
> This does indeed look similar to another problem which we've been working
> on.  We have a fix for that problem (the one we've been working on) and
> the fix will be available in the next service pack - 6.3.01i  - which
> should be available to you next week.  However, you might be experiencing
> a diferent symptiom.  One option would be for you to zip up the NCD & VCD
> file and send them to us ?  Or are they huge ?  The other option is for
> you to try the service pack next week.  Note - in order for you to use
> 6.3.01i you'll need to have the underlying 6.3i.  (From your other e-mail
> to the newsgroup it appears you are using 6.2.03i.)
> 
> Brendan
> 
> 


Article: 73576
Subject: Re: How To Synchronize FPGAs
From: "Leroy Tanner" <ikeepthespiritalive@freenet.de>
Date: Fri, 24 Sep 2004 14:32:01 +0200
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com>:
> ...or at least take all the high speed serial stuff into one FPGA and
> distribute it from that one to the others at a slower parallel rate.

ok, I agree on that and it might be a good approach to minimize skewing in
the first section. but nevertheless I must synchronize the other FPGAs to
each other, not at a rate of several GHz but say at ca. 300 MHz. In my
opinion a central clock isn't an appropriate solution!?



Article: 73577
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Fri, 24 Sep 2004 14:13:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <4153A8ED.D72961FB@yahoo.com>, rickman  <john@bluepal.net> wrote:
>Nicholas Weaver wrote:
>> 
>> In article <41525983.F7389D7E@yahoo.com>, rickman  <john@bluepal.net> wrote:
>> >I don't need to see the transistors, just a signal that they control.
>> >That would be in the metal.  It may be hard to sort out, but I am sure
>> >that is orders of magnitude easier than cracking the key by brute
>> >force.
>> 
>> However, those signals are still buried under 8 layers of metal, in a
>> flip-chip package, with live SRAM cells.
>
>Please explain this.  The outputs from the RAM cells never leave the
>lowest layer of metal?  

The output of the encryptor's ram cells only go to the encryption
engine itself, and if I was a paranoid designer, that would be a 2-3
layer metal design, with layers 4-9 on top of it with other stuff to
make probing difficult.

I can't confirm, not knowing the design, but I'd lay good odds that
the bitfile decryption engine is right next to the key storage, and
that nothing really goes above layer 3, with layers 4-9 being used for
other signals, power, ground, etc.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73578
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Sep 2004 11:00:37 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> In article <4153A8ED.D72961FB@yahoo.com>, rickman  <john@bluepal.net> wrote:
> >Nicholas Weaver wrote:
> >>
> >> In article <41525983.F7389D7E@yahoo.com>, rickman  <john@bluepal.net> wrote:
> >> >I don't need to see the transistors, just a signal that they control.
> >> >That would be in the metal.  It may be hard to sort out, but I am sure
> >> >that is orders of magnitude easier than cracking the key by brute
> >> >force.
> >>
> >> However, those signals are still buried under 8 layers of metal, in a
> >> flip-chip package, with live SRAM cells.
> >
> >Please explain this.  The outputs from the RAM cells never leave the
> >lowest layer of metal?
> 
> The output of the encryptor's ram cells only go to the encryption
> engine itself, and if I was a paranoid designer, that would be a 2-3
> layer metal design, with layers 4-9 on top of it with other stuff to
> make probing difficult.
> 
> I can't confirm, not knowing the design, but I'd lay good odds that
> the bitfile decryption engine is right next to the key storage, and
> that nothing really goes above layer 3, with layers 4-9 being used for
> other signals, power, ground, etc.

So does that make them invisble?  You only need to probe the device with
battery power, not main power.  So everything that is not powered by the
battery is at gnd potential.  I would be willing to bet that you can
still see between the top level runs.  

-- 

Rick "rickman" Collins

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

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

Article: 73579
Subject: Re: How To Synchronize FPGAs
From: "Josh Model" <model@ll.nospam.mit.edu>
Date: Fri, 24 Sep 2004 11:18:45 -0400
Links: << >>  << T >>  << A >>
Think about what a central clock entails from purely a routing perspective.
Let's assume you're an SI wizard, and have no issues there.

300 MHz would be ~ 3.3 ns per clock cycle.  If I remember my rule of thumb,
you've got about 6 inches per 1 ns for the speed of an electrical signal in
FR-4 material.  So the worst case match between all your data lines and all
clock lines for all FPGA's will be the skew that eats into your timing
budget.

Just as an example (I'm not really a layout person, so it's my posterior
speaking), matching all lines to 4 FPGAs +/- 3 inches seems relatively
tricky, but not completely unreasonable.  So now ~1/3 of your entire clock
cycle is wasted (more, if you were assuming DDR) before you even get to the
FPGA fabric.  it makes laying out your design that much more tricky.

Now, in the slightly more real world you've got to throw in the jitter
present on a 300 MHz clock, impedance mismatches causing reflections,
crosstalk on your board with all that data zipping around (because GHz and
even 300 MHz lines are really antennae)  and you've got a lot to deal with.

Anyhow, synchronzing dataflow at those speeds on a PCB is not nearly as
simple as just plopping down a clock.  It's a hard design, but you get to
choose where to place the burden.  If you've got really good PCB people,
maybe they can match and terminate the really well.  If you've got the DCM/
DLL (or their altera, or "insert brand" counterpart) hardware to de-skew the
board clock, you could let the FPGA do it (though I don't recall at what
frequencies the DCM's top out).  If you've got neither, you might want to
consider going to a single chip serial interface, because you're going to
get into trouble otherwise.

--Josh


"Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message
news:cj1476$9pc$1@mamenchi.zrz.TU-Berlin.DE...
>
> "Symon" <symon_brewer@hotmail.com>:
> > ...or at least take all the high speed serial stuff into one FPGA and
> > distribute it from that one to the others at a slower parallel rate.
>
> ok, I agree on that and it might be a good approach to minimize skewing in
> the first section. but nevertheless I must synchronize the other FPGAs to
> each other, not at a rate of several GHz but say at ca. 300 MHz. In my
> opinion a central clock isn't an appropriate solution!?
>
>



Article: 73580
Subject: Re: Webpack 6.3 and Spartan3-1000/1500?
From: "E.S." <emu@ecubics.com>
Date: Fri, 24 Sep 2004 09:37:27 -0600
Links: << >>  << T >>  << A >>
Simon wrote:
> Well, if webpack supports the XC3S1000/1500, will BaseX do the same ? 
> I've recently bought BaseX (no sign of any upgrade in the post, mind, 
> even though I've registered it etc...) but had resigned myself to using 
> a '400 part because there's no way I could justify $3k (after tax/import 
> duty/shipping) for Foundation. I'll be a bit miffed if the free version 
> can do more than the pay-for version though...

They probably still working on the features ;-)
If you look at the online shop, the WebPack has the support for the 
xc3s1000 & xc3s1500. If you download the comaprison chart, the support 
in WebPack is not there for the xc3s100 & xc3s1500.

So, less value if you pay for it ?

Xilinx, are you listening ?

It would be nice, if both packages would have the xc3s1000 & xc3s1500 
support in them ...



Article: 73581
Subject: Re: Mr. Greenfield, spare us the propaganda !
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 24 Sep 2004 15:37:34 GMT
Links: << >>  << T >>  << A >>
Thanks for commenting.

It's unfortunate that the way the postings were made it appeared that only
item #2 applied and that that was violated.  It was pointed out late in the
thread that you were (probably) responding to the Stratix-II vs Virtex-4
thread where a Xilinx professional highlighted the strong points (as he
knows them) of the Virtex-4 and left the discussion of the Stratix-II to
Altera.  To "reactively respond" would be to post a followup to that
conversation.  In keeping with the train of that discussion, it would have
made sense to highlight the positives of the Stratix-II - as in the August
news release by Altera's Senior VP of marketing
http://biz.yahoo.com/prnews/040830/sfm083_1.html - rather than to suggest
the competition is doing things so terribly wrong which seemed to be the
majority of the post.  The post appeared to be competitive attacks rather
than product commentary.

If you can provide reasoned insight into the Altera products and directions,
your input is welcome on this board.  Really.

Just please be part of a discussion - an existing thread - and keep the
issues to the technical items that affect the lives of designers.  Engineers
see much of marketing as "fluff" so the need to contribute should be minor.

And read the newsgroup when you have a chance.


"Dave Greenfield" <davidg@altera.com> wrote in message
news:5c156a0b.0409231601.32cec67d@posting.google.com...
> Now that the dust is starting to settle, I'd like to highlight the
> guidelines that Altera uses in involvement with this newsgroup.
>
> 1) We reactively respond to customer questions on both marketing and
> technical issues (if it is a marketing response, we may use a
> marketing person and clearly articulate the title of the poster).
> 2) We do not proactively start posts about our new products.
> 3) We respond to competitive commentary on our products, as not doing
> so implies agreement.
> 4) We refrain from personal attacks.
> 5) We refrain from competitive attacks unless provoked.
>
> My responses earlier this week addressed points 1, 3, and 5 above.
> There clearly are additional un-written guidelines with this
> newsgroup, and if I have offended anyone with my overt rather than
> covert marketing, I offer my apology. Thank you for the newsgroup
> etiquette training.
>
> Dave Greenfield
> Sr. Director of Propaganda & Ilk
> Altera Corporation



Article: 73582
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Fri, 24 Sep 2004 15:48:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <41543695.30F6A736@yahoo.com>, rickman  <john@bluepal.net> wrote:
>So does that make them invisble?  You only need to probe the device with
>battery power, not main power.  So everything that is not powered by the
>battery is at gnd potential.  I would be willing to bet that you can
>still see between the top level runs.  

The cells are static, so you can't track dynamic power which would
make it easier.  So you need to probe static signals buried under 4-8
layers of metal, without disrupting the battery power.  

You could drill down, but that's going to be annoying, especially
since if it were me, layer 3 & 4 would be a crisscrossing grid of
battery power/gnd links (I don't know if they do that, but I would).

Frankly, it is probably going to be vastly easier to do a sidechannel
analysis on encryptor power & EM signature, at least my gut thinks so,
or drill down to the CONFIG wires and just read the config as its
loaded, as the config info has to go everywhere.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73583
Subject: Getting info from a digital line
From: mwiesbock@gmail.com (weizbox)
Date: 24 Sep 2004 09:01:59 -0700
Links: << >>  << T >>  << A >>
I bought a Spartan-3 Starter board as well as the AIO1 fomr Digilent
that was suggested. Thus far I have gotten some good results with the
Starter board alone and begining to learn some vhdl, altho still very
foggy in some areas, as to be expected.

Now, I would like ot intergrate the AIO1 board. I have everyhting set
up and know which pin my Digital Data is coming in on, but thats were
im stuck. How would I go about getting that Digital data and turning
it into something useful, just even a basic multimeter type
application. As well are there any examples of this online(taking a
digital in line and seeing what the data it)?

Thank you very much for your time!
Weizbox

Article: 73584
Subject: Nios Addressing
From: "Luigi Padovani" <l.padovani@seventech.it>
Date: Fri, 24 Sep 2004 16:02:59 GMT
Links: << >>  << T >>  << A >>
Hello,

I have found a problem with a C++ Code,

if i have a Buffer of "unsigned char"  (for example 00 00 00 00 37 00 00 20
00 ecc..ecc.) ,i want to get a DWORD value from the 5 byte they should be
return 00 00 20 00 sequence, instead they give me the result from 37.... (a
4 bytes pairs)... if i try from  6 or 7 byte , they returned me the same
value , also from the 8 byte give me a new correct value.. the Nios can't
addressing the offset of 4bytes? , the same code compiled on pc work great..


Thank's a lot








Article: 73585
Subject: Re: NIOS II (full sample working with DMA in HAL)?
From: nknight@altera.com (Nathan Knight)
Date: 24 Sep 2004 09:27:50 -0700
Links: << >>  << T >>  << A >>
Nios II version 1.0 SP1, just released, contains a new software
example design called "memtest".  This example design checks using
#ifdef to see if the system contains a DMA.  If it does, it performs a
test of memory using HAL DMA code in addition to the normal tests it
runs.  Pasted below is a copy of the DMA test function which includes
calls to the DMA HAL routines.

-Nathan Knight
Altera Applications


/******************************************************************
*  Function: MemDMATest
*
*  Purpose: Tests every bit in the memory device within the 
*  specified address range using DMA.  The DMA controller provides 
*  a more rigourous test of the memory since it performs back-to-
*  back memory accesses at full system speed.
*
******************************************************************/
#ifdef DMA_NAME  
static int MemDMATest(unsigned int memory_base, unsigned int nBytes)
{
  int rc;
  int ret_code = 0;
  int pattern, offset;
  alt_dma_txchan txchan;
  alt_dma_rxchan rxchan;
  void* data_written;
  void* data_read;
  
  /* Get a couple buffers for the test */
  /* Using the "uncached" version of malloc to avoid cache coherency
issues */
  data_written = (void*)alt_uncached_malloc(0x1000);
  data_read = (void*)alt_uncached_malloc(0x1000);
  
  
  /* Fill write buffer with known values */
  for (pattern = 1, offset = 0; offset < sizeof(data_written);
pattern++, offset+=4)
  {
    IOWR_32DIRECT((int)data_written, offset, pattern);
  }

  /* Create the transmit channel */
  if ((txchan = alt_dma_txchan_open("/dev/dma")) == NULL)
  {
    printf ("Failed to open transmit channel\n");
    exit (1);
  }
  
  /* Create the receive channel */
  if ((rxchan = alt_dma_rxchan_open("/dev/dma")) == NULL)
  {
    printf ("Failed to open receive channel\n");
    exit (1);
  }
  
  for(offset = memory_base; offset < (memory_base + nBytes); offset +=
0x1000)
  {
    /* Use DMA to transfer from write buffer to memory under test */
    /* Post the transmit request */
    if ((rc = alt_dma_txchan_send (txchan, data_written, 0x1000, NULL,
NULL)) < 0)
    {
      printf ("Failed to post transmit request, reason = %i\n", rc);
      exit (1);
    }

    /* Post the receive request */
    if ((rc = alt_dma_rxchan_prepare (rxchan, (void*)offset, 0x1000,
dma_done, NULL)) < 0)
    {
      printf ("Failed to post read request, reason = %i\n", rc);
      exit (1);
    }
  
    /* Wait for transfer to complete */
    while (!rx_done);
    rx_done = 0;
    
    /* Clear the read buffer before we fill it */
    memset(data_read, 0, 0x1000);
    
    /* Use DMA to read data back into read buffer from memory under
test */
    /* Post the transmit request */
    if ((rc = alt_dma_txchan_send (txchan, (void*)offset, 0x1000,
NULL, NULL)) < 0)
    {
      printf ("Failed to post transmit request, reason = %i\n", rc);
      exit (1);
    }

    /* Post the receive request */
    if ((rc = alt_dma_rxchan_prepare (rxchan, data_read, 0x1000,
dma_done, NULL)) < 0)
    {
      printf ("Failed to post read request, reason = %i\n", rc);
      exit (1);
    }

    /* Wait for transfer to complete */
    while (!rx_done);
    rx_done = 0;
    
    if (memcmp(data_written, data_read, 0x1000))
    {
      ret_code = offset;
      break;
    }
  }
  alt_uncached_free(data_written);
  alt_uncached_free(data_read);
  return ret_code;
}
#endif /* DMA_NAME */

Article: 73586
Subject: Re: Getting info from a digital line
From: Prasanth Kumar <prasanth.kumar@comcast.net>
Date: Fri, 24 Sep 2004 16:44:06 GMT
Links: << >>  << T >>  << A >>
On Fri, 2004-09-24 at 09:01 -0700, weizbox wrote:
> I bought a Spartan-3 Starter board as well as the AIO1 fomr Digilent
> that was suggested. Thus far I have gotten some good results with the
> Starter board alone and begining to learn some vhdl, altho still very
> foggy in some areas, as to be expected.
> 
> Now, I would like ot intergrate the AIO1 board. I have everyhting set
> up and know which pin my Digital Data is coming in on, but thats were
> im stuck. How would I go about getting that Digital data and turning
> it into something useful, just even a basic multimeter type
> application. As well are there any examples of this online(taking a
> digital in line and seeing what the data it)?
> 
> Thank you very much for your time!
> Weizbox

You need to read the datasheet for the A2D convertor on that board. I
think it is an Analog Devices part. There will be a timing diagram
that shown how to request a conversion and how to clock out the data
serially. Then you will need to write a simple controller to read the
data serially and convert into parallel form and perhaps store into
a register. This would basically be a state machine and a shift
register.

Now if you want to make a multimeter, the data in parallel form would
need to be converted to a voltage level and then decimal form for
display on 7-segment led perhaps. The easy way to do that would be
to construct a 256 entry table in block ram that is addressed using
the A2D data. The block ram is preloaded with decimal values based on
calibration curves you generated on the A2D.



Article: 73587
Subject: Virtex-4 vs Virtex-II
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 24 Sep 2004 09:47:00 -0700
Links: << >>  << T >>  << A >>


> From: "Tim" <tim@rockylogic.com.nooospam.com>
> Newsgroups: comp.arch.fpga
> Date: Fri, 24 Sep 2004 01:19:09 +0100
> 
> I would rather like to see technical posts on new products.
> Xilinx used to have a section in their data sheets on how this
> generation/product differs from the previous generation/product
> and something along those lines would probably be of interest
> to a large fraction of the readership of the newsgroup.
> 
> Maybe of special interest to those of us designing products
> while trying to keep broadly up to date on the technology...

You asked for it, you get it, although it is quite long...
I did this for several device generations while I was responsible for data
sheets, and I did it again last month, but only circulated it within the
company. Note that this is one man's slightly biased view, meant for friends
and not for attack dogs...I am most impressed by the I/O and clocking
enhancements, by the FIFO option, and the versatile DSP slice (cascadable
multiply-accumulator).
===================================================================
Virtex-4 for the Experienced Virtex-II and Virtex-IIPro User
By Peter Alfke, 8-26, 2004

Virtex-4 offers about 100 innovations, and it may be heresy to compare it to
its predecessors, but here is an attempt:

Technology: 
90 nm triple-oxide process (three different oxide thicknesses plus different
transistor thresholds) optimizes the trade-off between speed, leakage
current, and I/O voltage tolerance . Vccint is now 1.2 V.
Lower static leakage and dynamic current for any conventional logic
implementation, and drastically lower power when using the new more highly
integrated hard cores (FIFO, EMAC, DSP slices)

Structure: 
Radically different, ASMBL chip layout arranges functions in vertical
columns, even the I/O. This allows Xilinx to introduce sub-families with
optimized mix between various functions without upsetting architecture or
software support. The DSP-oriented SX family has a much higher ratio of
multiply-accumulators and BlockRAMs relative to the logic resources in the
fabric. Using flip-chip packages, the ASMBL structure also offers better
power distribution and lower pin inductance.

I/O: 
Dramatically enhanced capabilities. Each I/O pin has its own
serializer/deserializer (Parallel/Serial and S/P converter). DDR interfaces
need only one clock and also avoid any 1-bit latency. A 64-stage
individually programmable delay line in each input can be used to adjust bit
alignment or clock alignment with <80 ps granularity, ideal for
source-synchronous interfaces. BitSlip supports word alignment. A
high-performance I/O clock can be driven directly from the pc-board. The
larger number (9 to 17 depending on chip size) of banks gives better I/O
granularity, especially in the larger devices. Configuration now has its own
bank.

CLBs: 
faster but no significant structural change.
To reduce chip area and to enhance performance, only 50% of the slices have
LUTRAM and SRL16 capability.

BlockRAM: 
optional pipeline output registers double performance to 500 MHz. Two
BlockRAMs can directly be concatenated for 36K x 1 operation, or for 512 x
72 bit operation with built-in Hamming error correction. The optional
hard-coded FIFO controller inside the BlockRAM runs at up to 500 MHz
reliably, even with asynchronous read and write clocks. FIFO data bus width,
fall-through operation, and the levels of the Almost_EMPTY and Almost_FULL
flags are programmable. The FIFO takes up no fabric area, is much faster,
much smaller, and much easier to design with than previous soft cores.

DSPSlices: 
Significantly enhanced from the traditional 18 x 18 twos complement
multipliers. Now include a 48-bit accumulator with three adder inputs and
very efficient cascade capability.

Clock Management Resources:
DCMs are faster, more precise, and have better jitter performance. Two
modes: highest speed and finest granularity, or longest delay range. Easy
dynamic reconfiguration of phase shift values and M, D. (But M and D changes
still require a DCM reset). Phase-Matched Clock Drivers (PMCDs) provide
multiple (divided) clock outputs that are delay-matched.

Global Clocks: 
routed differentially, thus faster and less sensitive to crosstalk. Duty
cycle is better maintained. More capable BUFGMUX.
The Xesium clocking architecture adds high-performance I/O clocks, and a
large number of regional clocks.


Available in Virtex-4 FX only:

PowerPC: 
runs 12% faster and has new APU co-processor interface with direct
connection to processor instruction pipeline. A third-party floating point
unit by QinetiQ provides up to 250 megaFLOP performance. Enhanced OCM
interface includes I/O handshaking.

RocketIO: 
0.6 to 11.1 Gbps (wider range than Virtex-IIProX) with additional advanced
input equalization options.

EMAC: 
New function, integrates the digital portion of 10/100/1000 Mbps Ethernet
Media Access Controller (MAC). Saves over 2000 slices of a soft-core
alternative.
===========================================================
I hope this is of some interest.
Peter Alfke, Xilinx Applications.


Article: 73588
Subject: Re: Xilinx DCMs
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 24 Sep 2004 09:57:02 -0700
Links: << >>  << T >>  << A >>

Article: 73589
Subject: Re: How To Synchronize FPGAs
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 24 Sep 2004 10:03:56 -0700
Links: << >>  << T >>  << A >>
Hi Leroy,
Say you've got 4 FPGAs A, B, C & D. Each gets fed the 300MHz clock, so on
the fabric of each FPGA is CLK_A, CLK_B etc. When you send data from (say)
FPGA B to FPGA D, send a clock with the data, generated by FPGA B from its
internal CLK_B, called (say) CLK_B_TO_D. Use this source synchronous clock
with a DCM in FPGA D to get the data into a BRAM FIFO inside FPGA D. Get the
data out from this FIFO into the fabric of FPGA D using CLK_D. Repeat for
all the other paths. Any good?
Cheers, Syms.

"Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message
news:cj1476$9pc$1@mamenchi.zrz.TU-Berlin.DE...
>
> "Symon" <symon_brewer@hotmail.com>:
> > ...or at least take all the high speed serial stuff into one FPGA and
> > distribute it from that one to the others at a slower parallel rate.
>
> ok, I agree on that and it might be a good approach to minimize skewing in
> the first section. but nevertheless I must synchronize the other FPGAs to
> each other, not at a rate of several GHz but say at ca. 300 MHz. In my
> opinion a central clock isn't an appropriate solution!?
>
>



Article: 73590
Subject: Re: Getting info from a digital line
From: Weizbox <mwiesbock@gmail.com>
Date: Fri, 24 Sep 2004 10:31:19 -0700
Links: << >>  << T >>  << A >>
Thanks for a push in the right direction! The board is connected right now as a duaghter board, would this be serial, or rs232 serial? sorry for the seemingly simple questions but this is entirley new to me. As well do you now of any good sites to help me get started with somthing like this and fpga/vdl in general?

Thanks!

Article: 73591
Subject: Re: Nios Addressing
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 24 Sep 2004 10:51:08 -0700
Links: << >>  << T >>  << A >>


Luigi Padovani wrote:

(snip)

> if i have a Buffer of "unsigned char"  (for example 00 00 00 00 37 00 00 20
> 00 ecc..ecc.) ,i want to get a DWORD value from the 5 byte they should be
> return 00 00 20 00 sequence, instead they give me the result from 37.... (a
> 4 bytes pairs)... if i try from  6 or 7 byte , they returned me the same
> value , also from the 8 byte give me a new correct value.. the Nios can't
> addressing the offset of 4bytes? , the same code compiled on pc work great..

Many machines require data to be aligned on a boundary matching the
size of the data.  A four byte DWORD should have an address that is
a multiple of four.

Yes, x86 doesn't require that but it is much slower when doing
a fetch like that.   It is not legal in C, and I don't believe in C++
to do that.  Copy it character by character (memcpy in C) to a
properly aligned variable.

-- glen


Article: 73592
Subject: Re: Webpack 6.3 and Spartan3-1000/1500?
From: Steve Lass <lass@xilinx.com>
Date: Fri, 24 Sep 2004 12:02:57 -0600
Links: << >>  << T >>  << A >>
It's my fault.  Based on excellent availability of Spartan3 devices, I 
made a last minute decision to add the 3S1000 and 3S1500 to the WebPACK.
Unfortunately, this was right after the CDs were created.

In 7.1i (Feb '05), BaseX will include these devices.  If you are a BaseX 
customer and need access to these devices, send me an email and I'll work
something out for you.  I'm travelling today, so don't expect a response 
until Monday

Steve

E.S. wrote:

> Simon wrote:
>
>> Well, if webpack supports the XC3S1000/1500, will BaseX do the same ? 
>> I've recently bought BaseX (no sign of any upgrade in the post, mind, 
>> even though I've registered it etc...) but had resigned myself to 
>> using a '400 part because there's no way I could justify $3k (after 
>> tax/import duty/shipping) for Foundation. I'll be a bit miffed if the 
>> free version can do more than the pay-for version though...
>
>
> They probably still working on the features ;-)
> If you look at the online shop, the WebPack has the support for the 
> xc3s1000 & xc3s1500. If you download the comaprison chart, the support 
> in WebPack is not there for the xc3s100 & xc3s1500.
>
> So, less value if you pay for it ?
>
> Xilinx, are you listening ?
>
> It would be nice, if both packages would have the xc3s1000 & xc3s1500 
> support in them ...
>
>


Article: 73593
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Sep 2004 16:28:24 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> In article <41543695.30F6A736@yahoo.com>, rickman  <john@bluepal.net> wrote:
> >So does that make them invisble?  You only need to probe the device with
> >battery power, not main power.  So everything that is not powered by the
> >battery is at gnd potential.  I would be willing to bet that you can
> >still see between the top level runs.
> 
> The cells are static, so you can't track dynamic power which would
> make it easier.  So you need to probe static signals buried under 4-8
> layers of metal, without disrupting the battery power.

I think you may not understand how em viewing of signals works.  Signals
with a positive voltage are bright and everything else is dim.  The
field of the positive tracks will attract electrons, even through the
oxide and other metal.  It is the field that is visualized, not the
metal itself.  Of course being deeply buried will make the field
distorted, but I bet that would not obliterate the image enough that you
can't distinguish the bits.  

This might be a useful research topic.  If the bounty were say, $10,000,
it might result in a few people cracking it.  I don't think many will
bother testing the Xilinx chips security for a couple of hundred
dollars.  

-- 

Rick "rickman" Collins

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

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

Article: 73594
Subject: Re: bin hot gray jedi encoding in ISE
From: jon@beniston.com (Jon Beniston)
Date: 24 Sep 2004 13:36:14 -0700
Links: << >>  << T >>  << A >>
user@domain.invalid wrote in message news:<cj102r$het$1@news.tue.nl>...
> Hello
> 
> I have some state machines in kiss which I am converting to the verilog 
> format. I would like to encode this verilog with binary, 1-hot, jedi and 
>   gray and after that to synthetize them in ISE.

Jedi is easy. Run XST with the -force option.

Cheers,
Jon

Article: 73595
Subject: Re: Getting info from a digital line
From: Weizbox <mwiesbock@gmail.com>
Date: Fri, 24 Sep 2004 13:43:24 -0700
Links: << >>  << T >>  << A >>
Im reading up on some of it now and was getting confused.. does teh ADC output a clock or do you give it a clock to use?

Article: 73596
Subject: Re: Getting info from a digital line
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 24 Sep 2004 16:02:57 -0500
Links: << >>  << T >>  << A >>
>Im reading up on some of it now and was getting confused..
> does teh ADC output a clock or do you give it a clock to use?

What does the data sheet say?

(Some of them can run either way - depends on mode bits.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 73597
Subject: Re: spartan-3 sram
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 24 Sep 2004 16:29:49 -0500
Links: << >>  << T >>  << A >>
> About
>write timing: Some SRAMS need a data hold after rising edge of nwe. Your
>timing between data out and nwe depends on the routing. To not waste an
>additional clock cycle on write I've used a neg-edge triggered FF for the
>nwe signal.

Check the fine print in the data sheet.

If you just advance the we signal by clocking on the other edge,
(that is move it earlier without changing the duration)
you may not meet address setup times.  (Which means the chip
might write something to the wrong address(es).)

I agree that it would probably be simpler to get something working
slowly at first.  Writes generally work cleanly at 3 cycles:
one for setup, one for active, and one for hold.

(Add a dead cycle between reads and writes to turn the bus around.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 73598
Subject: Re: Getting info from a digital line
From: Weizbox <mwiesbock@gmail.com>
Date: Fri, 24 Sep 2004 14:33:03 -0700
Links: << >>  << T >>  << A >>
I looked at the sheet and now i belive it wants a signal.. i think. The confusing part is when I look at the datasheet for the AD7823 and the AIO1, the seem to do some weird things. The CONVST label on the ADC changes over to ADCLK when it gets to the pinout, as well SCLK on the ADC changes to CONVST? Not sure why.... may take a few trial and errors to figure out what pins do what unfortunetly, or mabye Im reading it wrong...

Article: 73599
Subject: HDL Behaviorial Model for an LCD Controller
From: kryptonflash@yahoo.com (k flash)
Date: 24 Sep 2004 14:37:26 -0700
Links: << >>  << T >>  << A >>
I am looking for an LCD model which i can use as a test bench for my simulations.
Any ideas where i might be able to find one.

Thanks



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