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 124125

Article: 124125
Subject: Re: Uses of Gray code in digital design
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 12 Sep 2007 07:30:13 -0700
Links: << >>  << T >>  << A >>
CBFalconer wrote:

> You didn't leave much of a quote.

Sorry. The OP said:

 > So why do all synthesis tools propose "gray code" as one of the
 > encodings of state machines ?

> Assuming this has to do with
> Gray codes, there is no reason to assume the source can be clocked,
> in fact this is relatively rare.  In general source values change
> when they are in the appropriate mood.  Now deal with the result.

My points for the OP were that
1.Most state machines used
in practical controllers are synchronous
and

2. Their state graphs are not a simple
loop like a counter. This makes it difficult
to maintain a Gray encoding for all transitions in any case.

      -- Mike

From Iwo.Mergler@soton.sc.philips.com Wed Sep 12 07:36:41 2007
Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!newsfeed.yul.equant.net!lon04-news-philips!53ab2750!not-for-mail
Message-Id: <p4alr4-u6h.ln1@c2968.soton.sc.philips.com>
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Subject: Re: [Nios II] How fast the cpu in Nios II can reach in the Cycone ?
Newsgroups: comp.arch.fpga
References: <1189583937.448219.313990@r29g2000hsg.googlegroups.com>
Lines: 52
Organization: Not organised
User-Agent: KNode/0.9.2
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
Date: Wed, 12 Sep 2007 15:36:41 +0100
NNTP-Posting-Host: 161.85.127.140
X-Complaints-To: newsmaster@rain.fr
X-Trace: lon04-news-philips 1189608493 161.85.127.140 (Wed, 12 Sep 2007 14:48:13 GMT)
NNTP-Posting-Date: Wed, 12 Sep 2007 14:48:13 GMT
Bytes: 1981
X-Original-Bytes: 1938
Xref: prodigy.net comp.arch.fpga:136049
X-Received-Date: Wed, 12 Sep 2007 10:47:37 EDT (newsdbm02.news.prodigy.net)

lexluthor wrote:

> 
> 
> Can it reach 100 DMIPS ?
> 
> I give the cpu 100MHz clk, and use the Fast Core.
> 
> There is a program:
> 
> void main()
> {
>     while(1)
>     {
>         IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE,  data++);
>     }
> }
> 
> The frequence of change of the outputs can reach 100 MHz?

Short answer: no.

Medium answer:

Your code will look roughly like this in pseudo-assembler:

        load R1,PIO_0_BASE  # target address
        load R2,0           # data initialization
loop:
        store R2,[R1]
        incr  R2
        jump  loop

The fast version of NIOS II takes roughly two clock
cycles per instruction - a 100MHz clock should give
you around 50MIPS best case.

In your loop you will need three instructions per iteration.
The code will fit into the single-cycle cache, freeing
up the bus.

The PIO implementation uses a single cycle write, so assuming
you placed it on the same bus as the processor, this won't
be a bottleneck.

So your best-case rate of change on the PIO port
is a little under 17MHz.

Kind regards,

Iwo


Article: 124126
Subject: Re: Uses of Gray code in digital design
From: "Charles, NG" <site_blackhole@trellisys.ie>
Date: Wed, 12 Sep 2007 18:13:33 +0200
Links: << >>  << T >>  << A >>
David Brown wrote:

> It's even better - with the Gray code, you don't need the FF
> synchronisation at all, as long as you are stepping up or down through
> the codes (it's a different matter for step machines that jump steps).

IMHO I'd be very wary of this statement (and would be interested to hear
how others see it). I remember looking at metastability tests on
flip-flops many years ago and there are two issues here:
1) Catching / not catching a state change
2) Lengthening of the FF switching time when set-up/hold times are not met

Particularily with 2), the tests I observed back then showed a factor of
three to five times against the specified switching time when
set-up/hold times are met. The higher the capacitive load on the FF the
worse it got.

So, if you have your two gray counters (one being asynchronous) and feed
them to a comparator which then goes to a Full/Empty flag FF, the timing
of the path asynch_gray_counter -> comparator -> full_or_empty_ff will
not be what your timing analysis said if you actually hit the
meta-stability window. If you are running at max speed, this may well
mean that the set-up/hold times on the full/empty FF input are not met,
effectively meaning that the output of this FF now becomes meta-stable.

IMHO, the advantage of the Gray-coding is that you are guaranteed not to
observe any intermediate switching states (i.e. point 1 above is
addressed) but I would still synchronise the output to be sure that
metastability is not just propogated down the line and eventually
causing problems at some unexpected circuit node.

Regards,
Charles

Article: 124127
Subject: Re: precision errors. microblaze vs matlab single precision... huh?
From: chriskoh <chrisdekoh@yahoo.com>
Date: Wed, 12 Sep 2007 09:13:48 -0700
Links: << >>  << T >>  << A >>
Hi Goran,
    I am using type cast to single in matlab. Once you round the first
variable to single in matlab, it should round everything after that to
single already. Cos all resulting variables after that are already in
single precision. right?

by the way, you say " In order to get exactly the same every result
operation in Matlab has to be
done in single-precision."

but my question is, the difference in values of the result amount to
orders of  >0.5 occasionally! Isnt that a bit too much difference in
results?

Is the FPU inaccurate or am i seeing things...


Chris


