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 36900

Article: 36900
Subject: Re: Creating a jitter free clock
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Fri, 23 Nov 2001 21:54:21 -0000
Links: << >>  << T >>  << A >>

"Adrian" <g9731642@campus.ru.ac.za> wrote in message
news:ee734b3.-1@WebX.sUN8CHnE...
> Hi,
>
> I'm using a programmable clock which has an accuracy of 1 part per
million. i.e. I can set f = 1.000000 MHz. However, I need a clock with a
resolution of 1 part per billion ie. f can be set to 1.000000000 MHz and
does not vary over a period of at least 5 minutes.
>
> Is there anything I can add to my FPGA design to achieve this? Clock will
be running at approximately 32MHz.
>

maybe a better clock 8-)


> thanks
> adrian



Article: 36901
Subject: Re: wget of WebPack
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 23 Nov 2001 14:50:38 -0800
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp1@gustad.com> writes:
> In case somebody is struggling with a not-internet-exporer-for-windows
> web browser (like myself, using Opera under Linux) to download WebPack
> - Here is how you can download it using wget:
> 
> wget --http-user USER --http-passwd PASS http://www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe
> 
> Where USER is your Xilinx registered username and PASS is your
> selected password.

or even

wget http://USER:PASS@www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe

I wonder how much money they spent developing that horrible navigation
system?  It's almost as if their intent was to prevent people from
downloading the software.


Article: 36902
Subject: Re: fix LOC on LUT1
From: khtsoi@cse.cuhk.edu.hk
Date: 24 Nov 2001 00:17:30 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> For Virtex/VIrtexE, you can use a BEL constraint to place an element
> within the F or G LUTs, the X or Y flip-flops or the F or G xorcy gate.

> attribute BEL:string;
> attribute BEL of U1: label is "F";
> attribute BEL of U2: label is "G";
> attribute BEL of U3: label is "FFX";
> attribute BEL of U4: label is "FFY";
> attribute BEL of U5: label is "XORF";
> attribute BEL of U6: label is "XORG";

I got it work. Thanks very much!

---- Brittle

Article: 36903
Subject: an unespected clock
From: shengyu_shen@hotmail.com (ssy)
Date: 23 Nov 2001 21:07:52 -0800
Links: << >>  << T >>  << A >>
Hi everyone

I use synplicity 6.2 synthesis my design, after synthesis, in the
report, I found an strange line that report two clock, one is a
explict specified "clock",the other is "system", what this means?an
wrong with my deign?

as following

		 ##### START TIMING REPORT #####

		 Performance Summary 
		*********************

           Requested     Estimated     Requested     Estimated
Clock      Frequency     Frequency     Period        Period       
Slack
------------------------------------------------------------------------
System     85.0 MHz      173.5 MHz     11.8          5.8           6.0
clock      85.0 MHz      47.6 MHz      11.8          21.0         
-9.3
========================================================================

Article: 36904
Subject: Re: Altera Quartus fork bus on block diagram
From: cgorac@yahoo.com (Crni Gorac)
Date: 24 Nov 2001 00:40:05 -0800
Links: << >>  << T >>  << A >>
That is what I was looking for. Thank you very much.


"Wolfgang Loewer" <wolfgang.loewer@elca.de> wrote in message news:<9tlqq5$fuu$07$1@news.t-online.com>...
> Naming the busses should work.
> You can download a simple example from:
> 
> http://www.elca.de/downloads/bus_test.zip
> 
> - Wolfgang
> http://www.elca.de
> 
> "Crni Gorac" <cgorac@yahoo.com> schrieb im Newsbeitrag
> news:cb2002fc.0111220955.1033a5cb@posting.google.com...
> > Am using Altera Quartus II Web edition for some simple designs for my
> > students. My question is: how to fork bus in BDF file using this tool?
> > For example, I'm trying to use 2 4-bit adders to create 8-bit adder
> > and I would like to separate op0[7..0] input to op0[3..0] input of
> > low-nibbles 4-bit adder and op0[3..0] input of high-nibbles 4-bit
> > adder.
> >
> > Thanks.

Article: 36905
Subject: Re: AHDL to VHDL
From: "Alexey Borisov" <lepton@online.ru>
Date: Sat, 24 Nov 2001 16:02:14 +0300
Links: << >>  << T >>  << A >>

Jas <spammeanddie_coach.ent@xtra.co.nz> ÐÉÛÅÔ ×
ÓÏÏÂÝÅÎÉÉ:DcfK7.33$u46.42511@news.xtra.co.nz...
> Does anyone know of software to convert AHDL to VHDL ?
>
Xilinx xport.exe
Alexey



Article: 36906
Subject: Re: How to make an implementable big counter?
From: edick@hotmail.com (Richard Erlacher)
Date: Sat, 24 Nov 2001 18:23:54 GMT
Links: << >>  << T >>  << A >>
Well, OK ... Let's try this.  

We have a data stream that has to be sampled at 120 MHz, assembled
into words and shoved into an external DRAM.  The DRAM is small
(256Kx16) and the data will be assembled and then registered as words
before being pipelined off into the RAM.  States of the fast end of
the counter have to be decoded in order to synchronize the operation
with the RAM, and the MSB of the counter is a "DONE" bit.  When the
counter is reset, it runs until the msb, used as the count enable,
goes true.  That's a 22-bit counter ...  Not terribly long, but long
enough.  I suppose this could be done as 3-bit counter and a 19-bit
counter, but, either way, it's painful.  The DRAM access has to be
done in short (page-mode) bursts, which is why the synchronization of
the decoding of the lower 3-bit section of the counter is critical.  

How close to the required 120 MHz can this counter be made to go in an
FPGA with 5-volt-tolerant I/O?  It's got to be synchronous and the
sequence has to be monotonic, so the same counter will be useable to
accomplish refresh as required.  LFSR's don't produce that sort of
sequence.  What other alternatives are there?  

Dick


On Sun, 28 Oct 2001 03:27:33 GMT, Peter Alfke <palfke@earthlink.net>
wrote:

>I think this discussion has gone too abstract.
>What is a reasonable max counter length?
>64 bits, 80 bits, 100 bits, 140 bits?
>
>Who wants to count 100 MHz until the universe has frozen over a thousand
>times?
>There has to be some reason for all this. LFSRs are great as random
>number generators. Detecting zero is reasonably easy, but adds junk. So
>does arbitrary presetting...
>The conventional binary ripple-carry structure supported in good FPGAs
>is sufficiently compact and fast for all but the most exotic purposes.
>
>Peter Alfke
>
>
>glen herrmannsfeldt wrote:
>
>> Ray Andraka <ray@andraka.com> writes:
>>
>> >How long is *really long* ?   As I pointed out, 1 CLB worth of LFSRs
>> >gets you a period of over 2000 years with a 100 MHz clock.
>> >The single LFSR actually gets more efficient as you increase its
>> >length, since the termnal count only grows at log2(N) and the LFSR
>> >grows at a little less than 1/17 that rate.  Cascading 2 identical
>> >LFSRs gets you the same effect as doubling the length of a single
>> >LFSR, so it is more expensive.  Cascading different lenght LFSRs,
>> >however may give you better granularity in your selection of period.
>>
>> Well, I said really really long.
>>
>> I don't know Virtex so well, so I don't know which mode you use
>> to do this.  Does it include the feedback taps in that one CLB?
>> Can you select any feedback taps that you want?
>>
>> So you have a 64 bit LFSR to count your 2000 years, and need
>> a 6 bit counter to count the 64 successive zeroes.  The suggestion
>> was to use a LFSR counter to count those zeroes, though, yes,
>> there might be better ways to count to 64.
>>
>> As you mention, two LFSR's with different periods could be run
>> in parallel and then detect the simultaneous zero of the two.
>> With only one more CLB you could get a 128 bit counter, and count
>> for 3e22 years.
>>
>> How many CLB's does it take to make a complete LFSR counter?
>> (Inlcuding the preset ROM and load logic for arbitrary counts?)
>>
>> -- glen
>


Article: 36907
Subject: Re: How to make an implementable big counter?
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 24 Nov 2001 19:28:23 -0000
Links: << >>  << T >>  << A >>
>         That's a 22-bit counter ...  Not terribly long, but long
>enough.  I suppose this could be done as 3-bit counter and a 19-bit
>counter, but, ...  
>
>How close to the required 120 MHz can this counter be made to go in an
>FPGA with 5-volt-tolerant I/O?  

You can make a counter as big as you want if you can tolerate some
pipeline delays.  I think carry-save is the magic word.

The idea is to drop a FF into the carry chain every N steps, where
N is small enough to meet your timing.  Of course, that means the
top of the counter is X cycles behind the bottom where X is the number
of FFs you added.  But that doesn't matter if you just need a pulse every
x cycles.  (If you are loading the counter you may have to adjust the
constant.)

I don't really understand your problem, but it sounds like you can live
with (dance around) the pipeline complications.


