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 69925

Article: 69925
Subject: Re: Nios II = Microblaze
From: "Ken Land" <kland1@neuralog1.com>
Date: Mon, 24 May 2004 17:54:20 -0500
Links: << >>  << T >>  << A >>

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405241256.1b6a51e1@posting.google.com...
> Altera finally wakes up. They realize that the window register type
> architecture is not good for FPGAs and probably in general. They can
> no longer support their own marketing hype about how great Nios I is.
> If Nios 1 was so great, why did it need a complete redesign and
> rearchitecture? It means it was poor. That's the only reason you do a
> complete redesign. I believe they have switched to 32 bit instructions
> also. Didn't it used to be 16 bit? Guess that wasn't so great either.
>
> They copy the Xilinx Microblaze style implementation. To me it shows
> who knows what about designing and running a soft processor in an
> FPGA. Enough said.
>
> They throw all the current Nios customers under the bus. Requires
> publishing a 38 page app note to switch a Nios 1 to Nios II design.
> Current Nios users, I feel sorry for you. Be careful and do your back
> ups!

I try not to respond to trolls, but in your case I'll make an exception.

You don't know what your talking about!

Nios I with SOPC builder is a small fast, flexible processor with great
tools.  Nios II is even better.  It's smaller, faster, and has even better
tools.

How someone could see such an upgrade as something to feel sorry about is
madness.  If your car dealer called you up and said come pickup your new
replacement car only it looks better, runs faster and gets better mileage,
would you turn him down?

Try to use some common sense!

Ken Land



Article: 69926
Subject: Driving fpga pin out over long cable
From: "Tom Derham" <uceeted@ucl.ac.uk>
Date: Mon, 24 May 2004 23:23:09 GMT
Links: << >>  << T >>  << A >>
I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design
running with a 100MHz master clock.  This clock is derived from a single
source and distributed to each board so they are synchronised.  The boards
are postioned about 50m apart.

I need to synchronise events on the boards, but occasionally sending a
single pulse (say 10ns long) from the output pin of one of the FPGAs to the
other boards, to allow them to synchronise internal timers.  I need to make
sure that the pulse arrives at the other two boards at the same time so that
it is 'recognised' on the same rising edge of the reference clock in each
case, so that the boards synchronise together.

Clearly the attenuation of any 50m length of cable is such that I cannot
connect them directly, but nor do I want the complexity of converting the
pulse to optical fibre and back again.
For the distribution of the reference clock I am using National CLC005/012
driver and equaliser chipset over UTP, using equal length wires so as to not
introduce propagation skew.  For practical reasons I can't use the same
cable for sending this event pulse, and ideally would like a simple, elegant
solution.
I was just wondering if anyone had done anything similar before... if not, I
have a back-up plan using more of the National drivers, but I thought they
might be a sledgehammer to crack a nut - and am unsure what levels of skew
they may introduce themselves... jitter is not so important because the
event is resynced at the receiving fpga, as long as the total difference in
edge is less than half of the reference clock cycle (so 5ns).

Thank you in advance for any ideas....



Article: 69927
Subject: Re: Driving fpga pin out over long cable
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 25 May 2004 12:49:14 +1200
Links: << >>  << T >>  << A >>
Tom Derham wrote:
> I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design
> running with a 100MHz master clock.  This clock is derived from a single
> source and distributed to each board so they are synchronised.  The boards
> are postioned about 50m apart.
> 
> I need to synchronise events on the boards, but occasionally sending a
> single pulse (say 10ns long) from the output pin of one of the FPGAs to the
> other boards, to allow them to synchronise internal timers.  I need to make
> sure that the pulse arrives at the other two boards at the same time so that
> it is 'recognised' on the same rising edge of the reference clock in each
> case, so that the boards synchronise together.
> 
> Clearly the attenuation of any 50m length of cable is such that I cannot
> connect them directly, but nor do I want the complexity of converting the
> pulse to optical fibre and back again.
> For the distribution of the reference clock I am using National CLC005/012
> driver and equaliser chipset over UTP, using equal length wires so as to not
> introduce propagation skew.  For practical reasons I can't use the same
> cable for sending this event pulse, and ideally would like a simple, elegant
> solution.
> I was just wondering if anyone had done anything similar before... if not, I
> have a back-up plan using more of the National drivers, but I thought they
> might be a sledgehammer to crack a nut - and am unsure what levels of skew
> they may introduce themselves... jitter is not so important because the
> event is resynced at the receiving fpga, as long as the total difference in
> edge is less than half of the reference clock cycle (so 5ns).
> 
> Thank you in advance for any ideas....

  The natsemi drivers might seem an over-kill, but they do give you 
