PSoC or FPGA?

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

Reply to
fasf
Loading thread data ...

FPGA, without a doubt. PSoCs are interesting but have a very limited market.

There are hundreds of them around. I would suggest one of the Altera kits, only because their software is better than Xilinx and Altera is more "mainstream" than third place. Some put a lot of weight on experience with a particular vendor.

For FPGAs, I'd suggest VHDL. Verilog seems to be more popular in the ASIC world and VHDL in the FPGA world. Both would be helpful, but not at once. Do a typical "stoplight" design, then concentrate on simulation. VHDL for design is easy. Simulation is where it's at. Don't think you can skip simulation for anything more complex than a blinking light.

Reply to
krw

On a sunny day (Sun, 20 Mar 2011 12:19:43 -0500) it happened " snipped-for-privacy@att.bizzzzzzzzzzzz" wrote in :

Just for fun I did a frequency counter, a LCD display driver, and a smart card reader all without simulation on a Spartan 2. No problem. I used iverilog to test some crypto, and then used simulation to test it further. I did the TV up converter (15625 to VGA) without simulation, and the sync separator / slicer too. and the video filter. But I do not use MPlab for PICs either... just write the asm directly. Faster and better that way.

There is too much simulations in this world. NASA has changed from a manned space agency to one that sells simulations to the public of astronuts mars landing Zillions are spend on sup[p]er computers that do simulations of problems that any sane person can work out with eyes closed in a blink. Beware of simulations. Reality always rules, use a scope. But simulations can sometimes be cheaper and avoid lead poisening from soldering. I mean I am sure they ran simultions for those nuke plants too.

Reply to
Jan Panteltje

I never used a simulator for FPGA design and I did quite a few designs over the pas 10 years. I've always used a logic analyzer and a debug bus which can output internal FPGA signals. The use of a simulator is limited because you also have to model the outside world accurately. In my experience most of the problems are in interfacing with the (asynchronous) outside world.

Having typed that I must say that I'm interested in learning how to use a simulator for FPGA design to see if it really can shorten development time. I just didn't had the time yet. Simulating electronic circuits is an art in itself. I guess simulating FPGA designs is no different given the number of forum postings saying 'it works in the simulator but not on my board'.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

You needn't say anything else. At least you're consistent; clueless.

Reply to
krw

It's a *lot* easier simulating, even simple designs. There is no way you're going to get anything of any complexity working with just internal debug ports. A simulator can also test scenarios that are very difficult to force in the real world.

Most of my problems with the outside world is because whatever I'm interfacing to is not well documented. Asynchronous interfaces shouldn't be a major problem if the design is right. Modern FPGAs are quite fast.

That's what they all say. ;-) It's common to rush into the design phase. FPGAs are no different, here, except that you really can't tie a scope on nodes to see what's happening.

Simulation is an art. I did a *lot* of it, six years in design verification on PPC processors (Nintendo and Apple processors). I certainly don't go into that detail with my FPGA simulation, but I do a fair bit. VHDL for simulation is *much* different than that used for synthesis. In some ways it's easier, but the subset of the language used is far greater. Making a useful testbench is a lot of work but it does pay off in anything but the most trivial designs.

Reply to
krw

For more complicated signal processing I prototype in C first. That's much faster than simulating. Verifying the logic afterwards is a piece of cake if you implement some resources for self tests.

If you create a debug unit, you can output the most important signals. Software can also be used to read the status of the FPGA logic. This will also allow for debugging later on.

A few years ago I had to debug a PCI based design which sometimes got stuck when a computer of a specific type/brand rebooted. It turned out a statemachine didn't reset properly. This problem was triggered because the computer didn't unload the drivers before rebooting. The internal debug facilities of the design where very useful for tracking the problem using a logic analyzer.

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

You don't need to make a choice between PSOC and FPGA. Actel sells Smartfusion. SmartFusion intelligent mixed signal FPGAs are the only devices that integrate an FPGA, ARM=AE Cortex=99-M3, and programmable analog, offering full customization, For an overview see:

formatting link

An evaluation kit is available for $99.00. See:

formatting link

Howard

Reply to
hrh1818

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 soft drink machine that did the usual coin counting/dispensing during the day and at night reconfigured into a DTMF to dial the home office then reconfigured into a 300 BPS modem to upload data then downloaded instructions. At one company where I worked, the PSoC replaced three other micro controllers because of its flexibility.

