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

 

[austin]

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]

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

 

[Mike Treseler]

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

 

[HT-Lab]

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.

 

[ARH]

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

 

[glen herrmannsfeldt]

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

 

[Colin Paul Gloster]

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

 

On Jun 6, 9:17 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

Hans posted innews:Ybj9i.4930$sM1.2868@newsfe4-win.ntli.net:

...snip..

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.

Why is he in trouble?

Are you hinting to the fact that thread synchronisation by events is
not ideal and can lead to deadlocks and race conditions if you are not
careful? I have no idea how big of a problem this is in concurrent
model development. However, lets be realistic, a lot of big companies
like ARM and ST use SystemC for their models, do you think they would
spend all this effort on a language that is flawed in terms of
concurrency support?

I am no expert (not even a novice) so perhaps one of the Doulos guys
can shed some light on this?

Hans.
www.ht-lab.com

Good luck in your project whatever you choose to do.

Regards,
Colin Paul Gloster

 

[ARH]

On Jun 6, 11:32 am, han...@ht-lab.com wrote:

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....

Hans,

Thank you for contribution suggestions.

I want to work on a project that have some thing new to develop and
document it in some internal or international conferences, when I see
CPU86 project an initiative idea take place in my mind to contribute
with you to develop various aspect of it specially in the system level
description.

But when you say that x86 soft IP core have no main advantage versus
other useful CPU IP-core , I think that there are no thing new in this
work and after all no one interest it.

What is your idea about it? Are there any rooms in HT-Lab projects
that have a valuable academic tent?

Of course I am a novice student in hardware engineering and I can't
judge about the academic value of project.

Best regards
--ARH

 

[Terje Mathisen]

glen herrmannsfeldt wrote:

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.

Huh?

It is a pretty bad engineer who can only think in one language.

Always try to use the right tool for the job!

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

 

[HT-Lab]

"ARH" <haghdoost@gmail.com> wrote in message
news:1181149333.018129.33940@q69g2000hsb.googlegroups.com...

On Jun 6, 11:32 am, han...@ht-lab.com wrote:
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....

Hans,

Thank you for contribution suggestions.

I want to work on a project that have some thing new to develop and
document it in some internal or international conferences, when I see
CPU86 project an initiative idea take place in my mind to contribute
with you to develop various aspect of it specially in the system level
description.

But when you say that x86 soft IP core have no main advantage versus
other useful CPU IP-core , I think that there are no thing new in this
work and after all no one interest it.

Hi Arh,

I should have been more precise, there is no commercial advantage. Anybody
who needs an embedded soft processor is better off with one of the many
fully supported commercial offerings. I played with the Nios-I core and was
quite impressed that I could get a simple application (Faile chess engine)
up and running with a minimum amount of hassle. This is important for
commercial applications but less fun for a hobbyist

What is your idea about it? Are there any rooms in HT-Lab projects
that have a valuable academic tent?

Instead of worrying about the academic novelty of your project I would
simply select a project that you are most interested in, this will motivate
you and hence increases your chance of getting a high mark. If you really
want an academic subject than pick an area
(imaging/processor/comms/dsp/space/embedded/formal/soc etc) and then google
to see what research is going on. Then contact the university/company to see
if you can contribute/collaborate.

You seem to be interested in SoC development so why not pick a number of
open/free cores and build yourself a full system. You will discover that
putting all the blocks together is easily done but verification becomes a
nightmare

Good luck with your project,

Regards,
Hans.

Of course I am a novice student in hardware engineering and I can't
judge about the academic value of project.

Best regards
--ARH

 

[Colin Paul Gloster]

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 [..]

[..]"


In news:1181134884.494511.240490@k79g2000hse.googlegroups.com
timestamped Wed, 06 Jun 2007 06:01:24 -0700, hans64@ht-lab.com posted:
"On Jun 6, 9:17 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

Hans posted innews:Ybj9i.4930$sM1.2868@newsfe4-win.ntli.net:

..snip..

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.

Why is he in trouble?

Are you hinting to the fact that thread synchronisation by events is
not ideal and can lead to deadlocks and race conditions if you are not
careful?"

No. Hans said something about the SystemC(R) library and concurrency;
after that, ARH agreed with Hans about SystemC(R) abilities; and after
that C.P.G. pointed out that concurrency is not part of the SystemC(R)
standard. It is very clearly written in Section 4.2.1 The scheduling
algorithm:
"[..]

4.2.1.2 Evaluation phase

