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 78800

Article: 78800
Subject: BFM Basics
From: kedarpapte@gmail.com (Kedar P. Apte)
Date: 8 Feb 2005 03:07:54 -0800
Links: << >>  << T >>  << A >>
Hello All,

I want to learn more about BFMs.
Can anybody tell me some guidelines or some documents available on
basics of Bus Functional Models. like
what a BFM should contain.? block level design.
etc. etc

Please suggest me some good documentation also if it is there.

Thanks in Advance

Kedar

Article: 78801
Subject: Re: SimmStick FPGA module
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 08 Feb 2005 11:08:23 GMT
Links: << >>  << T >>  << A >>
Hi Antti,

>
> Nice to see that some of my project are still live - I am the "inventor" of
> the "SimmStick(tm)" standard :)

Sorry, I should have given the credits to you!
BTW.: Is this format still alive?

>> CPU design. Here is the suggested part list:
>>
>>     FPGA: Cyclone EP1C3 or Spartan XC3S200
>>     256Kx16 15ns SRAM
> -- here I would like to argue a lot!
> I understand that JOP runs ok in that memory, but... all the rest  (if using
> XC3S200) is uCLinux ready, except memory is not enough, so I would use 1
> 16bit SDRAM chip, not SRAM
> XC3S200 is large enough to hold ucLinux ready MicroBlaze setup.

However, SRAM is way much simpler to handle. I think SDRAM is a pain.

>>     2 MBit serial Flash
> -- again the 2MBit is enough for config, not for OS image, so if there would
> be some means of having more, that would be nice, sure thats an price issue

Could be an option. However, handling options are a pain in the manufacturing.

>>     3.3V linear regulation
>>     switching regulator for the core voltage
> for a small FPGA linear regulator is ok, too cheaper sure burns more energy,
> Trenz S3-1000 module as example has small linear regulator supplying max
> 0.9A for core

The 3.3V linear regulation is only for the IO. The core voltage gets a switching
regulator. If you are using this module in a 3.3V SimmStick bus you can go
without the linear regulation on board (will be a sloder jumper)

>>     20MHz clock to the PLL input
> NEEDED 5V compliance quickswitches !!!
> all new FPGAs are not 5V tolerant and for both mech standards simmstick and
> stamp 5V compliance is highly recommended to have, its a pain for
> manufacturer but a big + for the user

That's again pain. I was thinking about being not 5V compliant. It's time to stop
these 5V designs! Or, add series resistors - bad for the bandwidth.

>>
>> I've not yet decided about a X or A device.
>
> hard decision hugh?
> answer is simple. BOTH
> it doesnt cost so much more todo both variants, you may supply more support
> for either A or X as of your preferences (or customer interest) but from the
> hardware build expenses its even cheaper (per board) to order a combined pcb
> patch

I don't think it's possible to build one pcb for both. I want the module to be small.
As small as the 9 part SIMMs (79mm x 21mm).

>> 2.) The 'Basic Stamp' design is a board in the form of an old 40-pin (or
> less) DIL IC.
>>     An example (from a Java processor competitor): [2]
>
> You mean Parallax or those other guys? There are actually several stamp like
> clones thing.
> the stamp form factor is more challenging as the pcb are is very constrained
> :(

Yes, I would need parts on both sides of the pcb. However, it's only a little bit
more expensive in the manufacturing.

>
>> One nice thing about the SimmStick is that there are plenty of I/O boards
> already available
>> (see [4, 5, 6]).
>> It seems a relative 'old' design, but it's a bus and I can build my first
> JOP cluster with those
>> boards ;-)
>
> hm if you make the simmstick form factor board, here is a deal - I will
> donate all my leftover simmStick stuff that includes some connectors and
> protoboards etc, you can use all those boards and stuff as promotional bonus
> give away for the early customers :)

That's a deal :-) However, it's an indication that you don't buy ino the bus anymore.

>
>> What do you guys think about this idea? Does it make sense to build a
> another FPGA board?
>
> hm.. I just recently looked at the parallax pricing.. still selling basic
> interpreter for $49 (or more!) and still doing business. highend stamp are
> in $99 range! So a fpga plugin module in $99 range, sure it might be
> business idea still
>
Probably will give it a try.

Martin



Article: 78802
Subject: Re: Retaining not used nodes
From: mk<kal*@dspia.*comdelete>
Date: Tue, 08 Feb 2005 11:09:51 GMT
Links: << >>  << T >>  << A >>
On 8 Feb 2005 02:43:57 -0800, ALuPin@web.de (ALuPin) wrote:

>Hi,
>
>I have several nodes in my design (registered nodes) which do not have
>a "driving" purpose. But for later use of SignalTap (Altera tool to
>make internal FPGA nodes visible) I do want the synthesizer
>not to optimize these nodes away. On the other hand I do not want
>to route these nodes to output pins because of a limited amount of
>available pins.
>
>Is there some possibility to avoid that these registerd not used nodes
>are optimized away ?
>
>Thank you for your suggestion.
>
>Rgds
>André

There are synthesis pragmas which you can use to keep these registers
(syn_keep for synplicity etc.). If you have too much difficulty
convincing either the synthesizer or the mapper to keep these unused
registers, you can "or" the outputs of multiple registers and route it
to a single output pin which should vastly reduce your pin
availability concerns.


Article: 78803
Subject: Re: SimmStick FPGA module
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 12:22:39 +0100
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <martin.schoeberl@chello.at> schrieb im Newsbeitrag
news:H41Od.35105$2e4.21398@news.chello.at...
> Hi Antti,
>
> >
> > Nice to see that some of my project are still live - I am the "inventor"
of
> > the "SimmStick(tm)" standard :)
>
> Sorry, I should have given the credits to you!
> BTW.: Is this format still alive?

no problem.
hm alive I think yes, I a havent be doing much (read anything) for years but
there are still products around

> >> CPU design. Here is the suggested part list:
> >>
> >>     FPGA: Cyclone EP1C3 or Spartan XC3S200
> >>     256Kx16 15ns SRAM
> > -- here I would like to argue a lot!
> > I understand that JOP runs ok in that memory, but... all the rest  (if
using
> > XC3S200) is uCLinux ready, except memory is not enough, so I would use 1
> > 16bit SDRAM chip, not SRAM
> > XC3S200 is large enough to hold ucLinux ready MicroBlaze setup.
>
> However, SRAM is way much simpler to handle. I think SDRAM is a pain.
yes no, once the SDRAM controller is once configured it works, but agree
from the
ip core side its more painful, still 4MByte of onboard RAM would just GREAT!

hm I think it is possible to make a layout for either 54TSOP sdram and SRAM
(that would be beneath it) please consider..
that would be a mount option, :( but well I would consider.
I have several FGPA boards with 0.5MB RAM, and all of those are
"bad" as they can not boot linux :(
hm I have 40 PCS of those SDRAM overleft  in cut tape, again if there is
place to solder them those are yours for the project...

> >>     2 MBit serial Flash
> > -- again the 2MBit is enough for config, not for OS image, so if there
would
> > be some means of having more, that would be nice, sure thats an price
issue
>
> Could be an option. However, handling options are a pain in the
manufacturing.
yes I, know the manufacturing options are pain, its a mistake I have done
and
learned as well, I wanted the first simmstick so be cheap and flexible by
providing
lots of mounting options, that was bad actually would have been better to
add it all and sell a bit higher

> >>     3.3V linear regulation
> >>     switching regulator for the core voltage
> > for a small FPGA linear regulator is ok, too cheaper sure burns more
energy,
> > Trenz S3-1000 module as example has small linear regulator supplying max
> > 0.9A for core
>
> The 3.3V linear regulation is only for the IO. The core voltage gets a
switching
> regulator. If you are using this module in a 3.3V SimmStick bus you can go
> without the linear regulation on board (will be a sloder jumper)

hm ok, besides for spartan at least 2.5V is also needed !! even if 2.5 ios
are not used that an additional small regulator :(

> >>     20MHz clock to the PLL input
> > NEEDED 5V compliance quickswitches !!!
> > all new FPGAs are not 5V tolerant and for both mech standards simmstick
and
> > stamp 5V compliance is highly recommended to have, its a pain for
> > manufacturer but a big + for the user
>
> That's again pain. I was thinking about being not 5V compliant. It's time
to stop
> these 5V designs! Or, add series resistors - bad for the bandwidth.
yes pain, would be so much easier to go only by 3.3 or 2.5

> >>
> >> I've not yet decided about a X or A device.
> >
> > hard decision hugh?
> > answer is simple. BOTH
> > it doesnt cost so much more todo both variants, you may supply more
support
> > for either A or X as of your preferences (or customer interest) but from
the
> > hardware build expenses its even cheaper (per board) to order a combined
pcb
> > patch
>
> I don't think it's possible to build one pcb for both. I want the module
to be small.
> As small as the 9 part SIMMs (79mm x 21mm).

yes that should be the small board, I meant to produce two different
boards!!
(not one that can be used with both FPGAs)
each time you order PCB so you always get both X and A, if there comes
big overleft of X or A boards you can etiher sell away the remaining plain
PCB or then order the best seller as separate PCB

> >> 2.) The 'Basic Stamp' design is a board in the form of an old 40-pin
(or
> > less) DIL IC.
> >>     An example (from a Java processor competitor): [2]
> >
> > You mean Parallax or those other guys? There are actually several stamp
like
> > clones thing.
> > the stamp form factor is more challenging as the pcb are is very
constrained
> > :(
>
> Yes, I would need parts on both sides of the pcb. However, it's only a
little bit
> more expensive in the manufacturing.

depends how much you squeeze and what production quantities are.

The original STAMP in DIP28 where partially hand made, the Parallax
people had a barbeque at behind the office and a tin-pot in the middle so
they had a party and at the same time soldered those DIP pins to the
stamp modules - that also in large numbers. I think they dont have those
BBQ anymore but for the long time this was the procedure.
ah old good days ;)

> >> One nice thing about the SimmStick is that there are plenty of I/O
boards
> > already available
> >> (see [4, 5, 6]).
> >> It seems a relative 'old' design, but it's a bus and I can build my
first
> > JOP cluster with those
> >> boards ;-)
> >
> > hm if you make the simmstick form factor board, here is a deal - I will
> > donate all my leftover simmStick stuff that includes some connectors and
> > protoboards etc, you can use all those boards and stuff as promotional
bonus
> > give away for the early customers :)
>
> That's a deal :-) However, it's an indication that you don't buy ino the
bus anymore.

