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 140175

Article: 140175
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: LittleAlex <alex.louie@email.com>
Date: Fri, 1 May 2009 11:30:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 8:14 am, "MM" <mb...@yahoo.com> wrote:
> <Antti.Luk...@googlemail.com> wrote in message
>
> news:beb204d5-4792-4298-afb5-85b167e7e32f@b7g2000pre.googlegroups.com...
>
>
>
> >So for me it is clear that the OP doesnt want to pay $3395 for the EDK
> >license (and this is for one year only!).
>
> Antti,
>
> We have a team of 3 people (1 hardware, and 2 software, one of which is
> occasional) and I need to find an optimal licensing solution for all.
>
> /Mikhail

Brand-A has been using FlexLM licensing for years.  Their method
allows you to install w/o violating the terms, because the  software
in non-functional without the proper license file.  A license is NOT
needed to compile the firmware; only to build the chip.

For a software-only work I install the Q/N package, and the "hardware
guy" (who has the only license) shares 3 files with the "software
guy", and everyone is good to go.  Everybody does need their own JTAG
dongle, but they're cheap.

I would hope that the Brand-X licensing would allow the same.  If not,
they have shot themselves in the foot, and have only themselves to
blame.

$.02,
AL

Article: 140176
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: no_spa2005@yahoo.fr
Date: Fri, 1 May 2009 12:50:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

Even if I'm quite a "Xilinx "fan", I hate the new policy of  Xilinx
license. In my previous company, we'd bought as many license as the
number of FPGA engineers but we installed ISE on more PC : for lab,
for home (for work or to learn), for some developers who works on EDK
for few weeks/months and personally, I'd luck to have to 2 PC and I'd
installed ISE 10.1 on both with same license and now, it's impossible.
How to tell them it's very a bad idea ? Does they know that for a
small company it can be expensive and have a limited number of
licenses can reduce productivity (work at home for instance) ? What is
your opinion ?
Regards.

Article: 140177
Subject: Re: offset out
From: metinnn@gmx.de
Date: Fri, 1 May 2009 13:54:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 4:39=A0pm, "MM" <mb...@yahoo.com> wrote:
> There is no way to define minimum CLK to OUT with the OFFSET constraint.
> Instead you should make sure that the output flip-flops are placed in the
> IOBs and choose an IO standard with parameters hopefully matching your
> timing requirements. You can also move your output clock edge in a few
> different ways if needed.
>
> /Mikhail

Ok,

this matches with my assumptions.
But then, at least i must be able to check min output
timing after PAR.

So, for a given speed grade all i need to do is to check the option
"report fastest paths/verbose
hold paths" in timing report options. If the numbers listed there are
bigger
than my requirements i don't have to worry.

Metin

Article: 140178
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: LittleAlex <alex.louie@email.com>
Date: Fri, 1 May 2009 14:01:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 12:50 pm, no_spa2...@yahoo.fr wrote:
> Hi all,
>
> Even if I'm quite a "Xilinx "fan", I hate the new policy of  Xilinx
> license. In my previous company, we'd bought as many license as the
> number of FPGA engineers but we installed ISE on more PC : for lab,
> for home (for work or to learn), for some developers who works on EDK
> for few weeks/months and personally, I'd luck to have to 2 PC and I'd
> installed ISE 10.1 on both with same license and now, it's impossible.
> How to tell them it's very a bad idea ? Does they know that for a
> small company it can be expensive and have a limited number of
> licenses can reduce productivity (work at home for instance) ? What is
> your opinion ?
> Regards.

My opinion?  It is brave of you to ask.

My opinion is that Xilinx is motivated to sell silicon.  Improving my
or your productivity is not their first goal.

I understand that in the past, Xilinx had to pay a per-seat fee to the
supplier of their synthesis software, so controlling the number of
copies was important to them.  It is entirely possible that there are
features in their current suite that have similar fees attached.

