Topics and Ideas for BS Project

Hi friends,

I am new to this forum and found that you guys are really helpful to
each other with strong knowledge on FPGAs. So I thought to get your
help. So I would really appreciate you guys if you can help me.

I am a undergraduate student in electronic and computer engineering
and going to start my BS final project in next fall semester.
I need your help to find an interesting, new project topic that have
some thing new or contribution, I like to share my final effort in the
web (in places like Opencores.org as OpenHW project/contribution)

My abilities and interest is :

I have fully familiar with Verilog HDL and it's advanced topics like
PLI and FSM Design, but have a little practical experience.

I have familiar with FPGA design flow an related Simulation and
Synthesis tool (Modelsim, VCS, ISE ) and there are FPGA board in my
university that I can use it.

I like to use SystemC in my project and extend my knowledge to system
level descriptions. So I think that SoC design would be good but I
don't know which topic in this area fit to my interest, so looking for
some interesting project ideas or contribution idea.


I have some knowledge about graphic processors (GPU) and wrote several
articles about new GPUs architecture like R600 (GPU on the ATI Radeon
HD 2900XT Graphic card).

Also I have some Knowledge about pipelined processor and Datapath-
Control Design.

My Verilog HDL Class project was describe/validate a programmer Timer
approximately like Intel 8254 and I am familiar with synchronous
design.


I am undergraduate student and I don't want to do big project that eat
all of my project time to design process and waste documentation and
verification process time. So for these reason I want to select a
smallish project something that I can implement in about 50% of my
available time and then spend the other 50% on trying to answer/
implement/study some of the above issues.

I am looking for experienced individuals of the FPGA development
community that would be willing to aid me as mentors or technical
advisors. my project is strictly academic and unfortunately the only
thing that I can offer for any assistance is my gratitude.

I would appreciate any suggestions, at the least they would give me a
direction to think in.
Thanks

Try contributing to this:-
http://wiki.duskglow.com/tiki-index.php?page=open-graphics
Plenty of opportunity for BS. ;-)
HTH, Syms. 

haghdoost,

Of interest might be to compare a c language flow, vs a HDL language 
flow, for a suite of designs.

In other words, if you had:

a video application,
a dsp signal processing application
a networking application

each codes in both c, and VHDL, with the c being converted to HDL by a tool.

How do these compare?  Why is (is not) one better than the other?  What 
elements of coding style do not work (well)?

You may be able to find existing examples of HDL code for all of the 
above.  All that is needed is the core element of the application, and 
it actually doesn't have to work (unlike a real product), but it has to 
be good enough for the compare.  Specifications need to exist so you can 
code the equivalent function in c.

This might be more of a Master's project, but it could also be a good 
senior year project.  Discuss it with your advisor.

The XUP (Xilinx University Program), has the tools, the boards, and 
might be able to provide you with what is required.  Have your advisor 
contact the XUP with the requirements.

Austin

Austin,

Thanks for suggestion; I have some question about it to fully
understand you idea

1. I have think that all of the C based design flow ends to an HDL
description in low level of design and C isn't a suitable language for
designing a hardware because it's naturally sequential and limited in
many cases like X or Z data representation. May be your intent is
systemC ?

2. If assume you suggest compare C with HDLs, are there any
contribution in this work? Did you know  someone or community working
on this topic?

I appreciate for your attention.


On Jun 5, 6:04 pm, austin <aus...@xilinx.com> wrote:
> haghdoost,
>
> Of interest might be to compare a c language flow, vs a HDL language
> flow, for a suite of designs.
>
> In other words, if you had:
>
> a video application,
> a dsp signal processing application
> a networking application
>
> each codes in both c, and VHDL, with the c being converted to HDL by a tool.
>
> How do these compare?  Why is (is not) one better than the other?  What
> elements of coding style do not work (well)?
>
> You may be able to find existing examples of HDL code for all of the
> above.  All that is needed is the core element of the application, and
> it actually doesn't have to work (unlike a real product), but it has to
> be good enough for the compare.  Specifications need to exist so you can
> code the equivalent function in c.
>
> This might be more of a Master's project, but it could also be a good
> senior year project.  Discuss it with your advisor.
>
> The XUP (Xilinx University Program), has the tools, the boards, and
> might be able to provide you with what is required.  Have your advisor
> contact the XUP with the requirements.
>
> Austin

ARH wrote:

> 1. I have think that all of the C based design flow ends to an HDL
> description in low level of design and C isn't a suitable language for
> designing a hardware because it's naturally sequential and limited in
> many cases like X or Z data representation.

It's quite possible to write sequential HDL code
that describes parallel hardware.
While it is common to see HDL used as a netlist,
synthesis tools can do much more
with a synchronous process/block if I want to.

The C-like HDL's cover the same ground
but punt most of the bit level port details
to vhdl or verilog.

I agree with Austin that a side by side
benchmark for several HDL's would be
a useful and interesting project.
The C-like languages claim that a
C programmer can more quickly port
algorithms to hardware with yet another HDL.
It would be of interest to know if this is true.

         -- Mike Treseler

Austin, that is one tough project :-)

"ARH" <haghdoost@gmail.com> wrote in message 
news:1181066596.543625.105400@m36g2000hse.googlegroups.com...
> Austin,
>
> Thanks for suggestion; I have some question about it to fully
> understand you idea
>
> 1. I have think that all of the C based design flow ends to an HDL
> description in low level of design

Not necessarily there are some tools that go straight to edif like Handle-C 
and some go via an intermediate HDL language like Catapult and ImpulseC.

> C isn't a suitable language for
> designing a hardware because it's naturally sequential