Your 3-19 split may be the easier way to do things.  If you use the
(registered) carry out of the bottom 3 bits as a clock enable for
the top 19, you have 8 cycles for the carry to ripple through the
19 bit section.

This has the same sort of complication - the bottom 3 bits are
one step ahead of the top 19.  But you can fix that by generating
the clock enable a cycle early - when the bottom bits are 110 rather
than 111.

Look for some app notes.  Maybe older ones.  This was a more interesting
problem when chips were slower.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 36908
Subject: Re: How to make an implementable big counter?
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Sat, 24 Nov 2001 19:59:39 -0500
Links: << >>  << T >>  << A >>
Richard,

Try a SpartanXL.  In the highest speed grade it should reach to beyond
200MHz.  I currently have a 16 bit synchronous counter running at 200MHz in a
design.

Theron Hicks


Richard Erlacher wrote:

> Well, OK ... Let's try this.
>
> We have a data stream that has to be sampled at 120 MHz, assembled
> into words and shoved into an external DRAM.  The DRAM is small
> (256Kx16) and the data will be assembled and then registered as words
> before being pipelined off into the RAM.  States of the fast end of
> the counter have to be decoded in order to synchronize the operation
> with the RAM, and the MSB of the counter is a "DONE" bit.  When the
> counter is reset, it runs until the msb, used as the count enable,
> goes true.  That's a 22-bit counter ...  Not terribly long, but long
> enough.  I suppose this could be done as 3-bit counter and a 19-bit
> counter, but, either way, it's painful.  The DRAM access has to be
> done in short (page-mode) bursts, which is why the synchronization of
> the decoding of the lower 3-bit section of the counter is critical.
>
> How close to the required 120 MHz can this counter be made to go in an
> FPGA with 5-volt-tolerant I/O?  It's got to be synchronous and the
> sequence has to be monotonic, so the same counter will be useable to
> accomplish refresh as required.  LFSR's don't produce that sort of
> sequence.  What other alternatives are there?
>
> Dick
>
> On Sun, 28 Oct 2001 03:27:33 GMT, Peter Alfke <palfke@earthlink.net>
> wrote:
>
> >I think this discussion has gone too abstract.
> >What is a reasonable max counter length?
> >64 bits, 80 bits, 100 bits, 140 bits?
> >
> >Who wants to count 100 MHz until the universe has frozen over a thousand
> >times?
> >There has to be some reason for all this. LFSRs are great as random
> >number generators. Detecting zero is reasonably easy, but adds junk. So
> >does arbitrary presetting...
> >The conventional binary ripple-carry structure supported in good FPGAs
> >is sufficiently compact and fast for all but the most exotic purposes.
> >
> >Peter Alfke
> >
> >
> >glen herrmannsfeldt wrote:
> >
> >> Ray Andraka <ray@andraka.com> writes:
> >>
> >> >How long is *really long* ?   As I pointed out, 1 CLB worth of LFSRs
> >> >gets you a period of over 2000 years with a 100 MHz clock.
> >> >The single LFSR actually gets more efficient as you increase its
> >> >length, since the termnal count only grows at log2(N) and the LFSR
> >> >grows at a little less than 1/17 that rate.  Cascading 2 identical
> >> >LFSRs gets you the same effect as doubling the length of a single
> >> >LFSR, so it is more expensive.  Cascading different lenght LFSRs,
> >> >however may give you better granularity in your selection of period.
> >>
> >> Well, I said really really long.
> >>
> >> I don't know Virtex so well, so I don't know which mode you use
> >> to do this.  Does it include the feedback taps in that one CLB?
> >> Can you select any feedback taps that you want?
> >>
> >> So you have a 64 bit LFSR to count your 2000 years, and need
> >> a 6 bit counter to count the 64 successive zeroes.  The suggestion
> >> was to use a LFSR counter to count those zeroes, though, yes,
> >> there might be better ways to count to 64.
> >>
> >> As you mention, two LFSR's with different periods could be run
> >> in parallel and then detect the simultaneous zero of the two.
> >> With only one more CLB you could get a 128 bit counter, and count
> >> for 3e22 years.
> >>
> >> How many CLB's does it take to make a complete LFSR counter?
> >> (Inlcuding the preset ROM and load logic for arbitrary counts?)
> >>
> >> -- glen
> >


Article: 36909
Subject: Why "Can't scan device chains in APEX20K400E SOPC board from Altera"?
From: shengyu_shen@hotmail.com (ssy)
Date: 24 Nov 2001 18:33:32 -0800
Links: << >>  << T >>  << A >>
Hi everyone

 APEX20k400E SOPC board has three EPC2 for programing. QuartusII