I am rational enough to accept that Xilinx will provide priority to
the large user, and my hobby activity is more of a marketing cost than
a design win.  I wonder if a 3-man design team counts as a "large"
user.

How do you tell them that this is a bad idea?  By designing in Altera
or LatticeSemi parts.

AL

Article: 140179
Subject: Re: offset out
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 1 May 2009 17:08:37 -0400
Links: << >>  << T >>  << A >>
<metinnn@gmx.de> wrote in message 
news:4f17ca42-b62b-47f2-a7fe-d611b05857b9@f19g2000yqh.googlegroups.com...
>
> But then, at least i must be able to check min output
> timing after PAR.

I don't think minimum is ever guaranteed.


/Mikhail 



Article: 140180
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: Andy Peters <google@latke.net>
Date: Fri, 1 May 2009 14:13:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 8:09=A0am, "MM" <mb...@yahoo.com> wrote:
> "MikeWhy" <boat042-nos...@yahoo.com> wrote in message
>
> news:s%yKl.15543$hc1.2411@flpi150.ffdc.sbc.com...
>
>
>
> > What would that workflow look like? Seems to me anything useful would
> > involve a license violation of some sort. I hate to be the one to say
> > this, but MS has a Lite version of VS2008 for free download. As with
> > Eclipse, you either love it or you hate it, and I happen to hate Eclips=
e.
> > Why bother with SDK? (That wasn't rhetorical. I'm wondering this moment=
 if
> > there's something awefully compelling to make you contemplate what you'=
re
> > contemplating.)
>
> We currently have to support two projects. From the hardware point of vie=
w
> both of them have top level in ISE and both include a PPC subsystem. One =
is
> implemented in V4FX60 and another in V4FX20/40. On the software side the
> bigger board runs under VxWorks and we are using VxWorks design environme=
nt
> (another Eclipse) for the application software development. However, to
> build a BSP for that board, EDK has to be run on a PC where VxWorks is
> installed or at least that's what we believe, I can imagine that this can=
 be
> worked around somehow. As mostly a hardware designer I don't have VxWorks=
 on
> my PC, so this step is done by a software person. The smaller board runs
> with no OS and the application for it is maintained in SDK. I think debug=
ger
> facility in SDK will not work if EDK is not installed. Also, starting fro=
m
> 10.1 or perhaps even 9, SDK would alsways ask for an xmp file when starte=
d
> and it would then try to verify if BSP is up to date. I can't see how thi=
s
> will work without EDK...
>
> /Mikhail

I am told by the support person for an SDK Web Case that 11.1's SDK is
"more separate" from EDK than previous versions. Xilinx' intent for
SDK was always for the hardware guys to finish the FPGA design and
throw it over the wall to the software guys who are supposed to use
SDK.* But as it is now, SDK still requires EDK features.

I have not checked to see whether that assertion is true.

-a

* I know, this whole concept is ridiculous.

Article: 140181
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "StoneThrower" <digi_64-public[removethis]@yahoo.com>
Date: Fri, 1 May 2009 23:28:07 +0200
Links: << >>  << T >>  << A >>
> How do you tell them that this is a bad idea?  By designing in Altera
> or LatticeSemi parts.
My 25 cents for this tought ...
Or maybe Actel parts ... those flash, non-volatile ones, AFAIR, Igloo is the 
name. With ARM IP along with it.

-- 
StoneThrower
www.dgmicrosys.com


Article: 140182
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Fri, 1 May 2009 16:57:12 -0500
Links: << >>  << T >>  << A >>
<Antti.Lukats@googlemail.com> wrote in message 
news:beb204d5-4792-4298-afb5-85b167e7e32f@b7g2000pre.googlegroups.com...
well, the worry of OP comes from the fact that with 11.1 there is no
price
given for EDK any more, the only possibility to obtain EDK includes
buying
a package that includes a FULL ISE version.

so if you want EDK 11.1, you can buy it from Avent: 3395$ stock NO,
lead time 26 weeks, or
nuhorizons, price 3395, stock NO, lead time 2 weeks.