tracking with your clock system, and since that sounds like
it rather matters, anything you
a) already know
  and
b) tracks what you already use

sounds to me like a simple, elegant solution ?

  Another scheme for global sync, (but that some systems cannot 
tolerate), is to send a break in the clock stream - can be as simple as 
a single missing pulse. Gives you a time-Zero, and all units thereafter 
are in-phase.

-jg





Article: 69928
Subject: What can I do if my chip can't meet timing?
From: "Student" <student@nowhere.com>
Date: Tue, 25 May 2004 15:12:45 +0800
Links: << >>  << T >>  << A >>
Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin




Article: 69929
Subject: VPR & Reconfigurable system ?
From: Jack <jyhur63@naver.com>
Date: Tue, 25 May 2004 10:31:12 +0200
Links: << >>  << T >>  << A >>
hello

currently I am looking for the previous academic reconfigurable system 
which uses VPR as a software environment.

Could anyone point me out successfully published reconfigurable system 
(or stand-alone hardware) using VPR environment ?

Thankyou in advance


Article: 69930
Subject: Re: Nios II = Microblaze
From: jon@beniston.com (Jon Beniston)
Date: 25 May 2004 01:45:31 -0700
Links: << >>  << T >>  << A >>
> I believe they have switched to 32 bit instructions
> also. Didn't it used to be 16 bit? Guess that wasn't so great either.

Depends on what you are interested in. If it's code density, then
16-bit instructions are great. NIOS had a significant code size
advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't
important, but when you have an instruction cache, good code density
can also improve performance (less cache misses).

Cheers,
JonB

Article: 69931
Subject: Re: Nios II = Microblaze
From: Goran Bilski <goran@xilinx.com>
Date: Tue, 25 May 2004 11:27:22 +0200
Links: << >>  << T >>  << A >>

Jon Beniston wrote:

>>I believe they have switched to 32 bit instructions
>>also. Didn't it used to be 16 bit? Guess that wasn't so great either.
>>    
>>
>
>Depends on what you are interested in. If it's code density, then
>16-bit instructions are great. NIOS had a significant code size
>advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't
>important, but when you have an instruction cache, good code density
>can also improve performance (less cache misses).
>  
>
With the few benchmarks that I have done, I didn't see any big savings 
in the NIOS I code size.
I think that most NIOS2 users will see that the code size will not 
increase that much compared to NIOS1.
A 32-bit instruction can do more for each instruction than a 16-bit 
instruction and a 16-bit ISA also have problems with immediate values.

So the code size is very application dependent but you will not see a 
"significant" difference.

>Cheers,
>JonB
>  
>


Article: 69932
Subject: Re: HOWTO calculate the binary size of a .hexout/.flash/.germs file
From: "Jeroen" <sink@null.dev>
Date: Tue, 25 May 2004 12:29:01 +0200
Links: << >>  << T >>  << A >>
all formats are not neccesarily contigious, that means the file can contain
data for address 0x100-0x200 and 0x40000-0x4000F for example, is the binary
size 0x10F then, or 0x40000F?

But usually the files contain contigious addresses. The NIOS SDK comes with
a utility called nios-elf-size. Run it like "nios-elf-size
<yourfile>.objout", that will give you an indication how big your file will
be.

You can also interpret the last line of the SREC file yourself. When you run
out of code/data space I think the linker will give you an error.

Jeroen


"GreateWhite.DK" <mse@ect.dk> schreef in bericht
news:40b1bc0a$0$474$edfadb0f@dread14.news.tele.dk...
> Hi
>
> How can subject be done???
>
> Regards up front
> GreateWhite.DK
>
>



Article: 69933
Subject: Re: USB HUB?
From: "Jeroen" <sink@null.dev>
Date: Tue, 25 May 2004 12:36:43 +0200
Links: << >>  << T >>  << A >>

