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

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 83500

Article: 83500
Subject: Re: Microblaze FSL interface timing diagram
From: Paul Hartke <phartke@Stanford.EDU>
Date: Sun, 01 May 2005 09:25:18 -0700
Links: << >>  << T >>  << A >>
It took me a while to assemble all the FSL info the first time I looked
as
well.  Google is uncharacteristically unhelpful... 

Actual Waveforms are in the FSL pcore documentation:
http://www.xilinx.com/bvdocs/ipcenter/data_sheet/FSL_V20.pdf

The MicroBlaze Processor Reference Guide discusses the FSL assembly 
instructions:
http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf

The Microblaze Standalone Board Support Package has C macros for each of
the FSL assembly instructions:
http://www.xilinx.com/ise/embedded/oslibs_rm.pdf

XAPP529: Connecting Customized IP to the MicroBlaze Soft Processor Using
the Fast Simplex Link (FSL) Channel:
http://direct.xilinx.com/bvdocs/appnotes/xapp529.pdf

In EDK 7.1 (not sure about previous versions), the Create and Import 
Peripheral Wizard provides nice FSL starter file support:
http://www.xilinx.com/ise/embedded/est_rm.pdf

Paul

Philipp Grabher wrote:
> 
> Hello
> 
> Somehow I am not able to find in any Xilinx documentation a detail
> description of the FSL interface. I am especially looking
> for the read and write timing diagrams. Anyone knows where I can find them?
> 
> Cheers
> Philipp

Article: 83501
Subject: one hot decoder
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sun, 01 May 2005 19:32:40 +0200
Links: << >>  << T >>  << A >>
I need to add some more information to be absolutely accurate :

> -- -------------------------------------
>     Architecture RTL_if of HOTDECOD is
> -- -------------------------------------
> -- and how many LUTS for this one ?
> -- Isn't this description easier to rewrite under
> -- the form of a (size-independant) function ?
> begin
> 
> process (A)
> begin
>        if A(7) = '1' then Q <= "111";
>     elsif A(6) = '1' then Q <= "110";
>     elsif A(5) = '1' then Q <= "101";
>     elsif A(4) = '1' then Q <= "100";
>     elsif A(3) = '1' then Q <= "011";
>     elsif A(2) = '1' then Q <= "010";
>     elsif A(1) = '1' then Q <= "001";
>     elsif A(0) = '1' then Q <= "000";
>     else                  Q <= "---"; -- don't care
>   end if;
> end process;
> -- do you see a "priority" in the synthesized result ???

There IS in fact a priority in the description above which is
indeed respected in the synthesized result ! This description
works as a one hot decoder, but it is also a priority encoder
when it handles the overlapping cases.
This is why this solution is still not optimal (as a one-hot decoder)!
(5 LUTs instead of 3).