ISE/EDK or any other software is no longer available from Xilinx
online store, only from distributors.

So for me it is clear that the OP doesnt want to pay $3395 for the EDK
license (and this is for one year only!).

===============
I almost took that for gospel. Xilinx lists separate licensing for the EDK, 
SDK, and even DSP tools. 
http://www.xilinx.com/onlinestore/design_resources.htm

Node-locked license prices are as follows. Floating license are $100 more 
per seat.

EDK: $500
SDK: $200
CSP: $700

These seem to me to be in line with what I recall of the old pricing.

I'm affected because they no longer list separate licensing for system 
generator without acceldsp. Chipscope Pro appears to be sold only with CSP 
Serial. I don't recall the old pricing. It might be a useful bundling of 
additional functionality at low or no extra cost, or significantly higher 
cost for tools and functionality you don't and didn't need.



Article: 140183
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 01 May 2009 16:15:09 -0700
Links: << >>  << T >>  << A >>
no_spa2005@yahoo.fr wrote:
> Hi all,
> 
> Even if I'm quite a "Xilinx "fan", I hate the new policy of  Xilinx
> license. In my previous company, we'd bought as many license as the
> number of FPGA engineers but we installed ISE on more PC : for lab,
> for home (for work or to learn), for some developers who works on EDK
> for few weeks/months and personally, I'd luck to have to 2 PC and I'd
> installed ISE 10.1 on both with same license and now, it's impossible.
> How to tell them it's very a bad idea ? Does they know that for a
> small company it can be expensive and have a limited number of
> licenses can reduce productivity (work at home for instance) ? What is
> your opinion ?
> Regards.

Your posts indicates that your company buys 1 license per 1 engineer.

Under the 11.1 licensing system you can have a license server that 
manages your pool of floating licenses and have ISE 11.1 installed on 
any number of machines in your office.

Working from home is a different issue, but so long as the engineer has 
connection to the work network then there won't be any problem.

Ed McGettigan
--
Xilinx Inc.

Article: 140184
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Fri, 1 May 2009 22:38:04 -0500
Links: << >>  << T >>  << A >>
"MikeWhy" <boat042-nospam@yahoo.com> wrote in message news:...
> <Antti.Lukats@googlemail.com> wrote in message Node-locked license prices 
> are as follows. Floating license are $100 more per seat.
>
> EDK: $500
> SDK: $200
> CSP: $700
>
> These seem to me to be in line with what I recall of the old pricing.
>
> I'm affected because they no longer list separate licensing for system 
> generator without acceldsp. Chipscope Pro appears to be sold only with CSP 
> Serial. I don't recall the old pricing. It might be a useful bundling of 
> additional functionality at low or no extra cost, or significantly higher 
> cost for tools and functionality you don't and didn't need.

Pardon my musing... Regarding node-locked, is that tied to the MAC address 
on an Ethernet device on the licensed system? ??? ??? ??? ??? That seems to 
me to be self defeating for the product being licensed. Maybe I'm wrong and 
somebody really took the time and thought this through. What other "node" 
can they lock to?



Article: 140185
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 2 May 2009 00:26:11 -0400
Links: << >>  << T >>  << A >>
"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:wePKl.28356$yr3.9710@nlpi068.nbdc.sbc.com...
>
> Pardon my musing... Regarding node-locked, is that tied to the MAC address 
> on an Ethernet device on the licensed system?

Precisely so.

/Mikhail 