not necessarily - I have been occupied.
http://www.case2000.com/gallery/album01
some older pictures of family (part of it) there are now 3 kids.
Anna youngest is 1y3months. sick right now :(

> >
> >> What do you guys think about this idea? Does it make sense to build a
> > another FPGA board?
> >
> > hm.. I just recently looked at the parallax pricing.. still selling
basic
> > interpreter for $49 (or more!) and still doing business. highend stamp
are
> > in $99 range! So a fpga plugin module in $99 range, sure it might be
> > business idea still
> >
> Probably will give it a try.
>
> Martin

Good luck, and I see what support I can give on the way, there are some
ideas
for SimmStick that I did not realize, maybe its time for them to become
true.




Article: 78804
Subject: Microblaze and Picoblaze
From: usrdr@yahoo.co.uk
Date: 8 Feb 2005 03:45:18 -0800
Links: << >>  << T >>  << A >>
Hi Everybody,
I wonder some thing about microblaze and picoblaze.
*I must buy some tools for use microblaze or picoblaze? I think I must
buy Xilinx EDK for microblaze.
*EDK includes C/C++ compiler? or any?
*There are advantages at Debugging?
*If I use microblaze, FPGA'll be only processor? or I can write built
in USB, ethernet etc.?
*If I use Microblaze I must use only Virtex or Spartan 3?

thanks in advance


Article: 78805
Subject: Re: Microblaze and Picoblaze
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 12:47:04 +0100
Links: << >>  << T >>  << A >>

<usrdr@yahoo.co.uk> schrieb im Newsbeitrag
news:1107863118.391417.303930@l41g2000cwc.googlegroups.com...
> Hi Everybody,
> I wonder some thing about microblaze and picoblaze.
> *I must buy some tools for use microblaze or picoblaze? I think I must
> buy Xilinx EDK for microblaze.
yes EDK includes microblaze license + many free ip cores...
picoblaze is free but requires registration at xilinx web
pacoblaze is open source picoblaze compatible core

> *EDK includes C/C++ compiler? or any?
EDK includes many things, also C compiler.
the C compiler is GPL licensed so you can have it for free too

> *There are advantages at Debugging?
EDK includes debug support

> *If I use microblaze, FPGA'll be only processor? or I can write built
> in USB, ethernet etc.?
you can build in whatever you want.

> *If I use Microblaze I must use only Virtex or Spartan 3?
xilinx microblaze can be used on s2 s3 and any virtex
the open source microblaze (aeMB from opencores) can be used with any FPGA
> thanks in advance
>



Article: 78806
Subject: Re: warning messages,NgdBuild:454,DesignRules:331
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Tue, 08 Feb 2005 13:17:44 +0100
Links: << >>  << T >>  << A >>
Jack wrote:
> In my case,  the application does not behave as expected. So I am
> thinking that the
> 
>  WARNING:DesignRules:331
> 
> message might be a problem...
> 

This is not a problem.
In order to have a register file with one write port and two read port, the 
RAM32x1d primitive is duplicated.
I write the same data into both copies of the register file.
I can then have two separate read ports using the read only ports on each of the 
copy.
Since I only need one SPO output, the other one is left unconnected.
This is what the warning reports.

Göran

Article: 78807
Subject: Re: SimmStick FPGA module
From: Kolja Sulimma <news@sulimma.de>
Date: Tue, 08 Feb 2005 13:35:06 +0100
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> Hi all,
> 
> I'm thinking about a new board for JOP (or MB, NIOS). The board should be small and
> cheap (below the S3 Starter Kit). It should only contain the absolute necessary parts for a
> CPU design. Here is the suggested part list:
> 
>     FPGA: Cyclone EP1C3 or Spartan XC3S200
>     256Kx16 15ns SRAM
>     2 MBit serial Flash
>     3.3V linear regulation
>     switching regulator for the core voltage
>     20MHz clock to the PLL input
[..]
> What do you guys think about this idea? Does it make sense to build a another FPGA board?

What you describe is essentially our Micromodule minus USB plus SRAM.
http://www.trenz-electronic.de/prod/proden18.htm

If you can live with our form factor we could collaborate on a version 
with sram instead of usb.

For a cluster you can build a stack of these boards.

However I doubt that it makes sense to have boards that are so similar.

Kolja Sulimma




Article: 78808
Subject: Re: SimmStick FPGA module
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 13:46:07 +0100
Links: << >>  << T >>  << A >>

"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag
news:4208b1e6$0$810$9b4e6d93@newsread2.arcor-online.net...
> Martin Schoeberl wrote:
> > Hi all,

[snip]
> What you describe is essentially our Micromodule minus USB plus SRAM.
> http://www.trenz-electronic.de/prod/proden18.htm
>
> If you can live with our form factor we could collaborate on a version
> with sram instead of usb.

Hi Kolja

the cheapest mm with XC3S200 is 114.84EUR add 5 EUR for the special
connectors, then you would need to always make a custom PCB with those 0.8mm
headers that adds up price. A simmstick can be plugged into solderless
breadboard or any 0.1 proto board and requires no special connectors, so its
a little bit of different in the use. If the fgpa-simmstick is sub 99USD
then, well there is room for everybody on this planet. :)

the micromodules are nice too of course !
Antti
PS I am little disappointed in the designer of the RetroBB for the trenz
micomodules, the delta sigma AD DA circuitry, there are some very important
caps and resistors missing... for sound applicaiton the input should be AC
coupled and comparator biased with vcc/2 and the output again should be AC
decoupled (well thats not so big mistake, but still it isnt nice to feed 2V
DC into headphones..) I think the circuitry is 1:1 copied from Xilinx
appnote without thinking. Sometimes thinking is good, even I consider that
as heavy physcial work (to be minized if possible). Sorry - I was really
terrified when I looked at the retroBB schematics!












Article: 78809
Subject: Re: SimmStick FPGA module
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Tue, 8 Feb 2005 12:50:18 -0000
Links: << >>  << T >>  << A >>
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message 
news:H41Od.35105$2e4.21398@news.chello.at...
> Hi Antti,
>
>>
>> Nice to see that some of my project are still live - I am the "inventor" 
>> of
>> the "SimmStick(tm)" standard :)
>
> Sorry, I should have given the credits to you!
> BTW.: Is this format still alive?


Dontronics sells a range of SIMMsticks:

http://www.dontronics.com/cat_index_hard.html

Leon



Article: 78810
Subject: Input Timing Specification
From: tb_news@arcor.de (Thomas)
Date: 8 Feb 2005 05:28:19 -0800
Links: << >>  << T >>  << A >>
Hi all,

I have a signal that is valid 2 ns before the active clock edge
and stays valid until 5 ns after the active clock edge.
Is there a possibilty to put this constraint into
the ucf file?

any hints are welcome

Thomas

Article: 78811
Subject: Re: SimmStick FPGA module
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Tue, 08 Feb 2005 15:08:44 +0100
Links: << >>  << T >>  << A >>
Hi

Just my 2cents ...


> However, SRAM is way much simpler to handle. I think SDRAM is a pain.

SDRAM is not that hard and having a lot more capacity is a big plus IMHO, that
worth the extra work.

 
> The 3.3V linear regulation is only for the IO. The core voltage gets a switching
> regulator. If you are using this module in a 3.3V SimmStick bus you can go
> without the linear regulation on board (will be a sloder jumper)

Have a look at
http://focus.ti.com/lit/ds/symlink/tps75003.pdf

Really nice little chip ;)


>>>    20MHz clock to the PLL input

If there is a spare centimeter square, adding an unpopulated space for another
XTAL maybe.


>>NEEDED 5V compliance quickswitches !!!
>>all new FPGAs are not 5V tolerant and for both mech standards simmstick and
>>stamp 5V compliance is highly recommended to have, its a pain for
>>manufacturer but a big + for the user
> 
> 
> That's again pain. I was thinking about being not 5V compliant. It's time to stop
> these 5V designs! Or, add series resistors - bad for the bandwidth.

I agree. 5V compliance shouldn't be necessary ... If you need it, just do it in the
board you're plugging this module into.


Other remarks : 
Having a few I/Os routed as differential pair to the connector could be nice




