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 Mar 19, 11:24=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > This FPGA-centric approach meant that the whole thing fits in about 250 > LUTs, 2 BRAMS and 1 multiplier thingy, and runs at over 100MHz in a V2PRO > which is over 100MIPS because most instructions take one cycle, even > relative jumps. Bloody zero flag had the worst timing. Did you look at "Multiple cores" via time-slicing ? eg something like 16 x 160ns time-slots, that can allocate to register/flag copies. Much more deterministic than interrupts. A MIPS weighting can occur, by (perhaps Synth time?) mapping of slots to each 'core' - eg 1 slot for operator, 2 for ADC, and 13 for real work... > Like everyone says, the assembler took me a morning to write in Perl. > As for documentation, it's in VHDL. That's it, right? ;-) > > One interesting thing is that it was easy to let the processor do things > like READ R0,[R1++] because I could increment the registers at the same t= ime > as using them as indirect addresses. > > For me the cool part of the exercise was to get as much out of the proces= sor > with the least FPGAs resource. (Probably because I cut my teeth on XC2064= s > and XC3010s.) It's interesting to compare it with Jonathan's processor wh= ich > had a completely different focus and application. Instantiating carry > primitives probably isn't his main teaching objective! > > Cheers, Syms. So, where is the link so we can compare your documentation style with the other candidates :) ?Article: 139076
On Mar 20, 2:05=A0am, rickman <gnu...@gmail.com> wrote: > That last mux in the register address path is because you have dual > port memory and three addresses. =A0Source addresses have to be provided > in cycle 1 and target address in cycle 2. =A0So get rid of one field, > the target, and that mux goes away too. =A0Use one register for both > source and target and you get back three bits. =A0You could have 16 > registers and still have a bit left over, which I am sure someone can > find a good use for. =A0An added bonus of this optimization is that I > think you can reduce the clock cycles to 1 since you no longer need to > mux a register address between source and target. You can do single cycle three-address handling, if you don't mind being Block RAM wasteful. If you use TWO dual port memories, and always parallel the Target address they become content cloned, and you can read two operands via the two read ports. This comes from the "RAM is cheap enough to waste a little" camp.. :) -jgArticle: 139077
"gabor" <gabor@alacron.com> wrote in message news:ff899223-9e58-4dec-8158-990e6bf711f4@13g2000yql.googlegroups.com... > Depending on the LFSR construction, you may be able to use a > counter instead of a "wide gate". >For > a very long LFSR this approach generally uses much less > resources than the wide gate. And to cut down on the resources to implement the counter...implement the counter with an LFSR KJArticle: 139078
In article <1478a4ab-62d3-4e9d-b1a3-769f847260a2@j8g2000yql.googlegroups.com>, Jacko <jackokring@gmail.com> wrote: >hi > >Chuck and the poe are in the design lab, > >Chuck sys to pope "Have you got a rubber, my designs are getting big?" >Pope says "That's a bit RISCy!" > >So if you had possiblly 4 instructions to do stack init pointers and >save both aswell, what would you use? Do you ever read over your posts before submission? Do you have a spelling checker? > >cheers jacko -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 139079
On Mar 19, 11:08=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > In article <1478a4ab-62d3-4e9d-b1a3-769f84726...@j8g2000yql.googlegroups.= com>, > > Jacko =A0<jackokr...@gmail.com> wrote: > >hi > > >Chuck and the poe are in the design lab, > > >Chuck sys to pope "Have you got a rubber, my designs are getting big?" > >Pope says "That's a bit RISCy!" > > >So if you had possiblly 4 instructions to do stack init pointers and > >save both aswell, what would you use? > > Do you ever read over your posts before submission? > Do you have a spelling checker? ROFLMAO!!! All the "stuff" this guy posts and you are commenting on his ~~~spelling~~~!!! RickArticle: 139080
On Mar 19, 9:52=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 20, 2:05=A0am, rickman <gnu...@gmail.com> wrote: > > > That last mux in the register address path is because you have dual > > port memory and three addresses. =A0Source addresses have to be provide= d > > in cycle 1 and target address in cycle 2. =A0So get rid of one field, > > the target, and that mux goes away too. =A0Use one register for both > > source and target and you get back three bits. =A0You could have 16 > > registers and still have a bit left over, which I am sure someone can > > find a good use for. =A0An added bonus of this optimization is that I > > think you can reduce the clock cycles to 1 since you no longer need to > > mux a register address between source and target. > > You can do single cycle three-address handling, if you don't mind > being Block RAM wasteful. If you use TWO dual port memories, and > always > parallel the Target address they become content cloned, and you can > read two operands via the two read ports. > > This comes from the "RAM is cheap enough to waste a little" camp.. :) Unfortunately, some of us work in smaller FPGAs that are a bit more resource constrained, but I guess an extra 16 LUTs is not such a big deal if it makes the thing work nearly twice as fast. RickArticle: 139081
On Mar 19, 8:08=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "gabor" <ga...@alacron.com> wrote in message > > news:ff899223-9e58-4dec-8158-990e6bf711f4@13g2000yql.googlegroups.com... > > > Depending on the LFSR construction, you may be able to use a > > counter instead of a "wide gate". > >For > > a very long LFSR this approach generally uses much less > > resources than the wide gate. > > And to cut down on the resources to implement the counter...implement the > counter with an LFSR > > KJ Hi KJ, I don't understand "Divide-by-5 to 16 counter". I appreciate if you may explain the Table 2 and Figure 2 in more details to me. WengArticle: 139082
On 2009-03-14, Martin Schoeberl <mschoebe@mail.tuwien.ac.at> wrote: > 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. I wholeheartedly agree. (I more or less agree with the rest of your post as well, although this is the most important part I think.) Although I'm somewhat in favor of censoring all requests for the non-synthesizable mp3_decoder project :) Anyway, to keep this slightly on-topic for the group, wouldn't it be nice if the OpenCores project listing page would include some icons that told whether a certain core had been tested on a Xilinx FPGA and another icon for Altera FPGAs. (So you don't waste time registering an account in order to download a certain core only to discover that it uses a lot of primitives for an FPGA that you are not targetting.) /AndreasArticle: 139083
Hi, For efficient registerfile, you should check up the RAM32M primitives that was added for Virtex5 and also be available for Spartan6/Virtex6. For MicroBlaze when going from Virtex4 to Virtex5, this primitive helped to reduce the register file size with around 7x. It handles 1 write and 3 read ports very efficient. G=F6ran rickman wrote: > On Mar 19, 9:52=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > On Mar 20, 2:05=A0am, rickman <gnu...@gmail.com> wrote: > > > > > That last mux in the register address path is because you have dual > > > port memory and three addresses. =A0Source addresses have to be provi= ded > > > in cycle 1 and target address in cycle 2. =A0So get rid of one field, > > > the target, and that mux goes away too. =A0Use one register for both > > > source and target and you get back three bits. =A0You could have 16 > > > registers and still have a bit left over, which I am sure someone can > > > find a good use for. =A0An added bonus of this optimization is that I > > > think you can reduce the clock cycles to 1 since you no longer need t= o > > > mux a register address between source and target. > > > > You can do single cycle three-address handling, if you don't mind > > being Block RAM wasteful. If you use TWO dual port memories, and > > always > > parallel the Target address they become content cloned, and you can > > read two operands via the two read ports. > > > > This comes from the "RAM is cheap enough to waste a little" camp.. :) > > Unfortunately, some of us work in smaller FPGAs that are a bit more > resource constrained, but I guess an extra 16 LUTs is not such a big > deal if it makes the thing work nearly twice as fast. > > RickArticle: 139084
Hi I know this is too much to hope solution, but maybe.. the winter 2008 SBT tools seem to generate a multi boot header for cold boot only (works ok) trying warm-boot with the same multiboot applet doesnt seem to work however :( any help? (yes i have submitted help request to SBT) AnttiArticle: 139085
On Mar 20, 9:23=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote: > Hi, > > For efficient registerfile, you should check up the RAM32M primitives > that was added for Virtex5 and also be available for Spartan6/Virtex6. > For MicroBlaze when going from Virtex4 to Virtex5, this primitive > helped to reduce the register file size with around 7x. > It handles 1 write and 3 read ports very efficient. > > G=F6ran > > cool, 4 LUTs are used for 4 port 32 x 2 RAM with async read ports!! this allows VERYcomact register file! as example the opencores ARM core (yes the one that was removed on request from ARM) was very large because the register file did consume about the same as the rest of the design! eh, its funny how some features come to attention... when V5 was just launched i tried out some of the new primitives it was really great feeling to be able to implement a UART transmitter and baud rate generator that utilized: 0 LUTs 0 LUT flip flops =3D=3D 0 slices total 0 Block RAMs i think an UART can not be further optimized :) but during that exploration i did not check out RAM32M... thank you Goran now i am waiting S-6 even more! AnttiArticle: 139086
I wonder if anyone happens to have a couple of the right-angled version of the FX2 connector to mate with the expansion connector on the XIlinx S3A board ( or knows someone who stocks them for small qty buyers) The Hirose part no. is FX2-100S-1.27DS Digikey only stock the straight version (-DSA) mike@whitewing.co.ukArticle: 139087
For a register file with - 32 registers - 1 write port - 3 read ports - 16-bit wide only requires 32 LUTs. Hard to make it more efficient. It also maps extremely good with MicroBlaze since one instruction requires 3 read ports. "sw rd,ra,rb" G=F6ran Antti.Lukats@googlemail.com wrote: > On Mar 20, 9:23=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote: > > Hi, > > > > For efficient registerfile, you should check up the RAM32M primitives > > that was added for Virtex5 and also be available for Spartan6/Virtex6. > > For MicroBlaze when going from Virtex4 to Virtex5, this primitive > > helped to reduce the register file size with around 7x. > > It handles 1 write and 3 read ports very efficient. > > > > G=F6ran > > > > > > cool, 4 LUTs are used for 4 port 32 x 2 RAM with async read ports!! > > this allows VERYcomact register file! > as example the opencores ARM core (yes the one that was removed on > request from ARM) > > was very large because the register file did consume about the same as > the rest of the design! > > eh, its funny how some features come to attention... when V5 was just > launched i tried out > some of the new primitives > > it was really great feeling to be able to implement a UART transmitter > and baud rate generator that utilized: > > 0 LUTs > 0 LUT flip flops =3D=3D 0 slices total > 0 Block RAMs > > i think an UART can not be further optimized :) > > but during that exploration i did not check out RAM32M... > > thank you Goran > now i am waiting S-6 even more! > > AnttiArticle: 139088
> Digikey only stock the straight version (-DSA) ?! Digikey p/n H10644-ND, FX2-100S-1.27DS, right-angled (~as nicely shown on pics): http://parts.digikey.com/1/parts/287861-conn-recept-r-a-100pos-1-27mm-fx2-100s-1-27ds-71.html -- StoneThrower www.dgmicrosys.comArticle: 139089
On Fri, 20 Mar 2009 14:25:10 +0100, "StoneThrower" <digi_64-public[removethis]@yahoo.com> wrote: >> Digikey only stock the straight version (-DSA) >?! >Digikey p/n H10644-ND, FX2-100S-1.27DS, right-angled (~as nicely shown on >pics): >http://parts.digikey.com/1/parts/287861-conn-recept-r-a-100pos-1-27mm-fx2-100s-1-27ds-71.html Thanks - I did several searches & failed to find it - seems like they forgot to put the pin count in the item data so when I filtered to 100 pin, it didn't find it! Their parametric data is usually very good so I don't tend to look further if the search doesn't find something - have emailed them.Article: 139090
On Mar 20, 2:47=A0am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2009-03-14, Martin Schoeberl <mscho...@mail.tuwien.ac.at> wrote: > > > 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. > > I wholeheartedly agree. (I more or less agree with the rest of your post > as well, although this is the most important part I think.) > > Although I'm somewhat in favor of censoring all requests for the > non-synthesizable mp3_decoder project :) > > Anyway, to keep this slightly on-topic for the group, wouldn't it be nice > if the OpenCores project listing page would include some icons that > told whether a certain core had been tested on a Xilinx FPGA and another > icon for Altera FPGAs. (So you don't waste time registering an account > in order to download a certain core only to discover that it uses a lot o= f > primitives for an FPGA that you are not targetting.) > > /Andreas I think they need a lot more than a symbol to tell you what chip it will run on. If you ever look through the CPU directory looking for anything at all specific, you basically have to search each and ever one of the core listings. Even then, as you found, a lot of important "front page" info is missing, included sometimes whether or not the code actually does anything useful. Try getting an idea of the size of the CPU cores in terms of LUT usage. Many are listed as "XX% of an XXXYYYZZZ part", often a part 5 years out of date. Many others give you no idea of size, how well it works or if it is just a toy project. RickArticle: 139091
Dear FPGA users, This news group is valuable to all of us. I found that Google Group now allows users to report spam. I suggest we all take a few seconds to report spams on this comp.misc.fpga group. The result is yet to see, but we can start now. Just click into the spam message, then click "options" in the subject line, then "more options" in author line. I simply describe the reason as "This message is spam". I hope this helps. Thank you! Best, vax9000Article: 139092
On Mar 20, 6:31=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 20, 9:23=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote: > > > Hi, > > > For efficient registerfile, you should check up the RAM32M primitives > > that was added for Virtex5 and also be available for Spartan6/Virtex6. > > For MicroBlaze when going from Virtex4 to Virtex5, this primitive > > helped to reduce the register file size with around 7x. > > It handles 1 write and 3 read ports very efficient. > > > G=F6ran > > cool, 4 LUTs are used for 4 port 32 x 2 RAM with async read ports!! > > this allows VERYcomact register file! > as example the opencores ARM core (yes the one that was removed on > request from ARM) Is there any way to get that core anymore? I figure there have to be copies of it around. I guess it has gone deep underground. > was very large because the register file did consume about the same as > the rest of the design! > > eh, its funny how some features come to attention... when V5 was just > launched i tried out > some of the new primitives > > it was really great feeling to be able to implement a UART transmitter > and baud rate generator that utilized: > > 0 LUTs > 0 LUT flip flops =3D=3D 0 slices total > 0 Block RAMs > > i think an UART can not be further optimized :) > > but during that exploration i did not check out RAM32M... > > thank you Goran > now i am waiting S-6 even more! It's great when new features come out for FPGAs. But it is not always practical to take advantage of them. If you need to target your design to a range of FPGA products, you need to code for the "masses" of silicon. I'm having a problem right now coding to utilize the memory on a Lattice part because they recommend that you instantiate memory instead of inferring it. That's just not nice! RickArticle: 139093
On Mar 20, 8:03=A0am, VAX9...@gmail.com wrote: > Dear FPGA users, > > This news group is valuable to all of us. I found that Google Group > now allows users to report spam. I suggest we all take a few seconds > to report spams on this comp.misc.fpga group. The result is yet to > see, but we can start now. > > Just click into the spam message, then click "options" in the subject > line, then "more options" in author line. I simply describe the reason > as "This message is spam". I hope this helps. Thank you! > > Best, > vax9000 I'm astounded that Google hasn't added spam filtering and options to block messages from specific hosts. John ProvidenzaArticle: 139094
On Mar 20, 11:17=A0am, jprovide...@yahoo.com wrote: > On Mar 20, 8:03=A0am, VAX9...@gmail.com wrote: > > > Dear FPGA users, > > > This news group is valuable to all of us. I found that Google Group > > now allows users to report spam. I suggest we all take a few seconds > > to report spams on this comp.misc.fpga group. The result is yet to > > see, but we can start now. > > > Just click into the spam message, then click "options" in the subject > > line, then "more options" in author line. I simply describe the reason > > as "This message is spam". I hope this helps. Thank you! > > > Best, > > vax9000 > > I'm astounded that Google hasn't added spam filtering and options to > block messages from specific hosts. > > John Providenza Unfortunately a lot of the spam originates within Google groups...Article: 139095
I'm working with a new chipset and I've got to add some functionality to this coolrunner cpld xpla3 but I can't figure out its reports after I get through with the synth--translate--fit. A report comes out in html that looks like this: Summary Design Name OATS_TOP Fitting Status Successful Software Version K.39 Device Used XCR3512XL-12-PQ208 Date 3-20-2009, 10:42AM RESOURCES SUMMARY Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used 402/512 (79%) 854/1536 (56%) 374/512 (74%) 124/176 (71%) 858/1280 (68%) LOCAL CONTROL TERM RESOURCES ... and when I added some digital outputs, the %'s went up, but then I added a whole bunch of logic, and nothing changed, how to I find out if I'm hitting a resource limit elsewhere on this chipset? the html page has available as links: Summary Errors/Warnings Logic Inputs Function Blocks Equations Pin List Compiler Options Text Report Help The 'text report' seems to have a lot in it, it seems that the html reports are just organized parts of it.Article: 139096
On Mar 20, 5:20=A0pm, gabor <ga...@alacron.com> wrote: > On Mar 20, 11:17=A0am, jprovide...@yahoo.com wrote: > > > > > On Mar 20, 8:03=A0am, VAX9...@gmail.com wrote: > > > > Dear FPGA users, > > > > This news group is valuable to all of us. I found that Google Group > > > now allows users to report spam. I suggest we all take a few seconds > > > to report spams on this comp.misc.fpga group. The result is yet to > > > see, but we can start now. > > > > Just click into the spam message, then click "options" in the subject > > > line, then "more options" in author line. I simply describe the reaso= n > > > as "This message is spam". I hope this helps. Thank you! > > > > Best, > > > vax9000 > > > I'm astounded that Google hasn't added spam filtering and options to > > block messages from specific hosts. > > > John Providenza > > Unfortunately a lot of the spam originates within Google groups... hm.. i think domains like 163.com could be safely blocked, but yes the spammer will find the way back in still for technical groups should be rather easy to detect total spam messages i am also reporting spam posts to google, but nothing seem to help AnttiArticle: 139097
jleslie48 wrote:
> and when I added some digital outputs, the %'s went up, but then I
> added a whole bunch of logic, and nothing changed,
If the number of cells or Pterms used didn't change at all,
I would expect that a "whole bunch" of logic does not make it
out to a pin. I would run a sim to check.
-- Mike Treseler
Article: 139098On Mar 20, 1:41 pm, Mike Treseler <mtrese...@gmail.com> wrote: > jleslie48 wrote: > > and when I added some digital outputs, the %'s went up, but then I > > added a whole bunch of logic, and nothing changed, > > If the number of cells or Pterms used didn't change at all, > I would expect that a "whole bunch" of logic does not make it > out to a pin. I would run a sim to check. > > -- Mike Treseler ahhh, well that is a bummer. I just tied the output to a pin and now I"m getting: Fitting... . ERROR:Cpld:1063 - Design requires at least 947 macrocells, exceeds device limit 512. ERROR:Cpld:1062 - Design contains 2004 unique product terms, exceeds device limit 1536. ERROR:Cpld:1064 - Design rules checking error. Fitting process stopped. ...o ERROR:Cpld:868 - Cannot fit the design into any of the specified devices with the selected implementation options. any idea on how to make it fit?Article: 139099
On Mar 20, 2:58 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Mar 20, 1:41 pm, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > jleslie48 wrote:
> > > and when I added some digital outputs, the %'s went up, but then I
> > > added a whole bunch of logic, and nothing changed,
>
> > If the number of cells or Pterms used didn't change at all,
> > I would expect that a "whole bunch" of logic does not make it
> > out to a pin. I would run a sim to check.
>
> > -- Mike Treseler
>
> ahhh, well that is a bummer. I just tied the output to a pin and now
> I"m getting:
>
> Fitting...
> .
> ERROR:Cpld:1063 - Design requires at least 947 macrocells, exceeds
> device limit
> 512.
> ERROR:Cpld:1062 - Design contains 2004 unique product terms, exceeds
> device
> limit 1536.
> ERROR:Cpld:1064 - Design rules checking error. Fitting process
> stopped.
> ...o
> ERROR:Cpld:868 - Cannot fit the design into any of the specified
> devices with
> the selected implementation options.
>
> any idea on how to make it fit?
ok, before I added my functionality, I had:
Macrocells Used Pterms Used Registers Used Pins Used Function
Block Inputs Used
379/512 (75%) 831/1536 (55%) 354/512 (70%) 118/176 (68%)
779/1280 (61%)
so from my errors, I can see I added some 600 macrocells, and 1200
pterms,
how can I find out who is the piggy, and what can I due to trim things
down?
also, what is a macrocell and pterm?
I originally ran this program on a virtexII, and everthing looked
liked it
was pretty small and effecient:
Device Utilization Summary
[-]
Logic Utilization
Used
Available
Utilization
Note(s)
Number of Slice Flip Flops
1,282
27,392
4%
Number of 4 input LUTs
1,545
27,392
5%
Logic Distribution
Number of occupied Slices
1,302
13,696
9%
Number of Slices containing only related logic
1,302
1,302
100%
Number of Slices containing unrelated logic
0
1,302
0%
Total Number of 4 input LUTs
1,589
27,392
5%
Number used as logic
1,545
Number used as a route-thru
44
Number of bonded IOBs
Number of bonded
15
556
2%
IOB Flip Flops
1
Number of RAMB16s
2
136
1%
Number of BUFGMUXs
3
16
18%
but I cant seem to compare these two chips, the VIRTEX II vs the
XCR3512XL-12-PQ208
its apples to oranges, how does it work?
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