A really optimized one hot decoder (with all synthesis tools) can
be built with the following function (provided by S. Weir in an
old post) :

   ----------------------------------------------------------------------------
   -- Encode a vector of discrete bits into a binary vector representation,
   -- WITHOUT guarding against multiple bits on.
   --
   -- For a single bit on, the encoded value is the offset from the
   -- low index of src of the asserting bit, regardless of src's
   -- endianness.
   ----------------------------------------------------------------------------
   function fnEncBin ( src  : std_logic_vector ) return std_logic_vector is
    variable rslt : std_logic_vector( fnLog2M( src'length ) - 1 downto 0 ) ;
   begin
    rslt := ( rslt'range => '0' ) ;
    for rslt_idx in rslt'range loop
     for src_idx in src'length - 1 downto 0 loop
      if( ( ( src_idx / ( 2**rslt_idx ) ) MOD 2 ) = 1 ) then
       rslt( rslt_idx ) := rslt( rslt_idx ) OR src( src_idx + src'low ) ;
      end if ;
     end loop ;
    end loop ;
    return( rslt ) ;
   end ;

This function simply infers the OR gates directly !
In the case of this post, the one hot decoder ends up in
three (4 inputs) LUTs, one logic layer instead of 2 (or more).
I don't think there is any other description that infers the
minimal result with all synthesis tools.

Bert Cuzeau



Article: 83502
Subject: Re: Virtex4 and ISE reality check?
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 1 May 2005 19:59:46 +0200
Links: << >>  << T >>  << A >>
Hi

I bet no one can answer all your questions at the present time - for sure V4
DDR Designs works, so the tools must work too, but...

You asked a lot of questions about timing and reports and the accuracy of
them, I assume you do not have a FPGA test board for your design, so looking
at your schedule (production start July 2005 ?) there is on thing I can say
for sure, - with your deadline the only way to be somewhat confident that
the design will work is following:

go buy the ML461 memory reference board next monday, and implement the
tricky part on that part ASAP, and let it run continous in-FPGA memory test,
check for temperature influence, etc.. only based on those results you can
decide. If your management doesnt approve that investment (buying the ML461
board) then forget about V4 with DDR design for production start in July.

looking at the timing reports will not give you the confidence level needed
(at least that is my opinion), I'm sure some/many will disagree here..

Antti
PS as of ISE vs Synplify, Synplify is known to be better, but not always at
the moment I have a desing where ISE 6.3 meets PCI-X 100MHz timing, but
Synplify reports 31 levels of logic (vs 11 with XST) and the timing fails of
totally. No idea why this happens with that design, just a note that
Synplify doesnt necessarily always do thing better than XST synthesis.







<jjohnson@cs.ucf.edu> schrieb im Newsbeitrag
news:1114961847.181914.181930@z14g2000cwz.googlegroups.com...
>
> I've heard a few painful stories about implementing Xilinx Virtex4
> designs (bad SDF, bad bitfiles, power supply requirements, etc...)
>
> Are the parts and tool flows really ready for production designs with
> the V4? Should I bet the farm on getting a V4 design into production by
> July?
>
> Our vendor promises industrial-temp parts by June. We're merging 3
> mid-size V2Pro chips into one V4. The only tricky part is our 12-bit
> DDR deserializers on the front end: 5 interfaces at 360 MHz (times four
> 720 Mbps data streams on each interface).
>
> How accurate/reliable is the back-annotated SDF out of ISE (v7.1.01i)?
>
> How accurate/reliable are the timing reports from trce?
>
> If trce generates the SDF, they should correlate well, but do they? Is
> either one really trustworthy for analyzing/debugging? (I'm still
> trying to understand some of what I'm seeing on the V2Pro designs.)
>
> If I use the timing prorate options (max voltage, coldest temperature)
> in an attempt to anaylze min timing, are the trce reports and SDF
> output realistic?
>
> With fast DDR inputs, hold times are important too. The additional IOB
> delay element (~1.1ns if enabled?) also adds uncertainty to the
> setup/hold requirements, making for tighter data valid window
> requirements, and appears to do more harm than good in this case.
>
> OTHER TOOLS:
>
> Does anyone have specific comments regarding Synplicity (Synplify Pro)
> or Synopsys (DC-FPGA and PrimeTime) on a Virtex4 design?
>
> Thanks very, very much for your help.
>
> mj
>



Article: 83503
Subject: Re: PCI-X target chip with simple backend interface....
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 1 May 2005 20:18:13 +0200
Links: << >>  << T >>  << A >>
Hi Andy

why do you use invalid hotmail email address (I tried to mail you)?

It is possible that the chip you are looking for doesnt exist - I am
guessing that those who require the full PCI-X performance most likely are
either go ASIC or implement the core in FPGA. I would be very surprised to
find low simple to use PCI-X 533MHz bridge chip. Actually I am sure it
doesnt exist. The problem is that for the 'easy backend' its almost not
possible to be implemented off chip in a way that is universally useable. I
mean an unirsal PCI-X to local bus bridge would not be so much higher
performance than PCI to local bus chip, that is possible the reason why PLX
doesnt have it. And if PLX doesnt have it, it will not have it ever, because
they are much more into PCI express stuff than adding new PCI-X chips I bet.

in short: there is no vendor for what you are asking for and very likely
will never be.

Antti





<andyesquire@hotmail.com> schrieb im Newsbeitrag
news:1114943918.181796.63070@f14g2000cwb.googlegroups.com...
>
> After extensive Googling I'm unable to find a PCI-X target chip with a
> simple backend interface that would act as cost effective glue logic
> between a FPGA (Xilinx) and a PCI-X local bus.
>
> Surely there is a requirement for such a ASSP device in the market
> place, given the alternative is to purchase a PCI-X IP target core,
> typically costing over $10,000. I'm aware that PLX Technology offer
> such a device, but alas only for PCI.
>
> Does anybody know of a vendor?
>
> Thanks,
>
> Andy.
>



Article: 83504
Subject: Re: Virtex4 and ISE reality check?
From: "Marc Randolph" <mrand@my-deja.com>
Date: 1 May 2005 12:18:06 -0700
Links: << >>  << T >>  << A >>

Antti Lukats wrote:
[...]
> You asked a lot of questions about timing and reports and the
accuracy of
> them, I assume you do not have a FPGA test board for your design, so
looking
> at your schedule (production start July 2005 ?) there is on thing I
can say
> for sure, - with your deadline the only way to be somewhat confident
that
> the design will work is following:
>
> go buy the ML461 memory reference board next monday, and implement
the
> tricky part on that part ASAP, and let it run continous in-FPGA
memory test,
> check for temperature influence, etc.. only based on those results
you can
> decide. If your management doesnt approve that investment (buying the
ML461
> board) then forget about V4 with DDR design for production start in
July.

Not to mention that he was asking for I-temp parts:

>> Our vendor promises industrial-temp parts by June. We're merging 3

I don't know if "our vendor" means that the distributor is making these
promises, but I'd want it in writing with financial penalities -
because I'm pretty sure there is no way for them to meet that date:
I-temp parts typically aren't available for a number of months after
C-temp production.

> looking at the timing reports will not give you the confidence level
needed
> (at least that is my opinion), I'm sure some/many will disagree
here..

Considering that the design is supposedly already proven out, with one
exception, I'll go ahead and disagree with you :-).  Confirmation via
timing analysis should be enough, with the exception that one or more
of the errata may cause some grief (depending on his design).  As the
OP hints at, the data and clock relationship for the DDR interface
(2x360 MHz, I think) provides a challenge as well, but if simulated
accurately, shouldn't pose major issues.  I'm basing this on the fact
that my V4 interfaces (most of which migrated from V2Pro) came right
up.

But unlike the OP, I can say all of this because I have the luxury of
not having to face the music he will have to face if/when something
goes wrong and there is no time in this seemingly insane schedule to
fix it.

Speaking of which, why is there such an accelerated schedule from a
.edu?

> Antti
> PS as of ISE vs Synplify, Synplify is known to be better, but not
always at
> the moment I have a desing where ISE 6.3 meets PCI-X 100MHz timing,
but
> Synplify reports 31 levels of logic (vs 11 with XST) and the timing
fails of
> totally. No idea why this happens with that design, just a note that
> Synplify doesnt necessarily always do thing better than XST
synthesis.

Ken McElvain from Synplity (who usually hangs out here), would probably
be VERY interested in seeing your design - assuming this still happens
in 8.0.

Have fun,

   Marc


Article: 83505
Subject: Re: current price for (small quantity) XC4VFX12/FF668
From: Simon <news@gornall.net>
Date: Sun, 01 May 2005 12:19:08 -0700
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Simon" <news@gornall.net> schrieb im Newsbeitrag
> news:I4OdnQ3Pm-Iy6enfRVn-rw@comcast.com...
> 
>>Just trying to figure out what the rough price of V4 FX12/FF668 part
>>is... AVNet and NuHorizons aren't showing any prices or stock atm, and
>>digikey don't do anything even vaguely recent :-(
>>
>>Anyone bought any (quantity 1-10) recently and want to give me a
>>ball-park figure ?
>>
>>Cheers,
>>Simon.
> 
> 
> the ball-park figure is $100 if you get a very very very good deal, if not
> then multiply by the tambov's constant* to get your price.
> 
> Antti
> 
> *tambov's constant: a constant multiplier that when applied always gives the
> correct result for any equation.

Cheers Antti - first time I've heard of tambov's constant :-)

ATB,
	Simon

Article: 83506
Subject: Re: current price for (small quantity) XC4VFX12/FF668
From: Simon <news@gornall.net>
Date: Sun, 01 May 2005 12:24:38 -0700
Links: << >>  << T >>  << A >>
Marc Randolph wrote:
> 
> 
> But to directly answer the OP's question:
> 
> http://groups-beta.google.com/groups?hl=en&q=XC4VFX12
> 
>     Marc
> 

Cheers Marc,

Ouch! But then I guess they're not the spartan-like parts, and those 
embedded ethernet/cpu cores have to cost...

Still, it makes the AVNet FX12 board rather impressively priced at $249!

Cheers,
	Simon.

Article: 83507
Subject: Re: current price for (small quantity) XC4VFX12/FF668
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 1 May 2005 21:30:33 +0200
Links: << >>  << T >>  << A >>

"Simon" <news@gornall.net> schrieb im Newsbeitrag
news:HdidnbVA84cwtujfRVn-1Q@comcast.com...
> Antti Lukats wrote:
> > "Simon" <news@gornall.net> schrieb im Newsbeitrag
> > news:I4OdnQ3Pm-Iy6enfRVn-rw@comcast.com...
> >
> >>Just trying to figure out what the rough price of V4 FX12/FF668 part
> >>is... AVNet and NuHorizons aren't showing any prices or stock atm, and
> >>digikey don't do anything even vaguely recent :-(
> >>
> >>Anyone bought any (quantity 1-10) recently and want to give me a
> >>ball-park figure ?
> >>
> >>Cheers,
> >>Simon.
> >
> >
> > the ball-park figure is $100 if you get a very very very good deal, if
not
> > then multiply by the tambov's constant* to get your price.
> >
> > Antti
> >
> > *tambov's constant: a constant multiplier that when applied always gives
the
> > correct result for any equation.
>
> Cheers Antti - first time I've heard of tambov's constant :-)
>
> ATB,
> Simon

LOL ;) Tambov is a town somewhere in Russia, I dont know anything about that
town, but I think it maybe worse then Odessa. And Odessa is a place where
submarines need to be ordered two weeks in advance! (everything else in
stock at the black market). Actually maybe I am mistaken Tambov may also be
a quiet village or some person. But the constant is really great if you
manage to calculate it ;)














Article: 83508
Subject: Re: Virtex4 and ISE reality check?
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 1 May 2005 21:34:55 +0200
Links: << >>  << T >>  << A >>
"Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag
news:1114975086.086474.21700@o13g2000cwo.googlegroups.com...
>
> Antti Lukats wrote:
> [...]
> > You asked a lot of questions about timing and reports and the
> accuracy of
> > them, I assume you do not have a FPGA test board for your design, so
> looking
> > at your schedule (production start July 2005 ?) there is on thing I
> can say
> > for sure, - with your deadline the only way to be somewhat confident
> that
> > the design will work is following:
> >
> > go buy the ML461 memory reference board next monday, and implement
> the
> > tricky part on that part ASAP, and let it run continous in-FPGA
> memory test,
> > check for temperature influence, etc.. only based on those results
> you can
> > decide. If your management doesnt approve that investment (buying the
> ML461
> > board) then forget about V4 with DDR design for production start in
> July.
>
> Not to mention that he was asking for I-temp parts:
>
> >> Our vendor promises industrial-temp parts by June. We're merging 3
>
> I don't know if "our vendor" means that the distributor is making these
> promises, but I'd want it in writing with financial penalities -
> because I'm pretty sure there is no way for them to meet that date:
> I-temp parts typically aren't available for a number of months after
> C-temp production.
>
> > looking at the timing reports will not give you the confidence level
> needed
> > (at least that is my opinion), I'm sure some/many will disagree
> here..
>
> Considering that the design is supposedly already proven out, with one
> exception, I'll go ahead and disagree with you :-).  Confirmation via
> timing analysis should be enough, with the exception that one or more
> of the errata may cause some grief (depending on his design).  As the
> OP hints at, the data and clock relationship for the DDR interface
> (2x360 MHz, I think) provides a challenge as well, but if simulated
> accurately, shouldn't pose major issues.  I'm basing this on the fact
> that my V4 interfaces (most of which migrated from V2Pro) came right
> up.
>
> But unlike the OP, I can say all of this because I have the luxury of
> not having to face the music he will have to face if/when something
> goes wrong and there is no time in this seemingly insane schedule to
> fix it.
>
> Speaking of which, why is there such an accelerated schedule from a
> .edu?
>
> > Antti
> > PS as of ISE vs Synplify, Synplify is known to be better, but not
> always at
> > the moment I have a desing where ISE 6.3 meets PCI-X 100MHz timing,
> but
> > Synplify reports 31 levels of logic (vs 11 with XST) and the timing
> fails of
> > totally. No idea why this happens with that design, just a note that
> > Synplify doesnt necessarily always do thing better than XST
> synthesis.
>
> Ken McElvain from Synplity (who usually hangs out here), would probably
> be VERY interested in seeing your design - assuming this still happens
> in 8.0.
>
> Have fun,
>
>    Marc

Hi Marc,

good to see some one disagreeing with me ;)
yes and no to your comments - my comment was mainly because as you said
'insane schedule', otherwise I would be more relaxed. I did some very small
V4 stuff and did see weird things, and its all bleading edge, etc... all
that triggered my comment.

