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 130975

Article: 130975
Subject: Re: Spartan3 JTAG flash In System Programming over Ethernet
From: Fei Liu <fei.liu@gmail.com>
Date: Mon, 07 Apr 2008 15:26:08 -0400
Links: << >>  << T >>  << A >>
Petter Gustad wrote:
> cpandya@yahoo.com writes:
> 
>> If there is already a ready made solution for this then that will help
>> us.
> 
> I've made a programmer that works over ethernet. I've been modifying
> it over the last few years to get the cost down. I will make it into a
> product if there is a demand for such a programmer. I can program
> fpga's (altera and xilinx), as well as spi devices, i2c, and microchip
> microcontrollers. It can also program several flash devices attached
> to other processors etc which have a jtag interface.
> 
> I use it under linux, and the benefit is that you don't need a driver
> other than the network driver that is available with most (if not all)
> operating systems. 
> 
> Would there be any interest in such a programmer, or will most users
> want to stick with the programmers provided by the vendors?
> 
> 
> Petter
> 
Sorry, why do you need a programmer for this? Would it be possible to 
first write the flash memory on the fpga to load a minimal network stack 
that can interact with the jtag/ethernet interface, then directly 
program the FPGA over a null ethernet cable?

Fei

linux (192.168.1.1) <--> fpga_ethernet (192.168.1.2) <--> fpga spi flash

Article: 130976
Subject: Re: counterfeit Xilinx ?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 7 Apr 2008 19:51:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jon Elson <elson@wustl.edu> wrote:
...
> Anyway, I have made enormous progress on migrating to Spartan 2E, so I 

Take a plunge and go directly to 3E...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 130977
Subject: Re: counterfeit Xilinx ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 08 Apr 2008 08:43:17 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:
<snip>
> I've never been very successful at opening up Xilinx pacakges.  The 
> epoxy is
> harder than steel (well, at least really abrasive) and I don't have 
> something that will dissolve it.  These are TQFP's, so there's no metal
> lid.  They come in waffle trays, so there are a lot of "ends" to start 
> from.  What you say MAY make some sense, however, as the first batch of 
> boards I did used about half the tray without any bad ones!  Then, the 
> second batch I got 50+% bad.  Very curious!

  Solder the device onto a spare scrap of PCB, and then use a flat 
metalworking  file to remove the plastic. As the covering gets very 
thin, it will lift off the die, so with a little care, you can get quite 
clean exposure of most of the die. Enough to confirm it is 'Xilinx 
inside' :)

-jg