I would argue the opposite, people don't think parallel, they think 
sequentially and hence engineers tend to write many more line in a 
high-level sequential language than in a parallel one. Thinking of all the 
synchronisation issues between the concurrent blocks is a real pain. Some 
tools can reduce this pain for you (e.g. Catapult) but you still need to 
think like a hardware engineer when you use them (so I have been told, I 
have never used Catapult).

> and limited in
> many cases like X or Z data representation. May be your intent is
> systemC ?

Using SystemC for your project is a great suggestion since the simulator and 
IDE's are free (e.g. OSCI with Visual C++ on windows or KDeveloper/Anjuta on 
Linux) and you can really put your teeth into issue like delta cycles, 
concurrency and high-level programming all from one language, the only 
disadvantage IMHO is that you have to know C++. You can even use SystemC at 
a low hardware level, that is connecting blocks of logic between FF although 
some might argue this is abusing the language :-)

> 2. If assume you suggest compare C with HDLs, are there any
> contribution in this work? Did you know  someone or community working
> on this topic?

There are lots of papers and lots of tools that operate in the 
C/C++/SystemC/Handel-C domain but getting any sense where they are currently 
(or would be) most effective is a difficult job and most marketing 
departments would pay an arm and a leg for that answer :-)

Hans
www.ht-lab.com


>
> I appreciate for your attention.
>
>

Hans,

Thank you very much for your useful explanations.

I agree with you about systemC abilities and have to know C++ didn't
change my idea about this language because I learned C++ as the first
programming language.

Also I have no problem with learning any new language in my project
and I think this would be a good chance for me, for this reason I
mention SystemC and SoC design because I think these are new area in
Hardware Design that have shiny  future.


I have seen your website , www.ht-lab.com and I want to congratulate
you for your effort. I am one of the interest person in your CPU86
project. I involved to this project several days, last week and have
three question/offer about it :

1. Did you ever think to system level description ? there are several
IP-core from Ht-lab and Opencores.org that could be together in a
system level design.

2. what is the advantages of x86 CPU IP-core vs. other CPU IP that use
ordinary in SoCs (like embedded PowerPC cores)

3. in which places in this project you need contributor (especially in
Verilog version wrote by Antti Lucas because I prefer Verilog rather
VHDL)



ARH

ARH wrote:

> 1. I have think that all of the C based design flow ends to an HDL
> description in low level of design and C isn't a suitable language for
> designing a hardware because it's naturally sequential and limited in
> many cases like X or Z data representation. May be your intent is
> systemC ?

I agree.  To me the main advantage would be to use existing
C programs, but the usual hardware implementation of an algorithm
is very different from the software implementation.

I have been told that another reason is that it is too hard for
engineers to learn and understand both C and verilog.  This I also
don't believe, but maybe that is just me.

-- glen

Hans posted in news:Ybj9i.4930$sM1.2868@newsfe4-win.ntli.net :
     "[..]

     Using SystemC for your project is a great suggestion since [..]
     you can really put your teeth into issue like [..]
     concurrency [..]

     [..]"

In news:1181080157.909291.81940@p47g2000hsd.googlegroups.com
timestamped Tue, 05 Jun 2007 14:49:17 -0700, ARH <haghdoost@gmail.com>
posted:
     "Hans,
     
     Thank you very much for your useful explanations.
     
     I agree with you about systemC abilities [..]

     [..]"

Then perhaps you are in trouble because you have not noticed yet that
the SystemC(R) standard is actually explicitly written in a way which
does not use concurrency.

Good luck in your project whatever you choose to do.

Regards,
Colin Paul Gloster

Hi ARH,

On Jun 5, 10:49 pm, ARH <haghdo...@gmail.com> wrote:
> Hans,
>
> Thank you very much for your useful explanations.
>
> I agree with you about systemC abilities and have to know C++ didn't
> change my idea about this language because I learned C++ as the first
> programming language.
>
> Also I have no problem with learning any new language in my project
> and I think this would be a good chance for me, for this reason I
> mention SystemC and SoC design because I think these are new area in
> Hardware Design that have shiny  future.
>
> I have seen your website ,www.ht-lab.comand I want to congratulate
> you for your effort. I am one of the interest person in your CPU86
> project. I involved to this project several days, last week and have
> three question/offer about it :
>
> 1. Did you ever think to system level description ? there are several
> IP-core from Ht-lab and Opencores.org that could be together in a
> system level design.

Yes, I combined the core with 2 UARTs from opencores an 8254 timer, a
simple RTC and 2 cascading 8259 interrupt controllers from another
project (not free ip). The next step was to port some OS like ELKS/
FreeDOS/etc but I totally underestimated the amount of free time
required to do that port so the project was put into hibernation
mode :-)

>
> 2. what is the advantages of x86 CPU IP-core vs. other CPU IP that use
> ordinary in SoCs (like embedded PowerPC cores)

Very little, the only reason I would suggest the CPU86 is if you have
to run some 8086 legacy code, you want to build your own IBM PC/XT
from the ground up and/or you simple like the clean consistent
processor architecture :-). If you have to start from scratch than a
Nios/MicroBlaze/Mico8/Leon/etc softcore is a much better choice since
you not only get all the software development tools like gcc and gdb
but the vendors also provides you with a nice environment for adding
peripherals. This is one lessen I learned, writing a CPU in VHDL/
Verilog is straight forward but the software support is a different
story.

>
> 3. in which places in this project you need contributor (especially in
> Verilog version wrote by Antti Lucas because I prefer Verilog rather
> VHDL)

As I mentioned above, what is lacking is software support but
converting the processor to Verilog or finishing off Antti's one would
also be an interesting exercise. The other area which would be
interesting is taking the processor and building a proper verification
environment around it using SystemC, PSL and Mentor's AVM. But this
requires expensive tools like Questa....

If you need any help just send me an email,

Regards,
Hans
www.ht-lab.com


> ARH