Sylvain

Article: 78812
Subject: Re: opb_ddr connection to DDR chips
From: Sean Durkin <smd@despammed.com>
Date: Tue, 08 Feb 2005 15:11:46 +0100
Links: << >>  << T >>  << A >>
Sylvain Munaut wrote:
> Hello
> 
> I'm planning to do a microblaze design using external DDR memory using 
> the opb_ddr
> core. However I'd like to know if there is any constraints on how to 
> connect
> (which banks/pins ...) the DDR chip. Here I only have 1 point to point 
> connection
> of a 16 bits wide DDR.
> 
> I was planning on using two banks for all the DQS/DQM/DQ then another 
> bank for the
> control & address signals.
> 
> I haven't seen much info about that in the opb_ddr doc. But on DDR 
> interface appnotes,
> some have specific constrainst so I prefer to ask before making the 
> board ;)
There's several things to consider: First, you can't put DQS signals and 
DQ-signals in the same IO-tiles, because they use different clocks and 
there can only be one clock per tile for the IO-registers. That's one 
thing I stumbled upon in the past...

Second, the plb_ddr-controller from EDK3.2 (don't know if this applies 
to the opb_ddr in EDK6.X) suggested a clock feedback path, i.e. a 
separate trace feeding the clock sent to the DDR back into the FPGA. 
They use that to determine how to compensate for PCB routing delays. If 
you don't have that, you'll probably have to waste a DCM and do some 
fiddling around to figure out the correct phase shifts and such.

Third, remember that DDR-SDRAM has a MINIMAL clock rate at which it can 
operate. With the myriad of different manufacturers, types and 
speedgrades of SDRAM-chps available you should look out not to 
accidentally get a chip that doesn't run as "slow" as your controller.

If you're planning to use high clock rates, Xilinx recommends you use 
local clocks for the DQS signals, and then you'd have to use specific 
pins for the corresponding data signals. In Xilinx' Memory Corner you 
can download a "Memory Interface Generator" that can help with the pin 
assignments.

Other than that, the DDR-chip probably uses SSTL2, which means you have 
to hook up all the Vref-pins to 1,25V, so they are not available to use 
as I/Os. Termination is an issue as well, so you should connect the 
VRN/VRP-pins as well to be able to use the DCIs for termination. 
Depending on the board layout it might be neccessary to use series 
resistors and/or pullups at the DDR chip as well.

cu,
Sean

Article: 78813
Subject: Re: Retaining not used nodes
From: "Christos" <chris_saturnNOSPAM@hotmail.com>
Date: Tue, 8 Feb 2005 15:27:26 +0100
Links: << >>  << T >>  << A >>
Hi,

One thing that might work is to drive them to outputs and then define those
outputs as virtual pins with the assignment editor.
They will not be synthesised away.

hope this helps.

Christos Zamantzas

"mk" <kal*@dspia.*comdelete> wrote in message
news:ro7h01dckpv186f6el2cn8vjus11s1vvbb@4ax.com...
> On 8 Feb 2005 02:43:57 -0800, ALuPin@web.de (ALuPin) wrote:
>
> >Hi,
> >
> >I have several nodes in my design (registered nodes) which do not have
> >a "driving" purpose. But for later use of SignalTap (Altera tool to
> >make internal FPGA nodes visible) I do want the synthesizer
> >not to optimize these nodes away. On the other hand I do not want
> >to route these nodes to output pins because of a limited amount of
> >available pins.
> >
> >Is there some possibility to avoid that these registerd not used nodes
> >are optimized away ?
> >
> >Thank you for your suggestion.
> >
> >Rgds
> >André
>
> There are synthesis pragmas which you can use to keep these registers
> (syn_keep for synplicity etc.). If you have too much difficulty
> convincing either the synthesizer or the mapper to keep these unused
> registers, you can "or" the outputs of multiple registers and route it
> to a single output pin which should vastly reduce your pin
> availability concerns.
>



Article: 78814
Subject: Re: SimmStick FPGA module
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 15:37:22 +0100
Links: << >>  << T >>  << A >>
"Laurent Gauch" <laurent.gauch@DELETEALLCAPSamontec.com> schrieb im
Newsbeitrag news:4208CF2C.6010504@DELETEALLCAPSamontec.com...
> Kolja Sulimma wrote:
> > Martin Schoeberl wrote:

> What is the use of the finger connector on Micromodule
>
> Larry
HAHA its duplicate of your favorite interface JTAG!
Need to get piece of old floppy connector and saw it in pieces!

Antti



Article: 78815
Subject: Re: SimmStick FPGA module
From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com>
Date: Tue, 08 Feb 2005 15:39:40 +0100
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> Martin Schoeberl wrote:
> 
>> Hi all,
>>
>> I'm thinking about a new board for JOP (or MB, NIOS). The board should 
>> be small and
>> cheap (below the S3 Starter Kit). It should only contain the absolute 
>> necessary parts for a
>> CPU design. Here is the suggested part list:
>>
>>     FPGA: Cyclone EP1C3 or Spartan XC3S200
>>     256Kx16 15ns SRAM
>>     2 MBit serial Flash
>>     3.3V linear regulation
>>     switching regulator for the core voltage
>>     20MHz clock to the PLL input
> 
> [..]
> 
>> What do you guys think about this idea? Does it make sense to build a 
>> another FPGA board?
> 
> 
> What you describe is essentially our Micromodule minus USB plus SRAM.
> http://www.trenz-electronic.de/prod/proden18.htm
> 
> If you can live with our form factor we could collaborate on a version 
> with sram instead of usb.
> 
> For a cluster you can build a stack of these boards.
> 
> However I doubt that it makes sense to have boards that are so similar.
> 
> Kolja Sulimma
> 
> 
> 

What is the use of the finger connector on Micromodule

Larry
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable.  Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
----  See http://netwinsite.com/sponsor/sponsor_surgemail.htm  ----

