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 102525

Article: 102525
Subject: Re: IEEE-1394 (aka FireWire) Core
From: Felix Bertram <flx@bertram-family.com>
Date: Wed, 17 May 2006 13:50:40 +0200
Links: << >>  << T >>  << A >>
Hi Tom,

why not just using an existing link layer chip from Philips (if they 
still exist) or TI? This should save you from quite some hassle. The 
whole concept could look like this:
	http://www.bertram-family.com/felix/fw_audio.html

Regarding the future of FireWire: Have you noticed that Apple as one of 
the biggest promoters does not seem to invest too much into the future 
of FireWire, any longer? All Intel-based Macs only provide FireWire 400, 
iPod  does not support FireWire any longer. Maybe you should not invest 
too much time and money into the bus interface.


Best regards,

Felix
-- 
Dipl.-Ing. Felix Bertram
http://www.bertram-family.com/felix


soar2morrow@yahoo.com schrieb:
> I am interested in any FPGA cores that implement the IEEE-1394a
> FireWire interface. The application is to process images from several
> FireWire digital cameras in a hand gesture recognition system. Our
> current plan is to dedicate a computer to this task, but it may only be
> able to handle 3-4 cameras (we want to have as many as 8, meaning we
> may need 3 computers). The actual processing is quite simple and could
> be done by a single FPGA.
> 
> So far I have found a core from Altera that does what I need, but I
> would prefer a Xilinx core. Any ideas?
> 
> Tom Seim
> Pacific Northwest National Laboratory
> Richland, WA
> 


Article: 102526
Subject: Re: Xilinx Platform Cable USB protocol specifications and/or open-source
From: Felix Bertram <flx@bertram-family.com>
Date: Wed, 17 May 2006 14:37:04 +0200
Links: << >>  << T >>  << A >>
Hi Ed,

> It seems like you want to go to whole lot of effort to redo work that
> already exists and ships for free.  If so, then I guess everyone needs
> a hobby to work on.

it's good to see that Xilinx monitors this group- and the JTAG topic.

When talking about JTAG and using it to configure FPGAs or CPLDs and 
programming PROMs, you are probably right: Impact is your friend. It 
will do what you want and there is no need to use any open source 
solution or program something on your own.

BUT: Often my world does not look like this. I have setups that are 
mixed with chips from other manufacturers. I want to access all of them. 
I want to do some tests, toggle a few pins, see what happens. And now 
the pain begins, as I cannot. I cannot just write my own JTAG software, 
because I cannot access the Xilinx cable.

Of course Xilinx is right from a revenue perspective. All these "odd" 
setups do not generate any revenue for Xilinx. So why should Xilinx 
support these applications? Because engineers do not want to use two 
different cables: One for the Xilinx flow, one for the more advanced 
problems. It is obvious from a technical perspective, that everything 
that is required is already there.  So why should I buy another cable, 
just to be able to talk to the JTAG chain? This just does not make any 
sense.

OK, still I understand that Xilinx is not really motivated to do so. 
Probably, the documentation of the cable API will lead to a support 
night-mare. But again, there are solutions to it. Why not do it the 
other way around (and keep your driver dongled with Impact)? This is 
what I would really like to see:
- Create a properly documented API to talk to the driver.
- Make Impact use this API.
- Publish this API.
- Allow vendors to integrate their JTAG cables/ solutions with Impact.

This solution would probably make a lot of developers and vendors of 
development boards very happy. Including me.


Best regards, Felix

-- 
Dipl.-Ing. Felix Bertram
http://www.bertram-family.com/felix