a hub also needs to sense currents downstream devices use and it should be
able to turn devices off, so a FPGA only implementation is not possible. Is
there any reason you want to implement a hub in an FPGA, while readily
available hubs are cheaper than the FPGA device alone?

Atmel make HUB chips (AT43301 for example), maybe you can find some useful
info in the datasheets.

Jeroen

"jimboluke" <jimlyke@comcast.net> schreef in bericht
news:UemdnYXatLsRQjPdRVn-tw@comcast.com...
> Is there an open USB hub anywhere?  I can find USB device cores, but not
> hubs. -jim
>




Article: 69934
Subject: Re: Nios II = Microblaze
From: nkavv@skiathos.physics.auth.gr (Uncle Noah)
Date: 25 May 2004 03:38:27 -0700
Links: << >>  << T >>  << A >>
> "Stifler" <seannstifler69@hotmail.com> wrote in message
> news:bf780a06.0405241256.1b6a51e1@posting.google.com...
> > Altera finally wakes up. They realize that the window register type
> > architecture is not good. They can no longer support their own marketing 
> > If Nios 1 was so great, why did it need a complete redesign and
> > rearchitecture? It means it was poor. That's the only reason you do a
> > complete redesign. I believe they have switched to 32 bit instructions
> > also. Didn't it used to be 16 bit? Guess that wasn't so great either.

Other user said:
> Nios I with SOPC builder is a small fast, flexible processor with great
> tools.  Nios II is even better.  It's smaller, faster, and has even better
> tools.

Both can have good share in the market. For my own purposes it is more
probable that i would use Nios than MicroBlaze.

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Since customization is out of the issue, no Microblaze for me.

Uncle "The G.B. Man" Noah

Article: 69935
Subject: Re: Altium FPGA board
From: Rene Tschaggelar <none@none.net>
Date: Tue, 25 May 2004 12:44:04 +0200
Links: << >>  << T >>  << A >>
Chuck McManis wrote:

> "Rene Tschaggelar" <none@none.net> wrote in message
> news:40b0fd9d$0$721$5402220f@news.sunrise.ch...
> 
>>The Nexar package is not really that overpriced. It allows to develop
>>FPGAs with a 8051 kernel built in, with debugger, compiler, everything.
> 
> 
> I should have been more crisp, $8,000 is waaaaaaay overpriced for me. Even
> the $1000 I spent on the Proteus package (www.labcenter-electronics.com)
> seemed steep but it too has the embedded processor simulator (PIC, AVR, and
> 8051) and as I use PICs (some AVRs, but no 8051 yet) in my robotics I was
> moderatly motivated by it.

Yes, for non-protel user it is a lot to just have a look at.
And when you don't have a certain number of projects where you could
save a lot of time on development, it could be hard to justify.

> Bringing it back on topic...
> 
> Have you played with the FPSLIC stuff? AVR core plus FPGA? I've got the
> development board as I was looking at some sort of custome baseboard
> controller (SMBus, i2c, etc) and it looks great but Atmel doesn't seem
> particularly committed to it ...

As said, I had no gain in putting any core into an FPGA yet. While using 
a standalone cpu let you select between a bunch of compilers, they
somehow vanish when you put a core into an FPGA.
BTW, what does an I2C or SMB, that cannot be done with some port pins ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 69936
Subject: Re: Driving fpga pin out over long cable
From: Rene Tschaggelar <none@none.net>
Date: Tue, 25 May 2004 12:50:44 +0200
Links: << >>  << T >>  << A >>
Tom Derham wrote:

> I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design
> running with a 100MHz master clock.  This clock is derived from a single
> source and distributed to each board so they are synchronised.  The boards
> are postioned about 50m apart.
> 
> I need to synchronise events on the boards, but occasionally sending a
> single pulse (say 10ns long) from the output pin of one of the FPGAs to the
> other boards, to allow them to synchronise internal timers.  I need to make
> sure that the pulse arrives at the other two boards at the same time so that
> it is 'recognised' on the same rising edge of the reference clock in each
> case, so that the boards synchronise together.
> 
> Clearly the attenuation of any 50m length of cable is such that I cannot
> connect them directly, but nor do I want the complexity of converting the
> pulse to optical fibre and back again.
> For the distribution of the reference clock I am using National CLC005/012
> driver and equaliser chipset over UTP, using equal length wires so as to not
> introduce propagation skew.  For practical reasons I can't use the same
> cable for sending this event pulse, and ideally would like a simple, elegant
> solution.
> I was just wondering if anyone had done anything similar before... if not, I
> have a back-up plan using more of the National drivers, but I thought they
> might be a sledgehammer to crack a nut - and am unsure what levels of skew
> they may introduce themselves... jitter is not so important because the
> event is resynced at the receiving fpga, as long as the total difference in
> edge is less than half of the reference clock cycle (so 5ns).
> 
> Thank you in advance for any ideas....