Article: 78816
Subject: Re: V4LX25-ES and systemACE
From: "newman5382" <newman5382@yahoo.com>
Date: Tue, 08 Feb 2005 14:59:09 GMT
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:cua695$on8$01$1@news.t-online.com...
> Hi
>
> has any one some hints or tips how to get an Virtex4 LX25-ES configured 
> from
> SystemACE?
> we can configure from iMpact and if we load the uclinux kernel from XMD it
> works too.
> but now when I try to load the uclinux image from CompactFlash then there
> are problems
> if the FPGA is configured by impact then there will always be random 
> sector
> read errors
> when attempting to load the image.bin from CompactFlash. On ML300 I had to
> load from
> CF in order to access the CF, but with V4LX the FPGA config from
> CompactFlash doesnt
> seem to work, the status led blinks once and then the error led goes on. I
> assume it is the TDO

I get this symptom with a V2Pro board.  When I load the compact flash with 
the bit, bmm, and elf file.  When I just load the bit file into the compact 
flash, I get same symptom you get.  Also, the error reg in the sysace has a 
value of 0x000000C0 after the error LED goes on.  This doesn't solve your 
problem, but is another point of data.

regards,
-Newman

> tristate problem with -ES samples, but...
>
> ML401 has systemACE as well and that works! So whats the trick ??
>
> Antti
>
> 



Article: 78817
Subject: Re: BFM Basics
From: "newman5382" <newman5382@yahoo.com>
Date: Tue, 08 Feb 2005 15:02:37 GMT
Links: << >>  << T >>  << A >>
One source of refernece is :

Writing Testbenches
Functional Verification of HDL Models
by Janick Bergeron

-Newman

"Kedar P. Apte" <kedarpapte@gmail.com> wrote in message 
news:f37647e6.0502080307.49ae1b6c@posting.google.com...
> Hello All,
>
> I want to learn more about BFMs.
> Can anybody tell me some guidelines or some documents available on
> basics of Bus Functional Models. like
> what a BFM should contain.? block level design.
> etc. etc
>
> Please suggest me some good documentation also if it is there.
>
> Thanks in Advance
>
> Kedar 



Article: 78818
Subject: Re: V4LX25-ES and systemACE
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 16:07:23 +0100
Links: << >>  << T >>  << A >>
"newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag
news:1t4Od.15793$qB6.2868@tornado.tampabay.rr.com...
>
> "Antti Lukats" <antti@openchip.org> wrote in message
> news:cua695$on8$01$1@news.t-online.com...
> > Hi
> >
> > has any one some hints or tips how to get an Virtex4 LX25-ES configured
> > from
> > SystemACE?
> > we can configure from iMpact and if we load the uclinux kernel from XMD
it
> > works too.
> > but now when I try to load the uclinux image from CompactFlash then
there
> > are problems
> > if the FPGA is configured by impact then there will always be random
> > sector
> > read errors
> > when attempting to load the image.bin from CompactFlash. On ML300 I had
to
> > load from
> > CF in order to access the CF, but with V4LX the FPGA config from
> > CompactFlash doesnt
> > seem to work, the status led blinks once and then the error led goes on.
I
> > assume it is the TDO
>
> I get this symptom with a V2Pro board.  When I load the compact flash with
> the bit, bmm, and elf file.  When I just load the bit file into the
compact
how?
you mean when the bit file in the ACE file containts both fgpga bitstream
and elf data?
there is now way to directly load the Cf with elf and bmm, or

well with V2Pro boards I havent had problems, except that I wasnt able
to access the OPB_sysace unless the bitstream was loaded from CF
as well, but this was maybe becuase I did not chanhe the systemace
init mode to disable the auto load

> flash, I get same symptom you get.  Also, the error reg in the sysace has
a
> value of 0x000000C0 after the error LED goes on.  This doesn't solve your
> problem, but is another point of data.
hm I think I got 0x80 as or 0xB0 as errors

> regards,
> -Newman
well thanks any points are welcome!
Antti






Article: 78819
Subject: Re: opb_ddr connection to DDR chips
From: "Gabor" <gabor@alacron.com>
Date: 8 Feb 2005 07:36:43 -0800
Links: << >>  << T >>  << A >>

Sean Durkin wrote:
> Sylvain Munaut wrote:
> > Hello
> >
> > I'm planning to do a microblaze design using external DDR memory
using
> > the opb_ddr
> > core. However I'd like to know if there is any constraints on how
to
> > connect
> > (which banks/pins ...) the DDR chip. Here I only have 1 point to
point
> > connection
> > of a 16 bits wide DDR.
> >
> > I was planning on using two banks for all the DQS/DQM/DQ then
another
> > bank for the
> > control & address signals.
> >
> > I haven't seen much info about that in the opb_ddr doc. But on DDR
> > interface appnotes,
> > some have specific constrainst so I prefer to ask before making the

> > board ;)
> There's several things to consider: First, you can't put DQS signals
and
> DQ-signals in the same IO-tiles, because they use different clocks
and
> there can only be one clock per tile for the IO-registers. That's one

> thing I stumbled upon in the past...
>
> Second, the plb_ddr-controller from EDK3.2 (don't know if this
applies
> to the opb_ddr in EDK6.X) suggested a clock feedback path, i.e. a
> separate trace feeding the clock sent to the DDR back into the FPGA.
> They use that to determine how to compensate for PCB routing delays.
If
> you don't have that, you'll probably have to waste a DCM and do some
> fiddling around to figure out the correct phase shifts and such.
>

I got burned on this, too.  I have a SO-DIMM design with "59-bit" wide
data interface because of IOB assignments.  The IOB tiles have the same
pairing as differential signals, so it's easy to find them in the pin-
out diagrams.

> Third, remember that DDR-SDRAM has a MINIMAL clock rate at which it
can
> operate. With the myriad of different manufacturers, types and
> speedgrades of SDRAM-chps available you should look out not to
> accidentally get a chip that doesn't run as "slow" as your
controller.
>

This is less likely to bite you if you bothered to use DDR in the first
place.  Minimum for some chips is 83 MHz, others 66 MHz for DDR 1.

> If you're planning to use high clock rates, Xilinx recommends you use

> local clocks for the DQS signals, and then you'd have to use specific

> pins for the corresponding data signals. In Xilinx' Memory Corner you

> can download a "Memory Interface Generator" that can help with the
pin
> assignments.
>
> Other than that, the DDR-chip probably uses SSTL2, which means you
have
> to hook up all the Vref-pins to 1,25V, so they are not available to
use
> as I/Os. Termination is an issue as well, so you should connect the
> VRN/VRP-pins as well to be able to use the DCIs for termination.
> Depending on the board layout it might be neccessary to use series
> resistors and/or pullups at the DDR chip as well.
>

