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 98525

Article: 98525
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sun, 12 Mar 2006 10:07:11 -0500
Links: << >>  << T >>  << A >>
It can be useful.

Thank you.

Claude Sylvain
Electro-Technica inc.


"Kolja Sulimma" <news@sulimma.de> wrote in message 
news:4413e11b$0$12924$9b4e6d93@newsread4.arcor-online.net...
> Claude Sylvain schrieb:
>
>>     b) Build a custom program to read, interpret and program the .svf file 
>> into
>> the PROM, using the Microblaze CPU.
>
> There is a GPL licensed SVF player available:
> https://ssl.keshi.org/projects/logic/trac.fcgi/browser/openwince/current/jtag/README.svf
>
> Kolja Sulimma 



Article: 98526
Subject: Have webpack-81i running on grml Linux, rewrote ppcableIII jtag driver for Digilent to use direct io.
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Sun, 12 Mar 2006 15:16:38 GMT
Links: << >>  << T >>  << A >>
I got a Linux distro from  www.grml.org, and have the 8.1 webpack working on
it.
This is a small distro, and I think it should be possible to make one CD
with Linux and webpack as auto-run, but I only installed on harddisk (from CD
would be too slow for me).

Interesting is that I did not get the Xilinx GUI working in the install,
likely because I changed some stuff in grml, (removed X.org x server and
changed to XFree).

I moved to grml after I got pissed at all the ever increasing bloat from
Suse10. And yes I have the Redhat fedora too as many disks, but this grml is
only one CD.

So, as all characters in the Xilinx EULA were unreadable, I figured right
click button for NO on every question, and it installed itself anyways, so I
am free of Eula ;-) Thank you X.
Anyways, I copied some libs, (all .so), to /usr/local/lib/xilinx/, added that
path to /etc/ld.so.conf, then ran ldconfig.
Did export of XILINX from the zhs shell to env, and hey I can do the whole
project from scripts. (Without GUI).
The impact did not like my X3 par port cable , downloaded 2.6 drivers from X
website, still no go.
As the digilent lab board I use here at home to test, uses a par port cable
with JTAG, started writing jtag code, then found Mr Usselman already did that
for us.
But his did not work on my system, because I did not have the par port
modules and device.
So I rewrote his program for direct IO to the parport.
You can find it here (if you use digilent digilab board):
ftp://panteltje.com/pub/p3j.c
Compile with 
 gcc -Wall -O2 -o p3j p3j.c
tested on gcc-2.95, gcc-3.3, and gcc-4.0 (yes grml has all these).
Thank you Rudolf Usselmann.

Nothing is tested very much, maybe more later.





Article: 98527
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sun, 12 Mar 2006 10:44:16 -0500
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> wrote in message 
news:duv3bt$f4k$1@online.de...
> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
> news:5%DQf.5551$xM2.463864@news20.bellglobal.com...
>>I already found the BSDL description of the XCF02S PROM 
>>(http://www.xilinx.com/xlnx/xil_sw_updates_display.jsp?BV_UseBVCookie=yes&update=bsdl&software=PROMs).
>>
>> But, I was not knowing anything about SVF files.  That was the missing chain 
>> !
>>
>> Based on what I read in xapp503 
>> (http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf), the steps I will have 
>> to do are:
>>
>>    a) Convert the .bit configuration file to an .svf file, using iMPACT.
>>
>>    b) Build a custom program to read, interpret and program the .svf file 
>> into the PROM, using the Microblaze CPU.
>>
>>
>> I don't still know the time it takes to program a PROM row.  Maybe it is in 
>> the XCS02S BSDL file, and I have missed it.  Nervertless, it can be optained 
>> by doing iterative test.
>>
>>
>> Thank you for your help.  That's exactly the information I want.
>>
>> Claude Sylvain
>> Electro-Technica inc.
>>
>
> the timing is in SVF file if you look at it :)
> converting BIT to SVF makes real LARGE files,
> you are better to convert to XSVF, or depending your
> application just look at the SVF and implement the logic from there
> it isnt so complicated. most of the problems I had were related to
> special features of the XCF08P (parallel mode options) for XCF02s
> there should not be much magic required
>
> Antti
>