100 MHz on a long cable calls for either 50 Ohms, ECL or perhaps LVDS.

There also are the AnalogDevices ADum1400 family of magnetocouplers, 
some of which are spec'ed for 100MBit.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 69937
Subject: Re: Nios II = Microblaze
From: Goran Bilski <goran@xilinx.com>
Date: Tue, 25 May 2004 12:54:45 +0200
Links: << >>  << T >>  << A >>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en,sv
In-Reply-To: <b7a879e0.0405250238.11caeb7f@posting.google.com>
Xref: newsmst01a.news.prodigy.com comp.arch.fpga:72469



Have you looked at the FSL interface on MicroBlaze?
It will allow you to create custom functions which can be more powerful 
than custom instructions.

Göran

Uncle Noah wrote:

>>"Stifler" <seannstifler69@hotmail.com> wrote in message
>>news:bf780a06.0405241256.1b6a51e1@posting.google.com...
>>    
>>
>>>Altera finally wakes up. They realize that the window register type
>>>architecture is not good. They can no longer support their own marketing 
>>>If Nios 1 was so great, why did it need a complete redesign and
>>>rearchitecture? It means it was poor. That's the only reason you do a
>>>complete redesign. I believe they have switched to 32 bit instructions
>>>also. Didn't it used to be 16 bit? Guess that wasn't so great either.
>>>      
>>>
>
>Other user said:
>  
>
>>Nios I with SOPC builder is a small fast, flexible processor with great
>>tools.  Nios II is even better.  It's smaller, faster, and has even better
>>tools.
>>    
>>
>
>Both can have good share in the market. For my own purposes it is more
>probable that i would use Nios than MicroBlaze.
>
>In Microblaze there is no way to add your own custom instructions. It
>is not an extensible processor but just provides the means to add
>peripherals to a small SoC. Correct me if i am wrong. I just hope that
>the tools (assembler, simulator, debugger) can be retargeted for the
>new ISA. Or be able to use inline assembly with the new instructions.
>The corresponding hardware should be built by some RTL description i
>would give.
>
>Since customization is out of the issue, no Microblaze for me.
>
>Uncle "The G.B. Man" Noah
>  
>




Article: 69938
Subject: Virtex2P co-simulation problems using Modelsim and smartmodel
From: qudhs <qudhs@yahoo.com>
Date: Tue, 25 May 2004 15:41:46 +0300
Links: << >>  << T >>  << A >>
Hi!
I followed an instruction from xilinx website to setup the co-simulation
environment for ModelSim. libraries have been updated and smartmodel has
been installed.
However, when I try to run a behavioral model, which is created by
clicking the "simgen" button in EDK6.1 toolbar, things are not going
quite well. It seems that the PPC core (from smartmodel) doesn't
function correctly. Its 3 reset request signals
(C405CHIPRSTREQ,C405CORERSTREQ,C405SYSRSTREQ) always go to "X" after
rst_c405_chip, rst_c405_core, rst_c405_sys go back to "0" from "1".
Then, I created another structural model for the same design. the
problem with these reset signals went away.
so, could someone point out what I am missing to create a correct
behaviroal model? thank you in advance!
--yang


Article: 69939
Subject: AWGN
From: ivansimoes@msn.com (Ivan)
Date: 25 May 2004 05:58:10 -0700
Links: << >>  << T >>  << A >>
Hello guys,

I want to implement a simple code to generate a AWGN signal quantized
in 4 bits unsigned, I'd like to use this as an interference to a turbo
code project.

At the moment I'm trying to sum 16 differents PN sequences (each one
using 32 registers), but I think this project could be implemented
using less logic.

I'm wondering for any help and comments

Thanks

Ivan

