PSoC or FPGA?

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.

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.

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.

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

Question is, do I have time right now? Maybe.

I may have some questions when the time comes. But the above helps by giving me some things to check up on.

Sounds positive. And that's a lot, these days.

Jon

Yea, that was clear already.

On a sunny day (Mon, 21 Mar 2011 17:23:34 -0400) it happened Phil Hobbs wrote in :

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.

On a sunny day (Mon, 21 Mar 2011 13:31:27 -0700) it happened "Joel Koltner" wrote in :

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.

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

Jan Panteltje expounded in news:im9soq$e0a$ snipped-for-privacy@news.albasani.net:

If you work on large systems, then avoiding debuggers is a huge waste of time. When you have intermittant or unexplained failure(s) a debugger saves gobs of time since you don't have to anticipate what to "print".

When your code core dumps, a debugger will trace back the precise point of the failure and allows you to look at anything related to it.

All of this facility comes with a simple compile option. No need to code special macros.

In short, you're following some bad and antiquated advice.

Warren

On a sunny day (Tue, 22 Mar 2011 13:26:45 +0000 (UTC)) it happened Warren wrote in :

That is a matter of opinion. I have seen to many programmers staring too long at little windows with register values... While just some sane coding and understanding WHAT you were doing (in C), and print statements in the right place, would have saved hours, and prevented all that 'searching', and segfaults too.

It is a beginners idea, I started with 'debugger'. From a programming POV at some point you have to trust the compiler writers, no need to go through the generated asm even.

You can take that too far too. For example write in Java because you are scared of pointers, and then make a product that sucks for speed and performance. 'Oh lets write this in Java, it will run anywhere'. NOT. Coding is not for everyone, but many who have no talent for it do it for a job, like music made by somebody who cannot play. For those those sluggish languages and C++ was created, too bad it only makes their work worse. And then people start to believe you need many cores many GHz to do the simplest things, like email. And that sells hardware, so those manufacturers will not disturb that dream. The ones who sell you the next C++ compiler, plus debugger, will not disturb your dream either. Reality is however that you should have a clear mind when you code and not make one error every line, and spend 30 minutes with a debugger for every line of code you write. The fable of 'large project' is just that. Things should be modular, and C and C libraries is a very good way to do that. Linux is a good example from a huge project with many distributed developers, written in C, and in Linux I never used a debugger ever. Oh I know gdb, I played with it, but I rather write code than trace gcc output. Sure there are bugs in each gcc version, just that those never seem to have wrecked my code. Some sanity is required. Not everybody is a programmer, not everybody loves that stuff. I do not claim to be a programmer, I just write what I need, and somehow enjoy that. Some others benefit as I make much code available, if I can, and it is not NDA stuff. I know my programs are full of bugs, but they get the job done. That is the point where my quest for perfection in programming usually ends. Programs are a tool, not a purpose in themselves, no tool is absolutely perfect, try looking for the perfect hammer, I have broken some expensive ones... Anyways, there is no end to what can be said about that subject, and no limit to all the different viewpoints., This is just my viewpoint. So I will leave it at that,

comp.arch.fpga is a good newsgroup for FPGA questions. And there are far less offtopic posts than in this newsgroup, maybe because of less retirees and more people doing real work :-)

Thanks.

Jon

Jan Panteltje expounded in news:imanmt$clr$ snipped-for-privacy@news.albasani.net:

Your's is in the minority. :)

That speaks volumes about the programmers-- and nothing about the value of the debugger. Don't get me wrong- a few carefully crafted prints can augment a difficult debug.

But to write off a debugger is like saying "I can saw it by hand, so I don't need no stinkin' table saw".

Warren

That stuff is interesting in itself but not of much use when designing with FPGAs. FPGA architecture favors certain types of adders. It's rare that you'll beat synthesis for an ALU. As far as more complex functions like multipliers and dividers, the manufacturer's libraries are also going to be hard to beat.

Modern devices are *way* beyond where the Xilinx 4Ks were. The Altera and Xilinx FPGA logic elements are pretty similar (their CPLDs are quite different).

Always a good question. Priorities.

Moron, I'm hardware engineer. Software is for dweebs.

I am doing none of this for professional work -- I just enjoy learning, a lot. I want to know how to do things simply because I enjoy the process. Which means that I'd love to learn from the libraries of others, but I also need to learn to walk, first, so that I can place what I learn from professionals into a better contextual frame.

In any case, this kind of thing is pure joy to me.

I need to revisit, obviously.

Hehe.

Jon

Understood, I just wanted to make the point that while this stuff is useful to know, it doesn't have much application in FPGAs. ASIC design is a whole 'nuther kettle. FPGA, in this way, are much more restrictive.

It's even more fun when you can get someone to pay you to do it. ;-)

Indeed. The first time I saw carry chains, I said "yech, carry chains?". I finally had to suck it up and admit that a ripple counter was faster than the fancier counters, so why knock myself out. Besides, the carry chains are quite hand for other functions. ;-)

;-)

I'm getting paid to do stuff I'd do for free, or even pay others to allow me to do. If I got good enough to get paid for writing VHDL code and then added that to the list, I'd probably die from forgetting to eat out of the pure excess pleasure of it all. I'm far too lucky as it is. ;)

Jon