Article: 140186
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 1 May 2009 23:49:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 9:23=A0pm, "MM" <mb...@yahoo.com> wrote:
> "MikeWhy" <boat042-nos...@yahoo.com> wrote in message news:75GKl.28897>
>
> > well, the worry of OP comes from the fact that with 11.1 there is no
> > price
> > given for EDK any more, the only possibility to obtain EDK includes
> > buying
> > a package that includes a FULL ISE version.
>
> > Antti
>
> It's not quite true. You can still get EDK separately for $495
> (http://www.xilinx.com/onlinestore/design_resources.htm), and it looks as=
 it
> comes with a separate license, but it is not clear to me based on my
> previous experience whether EDK can actually be used on its own without I=
SE.
> I guess Webpack is an option if it will support the devices I need...
>
> /Mikhail

hm, my fault.. I looked the PDF document first, and that listed only
the bundles
so i overlooked the edk separate pricing in the web page

Antti

Article: 140187
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Sat, 02 May 2009 17:12:48 +0200
Links: << >>  << T >>  << A >>
LittleAlex wrote:
> How do you tell them that this is a bad idea?  By designing in Altera
> or LatticeSemi parts.

Well, at least Lattice's licensing system is the same as it is now with
Xilinx: node-locked licenses per machine or floating licenses for a
considerably higher price, so that won't really solve anything.

cu,
Sean

Article: 140188
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Sat, 02 May 2009 17:23:59 +0200
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
> Your posts indicates that your company buys 1 license per 1 engineer.
> 
> Under the 11.1 licensing system you can have a license server that
> manages your pool of floating licenses and have ISE 11.1 installed on
> any number of machines in your office.

Any news on the educational versions of ISE? Avnet and NuHorizons don't
list them at all, and the XUP-Website hasn't been updated yet (it still
talks about "ISE Foundation"...).

We have a mixture of licenses at the moment, some commercial ones for
our commercial projects, and educational licenses for our students and
for the research labs.

I've sent an email to xup@xilinx.com a few days ago asking about this,
but haven't gotten a response yet.

Should there be no more educational licenses, we'd have to buy dozens of
additional licenses, costs would skyrocket. Floating licenses don't help
much if you're teaching a course and 12 students have to use ISE at the
same time. WebPACK is sufficient for some stuff, but not all...

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
(simple, eh?).

Article: 140189
Subject: SysACE and append File
From: "lsmsc" <ls_msc@gmx.de>
Date: Sat, 02 May 2009 14:48:11 -0500
Links: << >>  << T >>  << A >>
Hi, 
I'm using the Xilinx EDK 8.2 with a XUP Virtex 2 Board for a project.
I want to save some data to a Compact Flash Card, which works fine, but I
am not able to apend to an already existing File. When I open it with
sysace_fopen it gets overwritten.

Anyone has an idea, how I can fix this?



Article: 140190
Subject: Re: ERROR:MapLib:979
From: "digiviki" <pus@liberouter.org>
Date: Sat, 02 May 2009 14:48:55 -0500
Links: << >>  << T >>  << A >>
>Hello,
>
>
>
>I am getting the following map error.
>
>ERROR:MapLib:979 - LUT3 symbol
>   "vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
>ASYNC_F_MUX" (output
>   signal=vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
>async_mux_f_out) has
>   input signal "vio_inst/U0/I_VIO/GEN_SYNC_IN[16].SYNC_IN_CELL/
>falling_out"
>   which will be trimmed. See Section 5 of the Map Report File for
>details about
>   why the input signal will become undriven.
>
>
>
>I am getting a total of 96 such errors. As per one of the Xilinx
>answer records http://www.xilinx.com/support/answers/30477.htm it asks
>to turn off the read cores Synthesis option. I am still getting the
>same error after turning off the read cores option.
>
>
>
>Please suggest a solution for this as soon as possible.
>
>
>
>Thanks
>

Hello,

I'getting the same errors. Have you found a working solution? I'm using
ISE 10.1.03, have you tried the new ISE 11?

Thanks,
Viktor



Article: 140191
Subject: Spartan3E Starter Kit MISO and Flash pin shared
From: "mstanisz" <matt.staniszewski@gmail.com>
Date: Sat, 02 May 2009 14:49:11 -0500
Links: << >>  << T >>  << A >>
Hi,