Article: 69940
Subject: Re: What can I do if my chip can't meet timing?
From: ALuPin@web.de (ALuPin)
Date: 25 May 2004 06:02:35 -0700
Links: << >>  << T >>  << A >>
"Student" <student@nowhere.com> wrote in message news:<40b2f02e@news.starhub.net.sg>...
> Hi, there:
> 
> My clock is 40MHz, but I have complicated FFT operations and other DSP
> stuff.
> The longest path is 25.8ns, though after I set the constraints at
> 23ns...Previously it
> was 27.5ns at constraints of 25ns...
> 
> What may I do now? How far can over constraining go? The source codes are
> from
> other people so I can't change a lot of it.
> 
> Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?
> 
> Does Synplify optimize for speed? How does it compare with XST?
> 
> Kelvin

Hi Kelvin,

if the source codes are from other people and you cannot change it
you should assume that is has been optimized for 40MHz, isn't it?  ;o)

You have to clarify for which clock frequency the original design has
been developed.

So basically the best possibility is to think about pipelining your design.
By doing so you will not have to worry about constraining.

Rgds

Article: 69941
Subject: Re: HOWTO calculate the binary size of a .hexout/.flash/.germs file
From: "GreateWhite.DK" <mse@ect.dk>
Date: Tue, 25 May 2004 15:08:13 +0200
Links: << >>  << T >>  << A >>
Thanks for your reply Jeroen.

I have reflected a bit over what you said. It has however resulted in some
other questions.

See what I want to do is to have some apps stored in my flash(1MB). On
powerup will me boot code get data in my flash that is compressed and then
extract the data directly to the RAM so I don't need any SREC file to be
translated by the GERMS.
How should this be done? Is it just taking the .out file and copy this into
the RAM or what kind of actions must I make use of?

Regards
GreateWhite.DK

"Jeroen" <sink@null.dev> wrote in message
news:40b31fe5$0$36169$e4fe514c@news.xs4all.nl...
> all formats are not neccesarily contigious, that means the file can
contain
> data for address 0x100-0x200 and 0x40000-0x4000F for example, is the
binary
> size 0x10F then, or 0x40000F?
>
> But usually the files contain contigious addresses. The NIOS SDK comes
with
> a utility called nios-elf-size. Run it like "nios-elf-size
> <yourfile>.objout", that will give you an indication how big your file
will
> be.
>
> You can also interpret the last line of the SREC file yourself. When you
run
> out of code/data space I think the linker will give you an error.
>
> Jeroen
>
>
> "GreateWhite.DK" <mse@ect.dk> schreef in bericht
> news:40b1bc0a$0$474$edfadb0f@dread14.news.tele.dk...
> > Hi
> >
> > How can subject be done???
> >
> > Regards up front
> > GreateWhite.DK
> >
> >
>
>



Article: 69942
Subject: Re: Driving fpga pin out over long cable
From: rrr@ieee.org (Rajeev)
Date: 25 May 2004 06:14:00 -0700
Links: << >>  << T >>  << A >>
Rene Tschaggelar <none@none.net> wrote in message news:<40b32543$0$718$5402220f@news.sunrise.ch>...

> 100 MHz on a long cable calls for either 50 Ohms, ECL or perhaps LVDS.
> 
> There also are the AnalogDevices ADum1400 family of magnetocouplers, 
> some of which are spec'ed for 100MBit.
> 
> Rene

One more vote for LVDS.  Here's an app note for TI M-LVDS technology.

http://focus.ti.com/lit/an/slla127/slla127.pdf

Basically they say -6dB at 30m over UTP for 100 Mbps, and a little
over 10% jitter at 50m.  I expect you may be able to do better with
co-ax cable -- look for a type with low-loss dielectric and, for lower
power consumption, higher characteristic impedance -- co-ax goes upto
about 100ohm.  You will need to
be careful about ground differences between the two ends.

Regards,
-rajeev-

Article: 69943
Subject: www.opencores.org ???
From: "mikegw" <mikegw20spamdiespam@com.hotmail>
Date: Tue, 25 May 2004 23:17:30 +1000
Links: << >>  << T >>  << A >>
Anyone know what happed to this site?  It has been off the air for a few
days now.

Mike



Article: 69944
Subject: Re: Nios II = Microblaze
From: jon@beniston.com (Jon Beniston)
Date: 25 May 2004 06:37:33 -0700
Links: << >>  << T >>  << A >>
> With the few benchmarks that I have done, I didn't see any big savings 
> in the NIOS I code size.