On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
> Hi,
>
> What rounding mode are you using for Matlab?
> MicroBlaze only uses round-to-nearest rounding mode.
>
> In order to get exactly the same every result operation in Matlab has to =
be
> done in single-precision.
>
> G=F6ran
>
> "chriskoh" <chrisde...@yahoo.com> wrote in message
>
> news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
>
>
>
> > Hi all embedded gurus out there,
> >    I am working on an embedded platform using microblaze. I am trying
> > to implement an algo, which does a inverse matrix function on the
> > microblaze (via C) and then port the results back to matlab.
> >   so this is the scenario.
>
> > 1) matlab generates some numbers, passes them to microblaze via the
> > UART (ie. PC to UART)
> > 2) microblaze will then generate the matrix, and then calculate its
> > inverse and do other stuff (dot product of matrices etc etc).
> > 3) microblaze will then send the result back to PC via UART.
>
> > Ok..so here's the problem.
> > the result obtained differs from matlab's result (I coded the same
> > implementation also in matlab). the result obtained varies up to an
> > error of 1 decimal place!!!
>
> > How I tried to debug
> > 1) step through the C code using the debugger for microblaze. (this is
> > very cool tool).
> > 2) at each step of the way, look at how the variables change for each
> > operation in the C code running on microblaze...and also observe how
> > the variables change in matlab
>
> > this is what I noticed
> > thinking it was due to matlab processing it in double precision, i
> > type cast the whole matlab routine in single precision. then I tried
> > to verify it again in the same way. And I get the same problem :(
>
> > can anyone help? As a result of this precision errors, the whole algo
> > fails to work. I am really not sure which one to trust now.
>
> > Would appreciate if anyone can help me on the same. The current
> > microblaze platform is using hardware FPU.
>
> > Chris- Hide quoted text -
>
> - Show quoted text -



Article: 124128
Subject: Re: Stratix III Memory usage efficiency
From: Subroto Datta <sdatta@altera.com>
Date: Wed, 12 Sep 2007 09:54:53 -0700
Links: << >>  << T >>  << A >>
On Sep 11, 8:33 am, davew <David.Wo...@gmail.com> wrote:
> Has anyone else encountered the problem of shape and size of M9K
> blocks (I suppose this applies to other devices also).  e.g. if I want
> a 2720X18 memory (48960 bits), the wizard will construct one out of 9
> 4096X2 memories (82944 bits) which is 60% efficient.
>
> Does anyone have a stategy for getting more efficiency of usage out of
> these blocks?
>
> I can think of one way (in this example by stacking 6 512X18 blocks
> and using multiplexers and decoders etc.) but perhaps someone has a
> better or more straightforward approach.
>
> I'm asking this about SIII because I am quite used to SII M4K and M512
> blocks which seemed to be a better fit for my designs.
>
> Thanks,
> DaveW.

Hi Dave,

The memory wizard configures the memories to their maximum depth
because this uses the least logic and runs at the greatest speed(i.e.
minimal decode logic required.)  There is a maximum depth parameter in
the Megawizard where the user can enter the maximum configuration
depth for your block.  In this case, if you enter 512 it should
configure them as 512x18 and do what you need.




Hope this helps,
Subroto Datta
Altera Corp.





Article: 124129
Subject: Re: precision errors. microblaze vs matlab single precision... huh?
From: Steven Derrien <sderrienREMOVE@irisa.fr>
Date: Wed, 12 Sep 2007 19:15:49 +0200
Links: << >>  << T >>  << A >>
Hi,

May 2 cents : It seems to me that Desktop PC FPU use larger mantissa 
internally than what is strictly required by the IEEE SP standard, 
especially for some operations (such as /,sqrt). That *might* explain 
your results.

Also, did you check that the matrix inversion algorithm you used is 
robust enough in terms of numerical stability ?

Hope it can help.

Steven

chriskoh a écrit :
> Hi Goran,
>     I am using type cast to single in matlab. Once you round the first
> variable to single in matlab, it should round everything after that to
> single already. Cos all resulting variables after that are already in
> single precision. right?
> 
> by the way, you say " In order to get exactly the same every result
> operation in Matlab has to be
> done in single-precision."
> 
> but my question is, the difference in values of the result amount to
> orders of  >0.5 occasionally! Isnt that a bit too much difference in
> results?
> 
> Is the FPU inaccurate or am i seeing things...
> 
> 
> Chris
> 
> 
> On Sep 12, 4:54 am, "Göran Bilski" <goran.bil...@xilinx.com> wrote:
> 
>>Hi,
>>
>>What rounding mode are you using for Matlab?
>>MicroBlaze only uses round-to-nearest rounding mode.
>>
>>In order to get exactly the same every result operation in Matlab has to be
>>done in single-precision.
>>
>>Göran
>>
>>"chriskoh" <chrisde...@yahoo.com> wrote in message
>>
>>news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
>>
>>
>>
>>
>>>Hi all embedded gurus out there,
>>>   I am working on an embedded platform using microblaze. I am trying
>>>to implement an algo, which does a inverse matrix function on the
>>>microblaze (via C) and then port the results back to matlab.
>>>  so this is the scenario.
>>
>>>1) matlab generates some numbers, passes them to microblaze via the
>>>UART (ie. PC to UART)
>>>2) microblaze will then generate the matrix, and then calculate its
>>>inverse and do other stuff (dot product of matrices etc etc).
>>>3) microblaze will then send the result back to PC via UART.
>>
>>>Ok..so here's the problem.
>>>the result obtained differs from matlab's result (I coded the same
>>>implementation also in matlab). the result obtained varies up to an
>>>error of 1 decimal place!!!
>>
>>>How I tried to debug
>>>1) step through the C code using the debugger for microblaze. (this is
>>>very cool tool).
>>>2) at each step of the way, look at how the variables change for each
>>>operation in the C code running on microblaze...and also observe how
>>>the variables change in matlab
>>
>>>this is what I noticed
>>>thinking it was due to matlab processing it in double precision, i
>>>type cast the whole matlab routine in single precision. then I tried
>>>to verify it again in the same way. And I get the same problem :(
>>
>>>can anyone help? As a result of this precision errors, the whole algo
>>>fails to work. I am really not sure which one to trust now.
>>
>>>Would appreciate if anyone can help me on the same. The current
>>>microblaze platform is using hardware FPU.
>>
>>>Chris- Hide quoted text -
>>
>>- Show quoted text -
> 
> 
> 

Article: 124130
Subject: Re: PCI byte enalbes in read cycles
From: "A.D." <isd_mod@libero.ix>
Date: Wed, 12 Sep 2007 17:29:12 GMT
Links: << >>  << T >>  << A >>
Mark McDougall <markm@vl.com.au> wrote in message
46e792c1$0$14150$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> No! They must not changed until the data has been
> transferred for the current phase.
> [...]

Ok, this is what I undestood at first. But suppose you
want to use BEs for a simple gating of the byte lanes:
you have to do it in a combinational way, or you have
to insert a wait state to latch BEs values and then put
gated data on the bus on the next clock. Am I wrong?
Both these things are quite bad! In the first case you
could obtain long propagation delay, in the second
case you waste 50% of clock cycles!

Regards,
Antonio





Article: 124131
Subject: Re: precision errors. microblaze vs matlab single precision... huh?
From: chriskoh <chrisdekoh@yahoo.com>
Date: Wed, 12 Sep 2007 10:29:23 -0700
Links: << >>  << T >>  << A >>
Hi Steven,
    so matlab results are more accurate?
    the matrix inversion algorithm method is rather robust actually in
terms of numerical stability. What I noticed however is that the
matrix formed already by my C code running on microblaze before the
inversion has already some numerical differences with matlab's
version. simple C code vs matlab single precision code.
but different results obtained. All discovered by stepping through the
C code running on microblaze.
    the matrix was formed simply by a dot product.

Chris

On Sep 12, 10:15 am, Steven Derrien <sderrienREM...@irisa.fr> wrote:
> Hi,
>
> May 2 cents : It seems to me that Desktop PC FPU use larger mantissa
> internally than what is strictly required by the IEEE SP standard,
> especially for some operations (such as /,sqrt). That *might* explain
> your results.
>
> Also, did you check that the matrix inversion algorithm you used is
> robust enough in terms of numerical stability ?
>
> Hope it can help.
>
> Steven
>
> chriskoh a =E9crit :
>
>
>
> > Hi Goran,
> >     I am using type cast to single in matlab. Once you round the first
> > variable to single in matlab, it should round everything after that to
> > single already. Cos all resulting variables after that are already in
> > single precision. right?
>
> > by the way, you say " In order to get exactly the same every result
> > operation in Matlab has to be
> > done in single-precision."
>
> > but my question is, the difference in values of the result amount to
> > orders of  >0.5 occasionally! Isnt that a bit too much difference in
> > results?
>
> > Is the FPU inaccurate or am i seeing things...
>
> > Chris
>
> > On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
>
> >>Hi,
>
> >>What rounding mode are you using for Matlab?
> >>MicroBlaze only uses round-to-nearest rounding mode.
>
> >>In order to get exactly the same every result operation in Matlab has t=
o be
> >>done in single-precision.
>
> >>G=F6ran
>
> >>"chriskoh" <chrisde...@yahoo.com> wrote in message
>
> >>news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
>
> >>>Hi all embedded gurus out there,
> >>>   I am working on an embedded platform using microblaze. I am trying
> >>>to implement an algo, which does a inverse matrix function on the
> >>>microblaze (via C) and then port the results back to matlab.
> >>>  so this is the scenario.
>
> >>>1) matlab generates some numbers, passes them to microblaze via the
> >>>UART (ie. PC to UART)
> >>>2) microblaze will then generate the matrix, and then calculate its
> >>>inverse and do other stuff (dot product of matrices etc etc).
> >>>3) microblaze will then send the result back to PC via UART.
>
> >>>Ok..so here's the problem.
> >>>the result obtained differs from matlab's result (I coded the same
> >>>implementation also in matlab). the result obtained varies up to an
> >>>error of 1 decimal place!!!
>
> >>>How I tried to debug
> >>>1) step through the C code using the debugger for microblaze. (this is
> >>>very cool tool).
> >>>2) at each step of the way, look at how the variables change for each
> >>>operation in the C code running on microblaze...and also observe how
> >>>the variables change in matlab
>
> >>>this is what I noticed
> >>>thinking it was due to matlab processing it in double precision, i
> >>>type cast the whole matlab routine in single precision. then I tried
> >>>to verify it again in the same way. And I get the same problem :(
>
> >>>can anyone help? As a result of this precision errors, the whole algo
> >>>fails to work. I am really not sure which one to trust now.
>
> >>>Would appreciate if anyone can help me on the same. The current
> >>>microblaze platform is using hardware FPU.
>
> >>>Chris- Hide quoted text -
>
> >>- Show quoted text -- Hide quoted text -
>
> - Show quoted text -



Article: 124132
Subject: Re: Good VHDL reference?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 12 Sep 2007 10:47:23 -0700
Links: << >>  << T >>  << A >>
Hi,
I just bought "Student's VHDL Guide" by Ashenden.

What is the difference between the following two books by the same
author:

The Designer's Guide to VHDL (Systems on Silicon) by Peter J. Ashenden
(Paperback - May 2002)
Buy new: $75.95 $56.19    40 Used & new from $49.18

The System Designer's Guide to VHDL-AMS (Systems on Silicon) by Peter
J. Ashenden, Gregory D. Peterson, and Darrell A. Teegarden (Paperback
- Sep 4, 2002)
Buy new: $81.95 $60.57    23 Used & new from $55.00

Weng



Article: 124133
Subject: Re: precision errors. microblaze vs matlab single precision... huh?
From: Paul Keinanen <keinanen@sci.fi>
Date: Wed, 12 Sep 2007 20:48:20 +0300
Links: << >>  << T >>  << A >>
On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisdekoh@yahoo.com>
wrote:

>
>but my question is, the difference in values of the result amount to
>orders of  >0.5 occasionally! Isnt that a bit too much difference in
>results?

That expectation might be realistic for expression containing only
multiplications and divisions. However, as soon as the expression
contains additions of a large and a small value or a subtraction
between two more or less equal values, the result depends heavily on
the floating point representation.

What exactly is "single precision floating point" ? 

I can think about at least a dozen representations that are using that
name, in which each representations might return a different result
with problematic parameters.

Paul


Article: 124134
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 12 Sep 2007 10:53:05 -0700
Links: << >>  << T >>  << A >>
Yes, Symon, that's shorter.



Article: 124135
Subject: Re: Uses of Gray code in digital design
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 12 Sep 2007 11:03:07 -0700
Links: << >>  << T >>  << A >>
Charles, you are right.
The identity comparison of two Gray counters avoids accidental
glitches, but does not avoid the inherent asynchronous nature of the
event. The design still has to resolve (better: live with) the
matastability issue.
Luckily, modern flip-flops resolve metastability pretty fast, at least
statistically.
XAPP094 is a Xilinx app note that quantifies the results for
Virtex2Pro FPGAs.
Peter Alfke

On Sep 12, 9:13 am, "Charles, NG" <site_blackh...@trellisys.ie> wrote:
> David Brown wrote:
> > It's even better - with the Gray code, you don't need the FF
> > synchronisation at all, as long as you are stepping up or down through
> > the codes (it's a different matter for step machines that jump steps).
>
> IMHO I'd be very wary of this statement (and would be interested to hear
> how others see it). I remember looking at metastability tests on
> flip-flops many years ago and there are two issues here:
> 1) Catching / not catching a state change
> 2) Lengthening of the FF switching time when set-up/hold times are not met
>
> Particularily with 2), the tests I observed back then showed a factor of
> three to five times against the specified switching time when
> set-up/hold times are met. The higher the capacitive load on the FF the
> worse it got.
>
> So, if you have your two gray counters (one being asynchronous) and feed
> them to a comparator which then goes to a Full/Empty flag FF, the timing
> of the path asynch_gray_counter -> comparator -> full_or_empty_ff will
> not be what your timing analysis said if you actually hit the
> meta-stability window. If you are running at max speed, this may well
> mean that the set-up/hold times on the full/empty FF input are not met,
> effectively meaning that the output of this FF now becomes meta-stable.
>
> IMHO, the advantage of the Gray-coding is that you are guaranteed not to
> observe any intermediate switching states (i.e. point 1 above is
> addressed) but I would still synchronise the output to be sure that
> metastability is not just propogated down the line and eventually
> causing problems at some unexpected circuit node.
>
> Regards,
> Charles