Probably not an issue with one 16-bit part, but with a large data bus
DCI will probably increase your power to an unacceptable level if you
don't have adequate heatsinking.  I've burned up some FG456 package
devices this way (64 data bits of DCI adds about 4W by my estimate).

For chips glued to the board (not DIMM or SO-DIMM) and short runs
you may get away without termination resistors to Vtt.  With these
resistors in place I found SSTL2_I adequate to drive without causing
overshoot.  This takes much less power than SSTL2_II_DCI for the
externally terminated case.

> cu,
> Sean


Article: 78820
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 08 Feb 2005 07:39:30 -0800
Links: << >>  << T >>  << A >>
Jim,

Yes, I see everyone taking advantage that LUT delays are variable, based 
on input.  The last stage selection is always faster, so there is one 
input that is always faster than the others.  Makes the software slower 
to P&R, but there is an advantage, and if taken, can provide that little 
extra ps of improvement.

As for Vt's, there is low Vt, and Hight Vt.  As for body biasing, it has 
practically no benefit (slope of body vs power is terrible, easier to 
just raise or lower Vdd).  So Intel has 100 adjustments, most of which 
are useless.

And, yes, we use low, and high Vt's, on core, mid-ox, and thick ox in 
the triple oxide process.  Only way to go.

Austin

Jim Granville wrote:
> austin wrote:
> 
>> Glen,
>>
>> " > I do wonder if the optimal LUT size has changed over the years.
>>
>>>
>>> Is there work showing the optimal LUT size as a function of silicon 
>>> resources needed to implement such LUTs?"
>>
>>
>>
>> Good point.  Paul has referred to their studies of replacing a 4 LUT 
>> with a 6 LUT, and then re-running synthesis to see just how much 
>> improvement one sees.
>>
>> Assuming one can get enough >4 term, <=6 term logic synthesised, one 
>> saves logic levels, and improves speed (even if a 6 LUT is slower than 
>> a 4 LUT).
>>
>> Then comes the other nagging questions:
>> - are inputs shared?
>> - how badly does that mess up the results?
>> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some 
>> extra logic to almost give you a 6 LUT?  How badly does that work?
>> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic 
>> terms, how badly does that increase the delay?
>>
>> I would claim a properly engineered 6 LUT would improve the overall 
>> performance.  A compromise would provide some improvement.  A poor 
>> implementation woukd make no difference.
>>
>> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?
>>
>> Can you use them as SRL?  LUT RAM?
>>
>> The synthesis tools all have to be retuned, and debugged to take 
>> advantage, so this is not without risk.
>>
>> As for area, a 6 LUT is not all that big as technology shrinks, so 
>> some combinations of variable LUT size, alternate architectures, is in 
>> my opinion, inevitable.
>>
>> As for speed, the smaller the technology, the less improvement in 
>> speed (ITRS roadmap, and anyone who says differently can be 
>> confidently ignored).  For speed, one now has to use triple oxide to 
>> get both speed and static power reduction (eg compare us to S2 at 25C 
>> and there is no difference for leakage, but compare us at 85C, and we 
>> are 1/2 to 1/3 the static power!).
>>
>> The wonderful thing about standard CMOS, is just that.  No one has a 
>> remarkably different or unique process.  But one can use standard CMOS 
>> with all of the available tricks, and see a 1/2 to 1/3 reduction in 
>> static power, an improvement in speed, and an improvement in SEU 
>> resilience.  Like V4.
> 
> 
> and Intel also varies the Vth over 21 steps, to have CLK, Vdd, Vth
> to tune for speed/power trade offs.
> 
> http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=TWZH2G3BR2K2OQSNDBCSKHSCJUMEKJVN?articleId=59301578 
> 
> 
>>
>> Also, there is room for improvement with the P&R tools, so software is 
>> always looking for that QOR improvement that gives us another speed 
>> grade advantage without any process change.  So far they do that every 
>> generation (they get credit for part of the improvement in speed with 
>> each generation, too, including the most recent ones).
> 
> 
>  A significant difference at the LUT spec level that I DID see ( and I 
> presume still applies ? ) is that Altera have differing LUT path delays
> ( all LUT legs are not created equal ), whilst Xilinx treated them
> all equal.
>  That means the Altera SW/HW can presumably choose the faster legs, 
> where that matters, and so shave 100's of ps off the critical path ?
>  => Faster P&R on otherwise similar silicon ?
> 
> -jg
> 

Article: 78821
Subject: Re: SimmStick FPGA module
From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com>
Date: Tue, 08 Feb 2005 16:40:37 +0100
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Laurent Gauch" <laurent.gauch@DELETEALLCAPSamontec.com> schrieb im
> Newsbeitrag news:4208CF2C.6010504@DELETEALLCAPSamontec.com...
> 
>>Kolja Sulimma wrote:
>>
>>>Martin Schoeberl wrote:
> 
> 
>>What is the use of the finger connector on Micromodule
>>
>>Larry
> 
> HAHA its duplicate of your favorite interface JTAG!
> Need to get piece of old floppy connector and saw it in pieces!
> 
> Antti
> 
> 
thanks Antti !

Article: 78822
Subject: Re: V4LX25-ES and systemACE
From: "newman5382" <newman5382@yahoo.com>
Date: Tue, 08 Feb 2005 15:41:54 GMT
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:cuakor$itp$05$1@news.t-online.com...
> "newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag
> news:1t4Od.15793$qB6.2868@tornado.tampabay.rr.com...
>>
>> "Antti Lukats" <antti@openchip.org> wrote in message
>> news:cua695$on8$01$1@news.t-online.com...
>> > Hi
>> >
>> > has any one some hints or tips how to get an Virtex4 LX25-ES configured
>> > from
>> > SystemACE?
>> > we can configure from iMpact and if we load the uclinux kernel from XMD
> it
>> > works too.
>> > but now when I try to load the uclinux image from CompactFlash then
> there
>> > are problems
>> > if the FPGA is configured by impact then there will always be random
>> > sector
>> > read errors
>> > when attempting to load the image.bin from CompactFlash. On ML300 I had
> to
>> > load from
>> > CF in order to access the CF, but with V4LX the FPGA config from
>> > CompactFlash doesnt
>> > seem to work, the status led blinks once and then the error led goes 
>> > on.
> I
>> > assume it is the TDO
>>
>> I get this symptom with a V2Pro board.  When I load the compact flash 
>> with
>> the bit, bmm, and elf file.  When I just load the bit file into the
> compact
> how?
> you mean when the bit file in the ACE file containts both fgpga bitstream
> and elf data?
> there is now way to directly load the Cf with elf and bmm, or
>
> well with V2Pro boards I havent had problems, except that I wasnt able
> to access the OPB_sysace unless the bitstream was loaded from CF
> as well, but this was maybe becuase I did not chanhe the systemace
> init mode to disable the auto load
>