The scheme uses registers to set up counters, timers, amplifiers, input/output pins, filters, and lots of other stuff. It is done by setting registers. Most of the setup is done in the GUI provided for free by Cypress. So, to get the chip to reconfigure itself, all you need to do is change the register settings. Even that can be handled by the GUI. Or, you can do it yourself.

The learning curve is steep with Cypress' PSoC 1. It is possibly shorter with the PSoC 3 and 5 due to the schematic-type setup.

I have no financial connection with Cypress. I've just been using their PSoC chips since about 2002.

Cheers, John

Reply to
John - KD5YI

On Sun, 20 Mar 2011 22:45:45 GMT, snipped-for-privacy@puntnl.niks (Nico Coesel) wrote: ...

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. If you are not simulating, you are leaving a lot on the table with respect to time (a largish FPGA can take hours to synthesize+p&r), observability and controllability of the chip under test.

--
Muzaffer Kal

DSPIA INC.
 Click to see the full signature
Reply to
Muzaffer Kal

On a sunny day (Sun, 20 Mar 2011 15:16:14 -0500) it happened " snipped-for-privacy@att.bizzzzzzzzzzzz" wrote in :

Take your intelligence for example.

I do not think we will ever see any code from you, all you do is boast about how big the things are you make, insult people, etc, while from the time it takes you to do the simplest things I guess you are at least incompetent, and at most a windbag.

Reply to
Jan Panteltje

Well, tell that to the big semi manufacturers :-) Many microcontrollers and SoCs have several versions with bugs. Recently even Intel got bitten badly.

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.

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

There's also too little simulation in the world.

The project you described, yeah, they're well within the realm of being straightforward enough to not bother with any simulation before you just program up a part and see what happens. But when you get to more complex systems, even with good designers it rapidly becomes obvious that simulation more than pays for itself. E.g., some years back I designed a DMA-based memory controller for 8 slots worth of SDRAM SIMMs, and since I wanted it to be reasonably efficient the memory controller could have several memory accesses in process simulation and would also re-order incoming DMA requests to better utilize SDRAM banks that had already been opened for other operations. I'm quite certain that without the Microon-provided SDRAM simulation models I used, I would have spent hundreds of additional hours trying to get the thing working -- if only due to ending up writing my own testbenches, since this had a 128-bit wide data bus running at over 100MHz, and I sure didn't have a logic analyzer or anything else that had nearly enough inputs to try to watch what was going on -- much less make much sense of it all (since all the acceses were so heavily interleaved).

The reason there's too little simulation in the world is that even of people who buy into the idea that simulation is a Good Thing, I've seen far too much cases where the designer (and this applies to those using C/C++ as well as VHDL/Verilog) writes a testbench that only exercises what the design *should* do... which is largely worthless; by far the greatest value from testbenches comes when you purposely try to destroy your design by feeding it an unrelenting stream of garbage data... or at least a stream designed to abuse the underlying model as much as possible. :-) (This is how I tested the SDRAM controller -- feeding it a new randomized request through every single DMA port on every single clock cycle...)

Although one doesn't always have a choice, it's best if someone else writes the testbench for your design... and that that person's deepest desire is to make your design fail. :-)

For a board level design, sure. For FPGA and (particularly) IC designs, it's quite expensive.

---Joel

Reply to
Joel Koltner

On a sunny day (Mon, 21 Mar 2011 09:58:00 -0700) it happened "Joel Koltner" wrote in :

Yes OK, and I use LTspice too... But what I do not like is where simulations replace what should be reality, like NASA having simulations of people landing on mars, while all they can really do is fly around the block (earth). The brain is quite powerful, and it can do most of the simulations that supercomputers are now used for, those are merely executing some equations that are always a subset of reality, then tinkered in a way so they see what they want to see, and that then is called a new 'theory'. Or in electronics 'design'. 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.

Reply to
Jan Panteltje

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)?

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

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."

:-)

Reply to
Joel Koltner

That looks very interesting and at a very good price, considering the plexi cover and all the rest.

That's good. What about the tools needed to load, modify, and recompile with it? It looks like the EDS is free:

formatting link

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.)

Jon

Reply to
Jon Kirwan

they want to see,

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 optimize 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've never done an FPGA, but I suspect they might be similar in that respect.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
 Click to see the full signature
Reply to
Phil Hobbs

Wow! You got that right. I don't WRITE CODE, moron.

least incompetent, and at most a windbag.

You sure are a useless twit, JP.

Reply to
krw

Um, I worked for one. I was on the verification team (a department of twelve) for some rather "big" processors.

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.

Duh!

How many flops? "Equivalent gates" is a meaningless number.

Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.