and as of Synplify the accident is with V 8.0 !

Antti













Article: 83509
Subject: Re: cross clock timing constraints
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 1 May 2005 12:37:46 -0700
Links: << >>  << T >>  << A >>
"design" <vasus_ss@yahoo.co.in> wrote in message 
news:1114950531.205850.61570@g14g2000cwa.googlegroups.com...
> Hi all,
>
> Would appreciate a lot if i could get some help on this.
> Got a couple of questions and have read a lot of those messages on this
> group on cross clock domain design.
> Infact I have changed my design to include asynchronous fifo in my
> design.
> Now data crossing happens only by the fifo.
>
> But first the clocks. There are three clocks. And the three clocks are
> getting generated from three DCMs using CLKFX outputs. with the same
> input clock to three of them
>
> Presently my design works but not always. Sometimes there is the wrong
> output when i reset the design.  i dont think this is the problem of
> the reset. Also the design is stable at lower frequencies.
>
Does the reset reset things synchronously or asynchronously? Async needs 
more care. Much, much more!

> The things I have done and experimented are
> 1.)used LOWSKEWLINES constraint on all the clocks and reset.(my design
> started working only after this.)oh yeah as well i am using 92% of the
> slices that is after i included the FIFO. this is ok.
>
Oh dear. So the clocks aren't on the dedicated global clock resource? That 
would be bad. Very, very bad.

