Prev: systemc
Next: sqrt(a^2 + b^2) in synthesizable VHDL?
From: bart on 9 May 2006 13:57
> Yeh, I have been following Lattice more closely recently, will take me
> some time to evaluate their specs more fully, may get more interested
> if they have a free use tool chain I can redo my work with.

> Does anyone have PCIe on chip though?

> John Jakson
>transputer guy

For PCIe x4, I think LatticeSC has the PHY and data link layers in the
structured ASIC (MACO) portion of the chip. For the transaction layer,
you'd need IP. See:
http://www.latticesemi.com/corporate/webcasts/preengineeredpciexpressso/index.cfm

Hope this helps.
Bart Borosky, Lattice

From: Phil Tomson on 9 May 2006 23:44
In article <1147153450.028603.66700(a)u72g2000cwu.googlegroups.com>,
JJ <johnjakson(a)gmail.com> wrote:
>
>Phil Tomson wrote:
>> In article <1146981253.226901.102660(a)i39g2000cwa.googlegroups.com>,
>> JJ <johnjakson(a)gmail.com> wrote:
>> >I always hated that the PCI cores were so heavily priced compared to
>> >the FPGA they might go into. The pricing seemed to reflect the value
>> >they once added to ASICs some 10 or 15 years ago and not the potential
>> >of really low cost low volume applications. A $100 FPGA in small vol
>> >applications doesn't support $20K IP for a few $ worth of fabric it
>> >uses. It might be a bargain compared to the cost of rolling your own
>> >though, just as buying an FPGA is a real bargain compared to rolling my
>> >own FPGA/ASIC too.
>>
>> That's why OpenCores is so important. (http://opencores.org) As FPGAs
>> become cheaper we're going to need an open source ecosystem of cores.
>> They've got a PCI bridge design at Open cores, for example.
>>
>> BTW: it would also be nice to have an open source ecosystem of FPGA
>> design tools... but that's a bit tougher at this point.
>>
>> Phil
>
>Yes but open source and closed source are also like oil and water esp
>together in a commercial environment. If I were doing commercial work I
>doubt I'd ever use opencores but I might peek at it for an
>understanding of how it might be done or ask someone else to. On a
>hobbyist level,

What's the hesitation?

> well I have mixed feelings about gpl too.

There are many more open source licenses besides gpl, though gpl is pretty
commonly used.

> I suspect the
>software world does far better with it since enough people support the
>gpl movement and there is a large user base for it. Hardware ultimately
>can't be made for free so it can't be the same model.
>

Hardware itself cannot be made for free, however various cores (such as a
PCI bridge that sparked this) can be created for free as it's pretty much
the same process as software development: code it up in synthesizable HDL,
simulate it to make sure it does what you want, synthesize it and try it
out in an FPGA. Computers aren't free either, but there is plenty of open
source software being created to run on them.

Phil
From: Phil Tomson on 9 May 2006 23:57
In article <1147155282.274065.16140(a)i40g2000cwc.googlegroups.com>,
JJ <johnjakson(a)gmail.com> wrote:
>
>Phil Tomson wrote:
>> In article <1146975146.177800.163180(a)g10g2000cwb.googlegroups.com>,
>> JJ <johnjakson(a)gmail.com> wrote:
>> >
>
>snipping
>
>> >
>> >FPGAs and standard cpus are bit like oil & water, don't mix very well,
>> >very parallel or very sequential.
>>
>> Actually, that's what could make it the perfect marriage.
>>
>> General purpose CPUs for the things they're good at like data IO,
>> displaying information, etc. FPGAs for applications where parallelism is
>> key.
>>
>
>On c.a another Transputer fellow suggested the term "impedance
>mismatch" to describe the idea of mixing low speed extreme parallel
>logic with high speed sequencial cpus in regard to the Cray systems
>that have a bunch of Virtex Pro parts with Opterons on the same board,
>a rich mans version of DRC (but long before DRC). I suggest tweening
>them, puts lots of softcore Transputer like nodes into FPGA and
>customize them locally, you can put software & hardware much closer to
>each other. One can even model the whole thing in a common language
>designed to run as code or be synthesized as hardware with suitable
>partitioning, starting perhaps with occam or Verilog+C. Write as
>parallel and sequential code and later move parts around to hardware or
>software as needs change.
>
>> I think the big problem right now is conceptual: we've been living in a
>> serial, Von Neumann world for so long we don't know how to make effective
>> use of parallelism in writng code - we have a hard time picturing it.
>
>I think the software guys have a huge problem with parallel, but not
>the old schematic guys. I have more problems with serial, much of it
>unnecessary but forced on us by lack of language features that forces
>me to order statements that the OoO cpu will then try to unorder. Why
>not let the language state "no order" or just plain "par" with no
>communication between.
>
>> Read some software engineering blogs:
>> with the advent of things like multi-core processors, the Cell, etc. (and
>> most of them are blissfully unaware of the existence of FPGAs) they're
>> starting to wonder about how they are going to be able to model their
>> problems to take advantage of that kind of paralellism. They're looking
>
>The problem with the Cell and other multicore cpus, is that the cpu is
>all messed up to start with, AFAIK the Transputer is the only credible
>architecture that considers how to describe parallel processes and run
>them based on formal techniques. These serial multi cpus have the
>Memory Wall problem as well as no real support for concurrency except
>at a very crude level, it needs to be closer to 100 instruction cycles
>context switches to work well, not 1M. The Memory Wall only makes
>threading much worse than it already was and adds more pressure to the
>cache design as more thread contexts try to share it.