Article: 124136
Subject: Altera + ARM Cortex-M1
From: vitek.vitek@gmail.com
Date: Wed, 12 Sep 2007 18:27:33 -0000
Links: << >>  << T >>  << A >>
Could we expect the same step from Lattice?
Or Xilinx will come with this possibility sooner?
http://www.altera.com/products/ip/processors/32_16bit/m-arm-cortex-m1.html
http://www.fpgajournal.com/articles_2007/20070911_arm.htm
Vita


Article: 124137
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: Andy <jonesandy@comcast.net>
Date: Wed, 12 Sep 2007 11:52:49 -0700
Links: << >>  << T >>  << A >>
On Sep 12, 12:53 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> Yes, Symon, that's shorter.

Have you thought about what happens to bus2ip_data before the magic
address is hit? What about after it has been hit?

What else (if anything) is driving bus2ip_data? If nothing,
bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
forevermore.

If something else is driving data, then a (others => 'X') will almost
certainly result.

Andy


Article: 124138
Subject: Re: Good VHDL reference?
From: Andy <jonesandy@comcast.net>
Date: Wed, 12 Sep 2007 11:54:54 -0700
Links: << >>  << T >>  << A >>
On Sep 12, 12:47 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> I just bought "Student's VHDL Guide" by Ashenden.
>
> What is the difference between the following two books by the same
> author:
>
> The Designer's Guide to VHDL (Systems on Silicon) by Peter J. Ashenden
> (Paperback - May 2002)
> Buy new: $75.95 $56.19    40 Used & new from $49.18
>
> The System Designer's Guide to VHDL-AMS (Systems on Silicon) by Peter
> J. Ashenden, Gregory D. Peterson, and Darrell A. Teegarden (Paperback
> - Sep 4, 2002)
> Buy new: $81.95 $60.57    23 Used & new from $55.00
>
> Weng