Here's a few results for you:

Dhrystone	0.873552983
JPEG	0.651083295
g726	0.781745341
g711	0.724035608
GSM	0.74610231
AES	0.659236641
TCP/IP	0.638751451
bzip2	0.812246882

I.e. NIOS is on average 25% smaller than Microblaze. Note: I have
taken into account the size of crt0 etc. etc..

> I think that most NIOS2 users will see that the code size will not 
> increase that much compared to NIOS1.

They will lose that 25%. Maybe it isn't important.

> A 32-bit instruction can do more for each instruction than a 16-bit 
> instruction 

Sure, but not all the time.

> and a 16-bit ISA also have problems with immediate values.

I don't know what you mean by problems, but yes, a 16-bit instruction
doesn't have as large a range for immediates as a 32-bit instruction.
NIOS got around this with their prefix instruction. They just happend
to lose out on performance as they didn't choose to decode a prefix
and the subsequent instruction in parallel.

> So the code size is very application dependent but you will not see a 
> "significant" difference.

Well, 25% seems significant to me.

I don't want to come accross as some NIOS fanboy, because I'm not.
It's just those are the facts as I seem them.

Cheers,
Jon

Article: 69945
Subject: Re: Nios II = Microblaze
From: jon@beniston.com (Jon Beniston)
Date: 25 May 2004 06:38:28 -0700
Links: << >>  << T >>  << A >>
> In Microblaze there is no way to add your own custom instructions. It
> is not an extensible processor but just provides the means to add
> peripherals to a small SoC. Correct me if i am wrong. I just hope that
> the tools (assembler, simulator, debugger) can be retargeted for the
> new ISA. Or be able to use inline assembly with the new instructions.
> The corresponding hardware should be built by some RTL description i
> would give.

Is anyone actually doing this?

Cheers,
JonB

Article: 69946
Subject: Re: Nios II = Microblaze
From: Goran Bilski <goran@xilinx.com>
Date: Tue, 25 May 2004 15:59:26 +0200
Links: << >>  << T >>  << A >>


Jon Beniston wrote:

>>With the few benchmarks that I have done, I didn't see any big savings 
>>in the NIOS I code size.
>>    
>>
>
>Here's a few results for you:
>
>Dhrystone	0.873552983
>JPEG	0.651083295
>g726	0.781745341
>g711	0.724035608
>GSM	0.74610231
>AES	0.659236641
>TCP/IP	0.638751451
>bzip2	0.812246882
>
>I.e. NIOS is on average 25% smaller than Microblaze. Note: I have
>taken into account the size of crt0 etc. etc..
>  
>
Is this with the register window enable or with the mflat option?
If you add the data into the sizes, the percentage will be even smaller.
For a lot of the application, the data size is normally larger than the 
code size.
The only benefit of smaller application size (code and data) is that you 
might get away with smaller memories.

>  
>
>>I think that most NIOS2 users will see that the code size will not 
>>increase that much compared to NIOS1.
>>    
>>
>
>  
>
>They will lose that 25%. Maybe it isn't important.
>
Normally not.

>
>  
>
>>A 32-bit instruction can do more for each instruction than a 16-bit 
>>instruction 
>>    
>>
>
>Sure, but not all the time.
>
But  most of the time.

>
>  
>
>>and a 16-bit ISA also have problems with immediate values.
>>    
>>
>
>I don't know what you mean by problems, but yes, a 16-bit instruction
>doesn't have as large a range for immediates as a 32-bit instruction.
>NIOS got around this with their prefix instruction. They just happend
>to lose out on performance as they didn't choose to decode a prefix
>and the subsequent instruction in parallel.
>
Which mean that you will need two 16-bit instructions instead of one 
32-bit instruction.
Which is then the same size.
If you look at the NIOS code, you will find a lot of the PFX instructions.

>
>  
>
>>So the code size is very application dependent but you will not see a 
>>"significant" difference.
>>    
>>
>
>Well, 25% seems significant to me.
>
>I don't want to come accross as some NIOS fanboy, because I'm not.
>It's just those are the facts as I seem them.
>  
>
>Cheers,
>Jon
>
Göran