I think that it will need some time to assimilate all the knowledge necessary 
to make this job done.  But, I have no time constraint on this task, so it is 
not a problem.


Thank you again.

Claude Sylvain
Electro-Technica inc.






Article: 98528
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sun, 12 Mar 2006 11:31:05 -0500
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:duv3bt$f4k$1@online.de...
> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
> news:5%DQf.5551$xM2.463864@news20.bellglobal.com...
>
> the timing is in SVF file if you look at it :)
> converting BIT to SVF makes real LARGE files,
> you are better to convert to XSVF, or depending your
> application just look at the SVF and implement the logic from there
> it isnt so complicated. most of the problems I had were related to
> special features of the XCF08P (parallel mode options) for XCF02s
> there should not be much magic required
>
> Antti
>

Maybe the simpliest way to get the job done is to make a .svf file converter 
that convert a .svf file (that describe JTAG operation to program a PROM) in 
term of PROM row content; and use the row programming algorythm included in 
xapp544 to program each PROM row.

This way the file that hold PROM information to program appear exactly the same 
as a "standard" EPROM file that can be in S-Record or Intel Hex format.  This 
kind of file can be easily uploaded from an host computer to the Microblaze 
CPU.


Claude Sylvain
Electro-Technica inc.




Article: 98529
Subject: LEON processor core
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sun, 12 Mar 2006 17:53:09 +0100
Links: << >>  << T >>  << A >>
I'm wondering why there are so few messages about LEON [1]
in this group. LEON looks like a very solid design (used
by the ESA) and it is available in a GPL version.
Could be a vendor independent replacement of NIOS/MicroBlaze
with a path to an ASIC.
The configuration is done via a simple Tcl/Tk script and
the Makefile contains several targets. Works out-of-the-box
for available tragets. Adaption to a new FPGA board [2] took
me a few (some) hours - not so bad.

What's your experience?

Martin


[1] http://www.gaisler.com/cms4_5_3/index.php?option=com_content&task=view&id=13&Itemid=53

[2] http://www.jopdesign.com/nios.jsp 



Article: 98530
Subject: Re: Shift Register synthesis??
From: "nezhate" <mazouz.nezhate@gmail.com>
Date: 12 Mar 2006 08:55:03 -0800
Links: << >>  << T >>  << A >>
hi, I suggest you to see the XST user guide 8.1i (page 93) for more
details, there they say because of the reset, your shift register can't
be synthetised as Lut configured as shift register .


Article: 98531
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 12 Mar 2006 18:30:07 +0100
Links: << >>  << T >>  << A >>
"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
news:Z0YQf.121$ng.22466@news20.bellglobal.com...
>
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:duv3bt$f4k$1@online.de...
>> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
>> news:5%DQf.5551$xM2.463864@news20.bellglobal.com...
>>
>> the timing is in SVF file if you look at it :)
>> converting BIT to SVF makes real LARGE files,
>> you are better to convert to XSVF, or depending your
>> application just look at the SVF and implement the logic from there
>> it isnt so complicated. most of the problems I had were related to
>> special features of the XCF08P (parallel mode options) for XCF02s
>> there should not be much magic required
>>
>> Antti
>>
>
> Maybe the simpliest way to get the job done is to make a .svf file 
> converter that convert a .svf file (that describe JTAG operation to 
> program a PROM) in term of PROM row content; and use the row programming 
> algorythm included in xapp544 to program each PROM row.
>
> This way the file that hold PROM information to program appear exactly the 
> same as a "standard" EPROM file that can be in S-Record or Intel Hex 
> format.  This kind of file can be easily uploaded from an host computer to 
> the Microblaze CPU.
>
>
> Claude Sylvain
> Electro-Technica inc.
>