Article: 130978
Subject: Re: Xilinx xilfatfs and systemACE speed issue
From: morphiend <morphiend@gmail.com>
Date: Mon, 7 Apr 2008 13:50:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> I am trying to squeeze some read speed out from CF using systemACE and
> xilinx standard libraries, but the performance is really really bad
>
> read using xilfats 400KB/s
> read using systemace low level (direct sector reads) 1MB/s
>
> I have found NO information in any Xilinx documentation what speeds
> can be excpected to be achived with systemACE
>
> the 400KB/s looks like really miserable :(
>
> i am using the CF card supplied by Xilinx, that is have not yet done
> testbenching with other better CF cards, but i would like to know if
> such testing has been done, and if there is hope of BIG speed
> improvment when using some high-speed CF cards.
>
> if i look at the spec of the CF card supplied by Xilinx it has 2ms
> controller overhead (command to data ready delay) this would limit
> access to maximum 500 sector reads commands sent to the CF, but we
> need to add time for data transfer too, but this could explain the 1MB/
> s measured speed
>
> Antti

We've noticed the same thing working with the sysace fs. The problem
is the overhead from it is QUITE slow since its missing some essential
features like a real seek(). My guess is that we're also seeing
slowdown on the SystemACE controller in the FPGA. We're using the OPB-
based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc
for each operation that adds overhead to the bus. It probably also
depends on what you're doing with the sysace files. We're reading
ELF's from CF, and b/c there was no seek() there were tons of extra
read()'s just to get to the intended part of the ELF, for loading.

Currently, we're looking at using the dosfs, which I think you pointed
a link to a few years back.

-- Mike


Article: 130979
Subject: Re: system level language: why all this fuss about
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 07 Apr 2008 14:53:19 -0600
Links: << >>  << T >>  << A >>
Karl wrote:
> why all this fuss  ...
> 
> thanks
I definitely think more abstraction is important, but I don't see the 
need for a new language.  Like Kolja points out, the languages we have 
now are fine.  There is plenty of abstractability in Verilog that is not 
supported by synthesizers.  Some synthesizers support very little 
abstraction, meaning a lot of code has to be structural.  This level of 
nonabstraction lengthens development time and makes the code nonportable 
and nonmaintainable.

The abstraction is mostly dependent upon the synthesizer, not the 
language.  If you look at any of the new-fangled languages, you'll find 
that they are not any more abstract than Verilog.  Once you take one of 
these supposedly abstract languages and manually insert the parallelism 
and pipelining and unrolling to make it synthesize the way you want, 
there is no abstraction.  The C, Matlab code, Perl, or whatever all ends 
up looking like low-level Verilog.  Maybe there is some marketing value 
in saying you can convert C to gates, but if it still takes a hardware 
engineer to write the C in the correct way, you haven't gained anything.

Things will only change when you can have a high-level algorithm coder 
write sequential code that can automatically be synthesized efficiently 
to a parallel pipelined circuit.  Or, in the case of a multicore 
processor, compiled to well-parallelized code.  But despite claims, this 
isn't happening and doesn't seem to be within grasp.  There are tools 
that do this, but they do it poorly.  Marketing folk like to claim, 
"Your C coders can write in C.  Our tool converts C to gates.  Therefore 
your C coders can build circuits."  But that's akin to saying, "Your 
employees can all write in English.  Therefore they can all create great 
war novels."  The state-of-the-art English compilers might be able to 
correct most spelling and a bit of grammar, but they aren't going to 
take your crappy prose and turn it into Hemingway or synthesize a 
sonnet.  -Kevin

Article: 130980
Subject: Re: Xilinx xilfatfs and systemACE speed issue
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 7 Apr 2008 14:03:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7 Apr., 22:50, morphiend <morphi...@gmail.com> wrote:
> On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > I am trying to squeeze some read speed out from CF using systemACE and
> > xilinx standard libraries, but the performance is really really bad
>
> > read using xilfats 400KB/s
> > read using systemace low level (direct sector reads) 1MB/s
>
> > I have found NO information in any Xilinx documentation what speeds
> > can be excpected to be achived with systemACE
>
> > the 400KB/s looks like really miserable :(
>
> > i am using the CF card supplied by Xilinx, that is have not yet done
> > testbenching with other better CF cards, but i would like to know if
> > such testing has been done, and if there is hope of BIG speed
> > improvment when using some high-speed CF cards.
>
> > if i look at the spec of the CF card supplied by Xilinx it has 2ms
> > controller overhead (command to data ready delay) this would limit
> > access to maximum 500 sector reads commands sent to the CF, but we
> > need to add time for data transfer too, but this could explain the 1MB/
> > s measured speed
>
> > Antti
>
> We've noticed the same thing working with the sysace fs. The problem
> is the overhead from it is QUITE slow since its missing some essential
> features like a real seek(). My guess is that we're also seeing
> slowdown on the SystemACE controller in the FPGA. We're using the OPB-
> based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc
> for each operation that adds overhead to the bus. It probably also
> depends on what you're doing with the sysace files. We're reading
> ELF's from CF, and b/c there was no seek() there were tons of extra
> read()'s just to get to the intended part of the ELF, for loading.
>
> Currently, we're looking at using the dosfs, which I think you pointed
> a link to a few years back.
>
> -- Mike

hm dont think there is any help, i just did buy "EXTREME III" CF card
with advertised min speed of 20MB/s, to my surprise it did not make
any speed improvement at all ! :(

the RAW sector read (no filesystem) is about 1MB/s, and i need 3MB/s
as bare minimum.

so using dosfs or any other library will not help as plain raw reads
are
way too slow.

Antti

Article: 130981
Subject: Modify POF with new ESB (ROM) content?
From: radarman <jshamlet@gmail.com>
Date: Mon, 7 Apr 2008 14:29:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,
We have a design that has an embedded PIC processor that uses ESB's
for instruction and data RAM. The target is an Altera APEX 20K100 with
an EPC2 configuration PROM.

What we would like to do is download the current POF from the
configuration PROM and update the instruction ROM with an updated
version. While this would be trivial to do going through the build
system again, we aren't sure the Quartus project we have builds
exactly what is in the EPC2 (hardware-wise). We got the code and
project from the contractor who designed the firmware, but the
firmware was done before revision control was in place, and no one
knows what, exactly, got put into the revision control system.

So, can you take a POF file from an EPC2 configuration memory and
alter the ROM contents of the ESB's?

Thanks!

Article: 130982
Subject: Re: system level language: why all this fuss about
From: Andy Peters <google@latke.net>
Date: Mon, 7 Apr 2008 14:31:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
> why all this fuss  about the need for new system level languages and
> higher abstraction..

... because, at least for FPGAs, the synthesis and simulation tools
have become free (witness Synplicity selling out to Synopsys) and as
such the big tool vendors need something to sell to you (or, at least,
to management).

-a

Article: 130983
Subject: Re: Spartan3 JTAG flash In System Programming over Ethernet
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 07 Apr 2008 22:18:49 GMT
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp6@gustad.com> wrote:

>cpandya@yahoo.com writes:
>
>> If there is already a ready made solution for this then that will help
>> us.
>
>I've made a programmer that works over ethernet. I've been modifying
>it over the last few years to get the cost down. I will make it into a
>product if there is a demand for such a programmer. I can program
>fpga's (altera and xilinx), as well as spi devices, i2c, and microchip
>microcontrollers. It can also program several flash devices attached
>to other processors etc which have a jtag interface.
>
>I use it under linux, and the benefit is that you don't need a driver
>other than the network driver that is available with most (if not all)
>operating systems. 
>
>Would there be any interest in such a programmer, or will most users
>want to stick with the programmers provided by the vendors?

Something that would be really nice is a parallel port programmer.
With a huge twist... Years ago I've build an eprom emulator which
simply simulates a printer. Configuring it is a matter of printing
text commands. Downloading the hex file is simply a matter of printing
it. No device drivers whatsoever are required. It will work with USB
to parallel converters (including the crappy ones). There is full flow
control as well and it is bleeding fast. It amazes me no-one ever came
up with something like that.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 130984
Subject: Re: system level language: why all this fuss about
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 7 Apr 2008 22:28:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Andy Peters <google@latke.net> wrote:
> On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
> > why all this fuss  about the need for new system level languages and
> > higher abstraction..

> ... because, at least for FPGAs, the synthesis and simulation tools
> have become free (witness Synplicity selling out to Synopsys) and as
> such the big tool vendors need something to sell to you (or, at least,
> to management).

You mean like everybody in the shop needs to upgrade his office because the
boss had got a need Laptop with Office 2xxx on it?
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 130985
Subject: Re: Virtex-5 FXT coming soon?
From: Simon <wlpstxzhd@gmail.com>
Date: Mon, 7 Apr 2008 16:14:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 6, 1:05 am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Apr 5, 11:12 am, Simon <wlpstx...@gmail.com> wrote:
>
>
>
> > On Mar 23, 4:01 pm, pmull...@yahoo.com wrote:
>
> > > On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
>
> > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> > > >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com...
>
> > > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> > > > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > > >> > but as the V5FX has been delaying so long, I have almost lost interest
> > > > >> > to follow up how much longer it is delaying in reality...
>
> > > > >> > The Spartan-4 is much more interesting,
>
> > > > >> Well, we are desperately waiting for the V5 MGTs.
> > > > >> Actually we need a solution for 10gbps soon as XAUI is going to be
> > > > >> replaced
> > > > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports.
>
> > > > >> Kolja Sulimma
>
> > > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed of
> > > > > MGTs
> > > > > V4 less than V2
> > > > > V5 less than V4
>
> > > > > so you may need wait V6 :(
>
> > > > > Antti
>
> > > > V6? Don't hold your breath.
>
> > > > A reliable source tells me that the 10Gbps serdes will be fully functional
> > > > in V12 Pro (they're skipping V13 for obvious reasons).
>
> > > > Bob
>
> > > I would check with Altera on Serdes as they have done it right and
> > > have been up to 6 Gbps for years.
>
> > As shown on the homepage of Xilinx, the new Virtex5 FXT is out now.
> > Does anybody know whether there is development board featured with
> > Virtex5 FXT available? Is that ML507, if so where is the info or data
> > sheet for this board?
>
> > Simon
>
> To the best of my knowledge, the ML507 board is identical in layout
> and appearance with the ML505 board, since the 'LXT and 'FXT chips are
> pin-compatible.
> Let's see on Monday at work...
> Peter Alfke


Is that possible to have a customised ML523 board armed with Virtex5
FXT instead of LXT?

Simon

Article: 130986
Subject: Re: system level language: why all this fuss about
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 07 Apr 2008 17:17:11 -0600
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
>> why all this fuss  about the need for new system level languages and
>> higher abstraction..
> 
> ... because, at least for FPGAs, the synthesis and simulation tools
> have become free (witness Synplicity selling out to Synopsys) and as
> such the big tool vendors need something to sell to you (or, at least,
> to management).
> 
> -a
The (erroneously) presumed fungability of all synthesis tools does 
eventually reduce their quality to the lowest common denominator.

Article: 130987
Subject: Re: Xilinx inferred FIFOs
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 07 Apr 2008 16:37:09 -0700
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> writes:
> The difference between Xilinx and Intel chips is that the decimal point for
> the price of the Xilinx parts is at the wrong position :-)

I dunno about that.  It seems to me that Xilinx makes a lot of Spartan 3
parts that are at quite attractive price points.  I certainly wouldn't
want to see Xilinx raise those prices to match Intel.

Article: 130988
Subject: Re: A Challenge for serialized processor design and implementation
From: Ray Andraka <ray@andraka.com>
Date: Mon, 07 Apr 2008 20:07:50 -0400
Links: << >>  << T >>  << A >>
Antti wrote:
> Hi
> 
> I have been think and part time working towards a goal to make useable
> and useful serialized processor. The idea is that it should be
> 
> 1) VERY small when implemented in any modern FPGA (less 25% of
> smallest device, 1 BRAM)
> 2) be supported by high level compiler (C ?)
> 3) execute code in-place from either serial flash (Winbond quad speed
> SPI memory delivers 320 mbit/s!) or from file on sd-card
> 
> serial implementation would be smaller and run at higher speeds, so
> 128 clock per machine cycle would already mean 2 MIPS, what would be
> acceptable for many applications.
> 
> Parallax basic stamps I executes 2KIPS only, so ultra lite serial
> processor in FPGA with 2 MIPS would be eh, for me its some to dream
> off :)
> 
> I have poked around this idea for some years, but never got the "final
> kick" to really go and do-complete the design and development of this
> processor.
> 
> So I decided to offer some bounty for others to maybe motivate to work
> for this goal and dream, current list of items available for the
> developers from my own funding is listed here (I hope to add items and
> maybe some $ by the time)
> 
> http://code.google.com/p/serial-processor/w/list
> 
> there is also very preliminary spec-goal document as well
> 
> Antti Lukats


