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
> When I see this with other IC/MCU vendors I get scared. I really like > these chips. The Cool Runner II series is great but I really dont like > having the 1.8v Core Requirement (at least with lower speed logic). The Lattice ispMach 4000V device has a 3.3V Vcc. If you're interested, here's the link to that product info, data sheets, etc.: http://www.latticesemi.com/products/cpldspld/ispmach4000bcv.cfm Regards, Bart Borosky, LatticeArticle: 102101
> If there's some reason that you really need it to be an > EPROM-like technology, I think there are flash-based FPGAs from Lattice, > and flash memory is functionally fairly similar to EPROM (aside from > not using UV to erase). the flash-based FPGAs from Lattice are called the MachXO (smaller densities 256 LUT - 2280 LUT) and LatticeXP (medium densities 3K LUT- 20K LUT). http://www.latticesemi.com/products/fpga/index.cfm Regards, Bart Borosky, LatticeArticle: 102102
G=F6ran Bilski wrote: > JJ wrote: > > > Curiously how do you prototype the architecture, in cycle C, or go > > straight to HDL simulation? > > > > Anyway have fun > > > > John Jakson > > transputer guy > > > > the details are at wotug.org if interested > > > > I personally use paper and pen. > I draw the datapath functionality and think about how they will map into > Xilinx FPGA structures while drawing and designing. > I like to have large papers so I can draw timing diagrams on the same pag= e=2E > Only when I have some design which I believe would be reasonable I start > to code. > > When I think more about it then I realize that my most used design tool > is still the paper and pen. > > G=F6ran Aha, I kinda do the opposite, draw lots of tiny fragments on the small notepad sheets and code up the model in cycle C in a Verilog subset or style. If I use larger sheets I am afraid I will have to redraw the whole thing too many times to keep if looking perfect. For awhile I even stooped to ascii graphics over .... background once things are settling down at least they can be edited in small blocks but some edits are torture, better for regular paths. I rediscovered Canvas for Mac & Windows an excellent older 2d drawing tool but thats all it can do, but far better than the OpenOffice drawing. Cycle C tells me right away that the architecture does what its supposed to possibly with millions of cycles of testing and analysis of different approaches but it doesn't give me any warnings about critical paths until its too late. The notepad drawings though layout the C code fragments as TTL/Lut level schematics so I usually have an idea of all path length. The cycle C and the Verilog though are layed out in the same format and sometime I can't tell which is which, although one has to be careful with assigns, in C they are sequential, in Verilog they are not. One nice aspect of the C approach is that parts of the cpu expressed in cycle C also have a faster behavioural version that can be used by other applications such as compiler or OS as if they were running on a PC with that hardware feature available such as the MMU which in this case does memory allocation and user level memory management. That means software can be written for the target and executed on a PC model of it even though the hardware design is incomplete. I do recall my days at Inmos where the Transputer was all over very large A1? sheets of paper and on the walls and floors at gate level, and much of it before any gate level simulation decades before synthesis. I wouldn't want to go back to that again. John Jakson transputer guyArticle: 102103
Eli, Thanks. Further on CPLDs: The lifetimes of the CPLD products are incredibly long. If you notice we have 5V, 3.3V, and 2.5V CPLD products still advertisd and supported on our website. We also have the older Coolrunner (XPLA3), and newer Coolrunner II. All of them are there, and are being produced and supplied. http://www.xilinx.com/events/webcasts/050906_coolrunner2cpld.htm Just because the latest darling is the latest product does not mean that there are not a ton of sockets out there that still need filling. It took us awhile to really understand the CPLD market (and how it is so different from the FPGA market), but now that we think we know what that market is looking for (basically: #1-price, #2-price, #2-price, #4-power...) Xilinx is the second largest CPLD supplier in the market, and growing. It is an important part of our business, and we have a division that is tasked with making a profit, and growing the market. The FPGA business is also important (obviously), and there we split into two groups: Virtex line, and Spartan line, each group with its own charter. As we move from 90nm to 65nm, and beyond, one can expect more diversity in the offerings for FPGAs, as the Spartan line has begun to attract new customers from new markets that the Virtex line has never been able to interest. It is all a very complex business. And obsoleting a line is only done when it is no longer making money (volumes have dwindled to such a small number that we are at end of life for the line). A last time buy notice is issued, follwed by a last time ship notice. http://www.xilinx.com/bvdocs/notifications/description.pdf Just search on 'last time buy CPLD' for the entire website and you will see the notices, and the dates. For CPLDs, it is extremely rare to end the line. Most notices are for transitions to less expensive fab partners so that we can continue to match prices in this vicious market (CPLDs). It may be that for the older devices, there are no new sockets that we are winning, and the volumes and contract are primarily being handled on a routine basis, so the shelf stock for small quantities is being discontinued by distribution. That is only fair. If they get no new requests for the part, they are unlikely to pay much attention to supporting small quantities. Peter and I both agree that a 'source for the small guys' is critical*, and he and I are still fighting that battle. Austin *we also know the small guy might be doing the job for a big guy, or might even be the big guy, too. Eli Hughes wrote: > Peter Alfke wrote: > >> There is ABSOLUTELY NO truth to this rumor. XPLA3 aka CoolRunner is >> alive and kicking and finds increasing acceptance in the market. >> Disappearance from our website and poor availability data from Avnet or >> DigiKey have nothing to do with the health of the product line and its >> long-time future. >> Rumors like this can become self-fulfilling, that's why I jumped in >> immediately. >> Will publish additional convincing data soon. >> Peter Alfke, Xilinx >> > > > Thanks for the feedback Peter. I sincerely appreciate the feedback you > and Austin give on this forum. I really do like the 3.3v coolrunner parts! > > -EliArticle: 102104
Rainer Buchty wrote: > In article <1146246311.256472.241490@j73g2000cwa.googlegroups.com>, > "JJ" <johnjakson@gmail.com> writes: > |> I wonder what others think of this, at $4500 its way to steep for most > |> individual buyers > > Still way cheaper than a Cray XD-1... > > Rainer Aha, looks like Cray has seen the light and is now partnering with DRC, lets the customer choose the configuration they want rather than fixed board level design. John JaksonArticle: 102105
bart wrote: >>When I see this with other IC/MCU vendors I get scared. I really like >>these chips. The Cool Runner II series is great but I really dont like >>having the 1.8v Core Requirement (at least with lower speed logic). > > > The Lattice ispMach 4000V device has a 3.3V Vcc. If you're interested, > here's the link to that product info, data sheets, etc.: > http://www.latticesemi.com/products/cpldspld/ispmach4000bcv.cfm > > Regards, > Bart Borosky, Lattice > Thanks for the info. Is the ISPLever - Starter equivilent to the XIlinx Webpack? Also what tools do I need for In system Programming?Article: 102106
fpga_toys@yahoo.com wrote: > JJ wrote: > > I think the software guys have a huge problem with parallel, but not > > the old schematic guys. I have more problems with serial, much of it > > unnecessary but forced on us by lack of language features that forces > > me to order statements that the OoO cpu will then try to unorder. Why > > not let the language state "no order" or just plain "par" with no > > communication between. > > Parrallel programming as both an undergraduate and graduate class has > been available for a while on most computer science and computer > engineering campuses, and is a core consideration in many undergraduate > and graduate computer architecture classes as well. > > While some older software guys that haven't kept current in their trade > may be unaware, I suspect there are as many older hardware guys that > have difficultly with VHDL, Verilog, SystemC, and current modeling and > simulation techniques too. > > Parallel hardware comes in many different flavors, and there are many > different solutions to specific and sets of those implementations, > frequently specific to industries, application areas, and home schools > of research. > > The complaints here are less than conclusive and complete, as they pick > and choose some of the worst .... anyone can trash many hardware > designs in a similar fashion as lacking complete knowledge of how to > implement a system that software can actually run on well without a > bunch of hacks. > > Good designs happen when each of hardware, systems software, > applications software, and good architects get togather and fit the > system design to the problem, rather than leaving hardware guys to go > off and have some confused idea that software guys have to patch up > later. Ofcourse the two should be done together with as much crossover knowledge as possible. Finishing hardware design before software starts is asking for trouble, seen that done too many times although it brings up the chicken & egg question. John JaksonArticle: 102107
I had to do something to override the misleading rumor! Peter Alfke, XilinxArticle: 102108
Phil Tomson wrote: > In article <1147155282.274065.16140@i40g2000cwc.googlegroups.com>, > JJ <johnjakson@gmail.com> wrote: > > > >Phil Tomson wrote: > >> In article <1146975146.177800.163180@g10g2000cwb.googlegroups.com>, > >> JJ <johnjakson@gmail.com> wrote: > >> > > > > >snipping > > > > > >Transputers & FPGAs two sides of the same process coin > > > > Are there any transputers still being made? > > Phil I believe so but only for embedded use in set top boxes by ST and if ordered in the millions. At one time they had IIRC 70-80% of that space locked up with ST20 derivatives which stripped down the Transputer of its links and added more conventional serial ports, plus set top specific IP cores. They also gutted the whole thinking, no more Transputer occam speak, the scheduler really is now more controlled by the application and is programmed in plain C. They really mights as well have just started over with a simpler RISC core and gone from there. There was a reference just a few years ago in EET of a newer 500MHz ASIC std cell part put together by the San Diego center. They might still have ST20 pdfs on the website but they really only have a handfull of customers. Also another legacy of the links is the IEEE 1355 SpaceWire link derived from the T9000 links, and even the HyperTransport links are familiar, some same people involved. My main reasoning for promulgating this sort of modern version of Transputer architecture is that in its previous form it had no where to go being an historical design locked into the 80s. But I realised that the Memory Wall and current cache designs kills modern versions of cpus that originally started even before the Transputer. The main idea I push is that a Thread Wall can replace the Memory Wall and that threaded cpus allow for incredibly simple Processr Element v the OoO,SS, designs we have now. Lots of PEs giving lots of threads are relatively free, it doesn't really matter if PEs are idle, the Memory bandwidth is where the real cost is and that limits the no of PEs that can be used in one package. The coventional thinking has it the other way around, expensive cpus with ever higher theoretical IPCs with cheap memory. John Jakson transputer guyArticle: 102109
John, I'm unfamiliar with cycle C, but your post has me interested. Is this a specific simulator? Or coding style? Are tools freely / cheaply available? Thanks! StephenArticle: 102110
My view is that the divide between hardware and software should be reduced -- starting at the requirements and specification stage -- to achieve better compute efficiency. Many software folks don't understand how FPGAs and the concurrent nature of RTL / ESL can benefit their application... Little do they realize that the portion of their algorithm which accounts for 80% of their CPU utilization might be done in 1/50 the time with a specialized accelerator / co-processor. On the other side of the coin, however, many hardware guys don't properly understand concepts like recursion, aspect oriented programming, object oriented programming, UML, etc. Not to mention graph and tree data structures. Both hardware and software designers should begin to take a system-level view, and understand that an efficient system is a balance between sequential software and parallel hardware; where partitioning decisions are governed by cost / benefit tradeoffs. Today and in the past it seems that choosing software over custom hardware was all too easy (except for applications like tele / datacom, which would be impossible without specialized HW). After all SW is easier to develop, well understood, and the price / performance of CPUs is amazing. None-the-less the price / performance of FPGAs is also increasing making them a viable option for those who seek to accelerate their specialized SW algorithms.Article: 102111
Keith Williams wrote: > I have a fairly large Altera-based design that will soon be updated to > Cyclone II and Quartus (from Flex10K and Max+II). > > Has anyone else been through this migration that would be willing to share > any gotchas? Is the migration tool in Quartus worthwhile? > > Thanks, > > Keith Hi Keith, Quartus has a Max+Plus II look and feel mode so that the Max+Plus II menus and tools behave similar to Max+Plus II.You can also specify this from the Tools->Customize dialog. The Tools menu in Quartus 5.1 and earlier has the familar Compiler, Simulator and Timing Analysis tools. In Quartus II 6.0 these tools are available on the Processing menu. Hope this helps, Subroto DattaArticle: 102112
Peter Alfke wrote: > There is ABSOLUTELY NO truth to this rumor. XPLA3 aka CoolRunner is > alive and kicking and finds increasing acceptance in the market. That I believe. > Disappearance from our website and poor availability data from Avnet or > DigiKey have nothing to do with the health of the product line and its > long-time future. .. but that is a strange statement indeed. I would say that a product that has poor availability, and suffers Disappearance, (as you admit) is not going to get new designs. Once a product is tagged NFND, then it fades from everyones radar quite quickly. ( not just designers, but FAE's and stockists.. ) Key Q: Do Xilinx not WANT new designs in this family ? > Rumors like this can become self-fulfilling, that's why I jumped in > immediately. > Will publish additional convincing data soon. > Peter Alfke, Xilinx >Article: 102113
Austin Lesea wrote: > The FPGA business is also important (obviously), and there we split into > two groups: Virtex line, and Spartan line, each group with its own > charter. > > As we move from 90nm to 65nm, and beyond, one can expect more diversity > in the offerings for FPGAs, as the Spartan line has begun to attract new > customers from new markets that the Virtex line has never been able to > interest. I notice NOT mentioned here are any NEW product plans for CPLDs ? That speaks volumes in itself.... :) -jgArticle: 102114
Eli Hughes wrote: > I have a question for those experienced with Altera devices. Could > someone please identify (roughly) the Brand A equivilents of these brand > X parts: > > CoolRunner II Atmel have ATF150xASL, that have wider Vcc, but lower Speeds. Their new ATF1502BE series, is more closely equivalent to the XCR2 family. Xilinx have larger devices in both series. -jgArticle: 102115
Jim, the website mention what is new, and it does not seem to be edited with the intention of continuously expressing the health of each individual product line. It's kind of "no news is good news". The non-availability for instant purchasing is a sore point, and has definitely gotten my attention, and I have raised what can only be described as a big stink about this. We are a large coumpany, and we seem to take forever to remedy this f@#$%@# situation. So, it affects instant purchases only, but should not affect your confidence in the product line. We are now in lots of consumer applications that we never even dreamed of for a programmable device (low priced and with very low power consumption). The product line is healthy, it just seems to have trouble creating attention on our website, and it has difficulties getting on the shelves of the retailers. Darn-it! Peter Alfke, XilinxArticle: 102116
radarman wrote: > No, it's not generally a licensing problem. It's more a problem with > lousy programming, and the different versions tripping over each other. > The software depends on environment variables instead of using the > registry for a lot of things, and depending on which is first, you can > end up calling the old version with the new version, or in my case, > vice-versa. Or you can move the environment variables into bat files, as I did several years back before the linux tools became usable (hosting WebPack and ISE 4.2 on WinMe): # cat Xilinx4K.bat SET PATH=C:\Xilinx4K\bin\nt;%PATH% SET XILINX=C:\Xilinx4K C:\Xilinx4K\bin\nt\ise.exe # cat XilinxFdn4.bat SET PATH=C:\XilinxFdn4\bin\nt;%PATH% SET XILINX=C:\XilinxFdn4 C:\XilinxFdn4\bin\nt\dsgnmgr.exe I assume that is still possible today?Article: 102117
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:1147286590.976800.162380@j33g2000cwa.googlegroups.com... >I had to do something to override the misleading rumor! > Peter Alfke, Xilinx > Humm... I did make full screenshots from the coolrunner webcast that was yesterday. well I was looking for SDIO related information, the promo for that webcast specially stated that the use of Xilinx PLDs will be a topic of that webcast. So far I have not found the word SDIO on any of the slides of the webcast. I will look tomorrow how much there is reference to XPLA3. Antti PS sorry - Xilinx promo docs have references to SDIO for many years, but that was always been only words on the presentation slides, this time I hoped there is some more info, so it is understandable that I was deeply disappointed. The reference to SDIO in the webcast promo was the only reason I did take the time to download that stuff at all. PPS - to my knowledge made public by me small IP core that works with MMC card (a FPGA configuration IP core) is was the first open source IP that can be used with the smallest PLDs and does do something useful with an MMC card. The IP core takes 22 PLDs cells in XC95 and 21 in Coolrunner - so its the cool thing is really cool. So seeing as almost only reference to SD/SDIO/MMC at the webcast a unredable scaled down screenshot from the statemachine from the CE ATA documentation how to implement a pulse extender to capture short pulse as interrupt event with Intel XScale ? Not very impressive. Maybe I should buy speakers and hear the audio of the webcast also :)Article: 102118
Franco Tiratore wrote: > Hi all. > > I'm currently trying to understand whether or not it is possible to > implement a 802.11a-compliant OFDM modulator/demodulator on an FPGA. Yes it is possible, you need to choose an FPGA large enough. > As far as I understand, the critical part of the project is the > 64-point complex FFT with 32 bit floating-point representation (each > real or complex number is represented in 32-bit floating-point). The The FFT is relatively easy, using fixed-point arithmetic. No reason to use floating point. Other parts of the system are more challenging. > FFT block should perform this calculation in no more than 2.5 us. Easily achievable without requiring a high clock rate. > I'm not an expert in this field, can anyone help me to understand > whether or not this performance is achievable with the FPGAs currently > available on the market? If yes: can you address me to some specific > FPGA model? If not: what is the critical part of my specifications? (I > suppose the time delay and the floating point spec). > The first thing you need to do is come up with an outline design for the complete implementation, not just the FFT. Then estimate the size of each block, and the total size of the design. Do this before you select the FPGA, and work out what clock rate is required and how much memory you need. You can break each part of the design into small blocks and learn as you go. Start with the FFT if you want, but it will not be the most difficult part. There are many papers on different FFT architectures, google for 'r2sdf fft' for examples.Article: 102119
"bart" <bart.borosky@latticesemi.com> schrieb im Newsbeitrag news:1147283511.142960.111630@y43g2000cwc.googlegroups.com... >> If there's some reason that you really need it to be an >> EPROM-like technology, I think there are flash-based FPGAs from Lattice, >> and flash memory is functionally fairly similar to EPROM (aside from >> not using UV to erase). > > the flash-based FPGAs from Lattice are called the MachXO (smaller > densities 256 LUT - 2280 LUT) and LatticeXP (medium densities 3K LUT- > 20K LUT). > http://www.latticesemi.com/products/fpga/index.cfm > > Regards, > Bart Borosky, Lattice > 8051 is about 98% of XP3 so I its no fit for machXO but in XP6 or larger its no problems AnttiArticle: 102120
Stephen Craven wrote:
> John,
>
> I'm unfamiliar with cycle C, but your post has me interested.
>
> Is this a specific simulator? Or coding style? Are tools freely /
> cheaply available?
>
> Thanks!
> Stephen
Google for various terms, < cycle C>, its mostly adhoc.
There are many ways to do cycle C, it goes back to really being a poor
mans simulator although it has some huge advantages and disadvantages
over real HDLs. In the far past it was Pascal, and BCPL even APL. I use
Verilog because it is fairly close to C syntax but the semantics
obviously very different.
There are ways to merge the two languages into one system, in larger
teams, people use the PLI interface but that has many of its own
drawbacks. Today there is also SystemVerilog, not sure where its at.
There are, were, several Cycle C vendors all pushing the same idea,
most starved to death, the ASIC world doesn't really like to pay for C
HDLs that are puny compared to real HDLs and many EEs are perfectly
able to devise their own Cycle C if they need to and have done so in
many larger companies. It boils down to a duplication of coding effort,
sometime it has to be done so that software guys can have access to a
functional model in their own language or because the executable
reference spec came from Matlab, Fortran F2C etc and can be executed
with a HDL C model.
Cycle C simulations can run models many orders fasters than HDL
simulators and to all intents C compilers and C cpu cycles are free
while most HDL simulators have restrictions and are much slower but
much more detailed and much better HDLs. Synopsys bought out one
Verilog simulator company Chronologic that had Verilog to C output that
really speeded things up, it was the fastest simulator out there but
was a $50K item.
That prompted me at one time to write HDL in a funky C HDL and put that
through the C preprocessor. It let me use a nested instances HDL like
syntax but it was really pretty awefull. Other people have done it
better many times. I later went the other route and just wrote a
Verilog to C compiler that accepted a restricted RTL single cycle
subset of Verilog and that produced fairly good C code about half as
fast as hand writtten C but since the source is Verilog, anyone could
use it and no mucking with low level C. I should have done maintenance
on it but have neglected it.
For the Transputer design, the PEs are really only a few pages of eqns,
I fell back on the HDL C with less ambitions, no nesting, that also
uses a few macros to put in "assign", "always", "begin" etc into the
code which translate into mostly null or { } tokens..
The real goal is to go back to the old V2C compiler and combine the
front end with the C compiler that is being developed that merges
subsets of event based Verilog with C++.
The merged language will take a C++ like class declaration and add
signal ports as well as assigns and always to it. So Verilog module
declarations become
process pname (port declarations) {
// std C statements and declarations
// limited Verilog signal declarations
// assign ..
// always ...
// some other Verilog stuff.
}
That will be some time off. I have no idea how much of C++ OO stuff
makes any sense beyond improved C. This is to replace the occam
langauge the Transputer originally ran. One can figure the simulator
event wheel is now inside the Transputer MMU core so the compiler has
to map Verilog constructs onto specialized instructions. Ofcourse the
behavioural code for the MMU and schedluer running on a PC could as
well be called a simulator engine.
John Jakson
transputer guy
Article: 102121Luke wrote: > The 16-bit cpu could access up to 256K of RAM and had 16 16-bit > registers. Could you page/tile the registers into a block ram ? > I actually am able to fit 12 of these on one spartan 3 1000 > chip, limited only by available block ram. It was nifty, but if I > really needed that much specialized processing power it would make more > sense to build some custom logic in the FPGA to do it. It is a good idea to have a number of options for any problem. Custom logic is great for non-data intensive HW fabric, but often you have things at the device driver level, where a small core makes better use of the FPGA than rolling the whole thing in logic. A faster small core, means one can do more in the core, before needing to move to logic. What's needed is really "the smallest core an HLL can work on". Some good work is being done around Pico/PacoBlaze. -jgArticle: 102122
Since you're using a DCM, you don't need to put a period constraint on clk4x. You only need to specify the period on the clkin to the DCM and the tool will automatically propagate this constraints to the DCM outputs with correct phase adjustments. This of course requires you set up the DCM attributes correctly. You can run the timing analyzer to see why you got a very high timing score and fix code and/or constraints accordingly. HTH, Jim http://home.comcast.net/~jimwu88/tools/Article: 102123
Peter Alfke wrote: > Jim, the website mention what is new, and it does not seem to be edited > with the intention of continuously expressing the health of each > individual product line. > It's kind of "no news is good news". > The non-availability for instant purchasing is a sore point, and has > definitely gotten my attention, and I have raised what can only be > described as a big stink about this. We are a large coumpany, and we > seem to take forever to remedy this f@#$%@# situation. > So, it affects instant purchases only, but should not affect your > confidence in the product line. We are now in lots of consumer > applications that we never even dreamed of for a programmable device > (low priced and with very low power consumption). > The product line is healthy, it just seems to have trouble creating > attention on our website, and it has difficulties getting on the > shelves of the retailers. Darn-it! Perhaps Xilinx could learn from ST, TI et al, who tag their devices 'Preview' 'Active', and 'Mature' (etc) ? That makes it clear what is bleeding edge, and what is trailing edge. -jgArticle: 102124
Henry Wong wrote: > Luke wrote: > > I've got a little hobby of mine in developing processors for FPGAs. > > I've designed several pipelined processors and a multicycle processor. > > > > I wonder how you manage to find enough time to do all of this! > > I've only found time during my undergraduate years to build two > processors, both with an excuse: > > A multicycle (>= 12!) processor for a 2nd-year digital logic project > (16-bit, 13MHz on Altera EPF10K70) > > A pipelined processor (no I/O though, so useless) built for clock speed > as a summer research project at my university. > (32-bit, 250MHz on Altera Stratix EP1S40) > > I haven't ever found enough time otherwise! haha, I designed a soft core CPU as well. It is a 16-bit one and is quite slow, but I could have sped it up easily had I not used BlockRAM for registers (also used for internal stack) . I like having banked registers though for fast and effortless context switching (since I am writing the stuff in assembly). I plan on pipelining it once I get some apps up and running (need to make assembler). I think it is a result of good time management! I salut you Luke! I must also say as well, I never found delay slots to be a feature. I have ALWAYS considered them a bug. By any chance do you work for Hitachi? :P (Check out the SuperH series CPU's if you didnt get the joke :) ) -Isaac
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