A chip too far? Where is your solution Mr Larkin?

...

Only if you get caught. >:->

Good Luck! Rich

On Thu, 21 Aug 2008 23:21:24 +0000, Guy Macon wrote: ...

LOL! ;-P

Cheers! Rich

He did it in about a half hour, probably close to the time I spent on the firmware version.

Yup, it cut our channel update time by some goodly factor, 3:1 maybe.

John

So I take it he used a library module for the divide routine then? Writing "x = a / b" in VHDL or Verilog often isn't even synthesizable, and when it is, I'd be a little leery of the efficiency of the implementation. (Although I'm told that "x = a * b" usually generates efficient multipliers these days...)

Cool.

---Joel

time.

That's hardly a generalized solution (as in "general purpose computer").

DES isn't in the same class as most other problems. Pipelining becomes a problem. Sure, FPGAs are generally faster than sequential software but code development is a *lot* more expensive.

There are a *lot* more issues than that.

makes no sense,

main CPU.

but

).

the above mentioned

compiler / specification

Just tap your shoes together three times...

a spare

linear to speed.

you are used

If your world is one problem, then use fully custom hardware. It'll beat an FPGA all to hell. Cost is an important engineering parameter.

Besides, Bentley MicroStation is better, more flexible, easier to use, more reasonable licensing, and best of all, less expensive.

How very strange, i read it as the contraction. (It is).

Very late to this party, having been incommunicado in rural Alaska for a week--but the biggest problem with reconfigurable hardware is the inconceivably vast task-switching overhead. If you can dedicate reconfigurable cores to tasks, a la JL's model, this is reasonable at the margins, but it won't ever be a mainstream programming model.

Cheers,

Phil Hobbs

On a sunny day (Sat, 23 Aug 2008 12:53:53 -0400) it happened Phil Hobbs wrote in :

Won't matter, configuring the hardware will be as loading a program into memory, you configure it ONCE for each program. So, if I have some sequential code, with some part optimised in gates, then the OS would load the sequential code in memory, stuff the hardware config bit stream in the FPGA, and have the program do it's thing. With some tricks only part of the FPGA would be used. An other program, loaded at a different time, would use an other part of that FPGA. Until all hardware resources in that FPGA are used, then no more programs that use FPGA real estate can be loaded (OS task to verify that). So the time issue you talk about, is only related to starting up the program. the HDL would have been synthesised at the same time the code was compiled.

So, as to 'task switching', start thinking _parallel_, the gate configurations do not change during task-switching, each program has it's own gates (FPGA real estate) as each program has its own memory (neither do you swap out sequential code form memory during a task switch, then reload the code).

What is needed to accomplish this is very large FPGAs that can be partially reconfigured, and compilers that spit out HDL (or bit streams) for those FPGAs for time critical parts of the code, a loading mechanism, OS support to keep track of resources, and hardware interface standards, This is all possible, and in some other postings links have been given. The main problem I see is an IP one, companies often share patents though.., and compiler design, new version, or new type of gcc, now that would be cool.

It would be great fun to have, in addition to, say, 2048 CPU cores, a couple dozen tightly-coupled FPGAs on our chip; or maybe just one giant FPGA to be partitioned as needed. Then one could set up a chunk of FPGA logic to do some specific-brutally-parallel function. Configuration time shouldn't be any worse than program loading for a regular CPU core. Less, since useful FPGA configs run into megabits, not hundreds of megabytes like some code.

(I admit that FPGA *compiles* take thousands or millions of times longer than code compiles.)

Some of the Xilinx cores now do this sort of backwards, toss a few PPC cores into a big Virtex.

This is the crazy aunt in the attic: what the hell are we going to do with all those transistors? Surely "more of the same" isn't the answer.

Where in Alaska? I spent some time in Juneau which, while being the state capital, is still pretty rural by most standards.

John

You assume that you'll have only one task per program.

FPGA.

that).

Assuming that the FPGA architecture is stable enough. Good luck running last year's code--and you guys complain about Bill breaking things.

sequential

I've written big-iron clusterized electromagnetic simulators, and have been writing highly multithreaded programs since the first modern PC OS came out in 1992 (OS/2 2.0). Thinking parallel is not a new concept.

reconfigured,

critical parts

Of course it's possible, and it'll be done on the margins, but it'll never be a mainstream approach because the hardware details can't be virtualized away when you're rewiring the hardware.

Cheers,

Phil Hobbs

John

its time.

It is one possible soution for extremely compute bound problems though.

A more generally applicable one is the class of profile directed optimisers that try much harder to optimise the hot spots where the program spends more than 80% of its time (and so offer the best return on investment). Profiling feedback can make an important difference to how well a program can be optimised for a given archicture.

A quick intro to the basic idea in the context of Alpha emulation of x86 code with a post execution binary converter applied to hotspots.

Regards, Martin Brown

You really are a sucker for MS marketing speak when it supports your cause aren't you?

I prefer Donald Knuths take on the situation. He is much closer to the truth (maybe slightly too pessimistic). At least with the current development toolsets these multicore things will spend most of their time with cores shut down to save power since few PC users will ever excercise more than two cores to any significant extent.

Regards, Martin Brown

It's not my cause. That's the way the world is going. What I hope is that kilocores will make computing more reliable, not less.

Multicore will make hard embedded systems a lot more interesting, and often eliminate the need for an RTOS.

If people keep running legacy bash-and-thrash OSs, sure most of the cores will go unused. So let's stop doing that.

I do like this:

"Programming is at heart mathematics, even though most of it is the most inelegant, ugly and innumerate applied maths ever seen on the planet."

except that most programming has nothing to do with mathematics.

John

"Hard" as in difficult, or "hard" as in hard-coded/wired?

Thanks, Rich

Or "hard" as in rad-hard? ;-)

Thanks, Rich

Hard as in deep-embedded, intimately connected into real hardware, non-Windows, reliable, realtime. Did I mention not Windows?

Think about a CPU running just one servo loop. Another CPU doing just operator keypad/display stuff. Another scanning an ADC and calibrating/linearizing sensors. One more doing the TCP/IP. One master supervisor loading and checking it all. Few or no interrupts. No context switching.

John

On a sunny day (Tue, 26 Aug 2008 22:26:33 GMT) it happened Rich Grise wrote in :

'hard' as in hardly' :-)