Antti,  I actually have something along those lines way back in my 
archives.  Unfortunately, it was for an XC3100 series part and was done 
as a schematic using Viewlogic.  I'd have to do some digging to a) find 
it, and b) extract it at this point. Unfortunately, I don't have the 
spare bandwidth to tackle that at the moment.

Article: 130989
Subject: Re: Virtex-5 FXT coming soon?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 07 Apr 2008 19:25:59 -0600
Links: << >>  << T >>  << A >>
Simon wrote:
> On Apr 6, 1:05 am, Peter Alfke <al...@sbcglobal.net> wrote:
>> On Apr 5, 11:12 am, Simon <wlpstx...@gmail.com> wrote:
>>> As shown on the homepage of Xilinx, the new Virtex5 FXT is out now.
>>> Does anybody know whether there is development board featured with
>>> Virtex5 FXT available? Is that ML507, if so where is the info or data
>>> sheet for this board?
>>> Simon
>> To the best of my knowledge, the ML507 board is identical in layout
>> and appearance with the ML505 board, since the 'LXT and 'FXT chips are
>> pin-compatible.
>> Let's see on Monday at work...
>> Peter Alfke
> 
> 
> Is that possible to have a customised ML523 board armed with Virtex5
> FXT instead of LXT?
> 
> Simon