> 2.)have mentioned the period constraint for the input clock to the DCM
> as well as the PERIOD constraints on the output clocks of the DCM.
>
> 3.) included the BRAMS_PORTA constraint for the FIFO. and then
> associated the clock nets for each of the ports of the FIFO. i think
> this is how to do it.  but in this none of the nets nor instances are
> included and analyzed.
> here is the output of the timing analyzer
>
> Timing constraint: TS_groupa1 = PERIOD TIMEGRP "clk_fpga"  18.182 nS
> HIGH 50.000000 % ;
>
> 0 items analyzed, 0 timing errors detected.
>
In my experience, this means that the analyser has analysed no items. So 
getting no errors isn't difficult to achieve. I suggest including more 
things in your timing group. Maybe BRAMS_PORTB could be a start?

> 4.) I think the only timing problem affecting my design is the cross
> clock domain in the FIFO itself.
> Slack:                  -11.613ns (requirement - (data path - clock
> path skew + uncertainty))
>  Source:               receiver/buffercatch/fifo/BU545 (FF)
>  Destination:          receiver/buffercatch/fifo/BU216 (FF)
>  Requirement:          0.001ns
>  Data Path Delay:      6.132ns (Levels of Logic = 5)
>  Clock Path Skew:      -5.482ns
>  Source Clock:         clk_fpga rising at 478487.558ns
>  Destination Clock:    clk_datain rising at 478487.559ns
>  Clock Uncertainty:    0.000ns
>
> I am not sure on how to constrain this. The from to constrain and the
> multicycle constraint will not work with my design because the clocks
> are not related and there is not a definite time period after which the
> other clock appears. the clocks are 55,34and 40MHZ.
>
Well, you've designed your async fifo properly, yes? (Opinion on this 
newsgroup is divided as to the ease of this task, as you may have recently 
read!) So, you don't need a clock to clock timing constraint, per se. You 
might consider some MAXDELAY ones on your signals which can be metastable, 
to help reduce the probability of an occasional error. BTW, a 1ps 
requirement can be tricky to meet. You might want to read about TIG 
constaints.