I've been working on a Spartan3E Starter Kit and I've hit a snag while
using both the onboard ADC and the StrataFlash PROM.  The SPI bus MISO
signal for the ADC and the memory's bit0 for its data are the same net. 
Could anyone explain how to map the MISO and data pin to the same NET? 
I've tried doing it in the MHS and UCF files in the Xilinx EDK, but it
doesn't seem to hold.  I think I may need to either modify the VHDL code or
possibly make another core to do what I need.

Does anyone know of a better core or way to modify one so that the LSB of
the flash data is a separate connection in EDK, so that I can map that pin
solely and not all 16 bits at once?  Also, is there some sort of IO bus
splitter?  I saw that the EDK includes IP cores for a bus splitter, but
they don't accept IO port connections.

I'd be happy to post my MHS and UCF files if that'd help.

Thanks!

Matt



Article: 140192
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 2 May 2009 20:57:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
mstanisz <matt.staniszewski@gmail.com> wrote:
 
> I've been working on a Spartan3E Starter Kit and I've hit a snag while
> using both the onboard ADC and the StrataFlash PROM.  The SPI bus MISO
> signal for the ADC and the memory's bit0 for its data are the same net. 
> Could anyone explain how to map the MISO and data pin to the same NET? 
> I've tried doing it in the MHS and UCF files in the Xilinx EDK, but it
> doesn't seem to hold.  I think I may need to either modify the VHDL code or
> possibly make another core to do what I need.

I believe this is explained in the documentation.  It seems that
there are a limited number of I/O pins, and some have two uses.
Page 87 of UG230 explains the problem.  Pretty much, you have
to multiplex between them, so that you can't use both at the
maximum rate.  

-- glen

Article: 140193
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: "mstanisz" <matt.staniszewski@gmail.com>
Date: Sat, 02 May 2009 17:17:38 -0500
Links: << >>  << T >>  << A >>
Hi Glen,

Thanks for the quick response.  I've read through the User's Guide and saw
that part.  I have a GPIO set up for all the CENs and CSs that I need to
control as specified in the documentation.  However, I wasn't sure how to
multiplex the two devices to the N10 net in the EDK, since the flash IP
core specifies a 16-bit bus and I only need to share 1 bit of that with the
MISO signal.  I feel I need to modify the system VHDL file that the EDK
generates, but I wasn't sure where I should do that.  Any help would be
great.  Thanks!

Matt


>mstanisz <matt.staniszewski@gmail.com> wrote:
> 
>> I've been working on a Spartan3E Starter Kit and I've hit a snag while
>> using both the onboard ADC and the StrataFlash PROM.  The SPI bus MISO
>> signal for the ADC and the memory's bit0 for its data are the same net.

>> Could anyone explain how to map the MISO and data pin to the same NET?

>> I've tried doing it in the MHS and UCF files in the Xilinx EDK, but it
>> doesn't seem to hold.  I think I may need to either modify the VHDL
code or
>> possibly make another core to do what I need.
>
>I believe this is explained in the documentation.  It seems that
>there are a limited number of I/O pins, and some have two uses.
>Page 87 of UG230 explains the problem.  Pretty much, you have
>to multiplex between them, so that you can't use both at the
>maximum rate.  
>
>-- glen
>

Article: 140194
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 2 May 2009 23:37:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
mstanisz <matt.staniszewski@gmail.com> wrote:
 
> Thanks for the quick response.  I've read through the User's Guide and saw
> that part.  I have a GPIO set up for all the CENs and CSs that I need to
> control as specified in the documentation.  However, I wasn't sure how to
> multiplex the two devices to the N10 net in the EDK, since the flash IP
> core specifies a 16-bit bus and I only need to share 1 bit of that with the
> MISO signal.  I feel I need to modify the system VHDL file that the EDK
> generates, but I wasn't sure where I should do that.  Any help would be
> great.  Thanks!

I am not sure what EDK is.

I think the usual way is to use only one at a time, and make
sure that the other one is disabled.  

There is a similar double use on the LCD display.

-- glen