The first units of the ML507 will be available in June and they will be
identical to the ML505 & ML506 boards except that they will use the new
XC5VFX70T-1CES devices, so get your PO and/or credit cards ready.

We will also be releasing ML52x boards with Virtex-5 FXT devices on
them, but this will not happen until late this year.  Your local System
I/O Specialist FAE has the new ML523-FXT boards in hand and should be
able to give you a demo earlier than the production release date.

Ed McGettigan
--
Xilinx Inc.

Article: 130990
Subject: Re: FPGA configuration mode on ML310
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 07 Apr 2008 19:32:15 -0600
Links: << >>  << T >>  << A >>
grant0920 wrote:
> Hi! everyone
> 
> I have a very basic problem. I know that the 6-position DIP switch on
> the ML403 board can control the configuration address and FPGA
> configuration mode. On the ML310 board, I am not sure where can set
> the FPGA configuration mode. I want to set the configuration mode of
> my ML310 borad as the SelectMAP mode. Please tell me how to set its
> FPGA configuration mode. Thanks very much!

This can't be done.  There is no support for SelectMAP configuration
on the ML310.

Ed McGettigan
--
Xilinx Inc.

Article: 130991
Subject: Avalon Bus <-> Wishbone Bus
From: benn <benn686@hotmail.com>
Date: Mon, 7 Apr 2008 20:15:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm pretty new to fpgas, but theres an i2c core on opencores.org that
I'd like to use in my Altera project.   I understand Wishbone is a
subset of Avalon, but what is involved in bridging these two together?