> If anyone feels this problem has been addressed before in a tech
> document like the xilinx app or anything please let me know the same.
>
> Thank you
> cheers
> vasu
>
There's a good XAPP about self-addressing fifos. I use those when I have to. 
They're great for keeping everything in the same clock domain, except at the 
I/O interface.
Cheers, Syms. 



Article: 83510
Subject: Re: cross clock timing constraints
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 1 May 2005 14:26:17 -0700
Links: << >>  << T >>  << A >>
Many questions. Let me just answer the one onFIFOs  :-)
An asynchronous FIFO provedes perfect isolation between the two clock
domains. I call it a shock absorber or  rubber band.
You just interface to the two sides, each in their own clock domain,
and the FIFO will take care of the data transport.
It sends a synchronized EMPTY signal to the read side,and a
synchronized FULL signal to the write side. Everything is synchonous to
the clock domain that is involved.
That's the beauty of it. You do not have to think.
Peter Alfke


Article: 83511
Subject: Re: Decoupling V2P
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 01 May 2005 15:11:45 -0700
Links: << >>  << T >>  << A >>
On Sat, 30 Apr 2005 16:51:23 -0700, "Symon" <symon_brewer@hotmail.com>
wrote:


>Try reading this http://www.sigcon.com/Pubs/news/1_17.htm