generates three corresponding .pof(as LED.pof,LED1.pof and LED2.pof)
when compliling. Their correct order is LED,LED1 and LED2 when
programing,but I use wrong order LED1,LED,LED2. And then QuartusII
cannot find the EPC2 chain any longer . How to do with it?Thanks.


 I set jumpers to bypass EPC2 and program the APEX directly , and it
works well. So I think that the .pof files with the wrong order
configure the EPC2s false. Maybe I should erase the three EPC2. When I
cannot scan the EPC2 chains with Quartus,how to erase them?

Article: 36910
Subject: Re: How to make an implementable big counter?
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 25 Nov 2001 04:10:13 GMT
Links: << >>  << T >>  << A >>
Dick, the way I understand this, you have a continuously running counter
that sampels incoming data. Every 16 clock ticks you dump the assembled data

wod into a DRAM ( why not SRAM, which would save you the fancy control and
the refresh ? And in Virtex-II you could easily store it in the BlockRAMs
inside...)
Absolutely under all circumstances use a modern FPGA with dedicated carry,
like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II.
Depending on the family, the carry delay is between 50 and 100 ps per bit,
so you should not have any difficulty with your 22 bits.
But if you are very conservative, you can break the counter into a 4-bit
front-end, decode its all-ones state (F), and use it as a count enable for
the remaining 18 bits.This is all very easy, and is totally synchronous. It
does not create any pipeline delay or other funnies. Your code is all
binary, like you want it to be.

Have fun!

Peter Alfke, Xilinx Applications
============================
Richard Erlacher wrote:

> Well, OK ... Let's try this.
>
> We have a data stream that has to be sampled at 120 MHz, assembled
> into words and shoved into an external DRAM.  The DRAM is small
> (256Kx16) and the data will be assembled and then registered as words
> before being pipelined off into the RAM.  States of the fast end of
> the counter have to be decoded in order to synchronize the operation
> with the RAM, and the MSB of the counter is a "DONE" bit.  When the
> counter is reset, it runs until the msb, used as the count enable,
> goes true.  That's a 22-bit counter ...  Not terribly long, but long
> enough.  I suppose this could be done as 3-bit counter and a 19-bit
> counter, but, either way, it's painful.  The DRAM access has to be
> done in short (page-mode) bursts, which is why the synchronization of
> the decoding of the lower 3-bit section of the counter is critical.
>
> How close to the required 120 MHz can this counter be made to go in an
> FPGA with 5-volt-tolerant I/O?  It's got to be synchronous and the
> sequence has to be monotonic, so the same counter will be useable to
> accomplish refresh as required.  LFSR's don't produce that sort of
> sequence.  What other alternatives are there?
>
> Dick
>


Article: 36911
Subject: DDS by LogiCore & how to overcome net delay
From: ekkho@students.wisc.edu (enny)
Date: 24 Nov 2001 22:04:13 -0800
Links: << >>  << T >>  << A >>
I am designing DDS using Core Generator

When doing implementation for Spartan2, Virtex, there are net delay
that cause it to have max freq of 47 Mhz, however I am planning to
apply 100 MHz clock or more so that the DDS can output higher
frequency --> Question: will DLL or frequency multiplier feature of
Virtex 2 helps ?

when I generate DDS with the same parameters, it keep gives me 
different # of LUTs, regs, primitives --- how come, and is it matter?

Thanks a lot in advance
enny

Article: 36912
Subject: ALTERA's Mercury CDR
From: "Arie Zychlinski" <ariez@attglobal.net>
Date: Sun, 25 Nov 2001 10:43:48 +0200
Links: << >>  << T >>  << A >>
I would be much obliged to learn for your experience with the ALTERA's
Mercury CDR using the M1GXCVR core. we intend to use it in a new project for
800 Mbps links.
thank you in advance.

--

                           yours -
                                     Arie Z.

============================================
 Arie  Zychlinski
 R&D Consulting & Development
 P.O.Box  536
 Kfar-Saba  44104
 ISRAEL

 Mobile: 972-58-320230
 Phone:  W: 972-9-7673074   H: 972-9-7658268

 E-Mail:  ariez@attglobal.net
 ===========================================



Article: 36913
Subject: Re: ALTERA's Mercury CDR
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 25 Nov 2001 21:12:07 GMT
Links: << >>  << T >>  << A >>
Here are some observations from my not-so-impartial viewpoint:

1. The Altera clock recovery requires a specialized training sequence.