[..]

Since process instances execute without interruption, only a single
process instance can be running at any
one time, and no other process instance can execute until the
currently executing process instance has
yielded control to the kernel. A process shall not pre-empt or
interrupt the execution of another process. This
is known as co-routine semantics or co-operative multitasking.

[..]"




In news:1181134884.494511.240490@k79g2000hse.googlegroups.com
timestamped Wed, 06 Jun 2007 06:01:24 -0700, hans64@ht-lab.com posted:
"[..] However, lets be realistic, a lot of big companies
like ARM and ST use SystemC for their models, do you think they would
spend all this effort on a language that is flawed in terms of
concurrency support?"

Yes. I could tell you about an unscalable slow SystemC(R) model none
of whose parts run concurrently for a major European Union research
project (whose name ironically enough is Scalable software Hardware
Architecture Platform for Embedded Systems) developed by one of the
two companies you explicitly mentioned. The time limit in the
nondisclosure agreement has not expired yet.

"I am no expert (not even a novice) so perhaps one of the Doulos guys
can shed some light on this?

[..]"

They tend to answer SystemC(R) questions very well on one of the
discussion forums on WWW.SystemC.org .

 

[Evan Lavelle]

On 7 Jun 2007 11:02:48 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

No. Hans said something about the SystemC(R) library and concurrency;
after that, ARH agreed with Hans about SystemC(R) abilities; and after
that C.P.G. pointed out that concurrency is not part of the SystemC(R)
standard. It is very clearly written in Section 4.2.1 The scheduling
algorithm:
"[..]

4.2.1.2 Evaluation phase

[..]

Since process instances execute without interruption, only a single
process instance can be running at any
one time, and no other process instance can execute until the
currently executing process instance has
yielded control to the kernel. A process shall not pre-empt or
interrupt the execution of another process. This
is known as co-routine semantics or co-operative multitasking.

I'm not quite sure what you're saying here, but SystemC would be
useless if it didn't support a user-level notion of concurrency. It
works like VHDL and Verilog - it has delta cycles, and 2-phase
evaluate/update semantics. This allows the simulation of simultaneous
accesses to multiple channels.

Or are you saying that you can't implement SystemC on concurrent
hardware/multi-threaded processors/whatever? This isn't the case. The
original (free) OSCI simulator used QuickThreads, which probably
explains the coroutine text in the LRM. But, if you look at 4.2.1 in
more detail, you'll see that you can implement your scheduler in any
way you want, as long as you preserve the simulation semantics. See
note 3 in 4.2.1.2:

"3 — An implementation running on a machine that provides hardware
support for concurrent processes may permit two
or more processes to run concurrently provided that the behavior
appears identical to the co-routine semantics defined in
this clause".

Besides, there's nothing wrong with non-preemptive coroutine
semantics. Why would you want to pre-empt an executing thread? Threads
have to execute until they reach suspend points, or delta cycles
wouldn't work. VHDL and Verilog work the same way - most of us have
managed to hang up a simulator with an infinite loop in a process.

"I am no expert (not even a novice) so perhaps one of the Doulos guys
can shed some light on this?

I guess they're working this week...

BTW, what is SystemC(R)? 'SystemC' is an OSCI trademark, in the same
way that 'Verilog' is a Cadence trademark.

Evan

 

[Colin Paul Gloster]

In news:lgfg635gsikhnj2ps84lv24fs0qpj84mt4@4ax.com timestamped Thu, 07
Jun 2007 18:55:05 +0100, Evan Lavelle <nospam@nospam.com> posted:
"On 7 Jun 2007 11:02:48 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:
[..]

standard. It is very clearly written in Section 4.2.1 The scheduling
algorithm:
"[..]

4.2.1.2 Evaluation phase

[..]

Since process instances execute without interruption, only a single
process instance can be running at any
one time, and no other process instance can execute until the
currently executing process instance has
yielded control to the kernel. [..]

I'm not quite sure what you're saying here, but SystemC would be
useless if it didn't support a user-level notion of
concurrency. [..]"

If one thread/process is running and all other threads/processes are
not running, then they are not running concurrently. They are not
running, actually.

"Or are you saying that you can't implement SystemC on concurrent
hardware/multi-threaded processors/whatever?"

I am not saying that. However, I am not aware of a SystemC(R)
implementation (aside from synthesizers of course) which actually
exploits concurrent hardware (e.g. a multiprocessor workstation). If
you check one of the forums on SystemC.org you can notice people who
were not pleased that their OSCI simulators would use just one
operating system process.