I'm assuming its not too trivial since I could buy an IP bridge that
does it from Men Micro, but what exactly is involved if I were to try
tackling this myself?

Thanks!

Article: 130992
Subject: Re: Avalon Bus <-> Wishbone Bus
From: "KJ" <kkjennings@sbcglobal.net>
Date: Tue, 8 Apr 2008 00:04:46 -0400
Links: << >>  << T >>  << A >>

"benn" <benn686@hotmail.com> wrote in message 
news:9778f926-8359-4310-a9bd-1ec3c9d0fabf@u36g2000prf.googlegroups.com...
> I'm pretty new to fpgas, but theres an i2c core on opencores.org that
> I'd like to use in my Altera project.   I understand Wishbone is a
> subset of Avalon, but what is involved in bridging these two together?
>

Not much, they have different names for the signals and that's most of the 
differences.  Functionally they are almost the same.

> I'm assuming its not too trivial since I could buy an IP bridge that
> does it from Men Micro, but what exactly is involved if I were to try
> tackling this myself?
>

Businesses are in business to sell, whether it's easy or hard doesn't 
matter, there is still $$ to be made.  To roll your own...

1. Take a look at the I2C core to see which types of transactions it handles 
(most likely it's a slave with only simple read and writes with a ready 
signal to hold things off).
2. Read through the Wishbone spec to get an understanding of the types of 
transactions that can be performed, but paying more attention to the subset 
of ones that the I2C core actually uses.
3. Repeat step 2 but reading the Avalon spec, making note of the 
differences.  As I mentioned at the start, you'll probably find that signal 
names are darn near the only differences.
4. Take a day or so and write the couple lines of code that it takes to 
create an entity/architecture that has Wishbone names on one side, Avalon on 
the other.  Write a testbench and see that it seems to work, hook up the I2C 
core to the Wishbone side and see if that works then start integrating the 
bridge and I2C core into your main design.

