Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
See Also
Discussion Groups | FPGA-CPU | Porting Adam Dunkel's uIP to FPGA CPUs
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Re: Porting Adam Dunkel's uIP to FPGA CPUs - Tommy Thorn - Apr 5 1:10:23 2009
Hi John,
you seem to touch on many different subjects here, soft-core ports of uIP, =
dev kits and their suboptimal memory options, and video processing using st=
andard SDRAM.
1) I haven't ported any of the uIP solutions available, but I can't imagine=
it to be very hard, especially as this is wildly used and thus probably no=
t overly buggy. It is on my TODO list for YARI, but I haven't gotten there.
2) Sadly, even though memory is relatively inexpensive (compared to an FPGA=
), few to none of the dev kits have a good set up there. There are a few ca=
rds that will take a standard DIMM or SO-DIMM, but alas it's not the norm.
3) All high end GPUs work just fine with standard (ok, bleeding edge) SDRAM=
, so it clearly is possible. Typically the tricks used are:
- batch processing whenever possible,
- caching when batch processing, and
- swizzling the memory layout so that 2D locality translates to mostly good=
1D locality (think Hilbert curves etc).
Obviously this add complexity to the video processing, but that's the probl=
em everyone has to deal with.
Cheers
Tommy
--- On Sat, 4/4/09, John Kent
> From: John Kent
> Subject: [fpga-cpu] Porting Adam Dunkel's uIP to FPGA CPUs
> To: f...@yahoogroups.com
> Date: Saturday, April 4, 2009, 8:33 PM
> Has anyone ported Adam Dunkel's uIP
> TCP/IP stack to an FPGA processor ?
>=20
> http://www.sics.se/~adam/uip/index.php/Main_Page
>=20
> I have some demo code that is supposed to implement Adam's
> TCP/IP stack=20
> in the cache memory of a PPC405 configured as an
> Ultra-Controller II on=20
> a Virtex 4 board but it does not work. I was wanting to use
> the Virtex 4=20
> board as an OFDM encoder/decoder for digital TV and use the
> ethernet=20
> interface to pipe MPEG encoded video to and from the board.
> For MPEG=20
> encoding I would need at least a XC3S1000 and even that
> might be a bit=20
> small. If I used a Spartan 3 board I'd need a softcore CPU,
> although I=20
> suppose the best solution would be to use EDK and the
> Microblaze. I=20
> don't really have the time at the moment to spend working
> on it I suppose.
>=20
> The problem with most low cost evaluation boards is that
> they only have=20
> the one big SDRAM chip which is normally dedicated to the
> CPU, so using=20
> them as frame stores for video processing is problematic.
> Frame stores=20
> are needed for warping or transposition, or when you want
> to perform non=20
> raster based operations. SDRAM is a real pain because it
> only really=20
> achieves it's full bandwidth in burst mode which assumes
> linear=20
> sequential addressing.
>=20
> I'd also like to use the ethernet interface on a pair of
> Spartan 3E-500=20
> boards for some computer vision experiments although they
> might be too=20
> small for what I want to do and the S3E-500 board suffers
> from a lack of=20
> separate SRAM for frame stores. The new Spartan 3 DSP board
> does have=20
> one ZBT RAM that can be used as a frame store but there is
> only one of=20
> them and it's limited to 1MByte.
>=20
> The PPC405 has an APU interface, but do any softcore CPUs
> have a=20
> provision for integrating things like video processing into
> them. There=20
> is DMA I suppose, but can you use the ALU and address
> generator of a CPU=20
> to perform video operations ?
>=20
> John.
>=20
> --=20
> http://www.johnkent.com.au
> http://members.optushome.com.au/jekent
>=20
>=20
>=20
> ------------------------------------
>=20
> To post a message, send it to: f...@yahoogroups.com
> To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@yahoogroups=
.comYahoo!
> Groups Links
>=20
>=20
> =A0 =A0 mailto:f...@yahoogroups.com
>=20
>=20
>=20
=20=20=20=20=20=20
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@yahoogroups.c=
om
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Porting Adam Dunkel's uIP to FPGA CPUs - John Kent - Apr 5 2:28:29 2009
Hi Tommy,
Tommy Thorn wrote:
> Hi John,
>
> you seem to touch on many different subjects here, soft-core ports of uIP, dev kits and their suboptimal memory options, and video processing using standard SDRAM.
>
>
Yes ... the email was a bit stream of conscienceness, but it was useful
in a way as it has given me a few ideas to work on.
> 1) I haven't ported any of the uIP solutions available, but I can't imagine it to be very hard, especially as this is wildly used and thus probably not overly buggy. It is on my TODO list for YARI, but I haven't gotten there.
>
>
I found your paper "Embedded JIT Compilation with CACAO on YARI". I was
wondering what YARI was, but I see it's a RISC CPU for running JAVA. I'm
sorry I must not have been paying close enough attention to the list in
the past. I do remember seeing YARI referred too.
> 2) Sadly, even though memory is relatively inexpensive (compared to an FPGA), few to none of the dev kits have a good set up there. There are a few cards that will take a standard DIMM or SO-DIMM, but alas it's not the norm.
>
> 3) All high end GPUs work just fine with standard (ok, bleeding edge) SDRAM, so it clearly is possible. Typically the tricks used are:
> - batch processing whenever possible,
> - caching when batch processing, and
> - swizzling the memory layout so that 2D locality translates to mostly good 1D locality (think Hilbert curves etc).
>
> Obviously this add complexity to the video processing, but that's the problem everyone has to deal with.
>
> Cheers
> Tommy
>
I guess Multi Media eXtensions have been around since the Pentium I, but
I never really looked into them to see what they were.
Graphics is about making dense information sparse. Computer vision is
about making sparse data dense. So I guess it's a matter of reversing
the process, although graphics can utilize symmetry where as the real
world is not so accommodating.
Thanks for your reply .... It's got my gray matter working.
The direction of data flow on graphics is out of the CPU, where as with
computer vision it is into the CPU.
John.
--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Tommy Thorn wrote:
> Hi John,
>
> you seem to touch on many different subjects here, soft-core ports of uIP, dev kits and their suboptimal memory options, and video processing using standard SDRAM.
>
>
Yes ... the email was a bit stream of conscienceness, but it was useful
in a way as it has given me a few ideas to work on.
> 1) I haven't ported any of the uIP solutions available, but I can't imagine it to be very hard, especially as this is wildly used and thus probably not overly buggy. It is on my TODO list for YARI, but I haven't gotten there.
>
>
I found your paper "Embedded JIT Compilation with CACAO on YARI". I was
wondering what YARI was, but I see it's a RISC CPU for running JAVA. I'm
sorry I must not have been paying close enough attention to the list in
the past. I do remember seeing YARI referred too.
> 2) Sadly, even though memory is relatively inexpensive (compared to an FPGA), few to none of the dev kits have a good set up there. There are a few cards that will take a standard DIMM or SO-DIMM, but alas it's not the norm.
>
> 3) All high end GPUs work just fine with standard (ok, bleeding edge) SDRAM, so it clearly is possible. Typically the tricks used are:
> - batch processing whenever possible,
> - caching when batch processing, and
> - swizzling the memory layout so that 2D locality translates to mostly good 1D locality (think Hilbert curves etc).
>
> Obviously this add complexity to the video processing, but that's the problem everyone has to deal with.
>
> Cheers
> Tommy
>
I guess Multi Media eXtensions have been around since the Pentium I, but
I never really looked into them to see what they were.
Graphics is about making dense information sparse. Computer vision is
about making sparse data dense. So I guess it's a matter of reversing
the process, although graphics can utilize symmetry where as the real
world is not so accommodating.
Thanks for your reply .... It's got my gray matter working.
The direction of data flow on graphics is out of the CPU, where as with
computer vision it is into the CPU.
John.
--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Porting Adam Dunkel's uIP to FPGA CPUs - Tommy Thorn - Apr 8 1:48:20 2009
> I found your paper "Embedded JIT Compilation with CACAO on
> YARI". I was
> wondering what YARI was, but I see it's a RISC CPU for
> running JAVA.
No, that is not accurate . YARI is a MIPS compatible soft-core.
It just happens to be used for a port of CACAO in the paper. It also
happens to be fast.
I see elsewhere you ask about caches. YARI has been designed around
caches for the beginning. It uses 4-way associative instruction and
data cache (presently write through and with random placement).
Lines are 16-bytes long and are burst filled. Memory uses a dedicated
burst oriented "bus" and IO uses a slower bus.
Other information on http://thorn.ws/yari
The only "porting" YARI would require for uIP is to support the ethernet
device on the dev kit. Being MIPS compatible makes the toolchain very
complete and mature.
Tommy
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Porting Adam Dunkel's uIP to FPGA CPUs - John Kent - Apr 8 2:39:21 2009
Hi Tommy,
Tommy Thorn wrote:
>> I found your paper "Embedded JIT Compilation with CACAO on
>> YARI". I was
>> wondering what YARI was, but I see it's a RISC CPU for
>> running JAVA.
>>
>
> No, that is not accurate . YARI is a MIPS compatible soft-core.
> It just happens to be used for a port of CACAO in the paper. It also
> happens to be fast.
>
>
Ahh I see.
> I see elsewhere you ask about caches. YARI has been designed around
> caches for the beginning. It uses 4-way associative instruction and
> data cache (presently write through and with random placement).
> Lines are 16-bytes long and are burst filled. Memory uses a dedicated
> burst oriented "bus" and IO uses a slower bus.
>
>
OK ... Yes I did see the data and instruction Cache ($) in the block
diagram in the paper.
> Other information on http://thorn.ws/yari
>
>
I'll check it out tomorrow. I'm in a bit of a hurry at the moment.
> The only "porting" YARI would require for uIP is to support the ethernet
> device on the dev kit. Being MIPS compatible makes the toolchain very
> complete and mature.
>
> Tommy
>
OK. I've seen a few MIPs based designs, but I have not looked into them
in any detail.
Write to you soon
John.
--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Tommy Thorn wrote:
>> I found your paper "Embedded JIT Compilation with CACAO on
>> YARI". I was
>> wondering what YARI was, but I see it's a RISC CPU for
>> running JAVA.
>>
>
> No, that is not accurate . YARI is a MIPS compatible soft-core.
> It just happens to be used for a port of CACAO in the paper. It also
> happens to be fast.
>
>
Ahh I see.
> I see elsewhere you ask about caches. YARI has been designed around
> caches for the beginning. It uses 4-way associative instruction and
> data cache (presently write through and with random placement).
> Lines are 16-bytes long and are burst filled. Memory uses a dedicated
> burst oriented "bus" and IO uses a slower bus.
>
>
OK ... Yes I did see the data and instruction Cache ($) in the block
diagram in the paper.
> Other information on http://thorn.ws/yari
>
>
I'll check it out tomorrow. I'm in a bit of a hurry at the moment.
> The only "porting" YARI would require for uIP is to support the ethernet
> device on the dev kit. Being MIPS compatible makes the toolchain very
> complete and mature.
>
> Tommy
>
OK. I've seen a few MIPs based designs, but I have not looked into them
in any detail.
Write to you soon
John.
--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )