1. Home
  2. Field-Programmable Gate Arrays
  3. SystemC comments

SystemC comments

I recently attended an FPGA vendor seminar that included some discussion of SystemC, HandelC and MentorGraphicsC. I tried real hard, honest I did, to shift my mental paradigms, and try to see the benefit of the use of C to abstract-away the clock aspects of vhdl rtl. I would say the systemC marketeers did a real poor job bringing the hardware people along to their way of thinking.

I suspect, however, that their arguements seem pretty common sense and obvious to software engineers, who know C and aren't familiar with what VHDL is all about (as well as hardware timing issues in general).

Even some of the software engineers in the audience explicitely stated that they thought that C/C++ was NOT a rapid development language, which is why they switched away from C to begin with, to Python, etc. to begin with.

Having sai all the above, let me now state the following:

I find writting that writing clk'ed "PROCESS"s in vhdl to be both easy to do as well as very reliable - that is, vhdl processes JUST work as long as you know what your doing and set realistic timing constraints. Thats no problem for me.

Most of my problems, however, are more "transactional" in nature - i.e. they have to do with communications between entities/processes across clock boundaries and/or interactions between data/signal producers/consumers driven by different external events. Not the timing within a process itself.

So, driven by the nature of most of the tricky problems I have to deal with, I am obviously open to some way of analyzing my system on a transactoinal level so as to gain insight to the various design architectural issues - i.e. analyzing the tradoffs of different possible solutions to the problem at hand.

However, being the engineer responsible for making the god damn thing work, I am obviously:

  1. primarily interested in timing. Thats what I do - design "timing".
  2. also interested in "implementation details" - though not necessarily vendor specific, I NEED to have the design process also participate in the implementation, otherwise its just taking project time away from the engineers and giving it to architects, without adding any value.
  3. Its got to facilitate debugging.

So if anyone has any introductory transactional analysis references, which aren;t SystemC vendor or approach specific, I'd appreciate it.

Thanks for listening to my rant!

Reply to
Mounard le Fougueux
Loading thread data ...

I agree. The synchronous process (always block) is where the hardware and software worlds can converge. This code can be viewed as an interrupt routine for the event of a rising clock edge: Hello. What state am I in? 42? OK. What are the inputs doing? OK, let's update the outputs like this. See you next time in state 43. Whatever the description language, this is what has to be covered.

The hardware guys may miss this by using TTL netlists because they don't trust synthesis. The software guys may miss this because there is no standard input or program completion and the syntax is a little different than C.

But you can put a lot in a process.

These problems can be addressed with design rules. Synchronize inputs. Register outputs. Minimize number of entities and processes. Communicate between procedures using process variables (blocking assignments). Process data and control together. Handshake external transactions (non-blocking assignments).

I do this with many functional simulations interspersed with a few trial synthesis/route/static timing.

I don't doubt that SystemC covers some of the same territory, but how can you beat cycle-accurate simulations backed by static timing analysis?

Start by reading these:

formatting link

Good stuff. Thanks for the posting.

-- Mike Treseler

Reply to
Mike Treseler

[snip]

Interesting. I was just wondering if SystemC et al are things that I should look into. Let me explain:

Coming from the world of software (from embedded C/asm to databases/PL/SQL + some old shool hardware experience) to the world of HDL I found it very refreshing and very appropriate the way the tools in this area have developed. In my case I seem set to become a happy verilog and ISE user.

I certainly don't want contrieved adaptions of non-HDLs and software development processes for my hardware design. In fact I'm so glad to find that verilog and the tools are just what they are. My first non-trivial HDL design is transactional in nature (packet switching) and the HDL is no hindrance. Quite the opposite - it makes things very clear.

As has been said, hardware IS NOT software, and if your daily diet is realtime/low-level programming the distinction should be easy to appreciate. If one is a software guy getting into hardware and wanting to think in huge abstractions, non-timed environment etc., one might need to play some with soldering irons and oscilloscopes first ;-)

Perhaps at some level of (co?) design complexity, these things (SystemC etc.) are really a necessity? On the other hand I've seen software be ruined by too much complexity and/or overhead in the languages, design and development processes, tools etc..

DJ

Reply to
Dr Justice

My obervation during further research, is that Verlilog has some limitations at the high end, where VHDL really shines, and conversely vhdl, unaided, has limitations at the low end (how to model a "jumper" in vhdl?).

It appears that systemC is intended to address some of the shortcomings of Verilog for verification (test benches)and larger systems that vhdl is great at.

So, it apppears that systemC is really geared for verilog users, who seem to think that the "C-Like" aspects of Verilog is a plus. I personnally think that VHDL has enough power to not need a lot of the systemC stuff, and its distinction between "variable" (space) and "signals" (time) is just, well, wonderfull.

However It would be nice to have some tools to guage the transactional level stuff, other just just old fashioned MS Power point, or Visio.

Reply to
Mounard le Fougueux

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.