I wasn't singing the virtues of any particular parallel architecture (like
the Cell) - I brought it up to say that these architectures are now
becoming known in the software engineering world and there are a lot of
folks in that camp wondering how we're going to effectively develop
software for them.


>
>> for new abstractions (remember, software engineering [and even hardware
>> engineering these days] is all about creating and managing abstractions).
>> They're looking for and creating new languages (Erlang is often mentioned
>> in these sorts of conversations). Funny thing is that it's the hardware
>> engineers who hold part of the key: HDLs are very good at modelling
>> parallelism and dataflow. Of course HDLs as they are now would be pretty
>> crappy for building software, but it's pretty easy to see that some of the
>> ideas inherant in HDLs could be usefully borrowed by software engineers.
>>
>>
>
>Yeh, try taking your parallel expertise knowledge to the parallel
>software world, they seem to scorn the idea that hardware guys might
>actually know more than they do about concurrency while they happily
>reinvent parallel languages that have some features we have had for
>decades but still clinging to semaphores and spinlocks.

You have to masquerade as a software guy ;-)

> I came across
>one such parallel language from U T Austin that even had always,
>initial and assign constructs but no mention of Verilog or hardware
>HDLs.
>
>But there are more serious researchers in Europe who are quite
>comfortable with concurrency as parallel processes like hardware, from
>the Transputer days based on CSP, see wotug.org. The Transputers
>native language occam based on CSP later got used to do FPGA design
>then modified into HandelC so clearly some people are happy to be in
>the middle.
>
>I have proposed taking a C++ subset and adding live signal ports to a
>class definition as well as always, assign etc, starts to look alot
>like Verilog subset but using C syntax but builds processes as
>communicating objects (or modules instances) which are nestable of
>course just like hardware. The runtime for it would look just like a
>simulator with an event driven time wheel or scheduler. Of course in a
>modern Transputer the even wheel or process scheduler is in the
>hardware so it runs such a language quite naturally, well thats the
>plan. Looking like Verilog means RTL type code could be "cleaned" and
>synthesized with off the shelf tools rather than having to build that
>as well and the language could be open. SystemVerilog is going in the
>opposite direction.
>
snip
>
>The real money I think is in the problem space where the data rates are
>enormous with modest processing between data points such as
>bioinformatics. If you have lots of operations on little data, you can
>do better with distributed computing and clusters.

Yes, bioinformatics can be a good application space for FPGAs (depending
on what you're doing)

snip

>
>Transputers & FPGAs two sides of the same process coin
>

Are there any transputers still being made?

Phil
From: fpga_toys on 10 May 2006 05:02

JJ wrote:
> I think the software guys have a huge problem with parallel, but not
> the old schematic guys. I have more problems with serial, much of it
> unnecessary but forced on us by lack of language features that forces
> me to order statements that the OoO cpu will then try to unorder. Why
> not let the language state "no order" or just plain "par" with no
> communication between.

Parrallel programming as both an undergraduate and graduate class has
been available for a while on most computer science and computer
engineering campuses, and is a core consideration in many undergraduate
and graduate computer architecture classes as well.

While some older software guys that haven't kept current in their trade
may be unaware, I suspect there are as many older hardware guys that
have difficultly with VHDL, Verilog, SystemC, and current modeling and
simulation techniques too.

Parallel hardware comes in many different flavors, and there are many
different solutions to specific and sets of those implementations,
frequently specific to industries, application areas, and home schools
of research.

The complaints here are less than conclusive and complete, as they pick
and choose some of the worst .... anyone can trash many hardware
designs in a similar fashion as lacking complete knowledge of how to
implement a system that software can actually run on well without a
bunch of hacks.

Good designs happen when each of hardware, systems software,
applications software, and good architects get togather and fit the
system design to the problem, rather than leaving hardware guys to go
off and have some confused idea that software guys have to patch up
later.

From: JJ on 10 May 2006 14:14

fpga_toys(a)yahoo.com wrote:
> JJ wrote:
> > I think the software guys have a huge problem with parallel, but not
> > the old schematic guys. I have more problems with serial, much of it
> > unnecessary but forced on us by lack of language features that forces
> > me to order statements that the OoO cpu will then try to unorder. Why
> > not let the language state "no order" or just plain "par" with no
> > communication between.
>
> Parrallel programming as both an undergraduate and graduate class has
> been available for a while on most computer science and computer
> engineering campuses, and is a core consideration in many undergraduate
> and graduate computer architecture classes as well.
>
> While some older software guys that haven't kept current in their trade
> may be unaware, I suspect there are as many older hardware guys that
> have difficultly with VHDL, Verilog, SystemC, and current modeling and
> simulation techniques too.
>
> Parallel hardware comes in many different flavors, and there are many
> different solutions to specific and sets of those implementations,
> frequently specific to industries, application areas, and home schools
> of research.
>
> The complaints here are less than conclusive and complete, as they pick
> and choose some of the worst .... anyone can trash many hardware
> designs in a similar fashion as lacking complete knowledge of how to
> implement a system that software can actually run on well without a
> bunch of hacks.
>
> Good designs happen when each of hardware, systems software,
> applications software, and good architects get togather and fit the
> system design to the problem, rather than leaving hardware guys to go
> off and have some confused idea that software guys have to patch up
> later.

Ofcourse the two should be done together with as much crossover
knowledge as possible. Finishing hardware design before software starts
is asking for trouble, seen that done too many times although it brings
up the chicken & egg question.

John Jakson

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: systemc
Next: sqrt(a^2 + b^2) in synthesizable VHDL?