"[..] But, if you look at 4.2.1 in
more detail, you'll see that you can implement your scheduler in any
way you want, as long as you preserve the simulation semantics. See
note 3 in 4.2.1.2:

"3 An implementation running on a machine that provides hardware
support for concurrent processes may permit two
or more processes to run concurrently provided that the behavior
appears identical to the co-routine semantics defined in
this clause"."

I am aware of that. It is also not necessary to have that written in
the standard: e.g. if a particular function is always called with a
parameter of exactly the same value then it might be optimized to not
bother passing the parameter in so long as the optimized version does
what is required of it. The designer would not even notice.

Are you aware of a SystemC(R) simulation engine which actually does
run threads/processes concurrently? I am aware of one which does
not. I do not contend that concurrency can not be achieved by a
SystemC(R) simulation engine, but before such a simulator is made, it
will be imaginary. Do people really want to bother? The SystemC(R)
standard was being drafted for years. How many more years until
concurrent simulations?

"Besides, there's nothing wrong with non-preemptive coroutine
semantics."

True. Sequential programming can be useful.

"Why would you want to pre-empt an executing thread? [..]"

Perhaps I would, perhaps I would not. It depends on what I am tying to
do. Preemptive multitasking operating systems do exist. I spoke about
concurrency whereas both preempting something and non-preemptive
coroutine semantics involve sequential programming which is not concurrent.

"[..]

BTW, what is SystemC(R)? 'SystemC' is an OSCI trademark, in the same
way that 'Verilog' is a Cadence trademark."

Terms and/or conditions similar to what were imposed on me can be
found on
WWW.SystemC.org/account/register.php
, such as:
"[..]

EXHIBIT D



Trademark Usage Policy

[..]

II. PROPER USE OF MARKS



Trademarks and service marks function as adjectives and generally
should not be used as nouns [..]
[..]

III. PROPER ATTRIBUTION
Trademark ownership is attributed in two ways, with the use of a
symbol [..]

[..]"

ASCII does not have a registered trademark character, so "(R)" can
suffice instead.

Regards,
Colin Paul Gloster

 

[Evan Lavelle]

[it's very hard to follow your posts - you need to attribute your
quotations]

On 8 Jun 2007 10:59:32 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

If one thread/process is running and all other threads/processes are
not running, then they are not running concurrently. They are not
running, actually.

that's how (most) computers work. That's also exactly how the standard
Unix process model works, but no-one claims that it's not a
"concurrent" OS. Anyway, the issue of how threads and processes are
handled is not related to any user-level notion of concurrency
provided by an HDL; SystemC, VHDL, and Verilog all provide user-level
concurrency, whatever hardware or OS they run on.

"Or are you saying that you can't implement SystemC on concurrent
hardware/multi-threaded processors/whatever?"

I am not saying that. However, I am not aware of a SystemC(R)
implementation (aside from synthesizers of course) which actually
exploits concurrent hardware (e.g. a multiprocessor workstation).

I'm not either, but that doesn't mean that it hasn't been done, or is
not possible. Are you aware of any VHDL or Verilog implementations
which exploit 'concurrent hardware'? Yes, I'm sure there are trivial
examples of multi-threaded simulators, but are you aware of any
simulators which assign processes to threads? I'm not. You can't do
this unless you're absolutely sure that the processes don't interact
(take another look at the rest of note 4.2.1.2: that's what it's
trying to say). Besides, it would generally be pointless; any
realistic simulation runs a vast number of "simultaneous" "concurrent"
processes, and you need special-purpose hardware to make any sense of
that.

If I can just repeat what I said, or tried to say, im my last post,
the issue of underlying concurrency support is just not relevant. HDL
simulation semantics are defined in such a way that everything happens
*sequentially*, in such a way that *models*, or simulates,
"concurrency". This is true of any HDL that I know about. If you're
really smart, you can try to take advantage of 'parallel' hardware to
run multiple processes simultaneously, but it's difficult.

If
you check one of the forums on SystemC.org you can notice people who
were not pleased that their OSCI simulators would use just one
operating system process.

I've been following these forums for years, and I don't recall any
specific discussions on this.

BTW, what is SystemC(R)? 'SystemC' is an OSCI trademark, in the same
way that 'Verilog' is a Cadence trademark."

Terms and/or conditions similar to what were imposed on me can be
found on
WWW.SystemC.org/account/register.php
, such as:
[...snipped]
ASCII does not have a registered trademark character, so "(R)" can
suffice instead.