The water is not too deep in making such a bridge, 'specially when narrowing 
it down to a particular Wishbone component.  Once you've done it for one 
component, you'll probably find that it's also not too difficult to 
generalize the bridge to handle more generic Wishbone components and still 
you'll find that it's not terribly difficult.

Kevin Jennings 



Article: 130993
Subject: Re: Protecting design from being downloaded on other (similar) FPGA devices
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 8 Apr 2008 05:13:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-04-05, Antti <Antti.Lukats@googlemail.com> wrote:
> the OP wants COTS board to be used
> 1) with no mods to the board
> 2) with no additions to the board
>
> so adding anything isnt an option

One way to do this (which is somewhat based on security
through obscurity) would be to modify the BIOS on the
computer so that it writes some secret initialization
sequence to the FPGA to enable it. There are tools
available which allows you to easily insert or remove
an option ROM image into an AWARD base BIOS.

Of course, this will not buy you _real_ security. But
it is enough to make sure that someone will have to
spend some time to analyze what is really going on
in your device.

If you want to tighten things up further you could make
sure that the secret initialization sequence will
depend on a serial number present in the computer
(harddrive or DDR dimm for example). This will make things
much more complicated for you and might also annoy a
customer if they have more than one of your device and
for some reason want to exchange parts in it.

Otherwise, perhaps you could use a TPM module in some
way, but I don't know if that could work or not in
your case.

/Andreas

Article: 130994
Subject: Re: Avalon Bus <-> Wishbone Bus
From: Mark McDougall <markm@vl.com.au>
Date: Tue, 08 Apr 2008 15:16:45 +1000
Links: << >>  << T >>  << A >>
benn wrote:

> I'm pretty new to fpgas, but theres an i2c core on opencores.org that
> I'd like to use in my Altera project.   I understand Wishbone is a
> subset of Avalon, but what is involved in bridging these two together?

Completely and utterly trivial.

Indeed, if it weren't for the fact that the I2c core has an unsigned port 
you wouldn't need to do anything at all, but since it does you need a 
(very thin) wrapper that presents only std_logic(_vector) ports.

Then you create a component, and simply map each port in the component 
builder to the equivalent Avalon signal. The only one that isn't perhaps 
_immediately_ obvious is that ACK <=> waitrequest_n and BTW you map *both* 
cyc and stb to chipselect (and ignore the warning).

I also chose to hard-code the generic in my wrapper as well, thus not 
presenting it in the wrapper port map.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 130995
Subject: Re: Modify POF with new ESB (ROM) content?
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 01:01:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7 Apr., 23:29, radarman <jsham...@gmail.com> wrote:
> Hello,
> We have a design that has an embedded PIC processor that uses ESB's
> for instruction and data RAM. The target is an Altera APEX 20K100 with
> an EPC2 configuration PROM.
>
> What we would like to do is download the current POF from the
> configuration PROM and update the instruction ROM with an updated
> version. While this would be trivial to do going through the build
> system again, we aren't sure the Quartus project we have builds
> exactly what is in the EPC2 (hardware-wise). We got the code and
> project from the contractor who designed the firmware, but the
> firmware was done before revision control was in place, and no one
> knows what, exactly, got put into the revision control system.
>
> So, can you take a POF file from an EPC2 configuration memory and
> alter the ROM contents of the ESB's?
>
> Thanks!

