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

Reply to
haghdoost
Loading thread data ...

Try contributing to this:-

formatting link
Plenty of opportunity for BS. ;-) HTH, Syms.

Reply to
Symon

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

Reply to
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 ?

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

Reply to
ARH

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

Reply to
Mike Treseler

Austin, that is one tough project :-)

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.

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

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 :-)

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

formatting link

Reply to
HT-Lab

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 ,

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

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

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

ARH

Reply to
ARH

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

Reply to
glen herrmannsfeldt

Hans posted in news:Ybj9i.4930$ snipped-for-privacy@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: snipped-for-privacy@p47g2000hsd.googlegroups.com timestamped Tue, 05 Jun 2007 14:49:17 -0700, ARH 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

Reply to
Colin Paul Gloster

..snip..

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.

formatting link

Reply to
hans64

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

--
- 
"almost all programming can be viewed as an exercise in caching"
Reply to
Terje Mathisen

Hans posted in news:Ybj9i.4930$ snipped-for-privacy@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: snipped-for-privacy@p47g2000hsd.googlegroups.com timestamped Tue, 05 Jun 2007 14:49:17 -0700, ARH posted: "Hans, Thank you very much for your useful explanations. I agree with you about systemC abilities [..]

[..]"

In news: snipped-for-privacy@k79g2000hse.googlegroups.com timestamped Wed, 06 Jun 2007 06:01:24 -0700, snipped-for-privacy@ht-lab.com posted: "On Jun 6, 9:17 am, Colin Paul Gloster wrote: > Hans posted innews:Ybj9i.4930$ snipped-for-privacy@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: snipped-for-privacy@k79g2000hse.googlegroups.com timestamped Wed, 06 Jun 2007 06:01:24 -0700, snipped-for-privacy@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

formatting link
.

Reply to
Colin Paul Gloster

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

Reply to
Evan Lavelle

In news: snipped-for-privacy@4ax.com timestamped Thu, 07 Jun 2007 18:55:05 +0100, Evan Lavelle posted: "On 7 Jun 2007 11:02:48 GMT, Colin Paul Gloster wrote: [..] >standard. It is very clearly written in Section 4.2.1 The scheduling >algorithm: >"[..] >

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

formatting link
, 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

Reply to
Colin Paul Gloster

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.

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.

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

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

Reply to
Evan Lavelle

In news: snipped-for-privacy@4ax.com timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle posted: "[..] On 8 Jun 2007 10:59:32 GMT, Colin Paul Gloster 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: snipped-for-privacy@4ax.com timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle 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$ snipped-for-privacy@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

formatting link
:"[..]

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

formatting link
:"[..]

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: snipped-for-privacy@4ax.com timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle 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

Reply to
Colin Paul Gloster

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
formatting link

I quote:

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

Reply to
Evan Lavelle

In news: snipped-for-privacy@4ax.com timestamped Wed, 13 Jun 2007 19:31:14 +0100, Evan Lavelle 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

formatting link
[..]"

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

Reply to
Colin Paul Gloster

As I said, I may not believe it, but in any case the thought process for C programming and verilog programming are different.

Switching between, say, Fortran, C, and PL/I the thought process will be similar, though the details are different.

I agree.

-- glen

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.