Article: 140195
Subject: Re: best soft core(s) that have C compiler support
From: rickman <gnuarm@gmail.com>
Date: Sat, 2 May 2009 20:53:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 29, 9:03=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote:
> On Mar 27, 11:24 pm, "Antti.Luk...@googlemail.com"
>
> <Antti.Luk...@googlemail.com> wrote:
> > the goal is to find best CPU for minimal SoC that should be
> > possible to fit to widest possible selection of FPGA's thats
> > why the huge ones are not listed. L8080 fits into smaller
> > end of FPGAs where 32 bit Cores do no longer fit. Also
> > some smaller FPGAs may have too small BRAM so
> > the 32 bit CPUs would just have too small instruction memory
> > for the C compiler to be useable at all.
>
> I guess I should have read this part before replying. Can you site the
> memory and LE/LC budget? Will there be external memory?
>
> It's trivial to make YARI run entirely out of BRAM (and get rid of the
> tags and the associativity), but MIPS-I obviously isn't the most
> compact ISA.
>
> If I was obsessed with space, I would take b16 as a starting point,
> work it until it would be feasible to write a compiler for, and then
> do that, but I think I'd rather stab myself in the eye with a chop
> stick.
>
> FPGA are getting bigger & cheaper at a faster rate than I can write
> compiler backends. The very smallest Spartan 6 has 3,400 LC and 32 Kib
> + 144 Kib of memory. I suspect these minimal core will be less
> appealing as time progresses.

There is always a need for very small CPUs and 3,400 LUTs are not all
that many if the CPU is just part of your design.  Even so, Spartan 6
is not out yet and will still not be a <$10 device (other than
>100,000/yr qty perhaps).  The sort of parts that Antti and I both are
using have about low thou LUT4s.  My current design is using 2000 of
3000 LUTs in the only part I can use on this board.  I am adding
functions for my customer and if I run out of space, I will have to
add a CPU to replace much of the logic.  I am allocating about 600
LUTs for this and expect the total design to use less than the current
2000 LUTs if I go that route.  Using a CPU using 2000 LUTs would not
be practical.

Rick