Article: 69947
Subject: Re: What can I do if my chip can't meet timing?
From: jon@beniston.com (Jon Beniston)
Date: 25 May 2004 07:39:24 -0700
Links: << >>  << T >>  << A >>
> My clock is 40MHz, but I have complicated FFT operations and other DSP
> stuff.
> The longest path is 25.8ns, though after I set the constraints at
> 23ns...Previously it
> was 27.5ns at constraints of 25ns...
> 
> What may I do now? How far can over constraining go? 

Keep going until the results don't get any better.

> The source codes are
> from
> other people so I can't change a lot of it.
> 
> Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

I think there is -opt_level (or something) that makes it work harder.

Also, you can set the P&R optimisation level.

Note: Estimated frequency after synthesis is not necessarily what you
will get after P&R.

> 
> Does Synplify optimize for speed? 

Yes.

> How does it compare with XST?

I have found it to be better. The extra performance is often very
heavily design dependant. More often than not, for me, it performs
much better with large designs.

Cheers,
JonB

Article: 69948
Subject: Re: What can I do if my chip can't meet timing?
From: Shalin Sheth <Shalin.Sheth@xilinx.com>
Date: Tue, 25 May 2004 08:37:49 -0700
Links: << >>  << T >>  << A >>
You may want to try to run map with the '-timing' option.

For more ideas check out this Tech Tip from Xilinx:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=rw_tim_closure

Shalin-

Jon Beniston wrote:
>>My clock is 40MHz, but I have complicated FFT operations and other DSP
>>stuff.
>>The longest path is 25.8ns, though after I set the constraints at
>>23ns...Previously it
>>was 27.5ns at constraints of 25ns...
>>
>>What may I do now? How far can over constraining go? 
> 
> 
> Keep going until the results don't get any better.
> 
> 
>>The source codes are
>>from
>>other people so I can't change a lot of it.
>>
>>Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?
> 
> 
> I think there is -opt_level (or something) that makes it work harder.
> 
> Also, you can set the P&R optimisation level.
> 
> Note: Estimated frequency after synthesis is not necessarily what you
> will get after P&R.
> 
> 
>>Does Synplify optimize for speed? 
> 
> 
> Yes.
> 
> 
>>How does it compare with XST?
> 
> 
> I have found it to be better. The extra performance is often very
> heavily design dependant. More often than not, for me, it performs
> much better with large designs.
> 
> Cheers,
> JonB


Article: 69949
Subject: Re: Driving fpga pin out over long cable
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 25 May 2004 15:56:46 GMT
Links: << >>  << T >>  << A >>
How about this weird idea:  Don't send a pulse, send an edge.  Your
attenuation might provide a little phase shift but it would be pretty easy
to alter the phase to match the clocks.  Rather than a smeared pulse with
low high-level amplitudes, you get a full transition with a consistent 50%
point.


"Tom Derham" <uceeted@ucl.ac.uk> wrote in message
news:xtvsc.1724$hu1.16883825@news-text.cableinet.net...
> I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design
> running with a 100MHz master clock.  This clock is derived from a single
> source and distributed to each board so they are synchronised.  The boards
> are postioned about 50m apart.
>
> I need to synchronise events on the boards, but occasionally sending a
> single pulse (say 10ns long) from the output pin of one of the FPGAs to
the
> other boards, to allow them to synchronise internal timers.  I need to
make
> sure that the pulse arrives at the other two boards at the same time so
that
> it is 'recognised' on the same rising edge of the reference clock in each
> case, so that the boards synchronise together.
>
> Clearly the attenuation of any 50m length of cable is such that I cannot
> connect them directly, but nor do I want the complexity of converting the
> pulse to optical fibre and back again.
> For the distribution of the reference clock I am using National CLC005/012
> driver and equaliser chipset over UTP, using equal length wires so as to
not
> introduce propagation skew.  For practical reasons I can't use the same
> cable for sending this event pulse, and ideally would like a simple,
elegant
> solution.
> I was just wondering if anyone had done anything similar before... if not,
I
> have a back-up plan using more of the National drivers, but I thought they
> might be a sledgehammer to crack a nut - and am unsure what levels of skew
> they may introduce themselves... jitter is not so important because the
> event is resynced at the receiving fpga, as long as the total difference
in
> edge is less than half of the reference clock cycle (so 5ns).
>
> Thank you in advance for any ideas....
>
>





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