there is no need for that, just program the .BIT file into the PROM, then
write your own data after the bitstream data, no need to convert to svf

antti





Article: 98532
Subject: Re: LEON processor core
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 12 Mar 2006 18:32:12 +0100
Links: << >>  << T >>  << A >>
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:441451f8$0$11610$3b214f66@tunews.univie.ac.at...
> I'm wondering why there are so few messages about LEON [1]
> in this group. LEON looks like a very solid design (used
> by the ESA) and it is available in a GPL version.
> Could be a vendor independent replacement of NIOS/MicroBlaze
> with a path to an ASIC.
> The configuration is done via a simple Tcl/Tk script and
> the Makefile contains several targets. Works out-of-the-box
> for available tragets. Adaption to a new FPGA board [2] took
> me a few (some) hours - not so bad.
>
> What's your experience?
>
> Martin
>

2 hours is correct, that what it usually takes to port LEON to new hardware.

and the best thing is the LEON system can run FULL MMU enabled linux
in spartan3 or any other low cost FPGA!

Antti 



Article: 98533
Subject: Re: Combinatorial Division?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Mar 2006 09:34:04 -0800
Links: << >>  << T >>  << A >>
In the early 'sixties, there was the "torsional delay line" memory:
A long (>20 m) piece of wire, rolled up and carefully suspended in a
box, with transducers at either end that kicked a twist into the wire
and sensed it at the other end. The wire materiel was such that the
temperature coefficient of the sound-wave propagation speed exactly
compensated the expansion of the wire length.
We (Sweda Cash Registers in Sweden) tried to put all the memory for a
whole cash register in there (15000 bits). It is amazing how creative
one can get when storage is that scarce...
But we eventually gave up. (And I moved to the US in '66...)
Peter Alfke




Article: 98534
Subject: Re: LEON processor core
From: "Jerome" <nospam@nospam.fr>
Date: Sun, 12 Mar 2006 18:52:20 +0100
Links: << >>  << T >>  << A >>
Is it possible to use it without SRAM and only with SDRAM ?

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dv1lus$iaa$1@online.de...
> "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
> news:441451f8$0$11610$3b214f66@tunews.univie.ac.at...
>> I'm wondering why there are so few messages about LEON [1]
>> in this group. LEON looks like a very solid design (used
>> by the ESA) and it is available in a GPL version.
>> Could be a vendor independent replacement of NIOS/MicroBlaze
>> with a path to an ASIC.
>> The configuration is done via a simple Tcl/Tk script and
>> the Makefile contains several targets. Works out-of-the-box
>> for available tragets. Adaption to a new FPGA board [2] took
>> me a few (some) hours - not so bad.
>>
>> What's your experience?
>>
>> Martin
>>
>
> 2 hours is correct, that what it usually takes to port LEON to new 
> hardware.
>
> and the best thing is the LEON system can run FULL MMU enabled linux
> in spartan3 or any other low cost FPGA!
>
> Antti
> 



Article: 98535
Subject: Re: LEON processor core
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 12 Mar 2006 18:57:37 +0100
Links: << >>  << T >>  << A >>
"Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag 
news:44145fdd$0$13024$626a54ce@news.free.fr...
> Is it possible to use it without SRAM and only with SDRAM ?
>

well you need some initialized memory unless you are loading the sdram over 
jtag debugger

basically, yes if you have means to load your application or bootloader into 
sdram
there si no need for any other memories

antti 



Article: 98536
Subject: Re: LEON processor core
From: ziggy <ziggy@fakedaddress.com>
Date: Sun, 12 Mar 2006 18:00:47 GMT
Links: << >>  << T >>  << A >>
In article <441451f8$0$11610$3b214f66@tunews.univie.ac.at>,
 "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote:

> I'm wondering why there are so few messages about LEON [1]
> in this group. LEON looks like a very solid design (used
> by the ESA) and it is available in a GPL version.
> Could be a vendor independent replacement of NIOS/MicroBlaze
> with a path to an ASIC.
> The configuration is done via a simple Tcl/Tk script and
> the Makefile contains several targets. Works out-of-the-box
> for available tragets. Adaption to a new FPGA board [2] took
> me a few (some) hours - not so bad.
> 
> What's your experience?
> 
> Martin
> 
> 
> [1] 
> http://www.gaisler.com/cms4_5_3/index.php?option=com_content&task=view&id=13&I
> temid=53
> 
> [2] http://www.jopdesign.com/nios.jsp 

its got its own ( yahoo based ) news group.

And yes, its pretty cool.

Article: 98537
Subject: Re: Combinatorial Division?
From: austin <austin@xilinx.com>
Date: Sun, 12 Mar 2006 10:11:09 -0800
Links: << >>  << T >>  << A >>
Peter,

Or, how about the mercury column?  Again, storing bits by whacking the 
one end of a box filled with merury, and sensing it at the other end?

My favorite is the drum memory for the GR15 tube computer:  each 
instruction had the address of the next one.

That way it didn't matter what order they were in.  In fact dropping the 
deck of cards, and mixing them up sped up execution (a crude but 
effective interleave).

Austin

Article: 98538
Subject: Re: fpga to 5v ttl logic
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 13 Mar 2006 07:20:31 +1300
Links: << >>  << T >>  << A >>
Eric Smith wrote:

> metal <nospam@spaam.edu> writes:
> 
>> agree 100%
>> 
>> it is the FPGA makers who are awkward; not the supply voltage.
>> 
>> imho, fpga makers have dropped the ball, by totally ignoring the
>> enormous markets of various mixed-signal products; where 5v is VERY
>> common...along with generally noisy environments.
>> 
>> I have always been amazed that not a single fpga-maker has made a line
>> of small-to-medium sized parts targeted not for blazing speed and
>> monster computing functions; but rather, for 5v I/O, all
>> Schmitt-trigger inputs, and very low cost.
>> 
>> Imho, such a line would sell like hotcakes.  Instead of hard-silicon
>> MAC's and such, where are the hard-silicon counter/timer modules, etc.
>> ??
>> 
>> I'd love to be able to buy a $5 part with 64 or 128 flops, and a hard
>> block of 8 timer/counters (hardly any chip area in modern silicon).
>> I've got =dozens= of apps for such a part.
>> 
>> In any case, it's not the users who are mistaken about 5v; but rather,
>> the fpga-makers...who are ignoring the -reality- of -ongoing demand-
>> for it, instead of embracing it via a profitable targeted
>> product-line.
>> 
>> just m-h-o as one of those pesky 5v users, of course... <g>


> 
> A good MAC is fairly complicated, and as a soft MAC takes up lots of
> FPGA real estate, so it makes sense to stick one or two on the die of
> larger parts since it's then a fairly small percentage of the part.  Not
> all the customers benefit, but some benefit a lot, and the others aren't
> penalized much.
> 
> But counter-timers don't take up much room in an FPGA, so if you go to
> hardwiring those, you don't gain anything, and you lose tons of flexibility.
> Inevitably the features of the hardwired timer-counter would never be quite
> what you need for any given design.  There would be only a small penalty,
> but it would be borne by all customers.  Very few would get any advantage,
> and the advantage would be very modest.  The cost/benefit analysis is
> much worse than with a MAC.
> 
> If you want them to build some other hardwired logic into their FPGAs, you'll
> need to come up with a *much* better example than that.

  How about speed ?

  However, what metal was talking about, is a CPLD, not a FPGA.

He is looking at the bottom end of the spectrum.
Some vendors currently come close :

Atmel have low power, 5V parts in the ATF150x series.
Xilinx have the CoolRunner2, with the larger ones having a divider 
chain, but not 5V.

but right now, no one has the twin features of 5V Drive and Schmitt Pins.

-jg



Article: 98539
Subject: Re:Low Icc FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 13 Mar 2006 07:26:33 +1300
Links: << >>  << T >>  << A >>
Eric Smith wrote:

> "Antti" <Antti.Lukats@xilant.com> writes:
> 
>>nice accident !
>>at least we know that number 5 isnt skipped in the Virtex roadmap ;)
> 
> 
> Assuming that the Marketing department doesn't rename it before offical
> introduction.  Things like that sometimes happen.
> 
> Presumably the Virtex 5 (or whatever it's going to be called) is the
> 65 nm part mentioned in a recent Xilinx press release.

Would make sense.

> What I'd like to see on the roadmap would be some very-low-leakage
> Spartan parts, for use in battery powered devices.  They wouldn't need
> to be anywhere near as fast as the Spartan 2, nor as dense.  Maybe it
> could be done with thick oxide in 180, 250, or perhaps even 350 nm.
> Gotta do soemthing with all that excess fab capacity in older processes;
> might as well make low-leakage FPGAs.  :-)