Article: 140196
Subject: Re: best soft core(s) that have C compiler support
From: rickman <gnuarm@gmail.com>
Date: Sat, 2 May 2009 21:52:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 5:19 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 28, 10:51 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 27, 10:13 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > Hi
>
> > > i know has been discussed before ;)
>
> > > if we leave out the vendor supplied ones (including open source like
> > > mico32)
> > > and the large ones, then my current list:
>
> > > Core   Datapath width   Spartan-3 slices for small SoC (approx, ISE
> > > 10.1 results)
> > > ZPU    32                     1000
> > > C16    16                     1000
> > > i8080  8                       1000
> > > L8080 8                       450
> > > L8080 8                       150 + 1 BRAM for microcode
>
> > > ZPU is stack based so most weird, but it has GCC support
> > > C16 has its own assembler/compiler/simulator supplied with source code
> > > i8080/L8080 are intel 8080 - I assume there is some  C compiler
> > > available
> > > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > > compiler code
>
> > > I wonder if there are better candidates for each bit-width category
> > > microblaze clone could be considered for 32, but i would rather leave
> > > such clones out from the table
>
> > > Antti
>
> > I'm curious, where did you get the data for your table, in particular
> > the ZPU?  I have been following the ZPU closely, reading the mailing
> > list.  Although the performance per MHz is not great, they seem to
> > have produced a fairly compact design, much smaller than 1000 LUTs.
> > They do a trade off between LUT usage and program memory by
> > "emulating" some instructions.  In reality, this is done like the
> > Intel software interrupt tables.  Instead of being executed by the
> > CPU, the opcode specifies an entry point to a code table to perform
> > the function of the instruction.  Just in the last week or so, a
> > person working on a pipelined version has gotten over 200 MHz in a
> > Virtex 5 and over 100 MHz in a Spartan 3.  It uses 655 LUTs when area
> > optimized and 711 when speed optimized.  The author claims 3.3 DMIPS @
> > 50MHz.  I don't know so much about DMIPS, but that sounds pretty slow
> > to me.  Clock speed isn't everything.
>
> > They claim even less LUT usage in other versions with less speed
> > optimizations, but I have not been able to verify this.
>
> > Rick
>
>    Number of BUFGMUXs                        1 out of 24      4%
>    Number of MULT18X18SIOs                   3 out of 20     15%
>    Number of RAMB16BWEs                     16 out of 20     80%
>    Number of Slices                       1057 out of 5888   17%
>       Number of SLICEMs                      0 out of 2944    0%
>
> ZPU_med
>
> results without tweaking.. :(
>
> seems i need serious optimizing to get down the resource useage
>
> Antti

Actually, I didn't notice that you were quoting "slices" which are
much less useful to count.  A slice is two FFs and two LUT4s.  If any
one of those four components (or anything else in the slice) is used,
then the entire slice is counted as used.  You really need to count
LUTs to compare apples to apples.

If you want a better count of what the ZPU is currently capable of,
you should go to the mailing list and ask how to get the current
code.  The original was on opencores, but now they are on some site
that uses git or something they feel is much better than the old CVS
used on oc.com.  I am a hardware geek (like yourself I believe) while
the ZPU guys are pretty much all softheads.  So they have a bend
towards fancier tools and such.  For example, the ZPU has "emulated"
instructions which they like to call "microcode".  This is just a hard
coded subroutine call, like the software interrupts on the x86
processors, which are used when an instruction is not implemented in
hardware.  They also like the 32 bit address space which is not very
useful in a FPGA.

That said, I read that they had a pipelined version well under 1000
LUTs, not 1000 slices.  So it should be in the same ballpark as the
L8080.

Rick

Article: 140197
Subject: Re: best soft core(s) that have C compiler support
From: rickman <gnuarm@gmail.com>
Date: Sat, 2 May 2009 21:58:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 5:11=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 28, 10:58=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > Hi
>
> > > i know has been discussed before ;)
>
> > > if we leave out the vendor supplied ones (including open source like
> > > mico32)
> > > and the large ones, then my current list:
>
> > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, I=
SE
> > > 10.1 results)
> > > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for =
microcode
>
> > > ZPU is stack based so most weird, but it has GCC support
> > > C16 has its own assembler/compiler/simulator supplied with source cod=
e
> > > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> > > available
> > > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > > compiler code
>
> > > I wonder if there are better candidates for each bit-width category
> > > microblaze clone could be considered for 32, but i would rather leave
> > > such clones out from the table
>
> > > Antti
>
> > Oh, BTW, why are you limiting your list to those processors? =A0There
> > are a ton of CPUs on the open cores web site. =A0Of course many of them
> > are not ready for prime time and some aren't even written, just shells
> > that were built for a project idea that never really started. =A0On the
> > other hand, there are many that are not only workable, seem to be
> > quite good.
>
> > One of the problems with open cores for CPUs is that there is no
> > standard for submission, so anyone can start a CPU design which is
> > listed along side of "real" projects, no matter how far it progresses
> > or what the goal. =A0More than one is just a design to see if it can be
> > done or an educational project. =A0I would like to see more info
> > provided by the authors and to have a summary table available that
> > allows the large list of CPU projects to be quickly evaluated for your
> > purpose. =A0As it is now, everyone who wished to look for a CPU there
> > has to spend hours looking at all of the projects. =A0The "new look"
> > they have come up with does nothing for the functionality that I can
> > see and some of the site still is not working, such as the forums.
>
> > Rick
>
> Rick
>
> I do have a large Excel table where i list all the soft cores, and
> their features :)
>
> will be published soon too
>
> i just am trying to use the table for one specific purpose now
>
> i know there are tons of cores, and .. many of them useable for
> some purpose, just the selection and find the right one is not
> always trivial
>
> Antti

