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 138875

Article: 138875
Subject: libxdh_PartAnno.dll
From: StYm <satyam.dwivedi@gmail.com>
Date: Thu, 12 Mar 2009 23:16:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
My Xilinx EDk (XPS) is not starting. It is giving error:

"This application has failed to start because libXdh_Part_Anno.dll was
not found. Re-installing the application may fix this problem."

I reinstalled, but of no use.

Can anyone help ??

Thanks,

Satyam

Article: 138876
Subject: DMCA and Google Groups
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 13 Mar 2009 01:42:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

it has come to my attention that I have commented in Google threads
where the original posting was in violation with DMCA.

unfortunatly those threads may get archived in the way that it is not
clear any more from whom the information is originating.

http://groups.google.co.uk/group/comp.arch.fpga/search?hl=en&group=comp.arch.fpga&q=can_tl_bsp&qt_g=Search+this+group

the above link as of today returns a thread with 3 posts, and listing
me as author? however none of the 3 posts are from me. I think I
posted later on that thread, but my posts seem to be removed while my
name is still attached to the thread.

I herein promise todo all my best not to post on threads where
previous postings may violate DMCA or copyrights. And of course I will
not make such postings myself as I have not done to my knowledge
before either.

Antti Lukats

Article: 138877
Subject: Re: What happens at opencores.org?
From: Jeremy Bennett <jeremy.bennett@embecosm.com>
Date: Fri, 13 Mar 2009 04:05:15 -0500
Links: << >>  << T >>  << A >>
On Wed, 11 Mar 2009 16:36:44 +0100, Martin Schoeberl wrote:

> Hi all,
> 
> looks like opencores.org changes it's hosting strategies without asking
> their user and core providers. At the moment the CVS access is down and
> it looks like they changed to SVN. Without a notice to the core
> providers.
> 
Hi Martin,

ORSoC AB, who took over responsibility for OpenCores in late 2007, have 
reimplemented the entire website back end. The switch over was earlier 
this week, but I believe has been in planning since the take over. At the 
same time they have switched to Subversion.

The website is mostly back up, and subversion access seems to work. The 
old mailing lists are now web based forums with email notification. I 
suggest you try posting there to try to get more information.

HTH,


Jeremy

Article: 138878
Subject: Re: I2C EEPROM
From: David Fejes <fejesd@gmail.com>
Date: Fri, 13 Mar 2009 03:55:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

Maybe this is a bit offtopic but may I ask you what kind of I2C ipcore
do you use? I have to implement some i2c slave logic with some
readable and writable registers in my next design and I'm curious
about that..

thank you in advance

On Mar 12, 5:05=A0am, Digi Suji <digis...@gmail.com> wrote:
> Hi,
>
> I am trying to read a byte from a particular address in I2C EEPROM.
> But the data I get is from a different location. For example, if try
> to read data from "x05" location, the byte from "x0B" location is
> read. If try to read data from "x06" location, data from "x0D" is
> read. If I try to read data from "x07", data from "x0F" is read. If
> you notice above situation, a fixed pattern is followed.
>
> I am using a I2C Master Core controller to read data from I2C EEPROM.
> Xilinx Post route simulation works fine but when I try to configure
> the Spartan 3E FPGA, I get the above described results. I2C EEPROM is
> external to the FPGA and I2C controller goes in to the FPGA.
>
> I am confused as to why is this happening. Can any one please help.
>
> Thanks.


Article: 138879
Subject: Re: What happens at opencores.org?
From: marcus.erlandsson@gmail.com
Date: Fri, 13 Mar 2009 04:21:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
The OpenCores team are putting in enormous resources in making sure
that
the OpenCores will continue to exist/expand. It is important that the
platform can continue to support good services to both
users and core-providers, also for the next 10-20 years. If possible
it is
also good if we can provide an even greater =93trust=94 and =93quality=94 i=
n
the
cores at OpenCores.

The complete redesign of the OpenCores-platform enable us to support
all
users with a future-proof and professional site. It also support
integrating
new functionalities much easier then before, since the old
platform had grown out of proportion.