I have a sample on the bench that draws 2.4uA, but it is not a Spartan 
FPGA... :)

-jg


Article: 98540
Subject: Re: Low Icc FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 13 Mar 2006 07:56:26 +1300
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Eric Smith wrote:
> 
>> "Antti" <Antti.Lukats@xilant.com> writes:
>>
>>> nice accident !
>>> at least we know that number 5 isnt skipped in the Virtex roadmap ;)
>>
>>
>>
>> Assuming that the Marketing department doesn't rename it before offical
>> introduction.  Things like that sometimes happen.
>>
>> Presumably the Virtex 5 (or whatever it's going to be called) is the
>> 65 nm part mentioned in a recent Xilinx press release.
> 
> 
> Would make sense.
> 
>> What I'd like to see on the roadmap would be some very-low-leakage
>> Spartan parts, for use in battery powered devices.  They wouldn't need
>> to be anywhere near as fast as the Spartan 2, nor as dense.  Maybe it
>> could be done with thick oxide in 180, 250, or perhaps even 350 nm.
>> Gotta do soemthing with all that excess fab capacity in older processes;
>> might as well make low-leakage FPGAs.  :-)
> 
> 
> I have a sample on the bench that draws 2.4uA, but it is not a Spartan 
> FPGA... :)

  I doubt anyone would be confused, but just in case, no, this is _not_ 