TWO HUNDRED bypass caps?!!! That's crazy.

John


Article: 83512
Subject: Re: Virtex4 and ISE reality check?
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Sun, 1 May 2005 23:36:39 -0400
Links: << >>  << T >>  << A >>
Hi Antti,

Testing out a system on a board only proves that the system will work on 
that chip -- (accurate/correct) timing reports with proper timing 
constraints are the only way to guarentee that a all chips will work across 
all specified conditions.  So while it is good advice to see if things work 
on a board, this only rules out a very bad timing problem, and won't 
identify marginal timing issues.

Regards,

Paul Leventis
Altera Corp. 



Article: 83513
Subject: Re: Virtex4 and ISE reality check?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 1 May 2005 20:52:59 -0700
Links: << >>  << T >>  << A >>
You wrote:
"With fast DDR inputs, hold times are important too. The additional IOB

delay element (~1.1ns if enabled?) also adds uncertainty to the
setup/hold requirements, making for tighter data valid window
requirements, and appears to do more harm than good in this case."

This is a big misunderstanding. The IDELAY feature allows you to adjust
the input timing by moving either the clock or the data with 75
picosecond granularity. We put this programmable (and servo-stabilized)
delay feature on every pin, exactly to solve challenges like yours.
I am at home now, but I will send you the pertinent information
tomorrow.
1 Gbps DDR @ 500 MHz clock rate is what we (conservatively) aimed for.
 
Peter Alfke, Xilinx Applications.


Article: 83514
Subject: Re: one hot decoder
From: "Neo" <zingafriend@yahoo.com>
Date: 1 May 2005 22:23:44 -0700
Links: << >>  << T >>  << A >>
Info,
The code above given by you for onehot did sysnthesize differently. the
"case" version systhesized to 3 LUT's involving only OR gates and didnt
infer priority structure infact it optimized as you have mentioned to a
series of OR gates. But the "if" version systhesiszed to 6 LUT's and
inferred a priority structure. Leonardo was used for the systhesis.


Article: 83515
Subject: Re: crazy behaviour of fpga, timing ?
From: "Alexander Korff" <alexander.korff@t-online.de>
Date: Mon, 2 May 2005 08:09:02 +0200
Links: << >>  << T >>  << A >>
I looked in the Quartus manual an read the chapter on "timing analysis", but 
even the Webcast which is available from alter gave me no clue what to do.
Is there some more literautre about this problems or an practical example ? 
I'm for example not sure at which time I would set the hold time ?

Wit best regards.

Alex

"info_" <"info_"@\\nospam_no_underscore_alse-fr.com> schrieb im Newsbeitrag 
news:UqGce.52197$Of5.33303@nntpserver.swip.net...
> Alexander Korff wrote:
>> Hi,
>>
>> after I added an extra process which gets the data (without combinational 
>> logic) from the external device, everything worls fine (-:
>> Thanks very much!
>>
>> Alex
>
> Thanks for the feedback.
> Apparently complex problems often have simple solutions :-)
>
> But remember that, if your input are synchronous to a clock that
> you are using in the FPGA, you should define the constraints.
> Dependending on Frequency, your design usually has very high
> chances to "work" just by registering the I/Os in or near the
> IO cell, but that is not totally reliable... a change of speed
> grade, or a new batch of components may alter this.
> With proper constraints, it _will_ work, or you'll be warned
> by STA.
>
>
> Bert Cuzeau 