NO

Altera is SO UTTERLY stupid in this regard.

a DATA2MEM (elf to bit file merge) is VERY important for softcore
processors in FPGA's, and Altera kinda claims they have NIOS and
stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their
toolchain!!

:(

Antti






Article: 130996
Subject: Re: Xilinx xilfatfs and systemACE speed issue
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 01:25:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7 Apr., 22:50, morphiend <morphi...@gmail.com> wrote:
> On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > I am trying to squeeze some read speed out from CF using systemACE and
> > xilinx standard libraries, but the performance is really really bad
>
> > read using xilfats 400KB/s
> > read using systemace low level (direct sector reads) 1MB/s
>
> > I have found NO information in any Xilinx documentation what speeds
> > can be excpected to be achived with systemACE
>
> > the 400KB/s looks like really miserable :(
>
> > i am using the CF card supplied by Xilinx, that is have not yet done
> > testbenching with other better CF cards, but i would like to know if
> > such testing has been done, and if there is hope of BIG speed
> > improvment when using some high-speed CF cards.
>
> > if i look at the spec of the CF card supplied by Xilinx it has 2ms
> > controller overhead (command to data ready delay) this would limit
> > access to maximum 500 sector reads commands sent to the CF, but we
> > need to add time for data transfer too, but this could explain the 1MB/
> > s measured speed
>
> > Antti
>
> We've noticed the same thing working with the sysace fs. The problem
> is the overhead from it is QUITE slow since its missing some essential
> features like a real seek(). My guess is that we're also seeing
> slowdown on the SystemACE controller in the FPGA. We're using the OPB-
> based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc
> for each operation that adds overhead to the bus. It probably also
> depends on what you're doing with the sysace files. We're reading
> ELF's from CF, and b/c there was no seek() there were tons of extra
> read()'s just to get to the intended part of the ELF, for loading.
>
> Currently, we're looking at using the dosfs, which I think you pointed
> a link to a few years back.
>
> -- Mike

Hi Mike

I tried my luck on Xilinx forums and there an Xilinx employee
suggested enableing burst mode in xps_sysace!
In EDK 9.2 and 10.1 the burst mode is hardcoded to 0 (disabled) and
explained as being 0 in the datasheet on page 9.

So while the Xilinx employee answer looked promising... HAA I invented
a new word !

XILOTEN

everyone is free to guess the meaning

Antti
PS Xilinx sorry, I have been saying that Xilinx systemACE is NOT
RECOMMENDED for new designs for years, now I just got another reason
why this is so.

Article: 130997
Subject: MIG/Corgen to XPS core insertion
From: xenix <lastval@gmail.com>
Date: Tue, 8 Apr 2008 01:42:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello all,
            I am creating at MIG a external DDR2 Memory controller.
Then i am trying to add this core to an XPS design. This controller i
want to be attached at the PLB bus. When i am going to import
peripheral from XPS my created core signals does not interface in
total number with the PLB's ones.

I would like to ask if there is a PDF or something similar explains
the step by step the process for  core insertion from coregen to an
XPS project.


regards
xenix

Article: 130998
Subject: Re: MIG/Corgen to XPS core insertion
From: xenix <lastval@gmail.com>
Date: Tue, 8 Apr 2008 01:43:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Forgot to say that i am using EDK  9.2


Article: 130999
Subject: Re: Modify POF with new ESB (ROM) content?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Tue, 08 Apr 2008 13:22:18 +0200
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@googlemail.com> writes:

> a DATA2MEM (elf to bit file merge) is VERY important for softcore
> processors in FPGA's, and Altera kinda claims they have NIOS and
> stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their
> toolchain!!

You can get the same functionality using 

quartus_cdb --update_mif

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?



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