I generate the ace file via impact
  - Prepare Configuration Files
  - System ACE File
  - System ACE CF  Novice
  - 128 Mbits Reserve Space
  - etc
  - add file download.bit, system.bmm, executable.elf

I read somewhere that the sysace is like some type of JTAG player,  I 
assumed that the elf would get loaded somehow like it does with xmd, except 
without xmd.  Perhaps I am wrong, and that is why it does not work for me. 
Also, when I try to read a sector via the MPU interface, it goes busy and 
never goes ready again (i.e. Status Reg bit 8 goes low and stays low even 
after I read out a sector of data.)  The sector reads 256 16 bit words of 
the same value.  When I use XSysAce_IdentifyCF, I get the expected 
Signature, but all the other fields come back with the Signature value also, 
and bit 8 of the status reg never goes busy.


>> flash, I get same symptom you get.  Also, the error reg in the sysace has
> a
>> value of 0x000000C0 after the error LED goes on.  This doesn't solve your
>> problem, but is another point of data.
> hm I think I got 0x80 as or 0xB0 as errors
>
>> regards,
>> -Newman
> well thanks any points are welcome!
> Antti
>
>
>
>
> 



Article: 78823
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 08 Feb 2005 07:43:01 -0800
Links: << >>  << T >>  << A >>
Paul,

We disagree on some points (power) and we agree on others(architectures).

I'll leave it at that.  Next comes the customer feedback and experiences.

Austin


Paul Leventis (at home) wrote:

> Hi Austin,
> 
> No offence, but I don't think you're going to get far with an attack on the 
> logic architecture.  I think you should read the paper at FPGA 2005 when you 
> get a chance.  It is very informative.
> 
> 
>>Then comes the other nagging questions:
>>- are inputs shared?
>>- how badly does that mess up the results?
> 
> 
> Irrelevant to the speed question.  A simple 6-LUT in Stratix II does not 
> share inputs.  LUT input sharing is an area optimization that we employ 
> intelligently to avoid any penalty on performance while reducing number of 
> ALMs required.
> 
> I should also point out that all our experiments during architecture 
> experimentation are full synthesis + place & route runs on 100+ designs. 
> One thing anyone who works on FPGA logic & routing architecture knows is 
> that intuition isn't worth too much -- you can argue about "will shared 
> inputs hurt things?" until you are blue in the face, but in the end only an 
> experiment will tell the truth.
> 
> Funny side story:  One time during architecture experimentation someone put 
> up a graph of some parameter (I forget what).  We sat their and rationalized 
> why the answer would come out that way, and were all content.  Then we 
> realized the graph was backwards and the trend was actually the other way 
> around.  We could rationalize that answer too...
> 
> Bottom line:  Logic & routing architecture development must involve large 
> amount of experimentation with real cad tools, otherwise you just don't 
> arrive at the right answer.
> 
> 
>>- given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
>>how badly does that increase the delay?
> 
> 
> Wrong again.  The ALM breaks into two independent 4-input LUTs with no delay 
> penalty (ok, maybe a couple ps for a gate load or two) relative to a 
> Stratix-like 4-LUT.
> 
> 
>>I would claim a properly engineered 6 LUT would improve the overall 
>>performance.  A compromise would provide some improvement.  A poor 
>>implementation woukd make no difference.
> 
> 
> Your first claim is correct.  And the ALM gives the speed of a 6-LUT, but 
> the extra circuitry added to support fractured modes (2 4-LUTs, shared LUTs, 
> etc.) is minimal and adds a tiny amount of delay to the guts of the LUT.
> 
> 
>>Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?
> 
> 
> Good questions.  The reality is that a real design mapped into 6-LUTs 
> doesn't yield all 6-input functions -- it decomposes into a set of functions 
> ranging from 1- to 6-inputs.  That is why making a pure 6-LUT architecture 
> is not so great for area -- for those functions that don't use 6-inputs, you 
> are wasting a lot of routing & logic area.  That is why we added the 
> fracturing capabilities of the ALM.  This makes the ALM more expensive than 
> a straight 6-LUT for implementing 6-input functions, but overall once the 
> distribution of functions is taken into account, the ALM comes out on top.
> 
> One alternative could be to make an architecture with a hybrid set of LUT 
> sizes.  But then you have to wonder whether you've picked the right mix of 
> the two, you have the pain of hetrogeneous floorplanning in layout, you have 
> potential issues with placement, more complicated CAD tools, etc.
> 
> 
>>Can you use them as SRL?  LUT RAM?
> 
> 
> No, the ALM can't do that.  We've argued about that many times in this 
> newsgroup -- SRLs and LUT RAM add cost to the Logic Element.  M512 memories 
> are more efficient for many circuits, while SRLs/LUT RAM are more efficient 
> for others.  Are SRL/LUT RAM a bad idea?  No.  Are they a slam dunk?  No.
> 
> 
>>The synthesis tools all have to be retuned, and debugged to take 
>>advantage, so this is not without risk.
> 
> 
> Yes, that was a risk.  We took that risk because we believed the ALM was a 
> large enough win on the performance front to be worth the investment in 
> synthesis and the risk to product success.  If the ALM had given us 5% 
> performance, there's no way we would have gone for it.  But sometimes you 
> need to take a big jump in architecture to get out of a local minimum in the 
> space of architecture possibilities.
> 
> We worked with our 3rd party synthesis vendors well in advance of the 
> release of Stratix II, and our own integrated synthesis was used during 
> architecture development and thus was already ready to go.
> 
> 
>>As for area, a 6 LUT is not all that big as technology shrinks, so some 
>>combinations of variable LUT size, alternate architectures, is in my 
>>opinion, inevitable.
> 
> 
> Actually, the area of everything (LUTs, routing, RAMs, etc) shrinks as 
> technology does, so I don't think the 4-LUT vs. 6-LUT question changes too 
> much with process.  The only effect here is that perhaps as the amount of 
> delay in routing vs. logic moves around with process, the precise answer as 
> to what LUT and Cluster sizes are optimal will shift slightly, but this is 
> probably a small effect.  A bigger effect could be evolution in the quality 
> of synthesis and CAD tools, the changing nature of user designs, and 
> advances in routing architecture.
> 
> 
>>As for speed, the smaller the technology, the less improvement in speed 
>>(ITRS roadmap, and anyone who says differently can be confidently 
>>ignored).  For speed, one now has to use triple oxide to get both speed 
>>and static power reduction (eg compare us to S2 at 25C and there is no 
>>difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
>>static power!).
> 
> 
> I haven't seen any worst-case power numbers from you guys Austin.  Typical 
> is a marketing number -- how do you define your "typical" silicon?  Let's 
> hold off the power conclusions until both companies release final specs.
> 
> Besides, total power is what matters and you guys have curiously been shying 
> away from dynamic power.  Your own web page claims equivalent dynamic power 
> for a Virtex-4 LUT + routing vs. an Stratix II LUT + routing -- but our LUTs 
> implement 25% more logic, and hence there are fewer of them in a given 
> design.  Our pin capacitance is 1/2 that of V-4 -- you know what this does 
> for I/O power?  Imagine 200 I/Os toggling at 200 Mhz with 6 pF instead of 12 
> pF loads @ 2.5V (just as an example) -- if I've done my math right that's 
> 1.5W right there.  Now there's a strong chance I've done my math wrong (give 
> me a break, its late) but you get the point!
> 
> 
>>The wonderful thing about standard CMOS, is just that.  No one has a 
>>remarkably different or unique process.  But one can use standard CMOS 
>>with all of the available tricks, and see a 1/2 to 1/3 reduction in static 
>>power, an improvement in speed, and an improvement in SEU resilience. 
>>Like V4.
> 
> 
> Yes, there are tricks to employ.  But they can cost speed.  They can cost 
> area.  They can increase wafer costs.  All involve trade-offs.  In the end, 
> we each picked the tricks we wanted to use.  Gate oxide is only one variable 
> to play with, and not the most effective one on the speed vs. leakage 
> trade-off front.
> 
> 
>>Also, there is room for improvement with the P&R tools
> 
> 
> True.  Both companies have teams beating on this software for lots of 
> performance.  But if you're now saying that perhaps future software and a 
> future speed grade will help you catch up on performance, I'm feeling pretty 
> happy with our position.
> 
> Regards,
> 
> Paul Leventis
> Altera Corp.
> 
> 