a Virtex-5 sample...

-jg


Article: 98541
Subject: Re: LEON processor core
From: "Jerome" <nospam@nospam.fr>
Date: Sun, 12 Mar 2006 20:11:03 +0100
Links: << >>  << T >>  << A >>
Ok but  my concern is about R/W cycles assuming i want to use SDRAM for code 
execution or data storage.
Acessing SRAM is only 2  cycles (adr / data )
But for SDRAM , event with smart sdram controller , it will take more , no ?

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dv1neh$l35$1@online.de...
> "Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag 
> news:44145fdd$0$13024$626a54ce@news.free.fr...
>> Is it possible to use it without SRAM and only with SDRAM ?
>>
>
> well you need some initialized memory unless you are loading the sdram 
> over jtag debugger
>
> basically, yes if you have means to load your application or bootloader 
> into sdram
> there si no need for any other memories
>
> antti
> 



Article: 98542
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sun, 12 Mar 2006 14:15:04 -0500
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dv1lqv$i60$1@online.de...
> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
> news:Z0YQf.121$ng.22466@news20.bellglobal.com...
>>
>> Maybe the simpliest way to get the job done is to make a .svf file converter 
>> that convert a .svf file (that describe JTAG operation to program a PROM) in 
>> term of PROM row content; and use the row programming algorythm included in 
>> xapp544 to program each PROM row.
>>
>> This way the file that hold PROM information to program appear exactly the 
>> same as a "standard" EPROM file that can be in S-Record or Intel Hex format. 
>> This kind of file can be easily uploaded from an host computer to the 
>> Microblaze CPU.
>>
>>
>> Claude Sylvain
>> Electro-Technica inc.
>>
>
> there is no need for that, just program the .BIT file into the PROM, then
> write your own data after the bitstream data, no need to convert to svf
>
> antti
>
>


Oh!  ok.

So simple, that I forgot that it can be done like that.

But it is not really the truth.  Some days ago, I read the first row on an 
XCF02S PROM, using xapp544 source code, and compare the values with the one 
found in the corresponding "download.bit" file.  Unfortunately, the values did 
not match.  Meaning that the "download.bit" file did not contain the "memory 
equivalent" of the PROM.

Maybe I done something wrong when doing this test !?
Maybe some simple translation have to be made.  Like inverting row bits, or 
something like that.

I will look for that.


Thank you again.

Claude Sylvain
Electro-Technica inc.





Article: 98543
Subject: Re: LEON processor core
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 12 Mar 2006 20:15:31 +0100
Links: << >>  << T >>  << A >>

"Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag 
news:44147254$0$13020$626a54ce@news.free.fr...
> Ok but  my concern is about R/W cycles assuming i want to use SDRAM for 
> code execution or data storage.
> Acessing SRAM is only 2  cycles (adr / data )
> But for SDRAM , event with smart sdram controller , it will take more , no 
> ?
>
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dv1neh$l35$1@online.de...
>> "Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag 
>> news:44145fdd$0$13024$626a54ce@news.free.fr...
>>> Is it possible to use it without SRAM and only with SDRAM ?
>>>
>>
>> well you need some initialized memory unless you are loading the sdram 
>> over jtag debugger
>>
>> basically, yes if you have means to load your application or bootloader 
>> into sdram
>> there si no need for any other memories
>>
>> antti
>>
>
>
thats almost always so that ext(sdram) accesses are way slower
cache helps to re-gain some cycles and improves performance

but as sw is getting larger and doesnt fit into onchip memory
so there are no options to use of sdram so if you can use
BRAMs for cache only

antti



Article: 98544
Subject: Re: LEON processor core
From: "Leon" <leon_heller@hotmail.com>
Date: 12 Mar 2006 11:25:58 -0800
Links: << >>  << T >>  << A >>

Martin Schoeberl wrote:
> I'm wondering why there are so few messages about LEON [1]
> in this group. LEON looks like a very solid design (used
> by the ESA) and it is available in a GPL version.
> Could be a vendor independent replacement of NIOS/MicroBlaze
> with a path to an ASIC.
> The configuration is done via a simple Tcl/Tk script and
> the Makefile contains several targets. Works out-of-the-box
> for available tragets. Adaption to a new FPGA board [2] took
> me a few (some) hours - not so bad.
>
> What's your experience?


I keep meaning to try it, seeing as I share my first name with it. 8-)

Leon


Article: 98545
Subject: Question about multi write ports RAM in FPGA?
From: "fpga" <hy34@njit.edu>
Date: 12 Mar 2006 11:49:30 -0800
Links: << >>  << T >>  << A >>
Hello,
Is that possible to make a multi write ports RAM(eg, a 512by32 RAM with
several read ports and several write ports) in FPGA by using
distributed RAM or block RAM? It is easy to implment a multi read
ports, one write port RAM in FPGA by usign the dual port block RAM. But
it seems it is impossible to implement a multi write ports RAM by usign
distribute or block RAM. Using D flip flop to implement the multi ports
RAM will costs too much resource.
Is there any suggestion to implement the multi write ports RAM in FPGA?
Thanks a lot.


Article: 98546
Subject: Re: Question about multi write ports RAM in FPGA?
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 12 Mar 2006 12:11:45 -0800
Links: << >>  << T >>  << A >>

fpga wrote:
> Hello,
> Is that possible to make a multi write ports RAM in FPGA by using
> distributed RAM or block RAM? It seems impossible to me. But using D
> flip flop to implement the multi ports RAM will costs too much resouce.
> Is there any suggestion to implement the multi write ports RAM in FPGA?
> Thanks a lot.