2. The claim that it eliminates the need for balanced pc-bord trace length is
somewhat strange, since the granularity of the clocking scheme is 300 ps at
best. That is equivalent to about 2 inches or 5 cm trace length. For any of the
more realistic smaller differences in trace length, this adaptive per-bit
clocking scheme offers no advantage.

3. And finally, Altera makes bogus claims about LVDS power consumption, where
they quote not the consumed power (Vcc x Icc ) in the driver, but rather the
power dissipated in the 100 Ohm termination resistor. Nobody cares about this
nice low number, which makes it a candidate for the "Misleading Marketing"
award of the year.

Parallel busses with 800 Mbps per channel are challenging today.
Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking.
Xilinx goes for fine-granularity ( 50 ps ) common clocking.
Guess which one I like better.

And next year, self-clocking bit-serial 2.5 Gbps,
with 4-channel bonding for 10 Gbps data traffic will become the standard.

Peter Alfke, Xilinx Applications Engineering.
========================================
Arie Zychlinski wrote:

> I would be much obliged to learn for your experience with the ALTERA's
> Mercury CDR using the M1GXCVR core. we intend to use it in a new project for
> 800 Mbps links.
> thank you in advance.
>
> --
>
>                            yours -
>                                      Arie Z.
>
> ============================================
>  Arie  Zychlinski
>  R&D Consulting & Development
>  P.O.Box  536
>  Kfar-Saba  44104
>  ISRAEL
>
>  Mobile: 972-58-320230
>  Phone:  W: 972-9-7673074   H: 972-9-7658268
>
>  E-Mail:  ariez@attglobal.net
>  ===========================================


Article: 36914
Subject: Re: ALTERA's Mercury CDR
From: rotemg@mysticom.com (Rotem Gazit)
Date: 25 Nov 2001 22:41:08 -0800
Links: << >>  << T >>  << A >>
Peter,
Can you elaborate (or give a pointer) on how Xilinx calculates its
LVDS buffers power consumption ?
Do Xilinx LVDS buffers support the full LVDS specification, or just
the "reduced range" ?.

Thanks,
Rotem Gazit
MystiCom LTD
mailto:rotemg@mysticom.com
http://www.mysticom.com/






Peter Alfke <palfke@earthlink.net> wrote in message news:<3C015E9A.B98CA518@earthlink.net>...
> Here are some observations from my not-so-impartial viewpoint:
> 
> 1. The Altera clock recovery requires a specialized training sequence.
> 
> 2. The claim that it eliminates the need for balanced pc-bord trace length is
> somewhat strange, since the granularity of the clocking scheme is 300 ps at
> best. That is equivalent to about 2 inches or 5 cm trace length. For any of the
> more realistic smaller differences in trace length, this adaptive per-bit
> clocking scheme offers no advantage.
> 
> 3. And finally, Altera makes bogus claims about LVDS power consumption, where
> they quote not the consumed power (Vcc x Icc ) in the driver, but rather the
> power dissipated in the 100 Ohm termination resistor. Nobody cares about this
> nice low number, which makes it a candidate for the "Misleading Marketing"
> award of the year.
> 
> Parallel busses with 800 Mbps per channel are challenging today.
> Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking.
> Xilinx goes for fine-granularity ( 50 ps ) common clocking.
> Guess which one I like better.
> 
> And next year, self-clocking bit-serial 2.5 Gbps,
> with 4-channel bonding for 10 Gbps data traffic will become the standard.
> 
> Peter Alfke, Xilinx Applications Engineering.
> ========================================
> Arie Zychlinski wrote:
> 
> > I would be much obliged to learn for your experience with the ALTERA's
> > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for
> > 800 Mbps links.
> > thank you in advance.
> >
> > --
> >
> >                            yours -
> >                                      Arie Z.
> >
> > ============================================
> >  Arie  Zychlinski
> >  R&D Consulting & Development
> >  P.O.Box  536
> >  Kfar-Saba  44104
> >  ISRAEL
> >
> >  Mobile: 972-58-320230
> >  Phone:  W: 972-9-7673074   H: 972-9-7658268
> >
> >  E-Mail:  ariez@attglobal.net
> >  ===========================================

Article: 36915
Subject: an error of quartus
From: shengyu_shen@hotmail.com (ssy)
Date: 25 Nov 2001 22:42:34 -0800
Links: << >>  << T >>  << A >>
I am using synplify to syn my design, after that , I perform post syn
smulation with vcs, vcs report an error in "ALTERA_MF.V" distribut
with Quartus 1.0, I found it actually an error,

in line 8296 of altera_mf.v, it is as follow:

assign rx_locklost = (deserialization_factor > 1) ?
i_rx_locked[number_of_channels-1:0] : {(number_of_channels-1){1'b1}};

notice that in this mux, the first way's width is number_of_channels,
but the second's width is number_of_channels-1

any idea about this error?

Article: 36916
Subject: FFT with Distributed Arithmatic
From: Hananiel Sarella <hsarella@honeybee.ececs.uc.edu>
Date: 26 Nov 2001 02:22:20 -0500
Links: << >>  << T >>  << A >>
Hello folks,
           Im trying to implement large FFTs on Xilinx vertex II FPGAs. I have a couple of questions. 
1. There are multipliers on chip with 5ns delays. There  is a paper by lez mintzer "large ffts on fpgas" which describes how to code one fft butterfly with DA tables. The pipeline delay in this case is less than the multiplier delay and there are more multiplies per stage delay.   
  Can some one tell me which is better?    
2. Im writing synthesizeable structural VHDL code for the butterfly processor. Im having to write code for controlling this for say, 8192 point FFT. Is this the way people do it. Like say guys writing xilinx cores. Or is there a better way you can suggest. 

Thanks a lot,
Hananiel





















Article: 36917
Subject: Some question on Synplify
From: dottavio@ised.it (Antonio)
Date: 25 Nov 2001 23:49:06 -0800
Links: << >>  << T >>  << A >>
1)
In my project I've a master clock at 165MHz and three clocks derived
by it , in Synplyfy Pro I could see and apply contrains only at the
first, why and how I could resolve this ??

2)
What is the meaning of the following estensions in HDL analist
schematics :
_cry   ,   _abx ,   _s   
and the meaning of FDR ,   FDS  , IBUF , INV , BUF

3) 
why some LUT on the HDL Analist are showed with a gray background ??
What's the meaning ??

Thanks

Article: 36918
Subject: CHES 2002 - Call For Papers
From: Christof Paar <christof@ece.wpi.edu>
Date: Mon, 26 Nov 2001 02:54:05 -0500
Links: << >>  << T >>  << A >>

     Workshop on Cryptographic Hardware and Embedded Systems 2002
                            (CHES 2002)
                       www.chesworkshop.org

         Hotel Sofitel, San Francisco Bay (Redwood City), USA
                       August 13 - 15, 2002


                      First Call for Papers

General Information

The focus of this workshop is on all aspects of cryptographic hardware
and security in embedded systems. The workshop will be a forum of new
results from the research community as well as from the industry. Of
special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submissions from academia,
industry, and other organizations. All submitted papers will be
reviewed.

This will be the fourth CHES workshop. CHES '99 and CHES 2000 were
held at WPI, and CHES 2001 was held in Paris. The number of
participants has grown to more than 200, with attendees coming from
industry, academia, and government organizations. The topics of CHES
2002 include but are not limited to:

   * Computer architectures for public-key and secret-key cryptosystems
   * Efficient algorithms for embedded processors
   * Reconfigurable computing in cryptography
   * Cryptographic processors and co-processors
   * Cryptography in wireless applications (mobile phone, LANs, etc.)
   * Security in pay-TV systems
   * Smart card attacks and architectures
   * Tamper resistance on the chip and board level
   * True and pseudo random number generators
   * Special-purpose hardware for cryptanalysis
   * Embedded security
   * Device identification



Instructions for Authors

Authors are invited to submit original papers. The preferred
submission form is by electronic mail to
submission@chesworkshop.org. The submissions must be anonymous, with
no author names, affiliations, acknowledgments, or obvious
references. Papers should be formatted in 12pt type and not exceed 12
pages (not including the title page and the bibliography). Please
submit the paper in Postscript or PDF, together with an extra file
containing the email and physical address of the authors, and an
indication of the corresponding author. We recommend that you generate
the PS or PDF file using LaTeX, however, MS Word is also
acceptable. All submissions will be refereed. Only original research
contributions will be considered. Submissions must not substantially
duplicate work that any of the authors have published elsewhere or
have submitted in parallel to any other conferences or workshops that
have proceedings.



Important Dates

 Submission Deadline:          May 1st, 2002.
 Acceptance Notification:      July 1st, 2002.
 Final Version due:            August 1st, 2002.
 Workshop:                     August 13th - 15th, 2002.

NOTE: The CHES dates August 13th - 15th are the Tuesday through
Thursday preceeding CRYPTO 2002 which starts on evening of Sunday,
August 18th.



Mailing List

If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
mailinglist@chesworkshop.org.



Program Committee