The latter is for vhdl-ams (analog mixed signal?), and probably has
more to do with the analog aspects of it.

Andy


Article: 124139
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 12 Sep 2007 12:20:56 -0700
Links: << >>  << T >>  << A >>
> Have you thought about what happens to bus2ip_data before the magic
> address is hit? What about after it has been hit?

No, I had not thought of it. I was just correcting the obvious
lack of a clk if-then and hopefully explaining why he got zeroes.
Perhaps, there is another driver.

> What else (if anything) is driving bus2ip_data? If nothing,
> bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
> forevermore.
>
> If something else is driving data, then a (others => 'X') will almost
> certainly result.
>
> Andy
> 



Article: 124140
Subject: Re: FPGA Archives
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 12 Sep 2007 12:25:20 -0700
Links: << >>  << T >>  << A >>
Thanks Martin,

I found google groops and this seems to search into the archives
without any problem and a nice interface to boot.

Don't know what c.a.f. stands for or how to use GNU, although for
you keyboard guys, I hear it's great.

Brad Smallridge


"Martin Thompson" <martin.j.thompson@trw.com> wrote in message 
news:ud4womgpr.fsf@trw.com...
> "Brad Smallridge" <bradsmallridge@dslextreme.com> writes:
>
>> How do you get messages from comp.arch.fpga archives?
>>
>> Google brings up headings that I may want to read, however,
>> when I click on those headings I go to the archives that
>> are listed by year and month.  There isn't a clear way
>> to find the message that I wanted to read.
>>
>
> The way I used to do it is to use the browsers search within the page
> funciton to find the words I originally told google to look for.
> Nowadays, if I'm looking for stuff on c.a.f, I use the "Google groups"
> interface to search for it (adding "group:comp.arch.fpga" to the text
> I type into the search box, or use the advanced search).
>
> I still use GNUS to post though, no pointy-clicky for me :-)
>
> Cheers,
> Martin
>
> -- 
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html 



Article: 124141
Subject: Ethernet Code Problem with Xilinx Spartan3E
From: calkins@millenworks.com
Date: Wed, 12 Sep 2007 13:09:30 -0700
Links: << >>  << T >>  << A >>
I'm trying to get a Spartan3E FPGA to communicate with a PC.  I'm
using lwIP and Microblaze and have managed to get the FPGA to receive
packets fine, but despite it appearing to bind and connect the socket
for transmitting data, I don't receive any data.  The code is below.
Your help would be greatly appriciated.

Thanks,
SC

/***************************** Include Files
*********************************/

/* Xilinx Includes */
#include "xstatus.h"       // Required for status checks on peripheral
functions
#include "xgpio.h"         // Required for GPIO peripherals
#include "xmk.h"

/* C Library Includes */
#include "string.h"        // Required for memset and strtok

/* lwIP Includes */
#include "netif/xemacif.h"
#include "lwip/udp.h"
#include "lwip/memp.h"
#include "netif/etharp.h"
#include "lwip/sys.h"
#include "lwip/sockets.h"

// OPB Timer/Counter Device Driver
#include "xtmrctr.h"

#include "Ethernet_10.h"

/************************** Variable Definitions
******************************/

extern XEmacIf_Config XEmacIf_ConfigTable[];

int numConnections;

int incoming_buffer_len;

int incoming_sock, outgoing_sock;

struct sockaddr_in incoming_udp, outgoing_udp;

XTmrCtr udp_transmitter_timer;

/
*****************************************************************************
*
* This is the UDP Transmitter Application Thread
*
* @param    baseaddr_p is the Base Address of OPB_Timer_0
*
* @return   None
*
* @note     None
*
******************************************************************************/

void udp_transmitter_int_handler (void* arg) {

   char writeBuffer[6];
   xil_printf("Sending Data\r\n");
   writeBuffer[0] = 'a';
   writeBuffer[1] = 'b';
   writeBuffer[2] = 'c';
   writeBuffer[3] = 'd';
   writeBuffer[4] = 'e';
   writeBuffer[5] = 'f';

//   write(outgoing_sock, "writeBuffer", 11); //hanging here
//   udp_send(outgoing_sock, "a"); //hanging here

   // Resets the UDP Transmitter Timer to a start mode
   XTmrCtr_Reset(&udp_transmitter_timer, 0);
}

/
*****************************************************************************
*
* This is the Network Listener Application Thread
*
* @param    sd - Socket ID
*
* @return   None
*
* @note     None
*
******************************************************************************/

void* processConnection(struct sockaddr_in input, int connections)
{
//    char receiveBuffer[6];//RECV_BUFFER_LENGTH];
//    int sd = *((int*) arg);
//    int bytesReceived;

    // Read the request data

    xil_printf("Data : %s \r\n", &incoming_udp);

//    xil_printf("Data Recieved: ");
//    xil_printf(&input);
//    xil_printf("\n\r");
//    xil_printf("Connections: ");

//    close(&input);
    numConnections--;
}

/
*****************************************************************************
*
* This is the UDP Application Thread, it generates and listens to udp
traffic
*
* @param    sd - Socket ID
*
* @return   None
*
* @note     None
*
******************************************************************************/