You would use (TM) in normal usage. But my point was that the word
"Verilog" is also trademarked. I'm sure that we could have a Verilog
discussion without continuously referring to "Verilog(R)" or
Verilog(TM)". Everybody else calls it "SystemC".

Evan

 

[Colin Paul Gloster]

In news:qgts635ef1r6kvl1vk0oqdmpmomseugodp@4ax.com timestamped Tue, 12
Jun 2007 12:00:51 +0100, Evan Lavelle <nospam@nospam.com> posted:
"[..]

On 8 Jun 2007 10:59:32 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

If one thread/process is running and all other threads/processes are
not running, then they are not running concurrently. They are not
running, actually.

that's how (most) computers work. That's also exactly how the standard
Unix process model works,"

Hi,

By invoking top with
top -i
(to more closely (though unfortunately still not perfectly) show only
active tasks)
and after invocation pressing 1 to remove the imaginary single CPU
load with loads for real CPUs, it is possible to check that tasks can
run literally concurrently (i.e. simultaneously
i.e. contemporaneously) as shown in some examples below...
Running NCSim with Verilog on a machine with four x86_64 cores (AMD Opterons)...
"top - 15:26:15 up 56 days, 20:29, 10 users, load average: 0.27, 0.14, 0.05
Tasks: 190 total, 3 running, 187 sleeping, 0 stopped, 0 zombie
Cpu0 : 52.2% us, 8.6% sy, 0.0% ni, 37.5% id, 0.7% wa, 0.0% hi, 1.0% si
Cpu1 : 93.4% us, 2.0% sy, 0.0% ni, 0.3% id, 4.3% wa, 0.0% hi, 0.0% si
Cpu2 : 72.1% us, 0.3% sy, 0.0% ni, 27.6% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 8108556k total, 4594596k used, 3513960k free, 143932k buffers
Swap: 0k total, 0k used, 0k free, 3576148k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3367 gloster 25 0 32128 16m 5440 R 99.5 0.2 0:06.16 ncsim
3300 petri 19 0 248m 159m 22m R 95.2 2.0 0:06.31 design_vision_e
31390 gloster 16 0 9620 1240 868 R 0.3 0.0 0:24.25 top"
Running NCSim with VHDL on a machine with four x86_64 cores (AMD Opterons)...
"top - 12:54:51 up 56 days, 17:57, 10 users, load average: 0.18, 0.08, 0.02
Tasks: 185 total, 2 running, 183 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.7% us, 0.0% sy, 0.0% ni, 98.3% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 88.4% us, 0.0% sy, 0.0% ni, 11.6% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 8108556k total, 4263752k used, 3844804k free, 143896k buffers
Swap: 0k total, 0k used, 0k free, 3408576k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31372 gloster 19 0 24916 10m 4700 R 88.3 0.1 0:02.71 ncsim
31390 gloster 16 0 9620 1212 864 R 0.7 0.0 0:00.10 top"
Running NCSim with VHDL on a machine with four Intel Xeon cores...
"top - 13:02:02 up 56 days, 17:31, 4 users, load average: 0.39, 0.14, 0.15
Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.7% us, 0.0% sy, 0.0% ni, 99.3% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 100.0% us, 0.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1034188k total, 650436k used, 383752k free, 18696k buffers
Swap: 2031608k total, 72320k used, 1959288k free, 328948k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24994 gloster 25 0 24924 10m 4700 R 99.9 1.0 0:13.74 ncsim
24681 gloster 16 0 2152 1148 884 R 0.3 0.1 0:02.25 top"


In news:qgts635ef1r6kvl1vk0oqdmpmomseugodp@4ax.com timestamped Tue, 12
Jun 2007 12:00:51 +0100, Evan Lavelle <nospam@nospam.com> posted:
"[..]; SystemC, VHDL, and Verilog all provide user-level
concurrency, whatever hardware or OS they run on.

[..]

[..] If I can just repeat what I said, or tried to say, im my last post,
the issue of underlying concurrency support is just not relevant. HDL
simulation semantics are defined in such a way that everything happens
*sequentially*, in such a way that *models*, or simulates,
"concurrency". This is true of any HDL that I know about."