Article: 78824
Subject: Re: V4LX25-ES and systemACE
From: "newman5382" <newman5382@yahoo.com>
Date: Tue, 08 Feb 2005 15:47:12 GMT
Links: << >>  << T >>  << A >>

"newman5382" <newman5382@yahoo.com> wrote in message 
news:655Od.15899$qB6.3561@tornado.tampabay.rr.com...
>
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:cuakor$itp$05$1@news.t-online.com...
>> "newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag
>> news:1t4Od.15793$qB6.2868@tornado.tampabay.rr.com...
>>>
>>> "Antti Lukats" <antti@openchip.org> wrote in message
>>> news:cua695$on8$01$1@news.t-online.com...
>>> > Hi
>>> >
>>> > has any one some hints or tips how to get an Virtex4 LX25-ES 
>>> > configured
>>> > from
>>> > SystemACE?
>>> > we can configure from iMpact and if we load the uclinux kernel from 
>>> > XMD
>> it
>>> > works too.
>>> > but now when I try to load the uclinux image from CompactFlash then
>> there
>>> > are problems
>>> > if the FPGA is configured by impact then there will always be random
>>> > sector
>>> > read errors
>>> > when attempting to load the image.bin from CompactFlash. On ML300 I 
>>> > had
>> to
>>> > load from
>>> > CF in order to access the CF, but with V4LX the FPGA config from
>>> > CompactFlash doesnt
>>> > seem to work, the status led blinks once and then the error led goes 
>>> > on.
>> I
>>> > assume it is the TDO
>>>
>>> I get this symptom with a V2Pro board.  When I load the compact flash 
>>> with
>>> the bit, bmm, and elf file.  When I just load the bit file into the
>> compact
>> how?
>> you mean when the bit file in the ACE file containts both fgpga bitstream
>> and elf data?
>> there is now way to directly load the Cf with elf and bmm, or
>>
>> well with V2Pro boards I havent had problems, except that I wasnt able
>> to access the OPB_sysace unless the bitstream was loaded from CF
>> as well, but this was maybe becuase I did not chanhe the systemace
>> init mode to disable the auto load
>>
>
> I generate the ace file via impact
>  - Prepare Configuration Files
>  - System ACE File
>  - System ACE CF  Novice
>  - 128 Mbits Reserve Space
>  - etc
>  - add file download.bit, system.bmm, executable.elf
>
> I read somewhere that the sysace is like some type of JTAG player,  I 
> assumed that the elf would get loaded somehow like it does with xmd, 
> except without xmd.  Perhaps I am wrong, and that is why it does not work 
> for me. Also, when I try to read a sector via the MPU interface, it goes 
> busy and never goes ready again (i.e. Status Reg bit 8 goes low and stays 
> low even after I read out a sector of data.)  The sector reads 256 16 bit 
> words of the same value.  When I use XSysAce_IdentifyCF, I get the 
> expected Signature, but all the other fields come back with the Signature 
> value also, and bit 8 of the status reg never goes busy.
Meant to say never goes ready
>
>
>>> flash, I get same symptom you get.  Also, the error reg in the sysace 
>>> has
>> a
>>> value of 0x000000C0 after the error LED goes on.  This doesn't solve 
>>> your
>>> problem, but is another point of data.
>> hm I think I got 0x80 as or 0xB0 as errors
>>
>>> regards,
>>> -Newman
>> well thanks any points are welcome!
>> 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