On Mon, 21 Mar 2011 20:25:49 GMT, nico@puntnl.niks (Nico Coesel) wrote:>John - KD5YI <sophi.2@invalid.org> wrote: > >>On 3/20/2011 4:10 AM, fasf wrote: >>> Hi, >>> i've worked wit 8bit/32bit microcontrollers for 5 years and now i want >>> to explore new fields, so i'm interested in these two solutions: PSoC >>> and FPGA. I'm totally new (i don't know neither VHDL nor Verilog) and >>> i don't understand the differences between these programmable devices. >>> For hobby, what do you think is more useful to study? Can you suggest >>> a low cost DevKit? >>> Any getting started suggestion will be very appreciated >> >> >>Well, I will put in a plug for Cypress' PSoC. I've been using them for >>years. However, if you need blazing speed, you will need to go the FPGA >>route as the PSoC is nothing more than a microcontroller that has some >>analog goodies. >> >>I like the PSoC because it is extremely configurable/reconfigurable to >>almost anything you need. An example that Cypress came out with was a >> >>I have no financial connection with Cypress. I've just been using their >>PSoC chips since about 2002. > >Looks interesting. I checked the website a bit but couldn't find all I >want to know: How is the analog performance regarding noise and >bandwidth? Can you also use a Psoc as a reconfigurable analog brick >(analog in - analog out)?I looked into them a year ago, or so. The A/D stuff was mediocre, at best. I didn't think the analog performance was anything to write home about, either.
PSoC or FPGA?
Started by ●March 20, 2011
Reply by ●March 21, 20112011-03-21
Reply by ●March 21, 20112011-03-21
"krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz> wrote:>On Mon, 21 Mar 2011 15:44:26 GMT, nico@puntnl.niks (Nico Coesel) wrote: > >>Muzaffer Kal <kal@dspia.com> wrote: >> >>>On Sun, 20 Mar 2011 22:45:45 GMT, nico@puntnl.niks (Nico Coesel) >>>wrote: >>>... >>>>You can simulate a lot but creating a set of tests which covers all >>>>the possible mayhem coming from the outside world is next to >>>>impossible. >>> >>>This suggests that making an ASIC work right the first time is next to >>>impossible but experience shows that it's not. So it's just a matter >>>of how diligent one is with one's tests. >> >>Well, tell that to the big semi manufacturers :-) > >Um, I worked for one. I was on the verification team (a department of twelve) >for some rather "big" processors. > >>Many >>microcontrollers and SoCs have several versions with bugs. Recently >>even Intel got bitten badly. > >Are you saying that you think simulation should make perfection automatic? No, >there are too many things that go unsimulated. That is, too little >simulation, not too much. > >>And there still may be unexpected behaviour coming from the outside >>which might not be addressed by the design (incomplete specification). >>If you have an ASIC you most probably need to fix the outside world, >>if you are using an FPGA (or something else which is programmable) you >>most likely end up fixing the FPGA design. > >Duh! > >>I think FPGA simulation is very usefull but I always got by without it >>or used other methods for verification. The maximum size of the >>designs I worked on is about 800k to 1M equivalent gates. > >How many flops? "Equivalent gates" is a meaningless number.Good question. I think somewhere between 1000 to 2000. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
Reply by ●March 21, 20112011-03-21
On 22/03/2011 6:44 AM, john1987 wrote:> Hi, > > I need to connect a 12 volts DC lead acid battery to a circuit. The > circuit draws 100mA and works at 3.3V. I am planning to use 7805 to > drop the voltage from 12 to 5 volts. > > The first thing is that how can I bypass the 7805 while charging the > battery? > > The thing is that I also needs to recharge the battery too. The > Circuit and the battery charger both have same input power connector > on them and the battery has the mating connector for both of them. > > > > Thanks > John,This is absolutely easy, I'm just not sure why you would do it. Just use diodes to isolate and bypass the circuit sections see: http://www.filedropper.com/2terminalpsu note U1 is supposed to be a 7805 but I didn't have one.
Reply by ●March 21, 20112011-03-21
On Mon, 21 Mar 2011 23:31:31 GMT, nico@puntnl.niks (Nico Coesel) wrote:>"krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz> wrote: > >>On Mon, 21 Mar 2011 15:44:26 GMT, nico@puntnl.niks (Nico Coesel) wrote: >> >>>Muzaffer Kal <kal@dspia.com> wrote: >>> >>>>On Sun, 20 Mar 2011 22:45:45 GMT, nico@puntnl.niks (Nico Coesel) >>>>wrote: >>>>... >>>>>You can simulate a lot but creating a set of tests which covers all >>>>>the possible mayhem coming from the outside world is next to >>>>>impossible. >>>> >>>>This suggests that making an ASIC work right the first time is next to >>>>impossible but experience shows that it's not. So it's just a matter >>>>of how diligent one is with one's tests. >>> >>>Well, tell that to the big semi manufacturers :-) >> >>Um, I worked for one. I was on the verification team (a department of twelve) >>for some rather "big" processors. >> >>>Many >>>microcontrollers and SoCs have several versions with bugs. Recently >>>even Intel got bitten badly. >> >>Are you saying that you think simulation should make perfection automatic? No, >>there are too many things that go unsimulated. That is, too little >>simulation, not too much. >> >>>And there still may be unexpected behaviour coming from the outside >>>which might not be addressed by the design (incomplete specification). >>>If you have an ASIC you most probably need to fix the outside world, >>>if you are using an FPGA (or something else which is programmable) you >>>most likely end up fixing the FPGA design. >> >>Duh! >> >>>I think FPGA simulation is very usefull but I always got by without it >>>or used other methods for verification. The maximum size of the >>>designs I worked on is about 800k to 1M equivalent gates. >> >>How many flops? "Equivalent gates" is a meaningless number. > >Good question. I think somewhere between 1000 to 2000.That's a moderate size. I'd never attempt anything even that complex without a pretty extensive simulation suite. I prefer to spend more time in simulation than in debug.
Reply by ●March 22, 20112011-03-22
Jon Kirwan wrote:> That's good. What about the tools needed to load, modify, > and recompile with it? It looks like the EDS is free: > > http://www.altera.com/products/ip/processors/nios2/tools/ni2-development_tools.html > > But have you gone through the steps? Is the Eclipse IDE also > free? (I'm not sure yet from a quick scan, but need to spend > more time I suppose.)Yes, I have tested it with my old T-Rex board and it works. I can create a NIOS II CPU with the free NIOS II EDS is and Quartus II Web Edition. The economy version is not crypted anymore, so you can see all the generated VHDL code for the CPU (doesn't look good, as usual for generated code) and the peripherals. If you choose the larger NIOS II CPU models, it will be crypted and time limited and you have to buy a license. But you have to spend some days learning the system. I've done a project some years ago, so I know where the pitfalls were, because NIOS EDS is not self-explanatory. E.g. you have to create a Quartus project, first, then call the SOPC Builder function from within and after you've designed your CPU system and peripheral, you have to start Eclipse and use the SOPC file for creating the Eclipse project. But when I tried the hello world wizard, it created the BSP, only, not the project, so I created it manually, but then the LED blinked on my T-Rex, after importing the generated VHDL files manually into the Quartus project. But it is worth to learn it, because there are lots of free cores in the SOPC Builder, which can be added by mouse click to the system and once the Eclipse project works, you can debug the system over JTAG. Maybe it is easier with some tutorial from Altera, I guess they have some. My main job is not hardware designing, so from a programmer perspective last time I tried to understand how the NIOS EDS worked, the whole system looked like a duct-taped system, with lots of Shell and TCL scripts, Perl code generators, Makefiles, all called from Java and the Makefiles called Java programs again. Perl, Shell etc. was running with Cygwin, which doesn't help for the speed. But at least it works and you can create commercial projects with it. Altera support was good, too, e.g. they helped me when I tried to do unusual things, like combining the bitstream configuration file and the NIOS ELF file into the configuration EEPROM, with my own checksum, which was possible, if you write your own Bash scripts. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbuss
Reply by ●March 22, 20112011-03-22
On Tue, 22 Mar 2011 07:20:06 +0100, Frank Buss <fb@frank-buss.de> wrote:>Jon Kirwan wrote: > >> That's good. What about the tools needed to load, modify, >> and recompile with it? It looks like the EDS is free: >> >> http://www.altera.com/products/ip/processors/nios2/tools/ni2-development_tools.html >> >> But have you gone through the steps? Is the Eclipse IDE also >> free? (I'm not sure yet from a quick scan, but need to spend >> more time I suppose.) > >Yes, I have tested it with my old T-Rex board and it works. I can create >a NIOS II CPU with the free NIOS II EDS is and Quartus II Web Edition. >The economy version is not crypted anymore, so you can see all the >generated VHDL code for the CPU (doesn't look good, as usual for >generated code) and the peripherals. If you choose the larger NIOS II >CPU models, it will be crypted and time limited and you have to buy a >license.Okay. I'll take a crack at it. I've an older xilinx 4000 series board I used to learn VHDL and _some_ floorplanning skills for fun. Been a while, though. It is worth another go. (Never did try verilog, yet.) I enjoyed struggling to develop a tiny cpu and achieved some modest success -- succeeded on a reasonably useful ALU and learned a little about carry forward vs ripple carry and about booth's divider, for example. This sounds like still more cheap fun, though I wonder if each cell in the Altera devices are as fancy as the xilinx 4000 cells were. Question is, do I have time right now? Maybe.>But you have to spend some days learning the system. I've done a project >some years ago, so I know where the pitfalls were, because NIOS EDS is >not self-explanatory. E.g. you have to create a Quartus project, first, >then call the SOPC Builder function from within and after you've >designed your CPU system and peripheral, you have to start Eclipse and >use the SOPC file for creating the Eclipse project. But when I tried the >hello world wizard, it created the BSP, only, not the project, so I >created it manually, but then the LED blinked on my T-Rex, after >importing the generated VHDL files manually into the Quartus project. >But it is worth to learn it, because there are lots of free cores in the >SOPC Builder, which can be added by mouse click to the system and once >the Eclipse project works, you can debug the system over JTAG. Maybe it >is easier with some tutorial from Altera, I guess they have some.I may have some questions when the time comes. But the above helps by giving me some things to check up on.>My main job is not hardware designing, so from a programmer perspective >last time I tried to understand how the NIOS EDS worked, the whole >system looked like a duct-taped system, with lots of Shell and TCL >scripts, Perl code generators, Makefiles, all called from Java and the >Makefiles called Java programs again. Perl, Shell etc. was running with >Cygwin, which doesn't help for the speed. But at least it works and you >can create commercial projects with it. Altera support was good, too, >e.g. they helped me when I tried to do unusual things, like combining >the bitstream configuration file and the NIOS ELF file into the >configuration EEPROM, with my own checksum, which was possible, if you >write your own Bash scripts.Sounds positive. And that's a lot, these days. Jon
Reply by ●March 22, 20112011-03-22
On a sunny day (Mon, 21 Mar 2011 13:31:27 -0700) it happened "Joel Koltner" <zapwireDASHgroups@yahoo.com> wrote in <AAOhp.318155$Mg5.159407@en-nntp-06.dc1.easynews.com>:>"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message >news:im8c6e$crk$1@news.albasani.net... >> Simulations is a drug. >> What you need is overview, and detailed knowledge of what you are doing. >> Bottom up, modular. >> Then nothing is impossible, and the sky the limit. >> Top-down with simulations sucks. > >Ever hard this quote, Jan? > >--> "Some people, when confronted with a problem, think "I know, I'll use >regular expressions." Now they have two problems." > >:-)Couple of years ago there was a Dutch software company that designed the luggage handling system for the new UK air terminal. Their simulation sold it I think. But the reality version had some serious problems that made the news quite a bit.
Reply by ●March 22, 20112011-03-22
On a sunny day (Mon, 21 Mar 2011 18:13:19 -0500) it happened izzzzzzzzzzzzzzzzzzzzzzzz> wrote:>Wow! You got that right. I don't WRITE CODE,Yea, that was clear already.
Reply by ●March 22, 20112011-03-22
On a sunny day (Mon, 21 Mar 2011 17:23:34 -0400) it happened Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in <4D87C1D6.6000109@electrooptical.net>:>Taking a simulation and poking it until it sort-of works is a recipe for >mediocre performance, at best. On the other hand, board turns and the >attendant delays are expensive. In analogue, it's best to design stuff >by hand and simulate to verify (and maybe optimise some badly-behaved >stuff that's hard to do by algebra, e.g. parametric effects). > >I'm a big fan of debuggers for code, because that makes it faster to >explore all the branches and reduces the number of bugs that make it >into the version control system.I stopped using debuggers in the eighties, after reading a paper from university that argued against debuggers in higher level languages,. It suggested to use print statements. Even asm is a high level language for me, usually first thing I do is add some routines to print decimal and ASCII via a serial port or pin for debug. Else in C printf(). But in C I start most functions with a parameter check, parameter report, that can be enabled by a debug flag set on the command line. So if I run program -v then it will print all function calls and all variables to those functions. Important in this is that you can have a user / customer run the program like that if it ever crashes and send you the output text, the last line will be the function with the incorrect code. It takes some discipline coding, but it works 100%. As for FPGA, I have not done so much with those as some geniuses here, the main philosophical difference is that things can happens in parallel, maybe difficult to grasp if one comes from a sequential programming background, but for somebody from a hardware background it is just a lot of simple hardware blocks connected together. With wires. Means you can build your own collection of blocks just like library functions. Issues are clock timing, gate delays, just like ordinary digital logic. FPGA vendors have their own libraries to solve standard problems, usually in an optimised form. That means however not all things are easily portable from one make FPGA to an other, It also means one manufacturer's FPGA may be more suitable to solve a specific problem than an other one. Have not used a FPGA in over a year, so maybe I should shut up on that subject. Some FPGA manufacturers have the worst software in the universe except for the Silversoft C compiler I once had for the Sinclair ZX80, maybe created by the same team? Xilinx comes to mind.
Reply by ●March 22, 20112011-03-22
On Tue, 22 Mar 2011 03:09:44 -0700, I wrote:><snip> >learned a little about carry forward vs ripple carry and >about booth's divider, for example. ><snip>Sorry. I meant booth's multiplication method. For the divider, I tried a technique I found in Analog Device's book on the ADSP-21xx family and non-restoring division, too. Jon