Once again I point out to you that providing the user with only one
conceptually running task and forcing the user to manually switch the
simulation from one task to another -- which is exactly what is forced
upon the user by SystemC(R) cooperative multitasking -- is not
user-level concurrency (though an optimizer might be able to find a
way to replace the source code with concurrent parts). This is unlike
the user-level perception of VHDL with processes whose interleaving is
a job for the simulator. It is true that inside a VHDL process one can
have sequential code, but the relationship between one VHDL process
and another VHDL process can be one of concurrency at the user-level,
which is not a SystemC(R) possibility at the user-level because
nothing in the SystemC(R) standard involves user-level concurrency.

"[..]

However, I am not aware of a SystemC(R)
implementation (aside from synthesizers of course) which actually
exploits concurrent hardware (e.g. a multiprocessor workstation).

I'm not either, but that doesn't mean that it hasn't been done, or is
not possible."

I had already admitted this in news:f4bcqk$lon$1@newsserver.cilea.it .


" Are you aware of any VHDL or Verilog implementations
which exploit 'concurrent hardware'? Yes, I'm sure there are trivial
examples of multi-threaded simulators, but are you aware of any
simulators which assign processes to threads? I'm not."

No, I am not aware of any industrial simulators which do this. In the
Cadence NCSim examples above, not much of the available processing
power was exploited.


"[..] Besides, it would generally be pointless; any
realistic simulation runs a vast number of "simultaneous" "concurrent"
processes, and you need special-purpose hardware to make any sense of
that."

Quite a lot of people write software which runs on multiprocessor
computers with a task which runs on one processor at the same
time as other tasks of the same software's run on other processors,
with some of these tasks interacting.

"[..] If you're
really smart, you can try to take advantage of 'parallel' hardware to
run multiple processes simultaneously, but it's difficult."

True.

">If

you check one of the forums on SystemC.org you can notice people who
were not pleased that their OSCI simulators would use just one
operating system process.

I've been following these forums for years, and I don't recall any
specific discussions on this."

Some examples (N.B. to other people, a password is required for all of
these webpages)...
From
WWW.SystemC.org/forum/forum.php?thread_id=3757&forum_id=15
:"[..]

By: Larry Whitley
Subject: sc model thread <-> system thread[ Reply ]
Date: 2006-08-21

[..]

I'll set the console into raw mode and use getchar() to wait for and
receive characters typed at the console. If I do this in a systemc
thread (a pthread) the model appears to stop executing while
getchar() waits for the next key to be hit. Thus the need for an
external system thread.

[..]

By: Vincent Viteau
Subject: RE: sc model thread <-> system thread[ Reply ]
Date: 2006-08-22
Hi Larry, If I understood right, I would have done something
similar. This was not about a console but graphical display. So I had
my SystemC model and a part of it was a graphical monitor and
capture. These last 2 elements were X windows supposed to interact
with the user. First I just did everything from SystemC but my problem
was that SystemC engine only executes in pure sequence and suspends
non active threads. This was not good: 1. to refresh the X windows
when necessary, 2. to properly capture all the user actions.

To address this, I used pthread threads. [..]

[..]"

From
WWW.SystemC.org/forum/forum.php?thread_id=3959&forum_id=15
:"[..]

By: Paco Blasco
Subject: Running SystemC on multiprocessor computer[ Reply ]
Date: 2006-12-15
Hi all: I'm developing some SystemC complex simulation, and I've
noticed that SystemC only use one processor becouse it appears to be
a monothread application. Pthreads/Fibers or QuickThreads maintain
only on thread (or fiber ) active each time. Is it possible to use
the full performace of a quad processor computer? Are the "control"
data of the kernel of systemc thread-safe? I want to modify the
"crunch" method of sc_simcontext to provide a concurrent method and
thread execution.

[..]"


In news:qgts635ef1r6kvl1vk0oqdmpmomseugodp@4ax.com timestamped Tue, 12
Jun 2007 12:00:51 +0100, Evan Lavelle <nospam@nospam.com> posted:
"[..]

You would use (TM) in normal usage. But my point was that the word
"Verilog" is also trademarked. I'm sure that we could have a Verilog
discussion without continuously referring to "Verilog(R)" or
Verilog(TM)"."

Whether or not "Verilog" is trademarked is irrelevant. The OSCI
expressly forbade in a license to me particular ways of using
"SystemC". I have noticed that you have an account of SystemC.org. How
did you get this account without consenting to the terms I mentioned?

"Everybody else calls it "SystemC"."

Not everybody else has agreed to abide by the OSCI's rules. People who
do not have a SystemC.org account nor a copy of anything from the OSCI
are not obliged to comply with the OSCI's rules.