Article: 83516
Subject: Re: Case statement illusions ?
From: backhus <nix@nirgends.xyz>
Date: Mon, 02 May 2005 08:20:35 +0200
Links: << >>  << T >>  << A >>
Hi Symon,
for (most) of the given examples case and if-elsif will give the same result.
Why?
Because in both cases :-) your selector is fully covered (uses all of the bits of a vector or whatever you use as a 
selector). Your if-elsif collapses into a parallel structure, because there is no priority of one value over the other 
possible.

but how about this:

Selector <= A&B&C;  -- I MUST do this for a case statement !
case Selector is
   when "001" => Output <= Input1;
   when "010" => Output <= Input2;
   when "100" => Output <= Input2;
   when others => Output <= (others => 'Z');
end case;

vs.

If C = '1' then
   Output <= Input1;
elsif B= '1' then
   Output <= Input2;
elsif C= '1' then
   Output <= Input3;
else
   Output <= (others => 'Z');
end if;

NOW the case produces a parallel multiplexer structure that is sensitive for the given code of Selector.
The if-elsif does something different. Whenever C becomes '1' (No matter how unlikely or unneccesary this might be in 
your particular design) it switches Input1 to the output. Here we have the always cited priority encoder.

To get the same functionality with a case you have to write a different code:

Selector <= A&B&C;  -- I MUST do this for a case statement !
case Selector is
   when "--1" => Output <= Input1;
   when "-10" => Output <= Input2;
   when "100" => Output <= Input2;
   when others => Output <= (others => 'Z');
end case;

Now the first >when< hits whenever C becomes '1'.
This code might produce something more "parallel" than the if-elsif, but who knows about the tricks of modern synthesis 
tools. :-)

Have a nice synthesis

   Eilert




Article: 83517
Subject: Reasonable Entry Level Dev. Board....
From: kg6lri@yahoo-dot-com.no-spam.invalid (vitoal18t)
Date: Mon, 02 May 2005 03:15:58 -0500
Links: << >>  << T >>  << A >>
I am new to FPGA field, I took two classes, learning how to implement
multiplexers, shift registers, ALUs and pieces of a scalar CPU. Most
of the projects were simulations without actualy synthesis. 

I want to get into Software Radio and try to implement some DSP
functions. I've been looking around and it seems that Digilent Inc.
Spartan 3 Board is a very good choice. It is reasonably priced, $99
and has several ports. 

Spartan 3 is powerful enough for most DSP projects, correct? Would
this be a good investment? What are other alternatives? 

I appreciate any input...

Thank you!


Article: 83518
Subject: OPB Intc - HELP !!!!
From: "Voxer" <wesley.mowat@baesystems.com>
Date: Mon, 2 May 2005 10:02:44 +0100
Links: << >>  << T >>  << A >>
I am writing the software for the PPC405 embedded in a V2pro.

I have an OPB Intc Interrupt controller and am having trouble getting it
going.

I know it's at the memory locations expected as the IVR contains all ones
and
all other regs contain zeros. Also, I cant write to any reg until I have set
the ME
bit is set which tells me that it is att least doing something.

I am tryin to do the old Enable Interupt , Set Interupt, Acknowledge
Interrupt test
but the ISR is not being cleared by the acknowledge.

Any other suggestions ????????

Cheers



Article: 83519
Subject: Re: cross clock timing constraints
From: "design" <vasus_ss@yahoo.co.in>
Date: 2 May 2005 02:09:15 -0700
Links: << >>  << T >>  << A >>
I am using the ASYNC fifo by Xilinx coregenerator. and that is where
the signal crosses clock domains. I cannot really apply MAXDELAY
constraints I believe. I have included BRAMS portb constraints also
from the beginning. its the same no change.

one thing i did try is to remove LOWSKEWLINES and try to use clock
buffers. still no difference.

i am wondering that peter spoke about the FIFO in general and didnt
give any suggestions on why there are no items analyzed. and regarding
the low requirement. I have read about the low requirement before but
then the time period i am mentioning is in even number and i believe
the DCM takes care of the rest of the timing requirements because all
of the clocks used in the design are outputs of DCM.

However thank you both for the suggestions.

vasu


Article: 83520
Subject: Frequency Limit !!
From: "Joey" <johnsons@kaiserslautern.de>
Date: Mon, 2 May 2005 12:53:14 +0200
Links: << >>  << T >>  << A >>
Hi Everyone !!

