Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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, ALArticle: 140176
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
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. MetinArticle: 140178
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. ALArticle: 140179
<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. /MikhailArticle: 140180
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
> 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.comArticle: 140182
<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
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
"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
"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. /MikhailArticle: 140186
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 AnttiArticle: 140187
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, SeanArticle: 140188
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
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
>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, ViktorArticle: 140191
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! MattArticle: 140192
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. -- glenArticle: 140193
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
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. -- glenArticle: 140195
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. RickArticle: 140196
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. RickArticle: 140197
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. RickArticle: 140198
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 AnttiArticle: 140199
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:
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