Prev: my lab
Next: Beta sucked?
From: David L. Jones on 11 Oct 2009 16:32 krw wrote: > On Sun, 11 Oct 2009 22:34:39 +1100, "David L. Jones" > <altzone(a)gmail.com> wrote: > >> krw wrote: >>> On Sun, 11 Oct 2009 12:57:04 +1100, "David L. Jones" >>> <altzone(a)gmail.com> wrote: >>> >>>> krw wrote: >>>>> On Sat, 10 Oct 2009 11:18:48 -0700, Charlie E. >>>>> <edmondson(a)ieee.org> wrote: >>>>> >>>>>> On Fri, 9 Oct 2009 21:18:47 -0500, "Jon Slaughter" >>>>>> <Jon_Slaughter(a)Hotmail.com> wrote: >>>>>> >>>>>>> Is there a development suite that is good but can target >>>>>>> multiple fpga manufactures? I don't really want to install a >>>>>>> bunch of 1GB+ light versions for each manufacture just to see >>>>>>> which one is best. In fact I can't even get libero to run >>>>>>> because it crashes on startup. >>>>>>> >>>>>>> Also, know of any links for DIY fpga programmers? How hard is >>>>>>> it to program? I figured that one just has to feed a bitstream >>>>>>> into the fpga similar to how a pic is programmed(or most devices >>>>>>> actually). Looking at the proASIC's makes me think it's a bit >>>>>>> different but I haven't found any conclusive way to program them >>>>>>> except by using DirectC or the STAPL Player. Since I'm >>>>>>> experimenting with these different manufactures I don't want to >>>>>>> have to buy a programmer for each chip. For as much as they cost >>>>>>> I could get nanoboard with 10^10x the functionality. >>>>>>> >>>>>> Jon, >>>>>> Ok, thought about this a bit. Part of the problem is that the >>>>>> EDA companies basically just provide a front end for the FPGA >>>>>> company's tools. They don't try and duplicate that back end >>>>>> effort, it isn't worth it for them. So, if you want to do more >>>>>> than just preliminary designs for each vendor, you will still >>>>>> have to install X number of starter editions for each vendor you >>>>>> want to try. >>>>> >>>>> Pretty much, but a lot of the design can be done on any one of the >>>>> vendor's tools then the design ported to the others. Of course >>>>> this presumes that you don't instantiate any primitives or use >>>>> exclusive features. >>>>> >>>>>> For the price, Altium at $3999 is probably the cheapest major >>>>>> company. When paired with their nanoboards, you can get a decent >>>>>> development platform to really try things out. Their latest >>>>>> nanoboard is only $399 and comes with a years subscription to the >>>>>> front end software. >>>>> >>>>> WHy spend the money. $4K is still a lot when the manufacturer's >>>>> give the stuff away. They're quite eager for business now too. >>>>> ;-) I Bought one of Altera's Cyclone-III (Arrow's, actually) >>>>> development boards for $200. There are even cheaper development >>>>> boards out there. Actel forgot to take their back. ;-) >>>>> >>>>>> There may be other small players, like Proteus, but I am >>>>>> unfamiliar with the tools. >>>>> >>>>> If all they're offering is the front end, why bother unless the >>>>> manufacturer's free tools don't work (high end chips or *really* >>>>> tight designs)? >>>> >>>> Altium's "front end" includes C and C++ compilers, >>> >>> What does a C/++ compiler do? FPGAs are concurrent devices so a >>> concurrent language is needed. >> >> It's for a soft core processor of course. A lot of FPGA designs >> these days will have a soft core processor in them, so it's a very >> common requirement. Altium comes with several soft cores for free. > > Ok, then is no different than any other *free* development system from > the chip manufacturers. Except that it's easier to use and "unified" (all in the one package) as the original thread title says. Altium have been flogging the "unified" title for years now. > Slaughter was suggesting that it was the FPGA > fabric development tool. Well that's just wrong, obviously. >>>> GUI like OpenBus, >>> >>> Everyone has a GUI. The whole purpose of a GUI is to make driving >>> the software simple(r). >> >> No, this is different. OpenBus is a propreity Altium thing that >> allows you to design an FPGA project in a visul "flow chart" type >> manner. i.e. drop a processor into your system and then connect >> external memory and periphers etc. You won't need any VHDL or other >> HDL code to get your project working if all the building blocks you >> want are in the Altium library. >> It almost certainly the easiest way possible to get an FPGA project >> up and running. It's not for everyone, but it is very simple. > > Proprietary is enough to kill the deal. For you, others may not care so much. > That's a major advantage of > HDLs; all you need is a text editor and you're good to go. Sure, but tell that to a beginner trying to crack into the world of FPGA's... > Indeed that's the one reason I won't use schematic entry for the data > flow. > Data flow is extremely tedious in HDL but locking it into a tool > defeats a major purpose of HDLs. > >>>> Real-time OS, and a C to Hardware compiler >>> >>> Oh, *that's* going to work. See above. >> >> Yes, it actually works. See above. > > SystemC, perhaps. If the love is so great for C why not Verilog. It's > almost as ugly as C. The advantage of a C-Hardware compiler is that you can write and refine your app in the soft processor in C (easier and more familar to most than a HDL, and maybe quicker recompile etc because you ain't rebuilding the FPGA) and then once your app is finished you can decide where you want more speed. Need a certain C function to execute quicker?, no problem, just drop it into the C-Hardware compiler and it automatically converts your that C code's function into HDL for you. And another advntage is you can continue to develop it in either C or HDL, your choice. It means that those familiar with C, processors, and sequential language programming can potentially take advantage of FPGA's without learning a HDL. Once again, not a solution for everyone, but very useful for many. >>>> along with the usual >>>> Schematic/VHDL/Verilog, all in a pretty easy to use environment. >>>> Plus you get 32bit processors and other IP. No restrictions. >>>> You get all that for 12months plus a development board all for >>>> $399. >>> >>> I thought you said the tools were $4K/yr. That is a big difference. >> >> No, an NB3000 development board with a 12month licence with >> everything you need to do FPGA/C/C++/C-Hardware/soft core etc is >> only $399. If you want the software outright it's only $995. You get >> everything except the PCB stuff. It's only $4K if you want the full >> package with PCB design outright. > > I misunderstood earlier. I was looking to switch schematic capture > tools a few weeks ago but we're pretty much locked into Allegro. I'm > pretty much stuck with Crapture. No point in going there, then. Altium's schematic-only (+FPGA/embedded) solution is either $999 outright or $49/month if your accountants prefer the 12month lease thing. Dave. -- --------------------------------------------- Check out my Electronics Engineering Video Blog & Podcast: http://www.eevblog.com
From: krw on 11 Oct 2009 17:11 On Sun, 11 Oct 2009 13:27:26 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On Oct 11, 1:10�pm, krw <k...(a)att.bizzzzzzzzzzz> wrote: >> On Sun, 11 Oct 2009 10:11:34 -0700 (PDT), MooseFET >> >> <kensm...(a)rahul.net> wrote: >> >On Oct 11, 8:32�am, krw <k...(a)att.bizzzzzzzzzzz> wrote: >> >[...] >> >> >> Proprietary is enough to kill the deal. �That's a major advantage of >> >> HDLs; all you need is a text editor and you're good to go. �Indeed >> >> that's the one reason I won't use schematic entry for the data flow. >> >> Data flow is extremely tedious in HDL but locking it into a tool >> >> defeats a major purpose of HDLs. >> >> >Even things like having to work around bugs in the various compilers >> >makes for troubles in porting between tools. �The Altera VHDL tool >> >doesn't do the right thing when you assign Z to a signal. �You have to >> >use their tri() kludge. >> >> Haven't quite gotten that far with Altera yet, but is this in internal >> 'Z' or inferring a 'Z' in an IOB? > >The assignment of the 'Z' was some layers deep and the signal came out >to a pin at the main level. Yes, that's a common problem. Xilinx has the same issue. The IOBs have to ge at the top level of hierarchy. :-( Actually, I find that to be good practice, but a PITA. > >> Tool bugs are certainly a problem, enough that I'd dump a manufacturer >> if they were too buggy. �Times have changed, though. > >At least, they need to publish a list of them and the work-arounds for >them. For things like that there usually are, though not tabulated I guess. >> >It is too long ago now so I'd have to paw through the source code but >> >there was another thing that the Altera tools messed up on that was >> >more major. >> >> Things have gotten a *lot* better over the years. �A decade ago I >> bought the Synplicity tools because Xilinx' were so messed up. �I >> wouldn't today. >> >> >Cypress used to make CPLDs but unfortunately, I designed one of them >> >in so they decided to get out the business. �Their development kit was >> >fairly nice. �It wasn't as huge as some others and seemed to be >> >targeted at just doing what was needed to make VHDL get into an IC. >> >It didn't have a lot of mysterious features to mess you up. >> >[....] >> >> >> I misunderstood earlier. �I was looking to switch schematic capture >> >> tools a few weeks ago but we're pretty much locked into Allegro. �I'm >> >> pretty much stuck with Crapture. �No point in going there, then. >> >> >If I didn't have to interface with others, I would use the GEDA >> >tools. �They keep all the files in ASCII. �This means that you can >> >make your own tools to do funny things you may decide are needed like >> >finding all the package types in the design etc. >> >> That's even easy with OrCAD Crapture. �There are a lot of things like >> that are easy in Crapture. �Unfortunately, other far more important >> things are impossible. �:-( > >I tried Crapture and after it munged the whole design, dropped it. I >use the clunky old DOS Orcad. It does all the things needed. I'd try the DOS version if I could. Crapture 15.7 crashes often (10-20 times a day, if I'm really using it) but usually saves on a crash. A couple of weeks ago it crashed taking all open files with it. Fortunately I'd just made a copy of all of the work. I "only" had to figure out what I'd done in the last couple of hours. It was only a day wasted. I wasted a lot more than that before figuring out that their hierarchy tools didn't work.
From: MooseFET on 11 Oct 2009 21:04 On Oct 12, 5:11 am, krw <k...(a)att.bizzzzzzzzzzz> wrote: > On Sun, 11 Oct 2009 13:27:26 -0700 (PDT), MooseFET > > > > <kensm...(a)rahul.net> wrote: > >On Oct 11, 1:10 pm, krw <k...(a)att.bizzzzzzzzzzz> wrote: > >> On Sun, 11 Oct 2009 10:11:34 -0700 (PDT), MooseFET > > >> <kensm...(a)rahul.net> wrote: > >> >On Oct 11, 8:32 am, krw <k...(a)att.bizzzzzzzzzzz> wrote: > >> >[...] > > >> >> Proprietary is enough to kill the deal. That's a major advantage of > >> >> HDLs; all you need is a text editor and you're good to go. Indeed > >> >> that's the one reason I won't use schematic entry for the data flow. > >> >> Data flow is extremely tedious in HDL but locking it into a tool > >> >> defeats a major purpose of HDLs. > > >> >Even things like having to work around bugs in the various compilers > >> >makes for troubles in porting between tools. The Altera VHDL tool > >> >doesn't do the right thing when you assign Z to a signal. You have to > >> >use their tri() kludge. > > >> Haven't quite gotten that far with Altera yet, but is this in internal > >> 'Z' or inferring a 'Z' in an IOB? > > >The assignment of the 'Z' was some layers deep and the signal came out > >to a pin at the main level. > > Yes, that's a common problem. Xilinx has the same issue. The IOBs > have to ge at the top level of hierarchy. :-( Actually, I find that > to be good practice, but a PITA. > > > > >> Tool bugs are certainly a problem, enough that I'd dump a manufacturer > >> if they were too buggy. Times have changed, though. > > >At least, they need to publish a list of them and the work-arounds for > >them. > > For things like that there usually are, though not tabulated I guess. > > > > >> >It is too long ago now so I'd have to paw through the source code but > >> >there was another thing that the Altera tools messed up on that was > >> >more major. > > >> Things have gotten a *lot* better over the years. A decade ago I > >> bought the Synplicity tools because Xilinx' were so messed up. I > >> wouldn't today. > > >> >Cypress used to make CPLDs but unfortunately, I designed one of them > >> >in so they decided to get out the business. Their development kit was > >> >fairly nice. It wasn't as huge as some others and seemed to be > >> >targeted at just doing what was needed to make VHDL get into an IC. > >> >It didn't have a lot of mysterious features to mess you up. > >> >[....] > > >> >> I misunderstood earlier. I was looking to switch schematic capture > >> >> tools a few weeks ago but we're pretty much locked into Allegro. I'm > >> >> pretty much stuck with Crapture. No point in going there, then. > > >> >If I didn't have to interface with others, I would use the GEDA > >> >tools. They keep all the files in ASCII. This means that you can > >> >make your own tools to do funny things you may decide are needed like > >> >finding all the package types in the design etc. > > >> That's even easy with OrCAD Crapture. There are a lot of things like > >> that are easy in Crapture. Unfortunately, other far more important > >> things are impossible. :-( > > >I tried Crapture and after it munged the whole design, dropped it. I > >use the clunky old DOS Orcad. It does all the things needed. > > I'd try the DOS version if I could. You may be able to lay your hands on a copy. They sold quite a few so there should be a lot of honest copies out there not in use. I run it under dosemu in a linux box. >Crapture 15.7 crashes often > (10-20 times a day, if I'm really using it) but usually saves on a > crash. It is Windoz software. The default action is to crash without warning. You need to go into the "hidden settings" dialog and set the crash to "daily" instead of "random". This way at least you would know that it will crash just once a day. What ever you do don't set your network up as a "windows domain" network and save the schematics in any folder that windows created. Make your own folder with your own name. For reasons that aren't clear, a network error will cause it to mung the files if you don't do this. Never bring up "outlook" when Crapture is running. They interact in a funny way that tanks Crapture. > A couple of weeks ago it crashed taking all open files with > it. Fortunately I'd just made a copy of all of the work. I "only" > had to figure out what I'd done in the last couple of hours. It was > only a day wasted. I wasted a lot more than that before figuring out > that their hierarchy tools didn't work. I use the DOS one. The "place sheet" works fine but there is one thing that you must never do. Never make two sheets in upper level use the same file to do repeated circuits. The net list generation doesn't work as documented in that case.
From: Jon Slaughter on 11 Oct 2009 21:24 "MooseFET" <kensmith(a)rahul.net> wrote in message news:a019ae9e-8406-46c6-9121-eb073ad2fd67(a)z3g2000prd.googlegroups.com... On Oct 11, 1:02 pm, krw <k...(a)att.bizzzzzzzzzzz> wrote: > On Sun, 11 Oct 2009 09:59:46 -0700 (PDT), MooseFET > > > > <kensm...(a)rahul.net> wrote: > >On Oct 10, 6:50 pm, "David L. Jones" <altz...(a)gmail.com> wrote: > >> Jon Slaughter wrote: > >> > "Jon Slaughter" <Jon_Slaugh...(a)Hotmail.com> wrote in message > >> >news:haoqug$35j$1(a)news.eternal-september.org... > >> >> Is there a development suite that is good but can target multiple > >> >> fpga manufactures? I don't really want to install a bunch of 1GB+ > >> >> light versions > >> >> for each manufacture just to see which one is best. In fact I can't > >> >> even get > >> >> libero to run because it crashes on startup. > > >> >> Also, know of any links for DIY fpga programmers? How hard is it to > >> >> program? I figured that one just has to feed a bitstream into the > >> >> fpga similar to how a pic is programmed(or most devices actually). > >> >> Looking at the proASIC's makes me think it's a bit different but I > >> >> haven't found any conclusive way to program them except by using > >> >> DirectC or the STAPL Player. > >> >> Since I'm experimenting with these different manufactures I don't > >> >> want to have to buy a programmer for each chip. For as much as they > >> >> cost I could get > >> >> nanoboard with 10^10x the functionality. > > >> > BTW, I forgot to mention that I want to program in C++. Pure C++ but > >> > SystemC or similar if necessary. > > >> Altium have a Xilinx (others on the way) development board and 12 month > >> license of their full soft package for > >> $399http://www.newark.com/altium/12-400-nb3000xn-01/nanoboard-3000xn-xili... > > >> For that you get C and C++, VHDL/Verilog, GUI like OpenBus, Real-time > >> OS, > >> and/or C to Hardware compiler for your development. Plus 32bit > >> processors > >> and other IP. No restrictions. > > >> Altium uses the Xilinx (or other) tools as the back-end, but it's all > >> seamless, you don't notice you are using them. > > >> If you do want to experiment with different manufactuers, the Nanoboard > >> NB2 > >> is better, but it's $2K. > > >> They have a JTAG programmer for $150 for use on your own custom > >> boards:http://www.newark.com/altium/12-403-dt01/usb-jtag-adapter/dp/10R0257 > > >If your software can output a *.JAM file, you can make your own JTAG > >cable for way under $150. > > >Altera published the code for a JAM/STAPL player some years back. I > >have a hacked version that I use all the time. The very nice thing > >about it is that it can be made simple enough that you can write the > >instructions for using it on a single page. > > The STAPL player is used for all their CPLDs as the means of in-system > programming. They have the source on their site. All you have to do > is add the low-level I/O routines for your hardware (e.g. PC printer > port) and link it all together. It's so easy Actel swiped it. ;-) My hacked version(s) will compile on a 16 bit MS-DOS machine with BC and work even for the large CPLDs and if compiled by gcc, it works on Linux. It flips the different code in and out with #ifdef statements. --- I downloaded that and DirectC from actel. The DirectC is C source that I believe you can use on just about any uC that you can compile it with. Should be easy to look at the code and figure out how it bit bangs the data(and interprets it). Although that could be a lot of work...
From: Michael A. Terrell on 12 Oct 2009 11:09
"David L. Jones" wrote: > > Altium's schematic-only (+FPGA/embedded) solution is either $999 outright or > $49/month if your accountants prefer the 12month lease thing. Somthing is wrong with your math: $49/month *12 = $588. -- The movie 'Deliverance' isn't a documentary! |