I was wondering about this stuff. Theoretically a 1:1 ratio between
Processor and the PLB as well as between the PLB and the OPB are possible.
But when I use the Wizard to make the "Base System", if I select 300MHz for
the processor, the maximum spped which I can select from the list would be
100MHz. What happens if I change this later in the MHS file. Can it somehow
do anything wrong to the board? I really dont want to destroy this board :)

Thank you !!

Joey



Article: 83521
Subject: Re: dynamic size of ports
From: backhus <nix@nirgends.xyz>
Date: Mon, 02 May 2005 13:59:48 +0200
Links: << >>  << T >>  << A >>
Hi Dan,
first thing to do: Think of the hardware you want to create.

A device with 12 output lines always ever has these wires.
There is no magical monkey inside the chip, riping off unused wires and reconnecting them as needed.
It's HARD-ware!

But then...
If you want to transmit the data, you can do it in some serialized manner.
With the help uf some useful algorithm
or even a simple dataformat (e.g. Datalength(4bits), Data (0 to 12 bits variable)).
(well, an dataformatter also has some kind of algorithm inside..)

In the end you see that compression only works by serialisation.
Otherwise you always have to keep your wires with you all the way.

Have a nice synthesis
   eilert


Dan Nilsen schrieb:
> Hi all!
> 
> I have a problem that someone here might have the answer to. I have a
> divider that takes inputs of 13 and 12 bits, and produces an output of
> 12 bits. I have a component to strip away the redundant bits from the
> divider, if the result of the division is, say an int value of 6, I
> don't want to use all 12 bits. This circuit is a part of an MPEG-4
> device, a quantizer, so I want to compress as much as possible. My
> question is then, how do I declare the ports on the component that
> strips away the bits to output an std_logic_vector that is not fixed
> in size, but dynamic? This must be synthesizable. Guess there are many
> ways of doing this, and I hope someone has got an answer to me.
> 
> Thanks,
> 
> Dan Nilsen


Article: 83522
Subject: Re: crazy behaviour of fpga, timing ?
From: ALuPin@web.de (ALuPin)
Date: 2 May 2005 05:02:50 -0700
Links: << >>  << T >>  << A >>
> But remember that, if your input are synchronous to a clock that
> you are using in the FPGA, you should define the constraints.
> Dependending on Frequency, your design usually has very high
> chances to "work" just by registering the I/Os in or near the
> IO cell, but that is not totally reliable... a change of speed
> grade, or a new batch of components may alter this.
> With proper constraints, it _will_ work, or you'll be warned
> by STA.
> 
> 
> Bert Cuzeau

Hi Bert,

I am facing a similar situation where I have to deal with an external
bidirectional data bus + ctrl signals coming directly from the pins.

The problem is that I have no time to register the incoming signals
so that I could work with the outputs of that register stages.
Instead I have to send data on the bus directly.

So my question:
When I use the pin signal (which is synchronous to the clock I use
in the sampling process) what timing constraints or other "proper"
constraints do you recommend ?

Thank you for your help.

Rgds
André

Article: 83523
Subject: Re: Reasonable Entry Level Dev. Board....
From: "Neo" <zingafriend@yahoo.com>
Date: 2 May 2005 05:03:08 -0700
Links: << >>  << T >>  << A >>
I think that board from digilent is about as good as you can get for a
starter on fpga. yeah the spartan is good enough for  DSP
implementations too. Maybe you can take a look at Xcess boards also
they have some competitive offerings.


Article: 83524
Subject: Re: Frequency Limit !!
From: Kolja Sulimma <news@sulimma.de>
Date: Mon, 02 May 2005 14:08:31 +0200
Links: << >>  << T >>  << A >>
Joey schrieb:
> Hi Everyone !!
> 
> I was wondering about this stuff. Theoretically a 1:1 ratio between
> Processor and the PLB as well as between the PLB and the OPB are possible.
> But when I use the Wizard to make the "Base System", if I select 300MHz for
> the processor, the maximum spped which I can select from the list would be
> 100MHz. What happens if I change this later in the MHS file. Can it somehow
> do anything wrong to the board? I really dont want to destroy this board :)
> 
> Thank you !!
> 
> Joey
No, it just will not work.
Try posting with less exclamation marks.

Kolja Sulimma



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

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