We feel that we have listen to the community, since we get allot of
Feedback - i.e. complaining about poor statistics, forum structure,
etc. But
unfortunately we also get some few complaints from a small portion of
users
that are just against all changes :-(


But for those users who has more concrete suggestion/ideas/
improvements,
feel free to contact us at oc-team@opencores.org



Best regards,

The OC-team

Article: 138880
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 13 Mar 2009 05:39:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mar, 05:22, Jacko <jackokr...@gmail.com> wrote:
> On 12 Mar, 21:44, rickman <gnu...@gmail.com> wrote:
>
> > On Mar 12, 1:30 pm, Jacko <jackokr...@gmail.com> wrote:
>
> > > hi
>
> > > 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16
> > > bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS
> > > at 20MHz.
>
> > > cheers jacko
>
> > What's a MIPS? =A0Native instructions? =A0Or something that can be
> > compared to other processors?
>
> Native instructions. Fetch/execute, and Fetch/execute/execute (SUm
> instruction).
>
> > I have yet found a good way to compare these small, FPGA CPUs. =A0The
> > ZPU is pretty small, but the originator seems to still think in terms
> > of Dhrystones. =A0I can't begin to measure my processor in Dhrystones.
>
> I do not yet have any C compilier so drystones are not measurable.
>
> > The original imnplementation was about 600 LUTs, 50 MHz, 50 MIPS in an
> > Altera ACEX 1K part (very old and pretty slow). =A0I am working to
> > update it for a more current FPGA.
>
> A re-implementation of the ALU is possible to improve clock rate, but
> the area does increase as it is a 16 bit ALU, with 4 operations. So 4
> ops * 4way multiplex. The reason for using a carry chain is that the
> alu shrinks as some of the multiplex is merged with the alu operations
> (not much more complicated than just add in luts). I understand from
> altera support that the two lut3 arithmetic mode is not really used,
> and so fast carry propagation is not done, and it is the critical
> path, hence the extra cycle inserted.
>
> A harvard architecture is not used. Code density is reasonably high
> using threaded subroutines, as no jump opcode has to prefix the jump
> address. In full ASIC custom logic such carry propergation issues are
> not as dominant .So considering each instruction is 16 bit data in
> width, the processor is quite impressivly small. If only the carry
> chain was used effectively in lut4 mode.
>
> Of course all optimization was for area, and not speed, with no
> retiming. Just the register duplication (2 LEs) for increased
> routability. Yes lack of high level software tools is a real pain for
> product design. But I'm slowly working on that. I do not have a major
> development team. I am just me, and this is not paid work.
>
> I think my offer of 1 free core per chip, for just a logo print, and
> documentation copyright recognition and URL is very good. Especially
> as this offer unlike the still standing BSD offer allows derived
> products without revealing the derived source.
>
> Cheers jacko

Jacko

what you think as "good" is not the same what others think.

you !=3D others;

if you use BSD license you can not attach it to the FIRST
instance of the core inside and asic or fpga, meaning
the user is free to use ANY number of copies of the
core, your restriction is not valid...

as of the logo print, sorry if you do not understand it,
even if the core and other copyright restrictions by
you may be ok for the legal department of large scale
corporation, the logo print will not be... for sure
not with that low quality bitmap, and also not when
you make better artwork also very unlikely

so what you are asking and what you think is good
is actually something that will drive any potential
users (if there are any) away from using the core.

if you want some $$$ then you should offer some
commercial licensing, not try get money from
paypal donations and indirect advertizement
by the logo print of yours...

my 3 cents

Antti

Article: 138881
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Herbert Kleebauer <klee@unibwm.de>
Date: Fri, 13 Mar 2009 14:02:21 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
 
> > I am still looking for a good small soft-core, and well it seem
> > not to exist...
> 
> I seem to recall that you were trying to find a bit serial CPU that
> would be the smallest possible in an FPGA.  

I don't think it is possible to make a serial CPU smaller than
a parallel one. Here is a 16 bit CPU with interrupt support 
built with only 65 flip-flop's. If you reduce the size to 
12 bit (3 kbyte memory space) you can even save 12 flip-flop's.

http://www.bitlib.de/pub/mproz/mproz3_e.pdf  (with internal RAM)
http://www.bitlib.de/pub/mproz/mproz2a.pdf    (with external RAM)

schematics in the zip files:

http://www.bitlib.de/pub/mproz/


Article: 138882
Subject: Re: MPCM3/XPS_LL_TEMAC with SFP/1000base-X
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 13 Mar 2009 06:38:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Jan, 12:05, Antti <Antti.Luk...@googlemail.com> wrote:
> On Jan 27, 9:08=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > On Jan 25, 10:34=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > Now when xilinx web is back online, well they do no have not a single
> > > reference design for the ethernet usingSFPoptical links
> > > all the demos are for the marvell SGMII phy only
>
> > > i tried to change the TEMAC PHY form SGMII to 1000base-x but
> > > unfortunatly the system did not work after that.
> > > well all phy registers readback 0, so maybe there is some major
> > > problem with some clocking, and there are no other changes
> > > required, but i kinda can not belive that xilinx has not ever
> > > made abase1000-xbased system for some of their board (ml405/ml505..)
>
> > > Antti
>
> > ok, i have a reference design, but our ownSFP/ethernet design still
> > doesnt work after MPMC2-MPMC3 migration
>
> > Antti
>
> it all works!!
>
> but we had to decrypt some more xilinx encrypted IP core sources
> and change low level settings of the MGT and hard TEMAC
>
> Antti

the decrypted files can be downloaded from Xilinx FTP site

ftp://ftp.xilinx.com/pub/swhelp/ip_updates/ar31919_xps_ll_temac_v1_01_b.zip

so there is no need to seek other solutions

Antti Lukats




Article: 138883
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Jacko <jackokring@gmail.com>
Date: Fri, 13 Mar 2009 08:06:26 -0700 (PDT)
Links: << >>  << T >>  << A >>

> Jacko
>
> what you think as "good" is not the same what others think.
>
> you != others;

I never said others may think this is a good offer, just that I think
it is a good offer.

> if you use BSD license you can not attach it to the FIRST
> instance of the core inside and asic or fpga, meaning
> the user is free to use ANY number of copies of the
> core, your restriction is not valid...

If BSD is used then BSD it is, BSD does not prevent me from doing what
I want with MY source, and so I am able to offer OTHER licences. The 1
core per chip licence is not BSD, instead I am making another issue of
the code under my copyright, in acordance with my wishes.

You are correct with respect to the licence used for the BSD issue.
But theat issue would not allow using proprietory logic, without that
other logic also being made part of the BSD.

> as of the logo print, sorry if you do not understand it,
> even if the core and other copyright restrictions by
> you may be ok for the legal department of large scale
> corporation, the logo print will not be... for sure
> not with that low quality bitmap, and also not when
> you make better artwork also very unlikely

What's so difficult about the reproduction of a BW image, also this
non BSD licence version did in no way specify the size that the logo
had to be printed at.

> so what you are asking and what you think is good
> is actually something that will drive any potential
> users (if there are any) away from using the core.

?

> if you want some $$$ then you should offer some
> commercial licensing, not try get money from
> paypal donations and indirect advertizement
> by the logo print of yours...

I have not refused any offer of comercial licencing, although I do
think that more than 1 core per chip is a little way off.

> my 3 cents

Fair enough

cheers jacko

Article: 138884
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Jacko <jackokring@gmail.com>
Date: Fri, 13 Mar 2009 08:34:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mar, 13:02, Herbert Kleebauer <k...@unibwm.de> wrote:
> rickman wrote:
> > > I am still looking for a good small soft-core, and well it seem
> > > not to exist...
>
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA. =A0
>
> I don't think it is possible to make a serial CPU smaller than
> a parallel one. Here is a 16 bit CPU with interrupt support
> built with only 65 flip-flop's. If you reduce the size to
> 12 bit (3 kbyte memory space) you can even save 12 flip-flop's.
>
> http://www.bitlib.de/pub/mproz/mproz3_e.pdf=A0(with internal RAM)http://w=
ww.bitlib.de/pub/mproz/mproz2a.pdf=A0 =A0(with external RAM)
>
> schematics in the zip files:
>
> http://www.bitlib.de/pub/mproz/

Interesting MISC design. Any idea what the LE count is?

Extra features offered by nibz.

-- predecrement/postincrement
-- a logic accumulator
-- faster indexing
-- subroutine support instructions
-- a parameter stack
-- a clock counter

Features not currently offered by nibz

-- interrupt support

cheers jacko

Article: 138885
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Walter Banks <walter@bytecraft.com>
Date: Fri, 13 Mar 2009 11:06:38 -0500
Links: << >>  << T >>  << A >>


Herbert Kleebauer wrote:

> rickman wrote:
>
> > > I am still looking for a good small soft-core, and well it seem
> > > not to exist...
> >
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA.
>
> I don't think it is possible to make a serial CPU smaller than
> a parallel one. Here is a 16 bit CPU with interrupt support
> built with only 65 flip-flop's. If you reduce the size to
> 12 bit (3 kbyte memory space) you can even save 12 flip-flop's.
>
> http://www.bitlib.de/pub/mproz/mproz3_e.pdf  (with internal RAM)
> http://www.bitlib.de/pub/mproz/mproz2a.pdf    (with external RAM)
>
> schematics in the zip files:
>
> http://www.bitlib.de/pub/mproz/

Serial processors only require a 1 bit alu, registers are shift registers
with a single in and out data line. The availability of large lowcost
bit serial memories like SD cards opens the possibility of creating a
small processor.

There may be issues how a serial processor design will map on the current
parts but the logic is significantly simpler that an equivalent parallel
design. None of this is free. The resulting processor will be slower for
the same clock speed.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com








Article: 138886
Subject: Re: What happens at opencores.org?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 13 Mar 2009 10:10:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mar, 13:21, marcus.erlands...@gmail.com wrote:
> The OpenCores team are putting in enormous resources in making sure
> that
> the OpenCores will continue to exist/expand. It is important that the
> platform can continue to support good services to both
> users and core-providers, also for the next 10-20 years. If possible
> it is
> also good if we can provide an even greater =93trust=94 and =93quality=94=
 in
> the
> cores at OpenCores.
>
> The complete redesign of the OpenCores-platform enable us to support
> all
> users with a future-proof and professional site. It also support
> integrating
> new functionalities much easier then before, since the old
> platform had grown out of proportion.
>
> We feel that we have listen to the community, since we get allot of
> Feedback - i.e. complaining about poor statistics, forum structure,
> etc. But
> unfortunately we also get some few complaints from a small portion of
> users
> that are just against all changes :-(
>
> But for those users who has more concrete suggestion/ideas/
> improvements,
> feel free to contact us at oc-t...@opencores.org
>
> Best regards,
>
> The OC-team

it seems that many links are now dead or then project deleted :(

too bad

Antti

Article: 138887
Subject: Re: What happens at opencores.org?
From: marcus.erlandsson@gmail.com
Date: Fri, 13 Mar 2009 10:41:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 13, 6:10=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On 13 Mar, 13:21, marcus.erlands...@gmail.com wrote:
>
>
>
> > The OpenCores team are putting in enormous resources in making sure
> > that
> > the OpenCores will continue to exist/expand. It is important that the
> > platform can continue to support good services to both
> > users and core-providers, also for the next 10-20 years. If possible
> > it is
> > also good if we can provide an even greater =93trust=94 and =93quality=
=94 in
> > the
> > cores at OpenCores.
>
> > The complete redesign of the OpenCores-platform enable us to support
> > all
> > users with a future-proof and professional site. It also support
> > integrating
> > new functionalities much easier then before, since the old
> > platform had grown out of proportion.
>
> > We feel that we have listen to the community, since we get allot of
> > Feedback - i.e. complaining about poor statistics, forum structure,
> > etc. But
> > unfortunately we also get some few complaints from a small portion of
> > users
> > that are just against all changes :-(
>
> > But for those users who has more concrete suggestion/ideas/
> > improvements,
> > feel free to contact us at oc-t...@opencores.org
>
> > Best regards,
>
> > The OC-team
>
> it seems that many links are now dead or then project deleted :(
>
> too bad
>
> Antti

Hi Antti.
Actually, there are more project now visible, then before. But some
projects where started 2000-2004, but never completed and no one has
updated the project ever since. These project will be moved to another
category shortly, so that it is clear to all users which project that
are ready and not. Send an email to oc-team@opencores.org and let us
know what project has been deleted, so that we can double check this.

As for the links, we will be fixing allot of the "broken" links within
the next coming weeks..


Best regards,
The OC-team


Article: 138888
Subject: Re: DDR access on Spartan 3E 500 Starter Kit
From: vinayaksanthosh@gmail.com
Date: Fri, 13 Mar 2009 11:24:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 6, 5:50=A0am, Keith M <kmo...@gmail.com> wrote:
> So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has
> onboard ddr memory to which I'd like to get access.
>
> What's the best way to get a simple read/write interface to the
> memory? =A0I'm learning verilog and prefer examples or code written in
> it.
>
> I've tried a couple options:
>
> 1. Memory Interface Generator from Xilinx. (MIG 23) =A0This looks like
> the most robust solution, but the code that is output seems overly
> complicated, mostly uncommented, and the example test bench is
> anything but straight forward. =A0The user guide UG086 is written ok.
>
> 2. Couple of opencores solutions, including ddr ctrl (the non wishbone
> version) =A0While it's commented better, there is zerodocumentation. =A0I
> can't get it to synthesize even though it's specifically designed for
> my kit. =A0The problems are related to .ucf constraints, but when I
> manually look through them, most of them seem ok. =A0It's as if the
> format of the .ucf file is not what XST(or whatever component that is)
> expects, so it generates about 40 errors.
>
> Is accessing this DDR memory more simple viaPicoblazeor Microblaze?
> Is Microblaze and associated parts free? =A0I didn't get any CDs
> whatsoever w/ my board.
>
> Thanks
>
> Keith

inorder to access thew memory u either need to perform most of the pre
functions say initialising ,charging,commands   etc . Better u use the
controller
       i was able to use the opencores ddr controller however i am
stuck at the point of controlling the ddr controller with the
picobalze controller.
      if u know a way please share it with me

Article: 138889
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Herbert Kleebauer <klee@unibwm.de>
Date: Fri, 13 Mar 2009 20:56:52 +0100
Links: << >>  << T >>  << A >>
Walter Banks wrote:
> Herbert Kleebauer wrote:

> > I don't think it is possible to make a serial CPU smaller than
> > a parallel one. Here is a 16 bit CPU with interrupt support
> > built with only 65 flip-flop's. 

> Serial processors only require a 1 bit alu, registers are shift registers
> with a single in and out data line. The availability of large lowcost
> bit serial memories like SD cards opens the possibility of creating a
> small processor.

Yes, you will save some logic if you use a 1 bit alu, but that's not
as much as you have to add for controlling the serial alu.

The goal was to make the smallest possible CPU which can at 
least address 32 kbyte RAM and supports interrupts. The first
idea was to use a serial design, but if you spend some time
thinking about it, then you will see that you never can get
it as small as a 16 bit design (also a 8 bit design is bigger
than a 16 bit design). This is at least true for the gate count,
if you also consider the routing resources then the difference
may be smaller.


Article: 138890
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 13 Mar 2009 13:39:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mar, 21:56, Herbert Kleebauer <k...@unibwm.de> wrote:
> Walter Banks wrote:
> > Herbert Kleebauer wrote:
> > > I don't think it is possible to make a serial CPU smaller than
> > > a parallel one. Here is a 16 bit CPU with interrupt support
> > > built with only 65 flip-flop's.
> > Serial processors only require a 1 bit alu, registers are shift registers
> > with a single in and out data line. The availability of large lowcost
> > bit serial memories like SD cards opens the possibility of creating a
> > small processor.
>
> Yes, you will save some logic if you use a 1 bit alu, but that's not
> as much as you have to add for controlling the serial alu.
>
> The goal was to make the smallest possible CPU which can at
> least address 32 kbyte RAM and supports interrupts. The first
> idea was to use a serial design, but if you spend some time
> thinking about it, then you will see that you never can get
> it as small as a 16 bit design (also a 8 bit design is bigger
> than a 16 bit design). This is at least true for the gate count,
> if you also consider the routing resources then the difference
> may be smaller.

it all depends the useage scenario

if BLOCK RAMs are available, it one concept
if not it different...

mproz executing code from serial flash would be
highly inefficient in terms of clock cycles wasted

so it different goals.

mproz uses 3 words per instruction, if code space
is 8mb or 8gb as for in place execute from sd
then it would be 12 bytes to read per instruction

a serialized design that aligns alu operations
with the speed of serially fetched instruction
bits would achive much better speed

Antti


Article: 138891
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 13 Mar 2009 21:22:11 +0000
Links: << >>  << T >>  << A >>
On Fri, 13 Mar 2009 13:39:33 -0700 (PDT), Antti.Lukats wrote:

>a serialized design that aligns alu operations
>with the speed of serially fetched instruction
>bits would achive much better speed

I have absolutely no idea what you mean by this.

I tend to agree with Herbert Kleebauer: if you 
are doing something highly iterative and pipelined,
and your algorithm is fixed, then a bit-serial
approach may save significant resources; but 
for a CPU that needs to do real work that is
not predictable in advance, I don't see 
the advantage.  The parts of a CPU that can
reasonably be bit-serialized are not likely
to be a large fraction of the whole design's
area cost, and there is a non-trivial
control overhead.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138892
Subject: Re: DMCA and Google Groups
From: Kolja <ksulimma@googlemail.com>
Date: Fri, 13 Mar 2009 15:05:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Well, I herewith declare to happily ignore the DMCA while beeing
outside of the
US. I follow the laws of my country and international treaties. That
is more
than the US government can claim to do.

Kolja

> I herein promise todo all my best not to post on threads where
> previous postings may violate DMCA or copyrights. And of course I will
> not make such postings myself as I have not done to my knowledge
> before either.

Article: 138893
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Walter Banks <walter@bytecraft.com>
Date: Fri, 13 Mar 2009 17:36:39 -0500
Links: << >>  << T >>  << A >>


Herbert Kleebauer wrote:

> Walter Banks wrote:
> > Herbert Kleebauer wrote:
>
> > > I don't think it is possible to make a serial CPU smaller than
> > > a parallel one. Here is a 16 bit CPU with interrupt support
> > > built with only 65 flip-flop's.
>
> > Serial processors only require a 1 bit alu, registers are shift registers
> > with a single in and out data line. The availability of large lowcost
> > bit serial memories like SD cards opens the possibility of creating a
> > small processor.
>
> Yes, you will save some logic if you use a 1 bit alu, but that's not
> as much as you have to add for controlling the serial alu.
>

Bit serial will be slow but remember that the data paths to registers
are reduced. The logic is considerably simpler.

There are other advantages as well like the ability to have variable
length data types, reducing the number of instructions to do
multi-byte math.

Bit serial is slower, to be sure. The controller needed to use a
SD card is not very much.

There are many applications that could be well suited to a bit serial
processor, for example a data logger.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





Article: 138894
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Jacko <jackokring@gmail.com>
Date: Fri, 13 Mar 2009 15:46:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mar, 21:22, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 13 Mar 2009 13:39:33 -0700 (PDT), Antti.Lukats wrote:
> >a serialized design that aligns alu operations
> >with the speed of serially fetched instruction
> >bits would achive much better speed
>
> I have absolutely no idea what you mean by this.

I think he was implying that ALU could work serially in the clocks to
fectch in a word or SPI nibble of the next instruction. Although I am
not sure this would be that beneficial beyond a certain instruction
complexity due to the number of seperate multiplexed particulates
(steps) of the number of instructions, making a counter, decode
complexity and seperation of writeback assignments to register
intermediates. Oh yes and the comparator for checking when the number
of bits has been completed.

> I tend to agree with Herbert Kleebauer: if you
> are doing something highly iterative and pipelined,
> and your algorithm is fixed, then a bit-serial
> approach may save significant resources; but
> for a CPU that needs to do real work that is
> not predictable in advance, I don't see
> the advantage. =A0The parts of a CPU that can
> reasonably be bit-serialized are not likely
> to be a large fraction of the whole design's
> area cost, and there is a non-trivial
> control overhead.

Yes the control overhead can be larger than a lot of people expect.
The routing reduction is not as critical, due to channels of fpga, or
number of metal layers in custom ASIC.

I would be very interested in finding out what 16 instructions would
be favorite for such a nibble sd processor.

cheers jacko

Article: 138895
Subject: Re: What happens at opencores.org?
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 14 Mar 2009 01:16:43 +0100
Links: << >>  << T >>  << A >>
>> looks like opencores.org changes it's hosting strategies without asking
>> their user and core providers. At the moment the CVS access is down and
>> it looks like they changed to SVN. Without a notice to the core
>> providers.
>>
> Hi Martin,
>
> ORSoC AB, who took over responsibility for OpenCores in late 2007, have
> reimplemented the entire website back end. The switch over was earlier
> this week, but I believe has been in planning since the take over. At the
> same time they have switched to Subversion.

That is ok - we shall not start to discuss if CVS or SVN is better
(or git ;-). However, the switch was never announced to the developers.
We did notice it from the fact that the CVS access just did not work
anymore. If you're in a critcal development phase that's no fun when
you have to switch the repository system without planning ahead....

Cheers,
Martin 



Article: 138896
Subject: Re: What happens at opencores.org?
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 14 Mar 2009 01:22:13 +0100
Links: << >>  << T >>  << A >>
Hi Marcus,

I did post my complain about opencores to this group as my comments
on the redesign and the new rules on access policies have been
filtered out from the oc mailing list.

Let's say it friendly: I don't think it's the best policy to censor
slightly critical comments on a list for discussion on open-source
projects.

And now here my original complains from around half year ago ;-) I don't
like that access to open-source projects is restricted to registered
user because:
    1. that's in my opinion against the OS philosophy
    2. it makes is uncomfortable to 'just check a project'
    3. sending a link to one of my files in the CVS web view is not
    practical anymore
    4. it spams the list of possible developers. When I want to add
    one to the project it takes minutes to find that person in a web
    list box that contains hundreds (or more) entries

I really liked opencores, but I get the feeling that it is controlled
too much, or in a way I don't like...

BTW: I'm not a user who is against all changes.

Cheers,
Martin

----- Original Message -----
From: <marcus.erlandsson@gmail.com> Newsgroups: comp.arch.fpga Sent:
Friday, March 13, 2009 12:21 PM Subject: Re: What happens at
opencores.org?


The OpenCores team are putting in enormous resources in making sure
that the OpenCores will continue to exist/expand. It is important
that the platform can continue to support good services to both users
and core-providers, also for the next 10-20 years. If possible it is
also good if we can provide an even greater “trust” and “quality” in
the cores at OpenCores.

The complete redesign of the OpenCores-platform enable us to support
all users with a future-proof and professional site. It also support
integrating new functionalities much easier then before, since the
old platform had grown out of proportion.


We feel that we have listen to the community, since we get allot of
Feedback - i.e. complaining about poor statistics, forum structure,
etc. But unfortunately we also get some few complaints from a small
portion of users that are just against all changes :-(


But for those users who has more concrete suggestion/ideas/
improvements, feel free to contact us at oc-team@opencores.org



Best regards,

The OC-team



Article: 138897
Subject: XST: Unconnected output pins
From: "Mad I.D." <madid87@gmail.com>
Date: Fri, 13 Mar 2009 17:43:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
When I do this in component instantiation statement
"...out_port=>out_port, read_strobe=>open..."
i get warnings.

I don't need read_strobe so I leave it open. (input pins are all used
or tied). XST gives a warning. Is there any smarter way to "not use a
output pin" or I just ignore that warning ?

Thank you !

Article: 138898
Subject: Re: XST: Unconnected output pins
From: newman5382@yahoo.com
Date: Fri, 13 Mar 2009 18:20:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 13, 8:43=A0pm, "Mad I.D." <madi...@gmail.com> wrote:
> When I do this in component instantiation statement
> "...out_port=3D>out_port, read_strobe=3D>open..."
> i get warnings.
>
> I don't need read_strobe so I leave it open. (input pins are all used
> or tied). XST gives a warning. Is there any smarter way to "not use a
> output pin" or I just ignore that warning ?
>
> Thank you !

If you right click on the message, there are options to filter the
message which leaves it to the designer's discretion.  I've tried
connecting a dummy wire to the unused output and xor similar wires to
an unused output pin.  This flags me that I have looked at the
situation but does result in code clutter, unrealized trimming of
circuitry, additional unneeded circuitry, etc.

Article: 138899
Subject: Re: XST: Unconnected output pins
From: newman5382@yahoo.com
Date: Fri, 13 Mar 2009 18:56:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 13, 9:20=A0pm, newman5...@yahoo.com wrote:
> On Mar 13, 8:43=A0pm, "Mad I.D." <madi...@gmail.com> wrote:
>
> > When I do this in component instantiation statement
> > "...out_port=3D>out_port, read_strobe=3D>open..."
> > i get warnings.
>
> > I don't need read_strobe so I leave it open. (input pins are all used
> > or tied). XST gives a warning. Is there any smarter way to "not use a
> > output pin" or I just ignore that warning ?
>
> > Thank you !
>
> If you right click on the message, there are options to filter the
> message which leaves it to the designer's discretion. =A0I've tried
> connecting a dummy wire to the unused output and xor similar wires to
> an unused output pin. =A0This flags me that I have looked at the
> situation but does result in code clutter, unrealized trimming of
> circuitry, additional unneeded circuitry, etc.

IIRC, if one can omit the output within coregen so it does not show up
in the instance, that helps too.




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