Beni Arazi, Ben Gurion University, Israel
Jean-Sebastien Coron, Gemplus Card International, France
Kris Gaj, George Mason University, USA
Craig Gentry, DoCoMo Communications Laboratories, USA
Jim Goodman, Lumic Electronics, Canada
M. Anwar Hasan, University of Waterloo, Canada
David Jablon, Phoenix Technologies, USA
Peter Kornerup, Odense University, Denmark
Pil Joong Lee, Pohang Univ. of Sci. & Tech., Korea
Preda Mihailescu, University of Paderborn, Germany
David Nacchache, Gemplus Card International, France
Bart Preneel, Universite Catholique de Louvain, Belgium
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Erkay Savas, rTrust Technologies, USA
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Jacques Stern, Ecole Normale Superieure, France
Berk Sunar, Worcester Polytechnic Institute, USA
Colin Walter, Computation Department - UMIST, U.K.



Organizational Committee

All correspondence and/or questions should be directed to either of
the Organizational Committee Members:

Burt Kaliski
(Program Chair)
RSA Laboratories
20 Crosby Drive
Bedford, MA 01730, USA
Phone: +1 781 687 7057
Fax: +1 781 687 7213
Email: bkaliski@rsasecurity.com

Cetin Kaya Koc
(Local Organization)
Dept. of Electrical & Computer Engineering
Oregon State University
Corvallis, Oregon 97331, USA
Phone: +1 541 737 4853
Fax: +1 541 737 8377
Email: Koc@ece.orst.edu

Christof Paar
(Publicity Chair)
Electrical Eng. & Information Sciences Dept.
Ruhr-Universitaet Bochum
44780 Bochum, Germany
Phone: +49 234 32 23988
Fax: +49 234 32 14444
Email: cpaar@crypto.ruhr-uni-bochum.de



Workshop Proceedings

The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.




Article: 36919
Subject: PCI-CORE in XC4000XLA using Leonardo Spectrum
From: Peter Gustafsson <Peter.J.Gustafsson@emw.ericsson.se>
Date: Mon, 26 Nov 2001 09:06:42 +0100
Links: << >>  << T >>  << A >>
Has anyone successfully used Leonardo Spectrum as
synthesis tool when using xilinx Logicore PCI32 in 
a xc4028xla?

I'm running into all kinds of problems which i think
is the synthesis phase "fault".

 * In M2.1i in map phase all logic is removed! if i use
   use the -u switch the logic remains and the core simulates.

   This is probably due to that the PCI clock buffer is defined 
   inside the PCI-CORE and as i use the PCI-core clock output to
   rest of my design it is crucial that the clock buffer inside the
   core is recognized.

I gladly tell you more about the problem....

Kind Regards

Peter Gustafsson

Article: 36920
Subject: Re: Some question on Synplify
From: sunny <sunrise@sunrise.at>
Date: Mon, 26 Nov 2001 01:00:10 -0800
Links: << >>  << T >>  << A >>
1. At least the log file should show you that there were some clocks detected. You will fínd a statement in which Synplify tells you that it is assuming clock frequency to be the same as "default" frequency. If you would use SynplifyPro you could use HDL Analyst debugging tool to search for those inferred clocks. 
Just open up "Technology View", flatten it and use the "Find" function to detect Synplify´s "keepbufs". Those keeepbufs will show you that Synplify was able to detect internally generated clocks.  

2. IBUF means an Xilinx Input buffer, obviously FDR and FDS are Flops with Reset and Set. Just think over what kind of components BUF and INV could be.

3. A gray LUT is not only gray but also shows you how the LUT was used. 

In general YOU SHOULD NOT use dervide clocks. Why don´t you use Clock Enable Inputs for derived frequencies?

Article: 36921
Subject: Re: Decoupling capacitors on Virtex II
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Nov 2001 09:43:58 +0000
Links: << >>  << T >>  << A >>
John  Larkin <jjlarkin@highlandSNIPTHIStechnology.com> writes:

> 
> Even on 4-layer boards, we specify a very thin dielectric layer
> between the power and ground planes to get the best plane effects. The
> PCB fab houses don't seem to mind.
> 

How thin do you go on 4 layer boards?  And what track
widths/impedances/heights above planes do you end up with on the
tracking layer?

> 
> The TDR we used has a net risetime of about 30 ps, or about 0.1"
> resolution inside FR4. Yes, it surprised me that the bypass cap
> location made no discernable difference to the impedance seen at the
> SMA test point. I think the FR4 material is lossy enough to smear out
> any reflections (or, in the frequency domain, kill the Q of any
> resonances, which would be well into the GHz range here). 
> 