Heck, a lot of them are unusable for *any* purpose.  I'd like to see
your data when you have it tabulated.  It would be interesting to
write an article of the history of CPU cores.  There is a lot of stuff
that isn't on oc.org.

Rick

Article: 140198
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 2 May 2009 22:50:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 3, 7:58=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 28, 5:11=A0am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 28, 10:58=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > > Hi
>
> > > > i know has been discussed before ;)
>
> > > > if we leave out the vendor supplied ones (including open source lik=
e
> > > > mico32)
> > > > and the large ones, then my current list:
>
> > > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx,=
 ISE
> > > > 10.1 results)
> > > > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> > > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM fo=
r microcode
>
> > > > ZPU is stack based so most weird, but it has GCC support
> > > > C16 has its own assembler/compiler/simulator supplied with source c=
ode
> > > > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> > > > available
> > > > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > > > compiler code
>
> > > > I wonder if there are better candidates for each bit-width category
> > > > microblaze clone could be considered for 32, but i would rather lea=
ve
> > > > such clones out from the table
>
> > > > Antti
>
> > > Oh, BTW, why are you limiting your list to those processors? =A0There
> > > are a ton of CPUs on the open cores web site. =A0Of course many of th=
em
> > > are not ready for prime time and some aren't even written, just shell=
s
> > > that were built for a project idea that never really started. =A0On t=
he
> > > other hand, there are many that are not only workable, seem to be
> > > quite good.
>
> > > One of the problems with open cores for CPUs is that there is no
> > > standard for submission, so anyone can start a CPU design which is
> > > listed along side of "real" projects, no matter how far it progresses
> > > or what the goal. =A0More than one is just a design to see if it can =
be
> > > done or an educational project. =A0I would like to see more info
> > > provided by the authors and to have a summary table available that
> > > allows the large list of CPU projects to be quickly evaluated for you=
r
> > > purpose. =A0As it is now, everyone who wished to look for a CPU there
> > > has to spend hours looking at all of the projects. =A0The "new look"
> > > they have come up with does nothing for the functionality that I can
> > > see and some of the site still is not working, such as the forums.
>
> > > Rick
>
> > Rick
>
> > I do have a large Excel table where i list all the soft cores, and
> > their features :)
>
> > will be published soon too
>
> > i just am trying to use the table for one specific purpose now
>
> > i know there are tons of cores, and .. many of them useable for
> > some purpose, just the selection and find the right one is not
> > always trivial
>
> > Antti
>
> Heck, a lot of them are unusable for *any* purpose. =A0I'd like to see
> your data when you have it tabulated. =A0It would be interesting to
> write an article of the history of CPU cores. =A0There is a lot of stuff
> that isn't on oc.org.
>
> Rick

Rick,

I do have a large excel table with soft processors where i have much
more metric per core
but as you said, much of what is available isnt much useable for
reason one or another

to fill out the table, and write something about each core means that
i actually have to
at least try out each of them, this will take some time, at the moment
i test what i think
are more interesting first

Antti





Article: 140199
Subject: Re: offset out
From: metinnn@gmx.de
Date: Sat, 2 May 2009 23:57:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 11:08=A0pm, "MM" <mb...@yahoo.com> wrote:
> <meti...@gmx.de> wrote in message
>
> news:4f17ca42-b62b-47f2-a7fe-d611b05857b9@f19g2000yqh.googlegroups.com...
>
>
>
> > But then, at least i must be able to check min output
> > timing after PAR.
>
> I don't think minimum is ever guaranteed.
>
> /Mikhail

Hi,

this would be a little disaster for us. If we cannot
rely on minimum output timing results.Suspicion
started as one my colleagues measured smaller
clk-to-out times as showed in min(hold) timing analysis.

But i don't understand somehow. Because Xilinx seem
to guarantee min timing for Inputs. You know the "VALID"
keyword, or if not used default zero hold time assumed for
hold analysis for input paths. Am i wrong?
Or, are you saying min timing is also not guaranteed for
inputs? At the end they are the same pads.

Thanks
Metin



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