Regards,
Colin Paul Gloster

 

[Evan Lavelle]

I'm afraid that you are, and I'm trying to be polite here, completely
wrong. SystemC does not operate the way that you think it does, and
neither do VHDL nor Verilog. All three define simulation semantics in
what is fundamentally exactly the same way.

Some simple Googling might convince you. Look up any thread that
discusses an endless loop which hangs up a Verilog or VHDL simulator.
How is this even possible with your world view?

2 minutes on Google found a simple explanation of how event-driven
simulation works, from Janick Bergeron. This is exactly what I've said
several times in this thread, but you may find it more believable from
Janick; see
http://groups.google.co.uk/group/comp.lang.vhdl/browse_frm/thread/3941f0c5edac84fa/ae8567e741594acb?lnk=st&q=endless+loop+group%3Acomp.lang.vhdl&rnum=6&hl=en#ae8567e741594acb

I quote:

Because simulators must emulate things that occur in parallel on a
single thread machine, they must perform something similar to
timesharing on the workstation you probably use. Each process gets the
simulation engine (CPU) and runs until it explicitely suspends itself
via a wait statement. Because all processes are run in a sequential
fashion (since there is only 1 CPU), time must not advance between
evaluation. If signals are assigned in zero-time, time must not
advance for the next cycle either.

Because simulators are not timeshared and assume that every process
will cooperate and release the engine eventually, you might get stuck
if a process fails to execute a wait statement. It is to prevent this
common mistake and give an indication as to what is going wrong that
some simulators have a delta cycle limit that cause a *break* when
that limit is reached, not a time advance.

This really is pretty basic. Janick wrote this 12 years ago, so the
details of single-processor/single-thread have changed, but the basics
are exactly correct.

I'm happy to discuss this with you if you have a specific objection,
or can demonstrate that the SystemC kernel does not also behave in
this way (and it most emphatically *does*), but it really isn't
helpful to add lots of irrelevant extras when replying to posts.

Evan

 

[Colin Paul Gloster]

In news:98c073t4kmbr3mcc4rqfdvuf1rjtouljpd@4ax.com timestamped Wed, 13
Jun 2007 19:31:14 +0100, Evan Lavelle <nospam@nospam.com> posted:
"I'm afraid that you are, and I'm trying to be polite here,"

Thank you for being polite.

"completely
wrong. SystemC does not operate the way that you think it does,
[..]

[..]"

What did I say that is wrong?

"Some simple Googling might convince you. Look up any thread that
discusses an endless loop which hangs up a Verilog or VHDL simulator.
How is this even possible with your world view?

2 minutes on Google found a simple explanation of how event-driven
simulation works, from Janick Bergeron. This is exactly what I've said
several times in this thread, but you may find it more believable from
Janick; see
http://groups.google.co.uk/group/comp.lang.vhdl/browse_frm/thread/3941f0c5edac84fa/ae8567e741594acb?lnk=st&q=endless+loop+group%3Acomp.lang.vhdl&rnum=6&hl=en#ae8567e741594acb

[..]"

Did I deny event-driven simulation exists? It is possible for
event-driven simulation to be implemented concurrently and for
simulated time to not advance at all due to an infinite number of
delta cycles stuck in a feedback loop. Paul J. Menchini gave an
example of such a feedback loop in the same thread you cited.

"[..]

I'm happy to discuss this with you if you have a specific
objection,"

Thank you.

"or can demonstrate that the SystemC kernel does not also behave in
this way (and it most emphatically *does*),"

I never said that it does not also have delta cycles.

" but it really isn't
helpful to add lots of irrelevant extras when replying to posts."

Sorry, I did not intend to add irrelevant extras. I am not sure which
ones I did, but here may be a few examples which I did not think were
irrelevant but if you want you can save time by ignoring the rest of
this post: I was asked "what is SystemC(R)?" so I explained that I am
supposed to use a registered trademark symbol and that I am supposed
to refrain from using "SystemC" as a noun; it was claimed that Unix
runs one process at a time without an admission that Unix can run more
than one process at a time and I was asked am I "aware of any VHDL or
Verilog implementations which exploit 'concurrent hardware'?" so I
showed evidence that a Unix clone can run more than one process and
that unfortunately NCSim does not exploit this; and you did not recall
"any specific discussions" from one of the SystemC.org forums about
how using a multiprocessor computer with an OSCI reference implementation
does not scale whatsoever so I showed two examples of such discussions.

Regards,
Colin Paul Gloster