FR4 is certainly more lossy at those sort of frequencies.  And the
skin effect will cause resistive losses also I imagine.

> I embarked on this because (besides it being fun) I had just finished
> a board that, using the usual ROTs, had something like 200 bypass
> caps, and it occurred to me that a) this was silly and b) I had never
> designed a multilayer board that actually failed because of
> insufficient logic bypasses.
> 

:-)  Good reasons!

> Hey, I'm an engineer; I don't have to understand it, I only have to
> make it work!
> 

Once we understand it we can then persuade others that they don't 200
caps also....

Cheers,
Martin


Article: 36922
Subject: Re: ALTERA's Mercury CDR
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Mon, 26 Nov 2001 11:04:00 +0100
Links: << >>  << T >>  << A >>
Peter,
you write "the granularity of the clocking scheme is 300 ps at best". Can
you please elaborate on what this assertion is based upon.

From: AN 130, CDR in Mercury Devices, page 8:
"... Each of the eight equally-spaced phase clocks is divided into seven
fractions; therefore, the resulting best-case clock granularity is 1/56 of
the clock period. ..."

1/56 of a 1.25 GHz clock is equal to about 14 ps.

14 ps in today's Altera devices compared to 50 ps granularity in future
Xilinx devices - please correct me if I have misinterpreted something here,
but guess which one I like better.

Wolfgang
http://www.elca.de

"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
news:3C015E9A.B98CA518@earthlink.net...
> Here are some observations from my not-so-impartial viewpoint:
>
> 1. The Altera clock recovery requires a specialized training sequence.
>
> 2. The claim that it eliminates the need for balanced pc-bord trace length
is
> somewhat strange, since the granularity of the clocking scheme is 300 ps
at
> best. That is equivalent to about 2 inches or 5 cm trace length. For any
of the
> more realistic smaller differences in trace length, this adaptive per-bit
> clocking scheme offers no advantage.
>
> 3. And finally, Altera makes bogus claims about LVDS power consumption,
where
> they quote not the consumed power (Vcc x Icc ) in the driver, but rather
the
> power dissipated in the 100 Ohm termination resistor. Nobody cares about
this
> nice low number, which makes it a candidate for the "Misleading Marketing"
> award of the year.
>
> Parallel busses with 800 Mbps per channel are challenging today.
> Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking.
> Xilinx goes for fine-granularity ( 50 ps ) common clocking.
> Guess which one I like better.
>
> And next year, self-clocking bit-serial 2.5 Gbps,
> with 4-channel bonding for 10 Gbps data traffic will become the standard.
>
> Peter Alfke, Xilinx Applications Engineering.
> ========================================
> Arie Zychlinski wrote:
>
> > I would be much obliged to learn for your experience with the ALTERA's
> > Mercury CDR using the M1GXCVR core. we intend to use it in a new project
for
> > 800 Mbps links.
> > thank you in advance.
> >
> > --
> >
> >                            yours -
> >                                      Arie Z.
> >
> > ============================================
> >  Arie  Zychlinski
> >  R&D Consulting & Development
> >  P.O.Box  536
> >  Kfar-Saba  44104
> >  ISRAEL
> >
> >  Mobile: 972-58-320230
> >  Phone:  W: 972-9-7673074   H: 972-9-7658268
> >
> >  E-Mail:  ariez@attglobal.net
> >  ===========================================
>



Article: 36923
Subject: fpga programming using microcontroller
From: swan <>
Date: Mon, 26 Nov 2001 03:27:37 -0800
Links: << >>  << T >>  << A >>
hi,
i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
rgds
swan

Article: 36924
Subject: Re: fpga programming using microcontroller
From: "MK" <mk@sgriol.demon.co.uk>
Date: Mon, 26 Nov 2001 14:32:09 -0000
Links: << >>  << T >>  << A >>

<swan> wrote in message news:ee7354f.-1@WebX.sUN8CHnE...
> hi,
> i'm using spartan fpga in a design having microcontroller. I want to
program the fpga through a microcontroller. i have gone through xapp058. but
to implement this code one needs an operating system and also this code is
too complicated to make any changes to it. is there any other way to achieve
this?
> rgds
> swan

xapp058 does the full JTAG thing and is attempting to be universal so that
makes it very complicated. If you want to write your own code its much
simpler to forget about JTAG and do it using the slave serial mode process.
Read xapp098 which tells you hwo to do it.
The last time I actually wrote a serial config progam was for an XC1800 (I
think) and the processor was a Motorola 68HC11. Its a while ago but I think
the code was less than 100 lines of C.


Michael Kellett
www.mkesc.co.uk







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