Article: 102527
Subject: Re: "disappointing" 550Mhz performance of V5 DSP slices
From: airtom@gmail.com
Date: 17 May 2006 06:07:42 -0700
Links: << >>  << T >>  << A >>
>>1GHz multipliers would be very hard to
>>use if the logic fabric and memories can't keep up
in some problems with pipeline techniques, logic fabric can keep up
For memories, i am sure u can design 2x faster memories
>>do you have
>>an application in mind that requires 1GHz multipliers
Scientific computation
>>The DSP48E is already pipelined. Obviously, adding extra (bypassable)
>>pipeline stages within the multiplier would increase the maximum clock
>>speed, but it also adds latency and silicon area, and increases power
>>consumption. Everything's a tradeoff...
Agreed
>>Note that there are many enhancements in the DSP48E over the Virtex-4 DSP48
>>block, not the least of which being a larger multiplier (25x18). So a direct
>>MHz-to-MHz comparison with the previous generation is not entirely fair.
Agreed
I am just noticing that moore law is not respected relative to dsp
frequency and wanted to know the reason for this(is it technological
problems, or strategic problems to satisfy the maximum number of
customers)
Cheers, Thom


Article: 102528
Subject: SystemACE bootloader for PowerPC on Virtex4 FX
From: "Jon Beniston" <jon@beniston.com>
Date: 17 May 2006 06:23:25 -0700
Links: << >>  << T >>  << A >>
Hi,

I am looking for a small bootloader (small because I'd like it to be in
BRAM) that can load a PowerPC ELF file (possibly binary) from a CF card
connected via a SystemACE controller and run it. Any recommendations?

I've serached through the news group, and it seems like Antti wrote one
for MicroBlaze, although the link to xilinx.openchip.org no longer
seems to be valid. I've also had a look through xapp482.pdf, but I was
hoping someone had already implemented this before :)

Cheers,
Jon


Article: 102529
Subject: Re: SystemACE bootloader for PowerPC on Virtex4 FX
From: "Antti" <Antti.Lukats@xilant.com>
Date: 17 May 2006 06:59:15 -0700
Links: << >>  << T >>  << A >>
hi, me Antti