void* udpAppThread(void* arg)
{
    int i;
    int leds_disp;
    int switches_value;
    int size;
	 int status;
    unsigned char mac_address[6];
    unsigned char ip_address[4];
    unsigned char gateway_addr[4];
    unsigned char subnet[4];
    struct ip_addr ipaddr, netmask, gateway;
    struct netif *server_netif;
    XEmacIf_Config *xemacif_ptr = &XEmacIf_ConfigTable[0];
    XStatus udp_transmitter_initialized;
    Xuint32 udp_transmitter_status;
	 XStatus register_setup_status;

    // MAC Address = 00-00-00-00-22-31
    memset(mac_address, 0, 6);
    mac_address[0] = 0x00;
    mac_address[1] = 0x00;
    mac_address[2] = 0x00;
    mac_address[3] = 0x00;
    mac_address[4] = 0x22;
    mac_address[5] = 0x31;
    xemacif_setmac(0, (u8_t *)mac_address);

    // Netmask = 255.255.255.0
    netmask.addr = htonl(0xffffff00);

    // Gateway = 10.1.2.1
    gateway.addr = htonl(0x0a010201);

    // IP Address = 10.1.2.101
    ipaddr.addr = htonl(0x0a010265);

    // Set up the lwIP network interface
    // Allocate and configure the server's netif
    server_netif = mem_malloc(sizeof(struct netif));
    if(server_netif == NULL)
    {
        xil_printf("ERROR: netif_add(): Out of memory for default netif
\n\r");
        return;
    }
    server_netif = netif_add(server_netif,
                             &ipaddr,
                             &netmask,
                             &gateway,
                             &XEmacIf_ConfigTable[0],
                             xemacif_init,
                             ip_input);
    netif_set_default(server_netif);

    // Register the XEMAC interrupt handler with the controller and
enable
    // interrupts within XMK
 
register_int_handler(XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR,
                         (XInterruptHandler)XEmac_IntrHandlerFifo,
                         xemacif_ptr->instance_ptr);

    enable_interrupt(XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR);

    // Create and bind the socket. Because the MicroBlaze and PowerPC
processors
    // are big-endian architectures, the calls to htons(), htonl(),
etc. aren't
    // necessary, but are included for completeness and portability
    incoming_sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
    incoming_udp.sin_family      = AF_INET;
    incoming_udp.sin_port        = htons(VMS_PORT);
    incoming_udp.sin_addr.s_addr = INADDR_ANY;
    bind(incoming_sock, (struct sockaddr*)&incoming_udp, sizeof(struct
sockaddr));

    outgoing_sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
    outgoing_udp.sin_family      = AF_INET;
    outgoing_udp.sin_port        = htons(90);
    outgoing_udp.sin_addr.s_addr = htonl(0x0a010264);
    status = bind(outgoing_sock, (struct sockaddr*)&outgoing_udp,
sizeof(struct sockaddr));
	 xil_printf("%d bind\r\n",status);
    status = connect(outgoing_sock, (struct sockaddr*)&outgoing_udp,
sizeof(struct sockaddr));
	 xil_printf("%d connect\r\n",status);

    xil_printf("Server initialization complete.\r\n");

    // Begin listening on the socket. For all new connections, spawn a
new
    // thread, processConnection(), to deal with them
    listen(incoming_sock, 20);
    numConnections = 0;

    // Initializes opb_timer_0 as udp_transmitter_timer
    udp_transmitter_initialized =
XTmrCtr_Initialize(&udp_transmitter_timer,
XPAR_OPB_TIMER_0_DEVICE_ID);

    if (udp_transmitter_initialized == XST_SUCCESS)
    {
        xil_printf("-- UDP Transmitter was initialized --\r\n");
    } else {
        if (udp_transmitter_initialized == XST_DEVICE_IS_STARTED)
        {
            xil_printf("-- UDP Transmitter was already initialized --\r
\n");
        } else {
            xil_printf("-- UDP Transmitter was not found --\r\n");
        }
    }

    //Sets options for udp transmitter timer
    XTmrCtr_SetOptions(&udp_transmitter_timer, 0,	// set the 0 timer
in opb_timer_0
         XTC_DOWN_COUNT_OPTION | 	// See page 3 on OPB Timer/Counter
v1.00b in regards to count down
         XTC_INT_MODE_OPTION | 		// Enables the timer counter
interrupt output.
         XTC_AUTO_RELOAD_OPTION);	// And reload the "reset" value and
begin counting again

    // set timer on 1 second interval
    XTmrCtr_SetResetValue(&udp_transmitter_timer, 0, 50000000);

    // Sets the UDP Transmitter Timer to a stop mode
    XTmrCtr_Stop(&udp_transmitter_timer, 0);

    // timer_int_handler process will execute on opb_timer_0 interrupt
    register_setup_status =
register_int_handler(XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR,
udp_transmitter_int_handler, NULL);
    enable_interrupt(XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR);

    if (register_setup_status == XST_SUCCESS)
    {
        xil_printf("-- Interrupt Successfully Created --\r\n");
    } else {
        xil_printf("Interrupt Error : ");
	     putnum(register_setup_status);
        xil_printf("\r\n");
    }

    // Sets the UDP Transmitter Timer to a start mode
    XTmrCtr_Start(&udp_transmitter_timer, 0);

    while(1)
    {
        // Will wait at the line below till code is recieved.
        incoming_buffer_len = read(incoming_sock, (struct sockaddr
*)&incoming_udp, sizeof(struct sockaddr));

		  // Increases numConnections everyime new connection is read.
		  // numConnections will decrease after connection is dropped
        numConnections++;

        xil_printf("%d bytes of data \r\n", incoming_buffer_len);
        // Spawn a new thread to handle the data for the new
connection
        sys_thread_new((void *)&processConnection, &incoming_sock,
numConnections);
    }
}

/
*****************************************************************************
*
* This is the Top Level Application Thread.  It will start all other
* Application Threads.
*
* @param    None
*
* @return   None
*
* @note     None
*
******************************************************************************/

void serverThread (void* arg) {

    // Initialize the lwIP library
    xil_printf("Initializing the lwIP library...\r\n");
    lwip_init();
//mem_init();
//memp_init();
//pbuf_init();
//netif_init();
//udp_init();


    // Sleep to allow lwIP initialization status messages to display
    // without interruption
    sleep(100);
    xil_printf("lwIP initialization done\n\r");

    // Spawn the UDP communication application thread
    sys_thread_new((void *)&udpAppThread, 0, 0);
    xil_printf("udpAppThread Started\n\r");
}

int main (void) {
    // Launch XMK
    xilkernel_main();

    return 0;
}


Article: 124142
Subject: Re: FPGA Archives
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 12 Sep 2007 16:12:56 -0400
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13egfkk93bre309@corp.supernews.com...
>
> Don't know what c.a.f. stands for

comp.arch.fpga :)

/Mikhail 



Article: 124143
Subject: Re: microblaze toolchain compilation question
From: "Vasanth Asokan" <vasanth@xilinx.com>
Date: Wed, 12 Sep 2007 13:36:50 -0700
Links: << >>  << T >>  << A >>
Some of the sources in the MB assembler were not really written in a 64-bit
safe fashion. The particular error that you are seeing is due to mismatched
type expansion for integer constants in the code. There are similair type
expansion bugs in the compiler as well due to missing prototypes for some
functions.

None of these issues affect 32-bit compilation. However, we are fixing these
bugs in the EDK 9.2i release so that the tools do build cleanly and produce
correct output on 64-bit machines.

Here are a couple of patches to get you going in the meanwhile. The patches
will not apply cleanly against your version of sources, so I am afraid you
will have to apply them manually. The changes are minor though, so it
shouldn't be too hard.

Vasanth

"taco" <tralalal@joepie.nl> wrote in message
news:fc83fr$qnm$1@usenet.uva.nl...
> John Williams wrote:
>
>> Hello Taco,
>>
>> taco wrote:
>>> hello all,
>>> I'm trying to compile the microblaze-toolchain from source on a 64 bits
>>> linux system, but got stuck. The source from the petalogix repository
>>> doesn't compile. a first problem was solved with help of colleague:
>>> a declaration error in 2 header files of binutils/gas (just wondering if
>>> this is done on purpose by petalogix..).
>>
>> I can assure you the source tarball you found on the PetaLogix website
>> is the same as was used to build the gcc at that time.  It builds fine
>> on a RHEL/CentOS 3 machine, such as the one I am using right now.
>>
>>
>> Regards,
>>
>> John
>
> Hello john,
> are you sure? I just did everything again in a clean directory. Executing
> do_everything results in:
> /usr/local/microblaze/microblaze-toolchain-sources/srcs/binutils//gas/config/tc-microblaze.h:63:
> error: array type has incomplete element type
> and the compilation stops.
> The solution is to move the struct relax_type from tc.h to as.h in
> srcs/binutils/gas and remove the forward declaration from as.h. It's just
> a
> simple order, but I assume that this also will not work on a RHEL system
> without doing this unless your gcc compiler works different.
> (a colleague running ubuntu had the same problem by the way)
>
> After this modification the same script continues but stops again in the
> gcc
> phase:
> mkdir -p -- libgcc
> mkdir -p -- bs
> mkdir -p -- libgcc/bs
> mkdir -p -- m
> mkdir -p -- libgcc/m
> mkdir -p -- bs/m
> mkdir -p -- libgcc/bs/m
> if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
> /usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/xgcc
>  -B/usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/


begin 666 gcc_microblaze_protos.patch
M9&EF9B M=7).<"!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC
M<F]B;&%Z92YC(&=C8R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B;&%Z
M92YC"BTM+2!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B
M;&%Z92YC"3(P,#<M,#8M,C @,3,Z-#,Z,S0N,# P,# P,# P("TP-S P"BLK
M*R!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+VUI8W)O8FQA>F4N8PDR,# W
M+3 V+3(P(#$T.C(X.C,S+C P,# P,# P," M,#<P, I 0" M,C S+#@@*S(P
M,RPV($! (&EN="!S:6UP;&5?;65M;W)Y7V]P97)A;F0@"0D)4$%204U3("@H
M<G0*('9O:60@=')A8V4@"0D)"0E005)!35,@*"AC;VYS="!C:&%R("HL(&-O
M;G-T(&-H87(@*BP@8V]N<W0@8VAA<B J*2D["B!V;VED(&=E;E]C;VYD:71I
M;VYA;%]B<F%N8V@@"0D)4$%204U3("@H<G1X("HL(&5N=6T@<G1X7V-O9&4I
M*3L*('9O:60@:6YI=%]C=6UU;&%T:79E7V%R9W,@"0D)4$%204U3("@H0U5-
M54Q!5$E615]!4D=3("HL=')E92P@<G1X*2D["BUV;VED(&9U;F-T:6]N7V%R
M9U]A9'9A;F-E( D)"5!!4D%-4R H*$-5355,051)5D5?05)'4R J+"!E;G5M
M(&UA8VAI;F5?;6]D92P@=')E92P@:6YT*2D["BUS=')U8W0@<G1X7V1E9B J
M9G5N8W1I;VY?87)G( D)"5!!4D%-4R H*$-5355,051)5D5?05)'4R J+"!E
M;G5M(&UA8VAI;F5?;6]D92P@=')E92P@:6YT*2D["B!I;G0@9G5N8W1I;VY?
M87)G7W!A<G1I86Q?;G)E9W,@"0D)4$%204U3("@H0U5-54Q!5$E615]!4D=3
M("HL(&5N=6T@;6%C:&EN95]M;V1E+"!T<F5E+"!I;G0I*3L*($A/4U1?5TE$
M15])3E0@;6EC<F]B;&%Z95]D96)U9V=E<E]O9F9S970@"5!!4D%-4R H*')T
M>"P@2$]35%]7241%7TE.5"DI.PH@=F]I9"!M:6-R;V)L87IE7V]U='!U=%]L
M:6YE;F\@"0D)4$%204U3("@H1DE,12 J+"!I;G0I*3L*0$ @+3(W,C$L-R K
M,C<Q.2PW($! (&9U;F-T:6]N7V%R9U]A9'9A;F-E("@*("\J(%)E='5R;B!A
M;B!25$P@97AP<F5S<VEO;B!C;VYT86EN:6YG('1H92!R96=I<W1E<B!F;W(@
M=&AE(&=I=F5N(&UO9&4L"B @("!O<B P(&EF('1H92!A<F=U;65N="!I<R!T
M;R!B92!P87-S960@;VX@=&AE('-T86-K+B @*B\*( HM<W1R=6-T(')T>%]D
M968@*@HK<G1X"B!F=6YC=&EO;E]A<F<@* H@("!#54U53$%4259%7T%21U,@
M*F-U;2P)"2\J(&-U<G)E;G0@87)G(&EN9F]R;6%T:6]N("HO"B @(&5N=6T@
M;6%C:&EN95]M;V1E(&UO9&4L"2\J(&-U<G)E;G0@87)G(&UO9&4@*B\*9&EF
M9B M=7).<"!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B
M;&%Z92UP<F]T;W,N:"!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+VUI8W)O
M8FQA>F4M<')O=&]S+F@*+2TM(&=C8RUO<FEG+V=C8R]C;VYF:6<O;6EC<F]B
M;&%Z92]M:6-R;V)L87IE+7!R;W1O<RYH"3(P,#<M,#8M,C @,3,Z-#,Z,S0N
M,# P,# P,# P("TP-S P"BLK*R!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE
M+VUI8W)O8FQA>F4M<')O=&]S+F@),C P-RTP-BTR," Q-#HR.#HT-2XP,# P
M,# P,# @+3 W,# *0$ @+3,X+#0@*S,X+#$Q($! (&5X=&5R;B!V;VED('-H
M:69T7V1O=6)L95]L969T7VEM;2 @("!005(*(&5X=&5R;B!V;VED(&]V97)R
M:61E7V]P=&EO;G,@*'9O:60I.PH@97AT97)N('9O:60@;6%C:&EN95]D97!E
M;F1E;G1?<F5O<F<@4$%204U3("@H=F]I9"DI.PH@(V5N9&EF(" O*B!25%A?
M0T]$12 J+PHK"BLC:69D968@5%)%15]#3T1%"BME>'1E<FX@=F]I9"!F=6YC
M=&EO;E]A<F=?861V86YC92 H0U5-54Q!5$E615]!4D=3("HL(&5N=6T@;6%C
M:&EN95]M;V1E+ HK"0D)"2 @=')E92P@:6YT*3L**V5X=&5R;B!R='@@9G5N
M8W1I;VY?87)G("A#54U53$%4259%7T%21U,@*BP@96YU;2!M86-H:6YE7VUO
M9&4L('1R964L(&EN="D["BLC96YD:68@+RH@5%)%15]#3T1%("HO"BL*("-E
M;F1I9B @+RH@7U]-24-23T),05I%7U!23U1/4U]?("HO"F1I9F8@+75R3G @
M9V-C+6]R:6<O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z92!G
M8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z90HM+2T@9V-C
M+6]R:6<O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z90DR,# W
M+3 V+3(P(#$S.C0S.C,T+C P,# P,# P," M,#<P, HK*RL@9V-C+V=C8R]C
M;VYF:6<O;6EC<F]B;&%Z92]T+6UI8W)O8FQA>F4),C P-RTP-BTR," Q-#HS
M-CHR-2XP,# P,# P,# @+3 W,# *0$ @+3,W+#,@*S,W+#0@0$ @355,5$E,
M24)?15A#15!424].4R ]("IM>&PM8F%R<F5L+7-H:69T+PH@(R,@56YF;W)T
M=6YA=&5L>2P@=&AI<R!D;V5S(&YO="!W;W)K+B!792!H879E('1O(&9I;F0@
M82!W87D@=&\@9&\@=&AI<RX@"B C(R!/=&AE<G=I<V4L("UX;"UB;&%Z96ET
M('=I;&P@8V%U<V4@;VYL>2!T:&4@8F%S92!L:6)G8V,@=&\@8F4@<&EC:V5D
M('5P(&%L=V%Y<RX*(",C($U53%1)3$E"7TU!5$-(15,@/2!:>&PM8FQA>F5I
M=#UM>&PM8F%R<F5L+7-H:69T(%IX;"UB;&%Z96ET/6UN;RUX;"US;V9T+6UU
$; HK"@``
`
end

begin 666 binutils_mb_lin64-2.patch
M9&EF9B M=7).<"!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B
M;&%Z92YC(&)I;G5T:6QS+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"BTM
M+2!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"3(P
M,#<M,#8M,C @,38Z,S4Z,#<N,# P,# P,# P("TP-S P"BLK*R!B:6YU=&EL
M<R]G87,O8V]N9FEG+W1C+6UI8W)O8FQA>F4N8PDR,# W+3 W+3$R(#$U.C(X
M.C0T+C P,# P,# P," M,#<P, I 0" M,C,V.2PV("LR,S8Y+#$P($! (&UD
M7VYU;6)E<E]T;U]C:&%R<R H8VAA<B J('!T<BP@=F%L=654('4*(" @(&EF
M("@A('1A<F=E=%]B:6=?96YD:6%N*0H@(" @(" @<W=I=&-H("AN8GET97,I
M"B @(" @("!["BL@(" @("!C87-E(#@Z('!T<ELW72 ]("AU<V4@/CX@-38I
M("8@,'AF9CL**R @(" @(" @(" @(" @<'1R6S9=(#T@*'5S92 ^/B T."D@
M)B P>&9F.PHK(" @(" @(" @(" @("!P=');-5T@/2 H=7-E(#X^(#0P*2 F
M(#!X9F8["BL@(" @(" @(" @(" @('!T<ELT72 ]("AU<V4@/CX@,S(I("8@
M,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#0Z('!T<ELS
M72 ]("AU<V4@/CX@,C0I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @
M(" @("!C87-E(#,Z('!T<ELR72 ]("AU<V4@/CX@,38I("8@,'AF9CL@+RH@
M9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#(Z('!T<ELQ72 ]("AU<V4@
M/CX@(#@I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"D! ("TR,S<X+#8@
M*S(S.#(L,3 @0$ @;61?;G5M8F5R7W1O7V-H87)S("AC:&%R("H@<'1R+"!V
M86QU950@=0H@(" @96QS90H@(" @(" @<W=I=&-H("AN8GET97,I"B @(" @
M("!["BL@(" @("!C87-E(#@Z("IP='(K*R ]("AU<V4@/CX@-38I("8@,'AF
M9CL@"BL@(" @(" @(" @(" @("IP='(K*R ]("AU<V4@/CX@-#@I("8@,'AF
M9CL**R @(" @(" @(" @(" @*G!T<BLK(#T@*'5S92 ^/B T,"D@)B P>&9F
M.PHK(" @(" @(" @(" @(" J<'1R*RL@/2 H=7-E(#X^(#,R*2 F(#!X9F8[
M("\J(&9A;&P@=&AR;W5G:" J+R @(" @(" @(" @(" @"B @(" @("!C87-E
M(#0Z("IP='(K*R ]("AU<V4@/CX@,C0I("8@,'AF9CL@+RH@9F%L;"!T:')O
M=6=H("HO"B @(" @("!C87-E(#,Z("IP='(K*R ]("AU<V4@/CX@,38I("8@
M,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#(Z("IP='(K
K*R ]("AU<V4@/CX@(#@I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"@``
`
end

begin 666 binutils_mb_lin64.patch
M9&EF9B M=7).<"!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B
M;&%Z92YC(&)I;G5T:6QS+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"BTM
M+2!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"3(P
M,#<M,#8M,3D@,3 Z-3<Z,S0N,# P,# P,# P("TP-S P"BLK*R!B:6YU=&EL
M<R]G87,O8V]N9FEG+W1C+6UI8W)O8FQA>F4N8PDR,# W+3 V+3$Y(#$Q.C0V
M.C0U+C P,# P,# P," M,#<P, I 0" M,3 U-BPY("LQ,#4V+#$P($! ('!A
M<G-E7VEM;2 H8VAA<B J(',L(&5X<')E<W-I;VY3("H@92P@:6X*(" @(&5L
M<V4@:68@*"AE+3Y87V]P("$]($]?8V]N<W1A;G0@)B8@92T^6%]O<" A/2!/
M7W-Y;6)O;"D@*0H@(" @(" @+RH)(" @?'P@*&4M/EA?;W @/3T@3U]S>6UB
M;VP@(" F)B!E+3Y87V%D9%]N=6UB97(@(3T@," I*2 J+PH@(" @(" @87-?
M8F%D*%\H(F]P97)A;F0@;75S="!B92!A(&-O;G-T86YT(&]R(&$@;&%B96PB
M*2D["BT@("!E;'-E(&EF("@H92T^6%]O<" ]/2!/7V-O;G-T86YT*2 F)B H
M92T^6%]A9&1?;G5M8F5R(#P@;6EN('Q\(&4M/EA?861D7VYU;6)E<B ^(&UA
M>"DI"BL@("!E;'-E(&EF("@H92T^6%]O<" ]/2!/7V-O;G-T86YT*2 F)B H
M*&EN="D@92T^6%]A9&1?;G5M8F5R(#P@;6EN('Q\("AI;G0I(&4M/EA?861D
M7VYU;6)E<B ^(&UA>"DI('L*(" @(" @(&%S7V)A9" H7R@B;W!E<F%N9"!M
M=7-T(&)E(&%B<V]L=71E(&EN(')A;F=E("5D+BXE9"P@;F]T("5D(BDL"B @
M(" @(" @(" @(" @(&UI;BP@;6%X+" H:6YT*2!E+3Y87V%D9%]N=6UB97(I
M.PHK(" @?0H@"B @("!R971U<FX@;F5W.PH@?0ID:69F("UU<DYP(&)I;G5T
M:6QS+6]R:6<O;W!C;V1E<R]M:6-R;V)L87IE+6]P8RYH(&)I;G5T:6QS+V]P
M8V]D97,O;6EC<F]B;&%Z92UO<&,N: HM+2T@8FEN=71I;',M;W)I9R]O<&-O
M9&5S+VUI8W)O8FQA>F4M;W!C+F@),C P-RTP-BTQ.2 Q,#HU-SHT,RXP,# P
M,# P,# @+3 W,# **RLK(&)I;G5T:6QS+V]P8V]D97,O;6EC<F]B;&%Z92UO
M<&,N: DR,# W+3 V+3$Y(#$Q.C$Q.C$S+C P,# P,# P," M,#<P, I 0" M
M-# P+#$T("LT,# L,30@0$ @8VAA<B!P=G)?<F5G:7-T97)?<')E9FEX6UT@
M/2 B<G!V<B(["B *( H@+RH@(V1E9FEN97,@9F]R('9A;&ED(&EM;65D:6%T
M92!R86YG92 J+PHM(V1E9FEN92!-24Y?24U-(" P>#@P,# P,# P"BTC9&5F
M:6YE($U!6%])34T@(#!X-V9F9F9F9F8@"BLC9&5F:6YE($U)3E])34T@("@H
M:6YT*2 P>#@P,# P,# P*0HK(V1E9FEN92!-05A?24U-(" H*&EN="D@,'@W
M9F9F9F9F9BD*( HM(V1E9FEN92!-24Y?24U--R @,'@P,# *+2-D969I;F4@
M34%87TE-33<@(#!X-V9F"BLC9&5F:6YE($U)3E])34TW("@H:6YT*2 P># P
M,"D**R-D969I;F4@34%87TE-33<@*"AI;G0I(#!X-V9F*0H@"BTC9&5F:6YE
M($U)3E])34TQ-2 @,'@P,# P"BTC9&5F:6YE($U!6%])34TQ-2 @,'@Q9F9F
M"BLC9&5F:6YE($U)3E])34TQ-2 H*&EN="D@,'@P,# P*0HK(V1E9FEN92!-
M05A?24U-,34@*"AI;G0I(#!X,69F9BD*( H@(V5N9&EF("\J($U)0U)/0DQ!
,6D5?3U!#("HO"B *
`
end


Article: 124144
Subject: Re: Uses of Gray code in digital design
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 12 Sep 2007 13:38:26 -0700
Links: << >>  << T >>  << A >>
I wrote:
> If the EEPROM bytes start as 0x00, and individual bits can be changed from
> zero to ones without having to erase the byte first, instead of incrementing
> the EEPROM byte you would use a progression like 00->01->03->07->0f etc.,
> so you get eight "increments" of a byte value with no erase, and in doing so
> only use up one unit of write endurance for that byte.

dick <dick_12345678@hotmail.com> writes:
> don't use binary coding but unary coding.

That's what I wrote, though for a large counter, you don't want to exclusively
use unary, because it will require too much space.  A combination of unary
code at the byte level with a gray code addressing scheme works quite nicely.


Article: 124145
Subject: Re: Uses of Gray code in digital design
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 12 Sep 2007 16:08:06 -0500
Links: << >>  << T >>  << A >>

>glitches. The typical write operation is:
>
>1. change address.

I think you also need something like:
  1.5: Wait for new address to settle

>2. toggle write signal to write data.


>Gray code avoids glitches in a different way. It avoids glitches by
>ensuring that only a single bit changes when the address change. This
>allows us to do everything in a single clock cycle:
>
>(write signal is always set)
>1. change address and  write data.

Gray code makes sure you only write something to either the
old address or the new address.  You also have to make sure
that the new data doesn't get written to the old address.
(or probably worse, part of the new data gets written
on top of the old data)

How about
  1: change address
  2: wait for address to settle and data hold time
  3: write new data

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


Article: 124146
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: Andy <jonesandy@comcast.net>
Date: Wed, 12 Sep 2007 15:11:31 -0700
Links: << >>  << T >>  << A >>
On Sep 12, 2:20 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> > Have you thought about what happens to bus2ip_data before the magic
> > address is hit? What about after it has been hit?
>
> No, I had not thought of it. I was just correcting the obvious
> lack of a clk if-then and hopefully explaining why he got zeroes.
> Perhaps, there is another driver.
>
> > What else (if anything) is driving bus2ip_data? If nothing,
> > bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
> > forevermore.
>
> > If something else is driving data, then a (others => 'X') will almost
> > certainly result.
>
> > Andy

Sorry Brad, my reply was meant for the OP instead of you.

Andy


Article: 124147
Subject: XAPP851 fifo36 missing
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 12 Sep 2007 15:35:13 -0700
Links: << >>  << T >>  << A >>
I need the FIFO36 entity for XAPP851
(DDR SDRAM Controller Using Virtex-5
FPGA Devices). Either it wasn't in
the zip file or I lost it while
unzipping it.

Thanks in advance,

Brad Smallridge
AiVision 



Article: 124148
Subject: Re: XAPP851 fifo36 missing
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 12 Sep 2007 15:47:14 -0700
Links: << >>  << T >>  << A >>
On second look, it cound be that FIFO36
is part of the unisim library?
Then why don't I have it?
Is it because I'm running ISE 7.1?
Or is it that the Web release doesn't support it?
Is it part of Synplicity?

 Brad Smallridge




Article: 124149
Subject: Re: XAPP851 fifo36 missing
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Wed, 12 Sep 2007 17:19:35 -0600
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> On second look, it cound be that FIFO36
> is part of the unisim library?
> Then why don't I have it?
> Is it because I'm running ISE 7.1?
> Or is it that the Web release doesn't support it?
> Is it part of Synplicity?
> 
>  Brad Smallridge
> 
> 
> 
That's a primitive, so it should be in the UNISIM library.  It's new 
with the Virtex-5 (Virtex-4 had a FIFO16).  So you might neet to update 
ISE.  See if you have a fifo36.v in xilinx/verilog/src/unisims.  If not 
you need to update.
-Kevin



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