Xilinx has dual ported block RAM. In which both ports (I believe) can
do simultaneous writes.

If you want more ports than that then you may have to use time
multiplexing.

--------------------------------------------------------------------------------------------------------------
I am an EE student looking for summer employment in Toronto, Canada
area
If you have any openings please contact me at isaacb[AT]rogers[DOT]com.


Article: 98547
Subject: Re: Combinatorial Division?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Mar 2006 12:17:48 -0800
Links: << >>  << T >>  << A >>
The mercury delay lines were earlier, and were used only in
"mainframes" of that day. Who wants to have a pot full of mercury
sloshing around in a cash register? But this was before environmental
concerns, when leaded gasoline was the best thing ever...

Did anybody mention the Williams tube? A CRT where you wrote to and
read from the tube face.
 It got killed by the early core memories, which in turn lived much
longer than anybody had expected. Non-volatile storage with destructive
read-out, just the opposite of SRAM nowadays.
Peter
Peter


Article: 98548
Subject: Re: Question about multi write ports RAM in FPGA?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Mar 2006 12:25:02 -0800
Links: << >>  << T >>  << A >>
Good catch, Isaac, you beat me to it.
Yes, BlockRAMs can write from both ports simultaneously, and the write
enable input can change from write to read on every clock tick.
Interestingly, ever write also performs a read of the same location,
either read-before-write or write-before-read. The former is more
useful.
For additional ports, use time multiplexing.
Peter Alfke


Article: 98549
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 12 Mar 2006 21:36:48 +0100
Links: << >>  << T >>  << A >>
"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
news:Iq_Qf.488$ng.39085@news20.bellglobal.com...
>
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dv1lqv$i60$1@online.de...
>> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
>> news:Z0YQf.121$ng.22466@news20.bellglobal.com...
>>>
>>> Maybe the simpliest way to get the job done is to make a .svf file 
>>> converter that convert a .svf file (that describe JTAG operation to 
>>> program a PROM) in term of PROM row content; and use the row programming 
>>> algorythm included in xapp544 to program each PROM row.
>>>
>>> This way the file that hold PROM information to program appear exactly 
>>> the same as a "standard" EPROM file that can be in S-Record or Intel Hex 
>>> format. This kind of file can be easily uploaded from an host computer 
>>> to the Microblaze CPU.
>>>
>>>
>>> Claude Sylvain
>>> Electro-Technica inc.
>>>
>>
>> there is no need for that, just program the .BIT file into the PROM, then
>> write your own data after the bitstream data, no need to convert to svf
>>
>> antti
>>
> Oh!  ok.
>
> So simple, that I forgot that it can be done like that.
>
> But it is not really the truth.  Some days ago, I read the first row on an 
> XCF02S PROM, using xapp544 source code, and compare the values with the 
> one found in the corresponding "download.bit" file.  Unfortunately, the 
> values did not match.  Meaning that the "download.bit" file did not 
> contain the "memory equivalent" of the PROM.
>
> Maybe I done something wrong when doing this test !?
> Maybe some simple translation have to be made.  Like inverting row bits, 
> or something like that.
>
> I will look for that.
>
>
> Thank you again.
>
> Claude Sylvain
> Electro-Technica inc.

if you read first locations - raw data !! out of xcf0xs that holds a valid 
bitstream
then you must see
ff ff ff ff 99 66 aa 55
or something alike the bit order may be reversed in the bytes

I said .bit file, well a bit file can be programmed as is, eg included the 
text header
as it want hurt, but you may strip anything before the ff ff ff ff <

xapp544 tries to use the free platform flash area as read-write eeprom so it
adds some special flags to rows to mark then free or dirty,
if you are looking for bitstream data then you need to check the plain raw 
readback
data from platform flash, it really really does containt the bitstream with 
no magic
applied, you can consider the platfrom flash as normal serial memory that 
can
be read and written using custom jtag instructions

antti











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