yes I wrote some systemace loader that I tested on ML300 loooong time
ago
some derivate of that is still in use.
wasnt very good one, the FAT support was really really minimal :(

there should be no problems fitting into brams, but better look at the
dosfs
that is very small and support FAT pretty completly, changing the
sector read
for systemace should not be a problem

antti
I may be able to dig out some of my old code, buts its rather nasty


Article: 102530
Subject: ANNC: ISE/WebPACK 8.1i tutorial available
From: "devb" <devb@xess.com>
Date: 17 May 2006 07:12:06 -0700
Links: << >>  << T >>  << A >>
We have released a new version of our ISE/WebPACK tutorial that is
updated to version 8.1i:
http://www.xess.com/appnotes/webpack-8_1-xsa.pdf .


Article: 102531
Subject: Re: ADC implementation on FPGA ?
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 17 May 2006 16:12:08 +0200
Links: << >>  << T >>  << A >>
Scope schrieb:
> Hi !
> 
> I would know if , to your mind, it may be possible to implement a 16 bits
> Analog-to-Digital Converter on a FPGA ( like a Spartan 3 for example ... )
> . 
> Any idea is welcome.

Search the Xilinx Website for application notes.
Or search the USPTO patent database for "Austin Lesea".

Kolja Sulimma

Article: 102532
Subject: Re: "disappointing" 550Mhz performance of V5 DSP slices
From: "Stephen Craven" <nevarcs@gmail.com>
Date: 17 May 2006 07:17:29 -0700
Links: << >>  << T >>  << A >>
Tom,

Moore's Law actually refers to transistor sizes, not clock frequencies.
 Interconnect delay at these deep submicron sizes has significantly
reduced clock frequency scaling - just look at how Pentium frequencies
have stopped increasing.

Xilinx could significantly pipeline the multiplier to get a much higher
clock rate, but, as mentioned previously, keeping it fed with data from
the configurable fabric would be difficult at higher frequencies.

MathStar has a field programmable array with 1GHz DSP performance, but
it's not bit-level configurable.

Stephen


Article: 102533
Subject: CoolRunner Pins during Programming
From: Eli Hughes <emh203@psu.edu>
Date: Wed, 17 May 2006 10:57:07 -0400
Links: << >>  << T >>  << A >>
I noticed that the CoolRunner (XPLA3) sets all of the pins (at least the 
ones I can monitor) high during in system programming.  Is there a way 
(programming file) to hold the pins low during programming?

Thanks,
Eli

Article: 102534
Subject: Re: ADC implementation on FPGA ?
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 17 May 2006 14:59:21 GMT
Links: << >>  << T >>  << A >>
Scope <romaingoron@hotmail.fr> wrote:
>Hi !
>I would know if , to your mind, it may be possible to implement a 16 bits
>Analog-to-Digital Converter on a FPGA ( like a Spartan 3 for example ... )
>. 
>Any idea is welcome.

What's the speed ..?
Voltage levels ..?
Cost ..?
Complexity ..?


Article: 102535
Subject: Hold Time Violations in Virtex4
From: Brijesh <brijesh_xyz@cfrsi_xyz.com>
Date: Wed, 17 May 2006 11:03:01 -0400
Links: << >>  << T >>  << A >>
Hello,

Iam getting the following hold time violation in my design. Its happen on the 
address inputs to a instantiated ram16x1d primitive. Source and desitnation 
flipflops are in the same clock domain. There does not seem to be a clock skew 
and iam using local clock resources for this clock.


--------------------------------------------------------------------------------
Hold Violations: TS_lp_clkin_p = PERIOD TIMEGRP "lp_clkin_p" 5 ns HIGH 50%;
--------------------------------------------------------------------------------
Hold Violation:         -0.089ns (requirement - (clock path skew + uncertainty - 
data path))
   Source:               lp_bus/rx/wr_addr_r[0] (FF)
   Destination:          lp_bus/rx/l1.2.r.SLICEM_G (RAM)
   Requirement:          0.000ns
   Data Path Delay:      -0.089ns (Levels of Logic = 1)
   Positive Clock Path Skew: 0.000ns
   Source Clock:         lp_bus/rx/lp_clk rising at 0.000ns
   Destination Clock:    lp_bus/rx/lp_clk rising at 5.000ns
   Clock Uncertainty:    0.000ns
   Timing Improvement Wizard
   Data Path: lp_bus/rx/wr_addr_r[0] to lp_bus/rx/l1.2.r.SLICEM_G
     Delay type         Delay(ns)  Logical Resource(s)
     ----------------------------  -------------------
     Tcko                  0.313   lp_bus/rx/wr_addr_r[0]
     net (fanout=10)    e  0.100   lp_bus/rx/wr_addr_r(0)
     Tah         (-Th)     0.502   lp_bus/rx/l1.2.r.SLICEM_G
     ----------------------------  ---------------------------
     Total                -0.089ns (-0.189ns logic, 0.100ns route)
                                   (212.4% logic, -112.4% route)
----------------------------------------------------------------------------------

According to their latest data sheet Tah = -0.29 ns.
But timing analyzer has it as Tah = 0.502 ( positive value)

I get same results on both ISE 7.1.04 and 8.1.03.

What am I missing? With a negative hold time, there should be no hold time 
violations.
How do I update the timing models/data?

Thanks
Brijesh

Article: 102536
Subject: Re: "disappointing" 550Mhz performance of V5 DSP slices
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 17 May 2006 17:35:02 +0200
Links: << >>  << T >>  << A >>
Stephen Craven schrieb:
> Tom,
> 
> Moore's Law actually refers to transistor sizes, not clock frequencies.
>  Interconnect delay at these deep submicron sizes has significantly
> reduced clock frequency scaling - just look at how Pentium frequencies
> have stopped increasing.
> 
> Xilinx could significantly pipeline the multiplier to get a much higher
> clock rate, but, as mentioned previously, keeping it fed with data from
> the configurable fabric would be difficult at higher frequencies.

Guys, guys. Can you ever get enough? I guess no! :-(
First, clock frequency is not necessary processing power.
Second, 550 MHz isnt a piece of cake, even if there are a few other 
fast(er) competitors.
Third, I think that all those fency Pentium/Athlon/Whatever CPUS are 
heavy pipelined.
Fourth, blablablablablablablablablablablablablabla

And, Iam not a follower of those stock market philosophy of ever 
(exponential) rising profit, or here in the electronic world ever 
(exponential) rising processing power/clock frequency. This "law" was 
suprisingly valid for a long time, it still can be fullfilled, even with 
the great challenges of deep sub-micron technology. But there is an end 
to all things.
Remember, the transfer function of a diode is also exponentional over 
many decades, until it ends up in smoke.

Regards
Falk

P.S. Reminds me again of some old basic rules for programmers.
    1st Your CPU ist always too slow.
    2nd You have always too less RAM.
    3rd The compiler is lousy.

Article: 102537
Subject: Re: CoolRunner Pins during Programming
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 17 May 2006 17:36:36 +0200
Links: << >>  << T >>  << A >>
Eli Hughes schrieb:
> I noticed that the CoolRunner (XPLA3) sets all of the pins (at least the 
> ones I can monitor) high during in system programming.  Is there a way 
> (programming file) to hold the pins low during programming?

Those are weak pull-ups.

Regards
Falk

Article: 102538
Subject: Re: "disappointing" performance
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 17 May 2006 08:45:16 -0700
Links: << >>  << T >>  << A >>
All,

A recent Intel presentation at an IEEE Workshop admitted that clock 
frequency has max'd out, and now has to go down (not up) in order to not 
create heat.

We have known that for years now.  So has AMD.

The only choice is "multi."

Intel proposes a future with more than 200 x86 cores on one die, with a 
"communications fabric" and many memories.  All on one die.  Small 
software problem to be solved by the need to have it solved....

One attendee of the conference (not me!) quipped, "sounds like you are 
describing a FPGA..."

Boy did the presenter get mad!  To be ccompared to a lowly FPGA!  He was 
spitting venom back at the attendee.  "There is no comparison!  FPGAs 
are fine grained, and this is not!"

Sounds like if that is the only difference, the FPGA wins.  Again.

Oh, and I can't wait for Intel to stub their toes on that 
"communications fabric" (left as an exercise for the student).  Or the 
software.

I think that we are all dissapointed:  no high K gate dielectric, so the 
supply voltage can't scale anymore, worsening variation in threshold 
voltages, because not only can you count the layers in the gate 
dielectric on your fingers, but you can count the ions that got 
implanted, too.  Not only does the source-drain leak when off, but gates 
leak now (at 65nm and below).

A new fab costing 2B$.  No clear path for lithography.

Good thing we make a standard product, and can afford to keep developing 
it.  ASSP vendors will have to consolodate, and reduce their offerings. 
  Real tough times ahead for some business models.  Only place to get 
the latest IP will be from FPGA vendors....

The future is ~500 MHz, more stuff, and voltages slowly decreasing to 
0.8 volts.

But, we can still get twice as many transistors per unit area, all the 
way down to 22nm.  And that increases thoughput and processing power.

45nm, 35nm, and then 22nm.  Life in the old horse yet.  2B 6 input LUTs 
in V8?  100 Mb of BRAM?  2,000 DSP processors?  Crystal ball is getting 
very hazy....Aunti Em!  Aunti Em!  She is holding her head! (apologies 
to the Wizard of Oz movie).

After that, we really are looking for that disruptive technology with 
which we can make a new FPGA.

Now if I could only get those unobtainium wafers to yield....

Austin

Article: 102539
Subject: Re: Power for Spartan 3
From: Greg Neff <greg@nospam.com>
Date: Wed, 17 May 2006 11:49:04 -0400
Links: << >>  << T >>  << A >>
On Wed, 17 May 2006 09:48:44 +0100, Peter Mendham
<petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote:

>rickman wrote:
>> I don't know about stupid, but I didn't see the equations...  :)  I
>> just used the stated feedback voltage and the resistor ratios to get my
>> numbers.  I don't know why your numbers are different from mine.  What
>> equations did you use?  I used Vf * (R1+R2/R2), where R1 is the
>> resistor that connects to the output voltage and R2 is the resistor
>> that connects to ground.
>
>Ahhh, thanks to your persistence, I have spotted what I was missing. 
>Yes, indeed, there was a certain amount of stupidity involved, I'd be 
>the first to admit.  The datasheet states a value of Vfb of 1.24V next 
>to equation 15.  Foolishly, I used this, instead of 1.22V as stated 
>earlier in the datasheet (which I've only just noticed).  I assume that 
>the 1.24V is the upper tolerance bound 1.22V+2% ~ 1.24V.  I'm not quite 
>sure why, it seems a little arbitrary to me to pick one boundary for the 
>example calculation. Thoughts?
>
>-- Peter

My first thought was a datasheet error, and there it is.  Download the
latest version of the datasheet.  The equation has been corrected.

http://focus.ti.com/lit/ds/sbvs052e/sbvs052e.pdf

I remember a TI datasheet error for a voltage supervisor, where the
timing capacitor equation produced a capacitance value of several
Farads.

I wish TI put revision histories in their documents.  It would be nice
to know what else changed...

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Article: 102540
Subject: Re: SystemACE bootloader for PowerPC on Virtex4 FX
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Wed, 17 May 2006 08:51:34 -0700
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
> Hi,
> 
> I am looking for a small bootloader (small because I'd like it to be in
> BRAM) that can load a PowerPC ELF file (possibly binary) from a CF card
> connected via a SystemACE controller and run it. Any recommendations?
> 

It is fairly straightforward to use xilfatfs (shipped with EDK) to load 
a file from the CF into memory and transfer control to the loaded 
program. Just use open/read file library calls.

/Siva

Article: 102541
Subject: Re: "disappointing" 550Mhz performance of V5 DSP slices
From: MikeShepherd564@btinternet.com
Date: Wed, 17 May 2006 16:56:17 +0100
Links: << >>  << T >>  << A >>
>Guys, guys. Can you ever get enough?

I agree with the sentiment.  Most of us aren't pushing the speed of
our devices.  We use FPGAs for other reasons.

Of course, there are always "leading edge" applications that need the
highest performance, but it's a small part of the market and a
minority interest.

Unfortunately, speed is the usual news from manufacturers:  "This will
run at 800MHz now and 950MHz by the end of next quarter...".

Yawn!

Maybe the speed freaks can form their own newsgroup ("FPGA
overclockers"?)  Stand by for photos of water-cooled chips, lit with
blue LEDs.

Article: 102542
Subject: Re: Xilinx Platform Cable USB protocol specifications and/or open-source
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 17 May 2006 09:12:19 -0700
Links: << >>  << T >>  << A >>
Laurent Pinchart wrote:
> That's not the only issue. The main problem is that the Jungo driver is a
> security hole by design: it gives applications access to PCI cards from
> user space without any security check, making it possible for any user to
> read from and write to any memory location. The people who designed such a
> piece of crap should be banned from using computers for the rest of their
> life.

Can you please cite a reference that documents this issue in detail? And
as I originally requested is there any known exploit that takes advantage
of this, again I need a cite.   I looked and I can't find anything other
than comments that are 4+ years old at this time.

If there is truly an issue here I will look into it further as my group
is one of licensees of Jungo drivers, but so far all I've seen is FUD for
"closed source" code.

Ed McGettigan
--
Xilinx Inc.

Article: 102543
Subject: Re: Xilinx Platform Cable USB protocol specifications and/or open-source
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 17 May 2006 09:23:19 -0700
Links: << >>  << T >>  << A >>
Felix Bertram wrote:
> BUT: Often my world does not look like this. I have setups that are 
> mixed with chips from other manufacturers. I want to access all of them. 
> I want to do some tests, toggle a few pins, see what happens. And now 
> the pain begins, as I cannot. 

The iMPACT software works with other devices in the chain by allowing you to
specify a BSDL file for the device when it doesn't recognize it.  The iMPACT
software also allows you to generate arbitrary JTAG sequences in order to do
anything that you want to do.  If you want to generate a program to improve
your ability to do this then run iMPACT in batch/command line mode and have
your program control iMPACT.

I would also suggest using a product like Universal Scan (http://www.universalscan.com/)
I've not used it personally, but I did have a conversation with the principal developer
a few years ago and it seems like a nice light weight tool to do exactly what you
want to do.  I think that it might be Windows only though.

Or, if the pins that you want to toggle are from a Xilinx device, then I would
suggest using ChipScope Pro with a VIO (Virtual I/O) core attached to the pins for
an even simpler product and it includes FPGA configuration capabilities. ChipScope Pro
does work on Linux.

Ed McGettigan
--
Xilinx Inc.

Article: 102544
Subject: Re: SystemACE bootloader for PowerPC on Virtex4 FX
From: "Jon Beniston" <jon@beniston.com>
Date: 17 May 2006 09:34:35 -0700
Links: << >>  << T >>  << A >>
Hi Siva,

Yep, but a bog standard implementation (i.e. just using the standard
library code) is going to be 20kB+. I don't have that many block RAMs
to play with, so want to create something as small as possible.

Cheers,
Jon


Article: 102545
Subject: Re: sending multiple char on RS232
From: "Dave Pollum" <vze24h5m@verizon.net>
Date: 17 May 2006 09:46:38 -0700
Links: << >>  << T >>  << A >>

YiQi wrote:
> the problem has solved by adding a extra clock cycle between 4 and 5,
> but I still don't understand why that will work. Maybe need to wait
> longer for sending the byte. If someone know, please tell me.  anyway,
>
>
> thanks Mike~!

BTW - In the UARTs I've used (Z8530, 16c450) the UART sets TBE to a 1
when it can accept a byte to be transmitted.
>..I still don't understand why that will work
Without seeing your code it would be difficult to help you.
-Dave


Article: 102546
Subject: Re: getting good deals on small qty?
From: =?ISO-8859-1?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Wed, 17 May 2006 18:47:03 +0200
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> Let me explain one reason why distis are reluctant to break a standard
> tray of ICs:

but how do you think a new project might start?

Usually we build something like 2-3 prototypes of one board and
implement the design ... this is enough to demonstrate that it's
working and we sell the design to someone manufacturing it ...

I'm glad that it is not my job to phone the distris and
beg for chips ...


bye,
Michael

Article: 102547
Subject: Re: IEEE-1394 (aka FireWire) Core
From: =?ISO-8859-1?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Wed, 17 May 2006 18:50:30 +0200
Links: << >>  << T >>  << A >>
Felix Bertram schrieb:
> Hi Tom,
> 
> why not just using an existing link layer chip from Philips (if they 
> still exist) or TI? 

AFAIR there is only one (very old) chip (TI TSB something) that has 
firewire and can connect to an FPGA ... all the others have PCI or PCIe


bye,
Michael

Article: 102548
Subject: Re: SystemACE bootloader for PowerPC on Virtex4 FX
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Wed, 17 May 2006 09:50:31 -0700
Links: << >>  << T >>  << A >>
Jon,

assuming that you are using System ACE CF to configure your Virtex-4 FX 
device you can load the boot code directly into the processor caches 
which gives you 16KB of instruction and 16KB of data space. That's 
enough for the bootloader you describe and you do not even need a single 
  BRAM.

- Peter


Jon Beniston wrote:
> Hi Siva,
> 
> Yep, but a bog standard implementation (i.e. just using the standard
> library code) is going to be 20kB+. I don't have that many block RAMs
> to play with, so want to create something as small as possible.
> 
> Cheers,
> Jon
> 


Article: 102549
Subject: Re: SystemACE bootloader for PowerPC on Virtex4 FX
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 17 May 2006 18:51:22 +0200
Links: << >>  << T >>  << A >>
dosfs claims to be <4k but I havent checked it with mb-gcc or ppc-gcc
antti

"Jon Beniston" <jon@beniston.com> schrieb im Newsbeitrag 
news:1147883675.279132.26480@y43g2000cwc.googlegroups.com...
> Hi Siva,
>
> Yep, but a bog standard implementation (i.e. just using the standard
> library code) is going to be 20kB+. I don't have that many block RAMs
> to play with, so want to create something as small as possible.
>
> Cheers,
> Jon
> 





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