Handel-C
Compilit
Wil it be replaced by C/C++ platform ?
It looks like Handel C is taking oof.
What I am wondering is will DK-1 suite be able to convert the test benches
into a supported
language as well ? For ASIC conversion, that is..
http://www.infoconomy.com/pages/search/group18585.adp
http://isdmag.com/story/OEG20010301S0056
http://www.celoxica.com/news/in_the_news.htm
Compilit
"Compilit" <comp...@yahoo.com> wrote in message
news:9aoga1$qt8$1...@taliesin.netcom.net.uk...
S. Ramirez
problem is that HDL is only a part of FPGA design. Just ask anyone in this
newsgroup about all of the problems involved with FPGA design. The majority
of them are not HDL problems. Therefore, one cannot take a programmer
(read: non hardware engineer), teach him/her Handel-C and expect him/her to
simply start cranking out FPGA designs. That person will have to know about
timing problems, metastability, floorplanning and a bunch of other skills
that are commonly required to complete an FPGA design. Essentially, that
person has to be a hardware person.
The first link given below is to an article about Celoxica. It's
obvious that this article was written by a semi-technical person, since
(s)he refers to VHDL as "Verilog HDL." The article to me reads simply as
marketing hype for this new language and tools. I am not saying that they
will not take off, but I doubt that they will unless they can get a
significant amount of us to go that way. I wish the company well, and I am
always looking for new, better and cheaper tools, but my present design flow
and methodology is sufficing quite well.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
"Compilit" <comp...@yahoo.com> wrote in message
news:9aoga1$qt8$1...@taliesin.netcom.net.uk...
niki
chip design using digital and analog logic. HDL was devised to describe a
hardware system effectively. HDL itself is not concerned about timing,
metastability and floorplaning of FPGA/ASIC/Full Custom/Semi-Custom design.
Thesedays it seems that folks think writing HDL as writing software codes
thanks to synthesis tools. However, HDL is not a piece of software code
like C/C++ but a truly dedicated language describing hardware.
Chung, MA
S. Ramirez <sram...@cfl.rr.com>이(가)
<K0Qz6.55451$Lz6.8...@typhoon.tampabay.rr.com> 기사에서 작성했습니다...
Rick Filipkiewicz
"S. Ramirez" wrote:
> I personally think that HDLs will evolve to C eventually, but the real
> problem is that HDL is only a part of FPGA design. Just ask anyone in this
> newsgroup about all of the problems involved with FPGA design. The majority
> of them are not HDL problems. Therefore, one cannot take a programmer
> (read: non hardware engineer), teach him/her Handel-C and expect him/her to
> simply start cranking out FPGA designs. That person will have to know about
> timing problems, metastability, floorplanning and a bunch of other skills
> that are commonly required to complete an FPGA design. Essentially, that
> person has to be a hardware person.
> The first link given below is to an article about Celoxica. It's
> obvious that this article was written by a semi-technical person, since
> (s)he refers to VHDL as "Verilog HDL." The article to me reads simply as
> marketing hype for this new language and tools. I am not saying that they
> will not take off, but I doubt that they will unless they can get a
> significant amount of us to go that way. I wish the company well, and I am
> always looking for new, better and cheaper tools, but my present design flow
> and methodology is sufficing quite well.
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL USA
I would agree & I would go further even than Simon. Although looking at Handel-C
itself it seems that it would do the job it seems that the marketing strategy of
these C-based HDL tools companies has very little to do with the technicalities.
They are mostly trying to talk to managers and saying:
``Hey guys here are some tools that will allow you to throw away all those
expensive, rare h/w types & replace them with off-the-shelf el-cheapo s/w
grunts''
The sad thing is my experience of most management types says they will buy it -
its what MBA training is all about. Remember these are the same people for who
marketing target with their whizzo GUIs [what other purpose do all those screen
shots on the Web serve ?].
What I actually don't understand is why the C-based tools are needed ? Verilog
is so easy to write that at the pure coding level any reasonably competent C/C++
programmer could pick it up in a couple of days. Then with a couple of years
practice they might, if they have the right mentality (*), get to produce h/w
that's not an embarrasment to their company.
(*) This is not just to do with timing, metastability, etc. My fear here is that
s/w types do not have the deep, ingrained, awareness that from day 1, hour 1,
minute 1 of design start any mistake they make could be fatal. s/w bug = fix it
& put a patch file on the Web, h/w bug = a $250K+ ASIC respin.
Robert Carney
Rick Filipkiewicz <ri...@algor.co.uk> wrote......
> "S. Ramirez" wrote:
> > I personally think that HDLs will evolve to C eventually,
Saying HDLs will evolve to C is like saying humans will evolve to monkeys.
>> but the real problem is that HDL is only a part of FPGA design>
I think that if C alone were enough for hardware design, it would have
been used instead of Verilog or VHDL. As it turns out, the programmer's
model is quite different for one case compared to the other. For C, as
with other system programming languages, the focus is on algorithms and
data structures used in the one-instruction at a time sequential flow.
To support hardware modeling, it was necessary to extend C to allow
the programmer to model the passage of time and the execution of
statements in concurrent processes. Not that such a thing couldn't
be done in C (Verilog is sometimes referred to as "C+-" ;-) , but the C
extensions need to be done in a "standard" way, to encourage the
support of third-party vendors (cell libraries, verification, synthesis...)
Maybe someday we'll have a set of standard libraries that extend
some other language to replace Verilog or VHDL. When that happens,
we'll still need "domain experts" , i.e., digital hardware savvy types
who can use the language to perform the modeling and analysis for
which it is intended. There has never been and probably never will
be a threat to employment security for hardware types from those
who are merely programmers, anymore than physicians are threatened
by others who happen to speak English or who have read about medicine
in a book somewhere.
niki
different from what software guys think in C prgramming. It is not that
different from schematic drawing of hardware components. If you don't have
a good idea about what hardware should be, you can't be a good HDL
designer. (designer! not programmer...)
Robert Carney
to help out in hardware design. Learn about
the PLI. Write some code that helps hw people
analyze and report on simulation activity.
With the PLI, your C code can be referenced
from a simulation as a library object. With
some simulators, the library is linked dynamically,
so it's not even necessary to rebuild the simulator
to take advantage of the nifty new widget you've
created for the hardware design and verification
community. Even better yet, with the emerging
Superlog language, you can inline your C code
in Verilog. Who knows, in a a few years, we
may be able to inline x86 asm in Verilog.
Bob Perlman
wrote:
These articles make it clear that Celoxica would like Handel-C to take
off. Whether it will is another matter.
Years ago, I used C (and FORTRAN--remember that?) to do cycle-based
simulations of hardware, but gave that up when capable HDLs came
along. I'm not saying that C will never evolve in such a way as to
supplant current HDLs, but I'm skeptical.
If Celoxica and similar companies convince managers that their
software people can use a C-like language to design FPGAs, that's
tantamount to declaring a guaranteed employment act for FPGA
consultants; we'll be cleaning up the mess for years.
Bob Perlman
cyber_spook
amout of software experiance I feel that a very important point is being
missed.
VHDL is like programing in assembly language but with some very nice added
funtions - you realy do need to undatand the target you are writing for!
however 'C' started to change that - a function written for an x86 could be
complied for a 6800!
What I'm getting at is that there are a lot of out of work C programmers that
with some experance of Handel-C are going to cross the border. Not to become
hard core hardware enginees but will fill the joinior engineer posts and alike
- from there is the opertunity for them to learn new skills and move up the
ladder. I see the coming of Handel-C as a was of getting more hardware
engineers and lowing the amount of unemployed Softy's.
However the problem is that there will be many more people leaving Uni with
these skills that don't understand the lower functions of hardware just as is
already happening in software - I used to work with a chap that was a very
good C programmer that had no idear what a register or a ALU was !? A product
of Uni mass production!?
And can I also point out that most hardware engineers work with Sotware
engineers (or should be) to get the best results. Lets not have a them and us
point of view! sometims a different approch is what is needed!
At the end of the day if you are good at what you do - why worry - its the
hardware chaps that have been blagging there boss for years that are in
danger!
Cyber_Spook
Rick Filipkiewicz
Bob Perlman wrote:
> OIf Celoxica and similar companies convince managers that their
> software people can use a C-like language to design FPGAs, that's
> tantamount to declaring a guaranteed employment act for FPGA
> consultants; we'll be cleaning up the mess for years.
>
> Bob Perlman
It might help if the company promoting Handel-C didn't sound like an unpleasant
disease picked up on holiday.
niki
I spent about 10 years doing semi-conductor design. Recently, I started to
feel more comfortable than ever before since fresh graduates have no idea
of what they are doing with HDL. :-) Thanks to synthesis tools, they
believe they are doing right job by clicking.
If I am a bit cynical, sorry for that. But, that is true. ;-)
cyber_spook <p...@cyberspook.freeserve.co.uk>이(가)
<3AD0DE23...@cyberspook.freeserve.co.uk> 기사에서 작성했습니다...
Richard Erlacher
like evolve from 'C'-language tools. That's about as far as they've
gone so far. However, if they ever figure out how to make a language
operate in parallel rather than serial fashion, it may evolve into
something useful for this task.
Dick
On Sat, 7 Apr 2001 18:46:03 -0700, "Compilit" <comp...@yahoo.com>
wrote:
>Does anyone what the future will be like for Verilog and VHDL ?
cyber_spook
differance were I work - The hardware department look a little worried as one
of the softy's is going grate guns with his evaluation copy of Handle-C. It
will be intresting to see how adapts to it better, the Embeded C programmer or
the Expert VHDL Engineer who thinks he knows nothing about software ( he needs
to look at some C code to see the simularits! ). I would love to have a change
( being a hardware engineer at hart with many years of C also under my belt).
Currenly I have to fullfill my needs as a hardwear Eng. at home programming
MAX7000's and FLEX10K's but also doing some assembler on a 68hc811.
I remmber using EPROMS as logic when I was a kid! still better than spending
hours wiring up 7400's chips - although I did plently of that two 8o)
Oh well - one day I get back in full time as a hardware Eng! Once I'v mastered
VHDL and Handle-C I guess?
Cyber_Spook
cyber_spook
parellel!?
cyber_spook
A E Lawrence
Actually Handel-C is thinly disguised occam which does have all those
features.
--
A E Lawrence
Lasse Langwadt Christensen
Rick Filipkiewicz wrote:
>
snip
>
> What I actually don't understand is why the C-based tools are needed ? Verilog
> is so easy to write that at the pure coding level any reasonably competent C/C++
> programmer could pick it up in a couple of days. Then with a couple of years
> practice they might, if they have the right mentality (*), get to produce h/w
> that's not an embarrasment to their company.
yep, figuring out how to describe the HW in what ever language you
choose shouldn't
be a big issue, figuring out what HW to describe is the hard part
>
> (*) This is not just to do with timing, metastability, etc. My fear here is that
> s/w types do not have the deep, ingrained, awareness that from day 1, hour 1,
> minute 1 of design start any mistake they make could be fatal. s/w bug = fix it
> & put a patch file on the Web, h/w bug = a $250K+ ASIC respin.
you could start them up slowly by having them write code to be put in
ROM :)
-Lasse
--
DK-9000
S. Ramirez
> > > I personally think that HDLs will evolve to C eventually,
> "Robert Carney" wrote:
> Saying HDLs will evolve to C is like saying humans will evolve to monkeys.
Looks like we're there already!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL 32765
Jamie Lokier
I've used Handel-C for a few years now, starting with a pre-release
version 2.0 and now adapting code to version 3, the DK1 version. Our
team here at CERN are going strong with it now. We build network
testing equipment, that means MACs, memory interfaces, network
protocols, traffic shaping and queueing, timing measurements, that sort
of thing. One of our boards has 35 Altera Flex10k50s. For my own part,
I have been involved at most levels of designs from schematics up to
VHDL and Handel-C (on FPGAs and CPLDs), to the software that runs the
show on a cluster of PCs.
I've had to do some very dirty things with Handel-C, because it didn't
(by itself) support all that we needed. Things like combining with
VHDL, and dual-port RAMs. But the latest edition "DK1", which is a
much-changed language, seems to have a lot of the needed features built
in now. (I've not used it enough to be sure, and some dirty things
are still required).
Its about time to clear up a few misconceptions about Handel-C.
Richard Erlacher writes:
> However, if they ever figure out how to make a language operate in
> parallel rather than serial fashion, it may evolve into something
> useful for this task.
Handel-C _is_ a parallel language.
Handel-C has explicit parallel statements, starting with "par". The
parallelism is very clear and easy to read. (IMO, what behavioural VHDL
should have been, with clean branch and join points in the control flow).
Judging from the responses here, a lot of hardware types see "C" and
assume that Handel-C is not a hardware language. You should get
familier with keywords like "par", "signal", "clock", "interface",
"chan" before assuming that Handel-C has much to do with C.
As Adrian E. Lawrence notes, it's thinly disguised Occam.
It's a lot nicer to read than Occam :-)
Actually it used to be that, but newer features are rather unlike Occam.
Version 3 of the language (the DK1 tool) introduces "signals", which
have different timing semantics to variables (not unlike VHDL's
variables and signals).
S. Ramirez <sram...@cfl.rr.com> writes:
> I personally think that HDLs will evolve to C eventually, but the
> real problem is that HDL is only a part of FPGA design. Just ask
> anyone in this newsgroup about all of the problems involved with FPGA
> design. The majority of them are not HDL problems. Therefore, one
> cannot take a programmer (read: non hardware engineer), teach him/her
> Handel-C and expect him/her to simply start cranking out FPGA designs.
> That person will have to know about timing problems, metastability,
> floorplanning and a bunch of other skills that are commonly required
> to complete an FPGA design. Essentially, that person has to be a
> hardware person.
There are levels of hardware knowledge. If you've been supplied with a
board with FPGAs on, designed by people who knew what they were doing,
you don't need to know about termination resistors, lead inductance etc.
The digital logic simply works to a specified limit. Until it doesn't,
but then you call in the board designers and get them to fiddle with the
scope :-)
It is _very_ good to have at least one person who understands FPGA
design constraints, floorplanning perhaps (though I don't bother -- I
use Alteras and their current PAR kit ignores most fitting constraints
anyway ;), and what typical Handel-C code maps to on the FPGA. This
sort of knowledge seems especially important at the I/O interfaces to
other chips, and when explaining the importants of pipelines et al.
Were you to follow the Celoxica "reconfigurable computer" route, you'd
have received delivery of a package where I/O interfaces are also solved
for you, in a library. I've never used a packet like this: our reality
means that boards are custom-designed for specific problems, and every
board is different.
"niki" <gu...@my.net> writes:
> I totally agree with you. HDL is for hardware modelling. It is 100%
> different from what software guys think in C prgramming. It is not that
> different from schematic drawing of hardware components. If you don't have
> a good idea about what hardware should be, you can't be a good HDL
> designer. (designer! not programmer...)
I've noticed the "firmware" folk, who know Handel-C and have a passing
familiarity with VHDL do understand how most of our more sophisticated
I/O interfaces work (written in highly-hacked Handel-C or
multi-clock-domain VHDL), but I'd guess they'd take an age to actually
write them.
I've also noticed that things like barrel shifters and pipelining are
still a big deal to them, so I do see there's still a gulf between
software-level design and thinking in terms of depth of logic. I've
also noticed that, although they fully understand Handel-C's kind of
parallelism, they are sometimes reluctant to use it. By contrast, a
VHDL designer prefers parallelism because its simpler than sequencing.
Having someone around who understands the FPGAs well seems to be pretty
helpful for the others. <ahem> But enough about me ;)
For the day to day "lets histogram the packet latencies today", or "we
need to match the diffserv field", or "can you add VLAN support?",
really no knowledge of the FPGA is required beyond knowing how much RAM
you have. This is where Handel-C excels at the moment, IMO.
Sometimes it really is a case of "we need feature X, how long?" and the
stunned looks you get when you implement the feature before they've
finished explaining the question are most satisfying :-)
cyber_spook <p...@cyberspook.freeserve.co.uk> writes:
> Currently I work as a IT suport Eng. (Yuk!) but I'm watching Handle-C
> make a differance were I work - The hardware department look a little
> worried as one of the softy's is going grate guns with his evaluation
> copy of Handle-C.
I think you will see more and more of that. In my experience, having
worked with both VHDL and Handel-C, writing Handel-C is a rather
speedier process. I'd bet your softy has a fairly good idea what's
going on at the FPGA level, and if not it will come to them as they get
closer and closer to the timing constraints. Logic depth, pipelining
and sensible simple parallelism come to mind as Handel-C level concepts
that map well to FPGAs.
Rick Filipkiewicz <ri...@algor.co.uk> writes:
> (*) This is not just to do with timing, metastability, etc. My fear
> here is that s/w types do not have the deep, ingrained, awareness that
> from day 1, hour 1, minute 1 of design start any mistake they make
> could be fatal. s/w bug = fix it & put a patch file on the Web, h/w
> bug = a $250K+ ASIC respin.
This _really_ doesn't matter with FPGAs. 10 minute design cycle, about
5 times slower than writing C on a fast day. Sure you _can_ scrutinise
the code carefully for hours, but sometimes it's easier to write the
obvious code, if it works great otherwise pull out the scope and ask
"what should I be seeing on the scope about here?".
It never costs $250k. Maybe $2000 when you realise you need a faster
FPGA :-)
> To support hardware modeling, it was necessary to extend C to allow
> the programmer to model the passage of time and the execution of
> statements in concurrent processes. Not that such a thing couldn't be
> done in C (Verilog is sometimes referred to as "C+-" ;-) , but the C
> extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)
One of Handel-C's characteristics is that passage of time does not
appear explicitly in most programs. This is a big contrast with
Verilog, and it does (IMHO) make the Handel-C quite nice to read.
There's a "delay" statement but it's not often used.
Robert Carney <bobc...@worldnet.att.net> writes:
> What I actually don't understand is why the C-based tools are needed ?
> Verilog is so easy to write that at the pure coding level any
> reasonably competent C/C++ programmer could pick it up in a couple of
> days. Then with a couple of years practice they might, if they have
> the right mentality (*), get to produce h/w that's not an embarrasment
> to their company.
Canned answers:
(a) It doesn't take a couple of years to produce good code with Handel-C
(IMO it doesn't with Verilog either).
(b) Handel-C is sometimes verbose than Verilog for similar functionality.
(c) Verilog expects you to understand the basics of clock signals and
so on. As it happens you can get by in Handel-C without
understanding how the logic is synthesised, nor with much
awareness of the clock signal. Don't expect to write a SERDES
this way of course :-) But it's useful for writing DSP-like
algorithms or network protocol processing on FPGAs, for example.
You can still optimise the timing, without the clock signal being
in your face.
(d) Counterpoint: You have a good point about Verilog being pretty
close to these C-like languages though.
Rick Filipkiewicz <ri...@algor.co.uk> writes:
> I would agree & I would go further even than Simon. Although looking at
> Handel-C itself it seems that it would do the job it seems that the
> marketing strategy of these C-based HDL tools companies has very little
> to do with the technicalities. They are mostly trying to talk to
> managers and saying:
>
> ``Hey guys here are some tools that will allow you to throw away all
> those expensive, rare h/w types & replace them with off-the-shelf
> el-cheapo s/w grunts''
I agree. Before they were called Celoxica, Celoxica's site had
"application notes" with nothing of the technical depth we'd expect.
Thankfully they have renamed them "case studies" now. Also, don't
expect to learn the Handel-C language from documents on the web site!
(AFAIK you have to register to see the language reference manual). It
seems very much a marketing and community-building exercise. To be
fair, they do have an active on-line community via their site, should
you wish to register.
I have similar reservations about C Level Design. Anyone have a manual
for their Cycle-C product? I couldn't find anything except brochures,
fluff and screen shots on their web site. I daresay if I emailed them I
_might_ get a manual and maybe a trial version, but I don't have much
time for the attitude that isn't encouraging me discover the tool for
myself.
Robert Carney <bobc...@worldnet.att.net> writes some more:
> the C extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)
At the moment each company has its own language, its own GUI, and a big
lack of handy on-line tutorials. Like they'd rather not have everyone
using their languages. Perhaps they want hardware engineers kept well
away, you know how they'll just pick on the bad points without
appreciating the good points ;-) At one time, I saw on C Level Design's
web site that they weren't revealing how their Cycle-C language worked:
it was only going to be used by their internal design teams. This seems
to have changed with their reported new relationship with Altera.
There may be some hope for standards in this field, according to
articles about C Level Design:
http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2237.html
http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2213.html
When some kind of standard emerges, if anyone wants to support the
development of an open source tool, do let me know :-)
cheers,
-- Jamie
Fabrice MONTEIRO
When one writes a HDL model, he may be describing an algorithm, an
architecture or both. The abstraction level of the model can range
from technological gates to large abstract functional blocks.
If a model is designed for simulation purpose only, no limits should
apply on the complexity it can reach (except those related to the
performance of the computer on which the simulation is to be done).
In VHDL, for instance, it possible to design a simulable model of a
system, should it be modeled from logical gates or from complex
sequential processes (I suppose this is also true for Verilog).
If synthesis is considered, an important information must be taken
into account: what are the synthesis tool assumptions applying to the
input time model !...
These assumptions are implicitly contained in what is usually called
"level of modelisation". Indeed, most of the confusion comes from not
explicitly telling what "level of modelisation" is considered.
Actually, most of the synthesis tools rely on RTL modelisation, but
it is not the only modelisation level that can be considered. There
are some major levels applying to modelisation of digital systems:
- logical
- RTL
- behavioral
In a logical level description, all the VHDL processes should describe
only purely combinatorial "blocks" (of any complexity). Each process
describes the "algorithm" of a combinatorial "block". Complex systems
are designed interconnecting all this combinatorial blocks.
-- example of a VHDL combinatorial process
-- where a, b and s are std_logic signals
comb: process (a,b)
begin
if a=b then
s <= '1';
else
s <= '0';
end if;
end process comb;
In an RTL level description, the VHDL processes describe combinatorial
"blocks" (as in logic level descriptions) or synchronous "blocks". From
a practical point of view, each "synchronous" process describes a time-
limited algorithm, the algorithm of a clock cycle period. The algorithm
can be as complex as needed, the only limitation being the tool and the
computer limits.
-- example of a VHDL "synchronous" process with asynchronous setup
-- rst, clk, a, b and s are std_logic signals
synch: process (rst,clk)
begin
if rst='1' then
s <= '0';
elsif rising_edge(clk) then
if a='1' then
s <= b;
end if;
end if;
end process synch;
As all the operations described in the process are processed in the
same clock cycle, all the required hardware must be generated. If three
arithmetic operations are done in the same clock cycle, three operators
must be synthesized (of course, synthesis optimizations can eventually
generate less hardware).
A behavioral description may be compared to a parallel C program with
explicit synchronisations (with semaphores, mutex, signals, etc.). The
VHDL processes can be compared to C threads or processes. Each process
describe a sequential algorithm, not time-limited. For a synchronous
design, this means that the algorithm can spread on several clock
cycles.
-- example of a VHDL "behav" process
-- clk, a, b and s are std_logic signals
behav: process (clk)
begin
wait until clk='1';
s <= '0';
for i in 0 to 3 loop
wait until clk='1';
s <= (not s) and (a or (not b));
end loop;
while true loop
wait until clk='1';
end loop;
end process synch;
Much more complex behaviors can be described, and if the model is not
synchronous, it may be very hard to find what hardware can match the
algorithm. Most of the time, there can be several different solutions.
Indeed, it is possible to write an asynchronous model that will be
implemented in a synchronous way. The synthetiser will have to determine
simultaneously, the number of cycles and the hardware ressources. That
is, find an architecture and match the algorithm on this architecture
!...
And this is a quite complicated task. This is a reason for which this
kind
of synthetiser is not yet the industry standard.
When behavioral synthetisers will be a standard, it will be possible to
use C-like languages or VHDL or Verilog (or else) indiferently.
However, if one still needs to control the generated architecture in its
model, he will still need to use RTL or logical modelisation. And this
is
not possible (yet?) with traditional algorithmic languages as C or C++.
--
+-----------------------------------------------+
Fabrice MONTEIRO
LICM / CESIUM
Universite de METZ
7, rue Marconi
57070 METZ / FRANCE
Phone: +33 (0)3.87.54.73.11
FAX: +33 (0)3.87.54.73.01
Email: fabrice....@ieee.org
+------------------------------------------------+
cyber_spook
if im wrong... I'll post some real code If I can get my hands on it.
par
{
this responds to the first clk and runs in paralle with the next bit
below.
}
par
{
in parralle with bit above on first clk..
par
{
nested parralle functions that respond to the second clk..
}
par
{
......
}
}
S. Ramirez
> -- Jamie
Jamie,
You've covered a lot of ground, so I won't bother to elaborate on what
you said; however, I really do appreciate your insight into Handel-C, since
you have knowledge of this language AND VHDL and Verilog.
Thanks for your explanations.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
niki
the same concept. Levels of abstraction contains (1) architectural (2)
algorithmic (3) functional blocks (4) logical (5) circuit levels from
highest to lowest. Design domains are comprised of (1) behavioural (2)
structural (3) physical modelling.
Usually, when they talk about synthesis, this means logical abstraction
level. It is called RTL in terms of structural modelling. Behavioural
modelling doesn't necessarily mean that there is no logical abstraction.
This is well explained in the chapter 1 of "Principles of CMOS VLSI design"
by Weste and Eshraghian.
-Niki
Fabrice MONTEIRO
not on design domains.
If all processes on which rely a hierarchical VHDL model are RTL
compliant,
the model is RTL compliant. Thus, in order to design RTL models, one
must
write RTL processes.
Different architectures can match an given algorithm. In RTL, each
process
describes the architecture of a "sub-block" of the design. Note that i
am
not talking of structural VHDL.
I give in the following, examples of different architectures for the
same
algorithm. All are synchronous clocked designs. Let the algorithm be the
following:
algorithm:
-> wait until a wait_signal is reset
-> compute the sum of stored integer numbers
-> set an end_signal
-- VHDL design nr 1
addOne: process (rst,clk)
variable i: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=0;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=0;
end_signal <= '0';
else
if i<size_of_my_array then
total <= total+my_array(i);
i:=i+1;
else
end_signal <= '1';
end if;
end if;
end if;
end process addOne;
-- VHDL design nr 2:
addTwo: process (rst,clk)
variable i,j: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=0;
j:=1;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=0;
j:=1;
end_signal <= '0';
else
if i<size_of_my_array then -- supposing size_of_my_array is even
total <= total+my_array(i)+my_array(j);
i:=i+2;
j:=j+2;
else
end_signal <= '1';
end if;
end if;
end if;
end process addTwo;
-- VHDL design nr 3:
addAndShift: process (rst,clk)
variable i: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=size_of_my_array;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=size_of_my_array;
end_signal <= '0';
else
if i/=0 then
total <= total+my_array(0)
my_array <= my_array(0) & my_array(size_of_my_array-1 downto
1);
i:=i-1;
else
end_signal <= '1';
end if;
end if;
end if;
end process addAndShift;
All the designs implement the same algorithm but not the same
architecture.
On the first design, once the start_signal is set, size_of_my_array
clock
cycles are required to compute the sum. The stored data my_array is in a
single ROM or RAM (only one address must be reached at a time). Only one
adder is required to add the data to the total. The data addresses are
generated by a counter.
Only (size_of_my_array/2) clock cycles are required on the second
design.
But the data must be partitionned into two different ROMs or RAMs (as
two
addresses must be reached at a time), one for the odd addresses, the
other
for the even addresses. Two adders are required to add the data to the
total. The data addresses are generated by two counters.
In the third design, the data is stored in a cyclic shift register. The
number
of clock cycles required to compute the sum is (size_of_my_array). The
counter
i is only used to know if all data was processed, as no ROM or RAM
address
must be generated.
Renaud Pacalet
>
> Does anyone what the future will be like for Verilog and VHDL ?
>
> Wil it be replaced by C/C++ platform ?
>
Yes, it could be. Because of all that money they spend on marketing.
What will it look like? Simple. You'll have some new statements
(process, wait, etc.) and a new kind of variable that will probably
be named "signal". As it will be "pure" C it'll cost nothing,
except for the debugger the waveform tool, the synthesizer, etc. As
it will be "pure" C it will be much faster than VHDL, except if
you're using signals, concurrent statements and don't disable all
the dynamic checks (in that case it will be as slow as VHDL). As it
will be "pure" C it will be very portable, as portable in fact as
any C code and this will be a real advantage on VHDL. As it will be
"pure" C you will not need to know anything about hardware to
design ASICs or FPGAs, except for signals and concurrent stuff but
everybody knows it's totally useless. As it will be "pure" C it
will be very easy to extend it to analog domain (the name will be
C-AMS). It will be very well suited to software / hardware
co-design and the software / hardware partitionning will be very
easy : those parts with signals and concurrent stuff will be
hardware parts and those parts written in good old C will be
software parts and as they will not be designed by the same people
it will be impossible to mix up. As it will be "pure" C you'll
never see again the stupid VHDL error messages:
"array constraint violation, line 15, column 43, file foo.vhd"
but see usefull messages:
"segmentation fault, core dumped"
As it will be "pure" C it will drammatically reduce the amount
of bugs and so you'll save more money than with unsafe languages
as VHDL.
There are a lot of other good points about this but I think I named
the most important. To be honest, there will be drawbacks too, I
guess, but today I can't imagine what they will be.
Best regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr
Brendan Lynskey
Is anyone else out there slightly worried about this whole thing? Maybe we
should all accept the inevitable and take a course in programming?
Mike Treseler
No worries. VHDL will be around a long time.
However, knowing a second language is useful
for many reasons if you are so minded.
Perl and/or C would be good choices for a hardware guy.
There's also no law against using variables
and complex data sturctures in a VHDL process.
-Mike Treseler
cyber_spook
Handle-C *IS* not C it a VHDL type language written in a 'C' style but that
it.
I have see software eng's try to do this - yes they have a foot on the ladder
knowing C but they don't know Handle-C and they don't know Hardware.
One chap said to me... "whats the differance between a MAX7096 and a FLEX20K?
as this will not complie to an MAX7096!!"
I say - go get a demo vertion and lean it! it will be a great tool that will
help you. Think about it... you go for an interview and you are a *hardware*
eng that fully understands VHDL and you have a basic knowlage of Handle-C. I
don't think I'd interview the chap above that asked that question - would you?
For the softy's out there they will see the simularities between C and VHDL as
it stands today - as a hard/software engineer I found VHDL very quick to pick
up and can even see bits of pascal in Verilog - VHDL and AHDL!? I don't see
every one getting worried about all them out of work pascal programmers
getting top paid hardware jobs.
Cyber_Spook
niki
here seem to worry about their jobs because of fancy "Handel-C". ;-) (For
your reference, I talked with at least 5 years experienced engineering
colleagues in my consulting firm. Surprise! Nobody heard Handel-C. Me,
either.)
If you really worry about your hardware job, go to Synopsys education
sessions and learn theier C++ aproach synthesis. Youl will find there is no
difference between C++ and HDL approach synthesis. Folks, basically it is a
matter of real hardware, not an abstract language.
riley
impressive. But.... we are also in the process of putting together a million
gate FPGA design running at 133Mhz. It's VERY difficult to meet timing. Add a
layer of abstraction? I don't think so.
Will Handel-C replace VHDL? Not in critical designs. Can you imagine the levels
of logic a SW eng would end up with?
Will it allow more people to design hardware? Yes.
In article <9aoga1$qt8$1...@taliesin.netcom.net.uk>, comp...@yahoo.com says...
>
>Does anyone what the future will be like for Verilog and VHDL ?
>
>Wil it be replaced by C/C++ platform ?
>
Jonathan Bromley
writes
>> Does anyone what the future will be like for Verilog and VHDL ?
>> Wil it be replaced by C/C++ platform ?
>
>Yes, it could be. Because of all that money they spend on marketing.
>What will it look like? Simple. You'll have some new statements
>(process, wait, etc.) and a new kind of variable that will probably
>be named "signal". As it will be "pure" C it'll cost nothing
ROTFLMAO! Thanks Renaud!
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan...@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Johan Petersson
"Brendan Lynskey" <brendan...@pace.co.uk> skrev i meddelandet
news:9b40sg$gr6$1...@nh.pace.co.uk...
> So considering all that's been said, what a VHDLer to do?
>
> Is anyone else out there slightly worried about this whole thing? Maybe we
> should all accept the inevitable and take a course in programming?
>
>
NO! You'll be able to use your vhdl/gate arrays skills till death if you
just keep an awareness
of what happens with the gate arrays themselves -
But it's no bad idea to take a programming course so that you can do HIGH
LEVEL models
of your HW. If you do something like microprocessor architecture, VHDL is a
little to slow to
write a high level model - or rather the VHDL high level model would take
weeks in the simmulator -
thats when a HWdesigner might want some programming skills :)
My own opinions, of course -
/Johan - www.wdi.se
Andy Freeman
> the programmer to model the passage of time and the execution of
> statements in concurrent processes.
Having actually used C to design hardware, I note that the above is
both widely believed and wrong. (It's also why most of the C-based
hardware design languages aren't all that useful.)
Yes, physical hardware is event driven; a change in a signal can cause
things to happen, and those things often happen concurrently.
However, consider what "make timing" means. For almost all of us,
it means "there's enough time between clocks for the hardware to
react, for the relevant signals to propagate through the gates and
wires". (That's true whether we're talking about activity between
events for the same clock or different clocks.) That's why we tell
our tools the desired clock periods and relationships.
Thus, the design problem is to specify what happens between clocks.
(Yes, you also have to do it within the power and area/gates budget.)
One way to express activity is as events for each and every signal.
Verilog is a lot like this. Many of the C-based design schemes work
similarly, by allowing the designer to define events to design around.
Another way is to use time-aware processes or other mechanisms.
Handel-C is basically like this.
A third way is to describe the activity between clocks and to use
clocks to define storage. With this scheme, clocks are the only
events - everything else is logic and connectivity. (Two-phase
design is a mapping of this concept onto Verilog's event model.)
The problem with time-aware design is that it doesn't work well in
the large. People think that they know how to express parallelism,
but they fail miserably when the system is large. They write
heisenbugs. Such systems also force designers to say things
redundantly or that shouldn't be specified by programmers.
Consider
a = b & c;
d = e & f;
In Handel-C, those statements each define storage elements, a and b,
and they define a two clock sequence. What clock you ask? I don't
know.
Most systems that have lots of activity between clocks. Much of that
activity is fairly independent. With Handel-C, multiple operations
within a single clock requires more code, the "par" form, or more
code for the common case. In addition, the designer has to worry
about how different par forms interact.
With clock-based design, as in reality, connectivity defines
concurrency. You don't have to worry about evaluation order; you
write what looks like boring sequential code, computing (or reading)
inputs before using them in other computations, eventually leading
to storage inputs, which are necessarily clocked. As a result, you
just have to worry about the activity between clocks.
Also, simulations really fly because there's basically no simulation
overhead. The "RTL" for my designs was so fast even on a slow sparc
box that that I was able to use it for application development. When I
wanted a compute farm, I took some floppies to Fry's, popped them
in fast PCs, hit ctrl-alt-del, and then listened to a short lecture
on computers.
If I'd ever run into a single simulation that took too long, another
advantage of clock-based design is that it can be automatically mapped
for execution on a multiprocessor, with no chance that the behavior
changes at all.
When these designs are mapped to hardware, all of their concurrency
is exposed. If there is too much activity between clocks (either
from the mapping or from your design), you won't make timing. If
there is too little, maybe you're using too many clocks, or maybe
you can slow them down. No matter what, the system behaves as it
did before synthesis.
Clock-based design does have some limitations. You can't use it
for ring-oscillators (a ring of inverters with no clocked/storage
elements). Some ring-like priority schemes (with clocked elements)
are somewhat difficult to express as well, but they're rare enough
that the extra hassle doesn't matter much.
-andy
ps - Yes, I had both unknowns and tri-states.
news_alias
Andy Freeman <ana...@earthlink.net>
....
> > To support hardware modeling, it was necessary to extend C to allow
> > the programmer to model the passage of time and the execution of
> > statements in concurrent processes.
>
> Having actually used C to design hardware, I note that the above is
> both widely believed and wrong. (It's also why most of the C-based
> hardware design languages aren't all that useful.)
Are you sure? Maybe the widely held beliefs are not wrong.
The programmer's model for C is for a single instruction processor
and no awareness of how long it takes to process each instruction.
To model multiple processes and the passage of time, C can be
extended. Whether with libraries or with a new 'extended'
language, something extra can be used. Compare Verilog to VHDL
or Quicksim, or any other simulators (there used to be alot of
them) and you'll see that they go about solving the problem of
modeling hardware in a similar way. Were they all wrong?
Andy Freeman
> Andy Freeman <ana...@earthlink.net>
> ....
> > > To support hardware modeling, it was necessary to extend C to allow
> > > the programmer to model the passage of time and the execution of
> > > statements in concurrent processes.
> >
> > Having actually used C to design hardware, I note that the above is
> > both widely believed and wrong. (It's also why most of the C-based
> > hardware design languages aren't all that useful.)
>
> Are you sure? Maybe the widely held beliefs are not wrong.
>
> The programmer's model for C is for a single instruction processor
> and no awareness of how long it takes to process each instruction.
C has a sequential model for disambiguating dependencies, but that's
really as far as it goes. That model does not imply or require
serial execution and it is perfectly capable of modelling arbitrary
static parallelism. (That's all you get in hardware until someone
invents a way to create new gates while the system is running.)
Some hardware design languages let you say how long an operation will
take, but you can't do much with that ability. In particular,
the correctness of the design can't depend on those numbers. (I'm
ignoring the various delays used in broken verilog to trick the
event queue. If your synthesized code behaves differently than
your RTL until you add those delays, you're writing broken code.
If the behavior of your code depends on those delays, you're
writing broken code.)
Delays are really just a poor-man's way of doing timing analysis.
There's nothing wrong with that, but don't confuse it with any
useful awareness of operation time.
> To model multiple processes and the passage of time, C can be
> extended.
While true, that doesn't imply that such extensions are necessary
or even useful for modelling hardware.
With "the right extensions", you can write event-driven code in
C, just like you do in Verilog. However, at that point, one might
well ask why you don't simply use Verilog.
If C is to be a useful hardware design language, it has to be
different than Verilog. There are lots of ways to be different;
I've had experience with some of them, and I've found that
some work better than others.
-andy
Andy Freeman
> assume that Handel-C is not a hardware language. You should get
> familier with keywords like "par", "signal", "clock", "interface",
> "chan" before assuming that Handel-C has much to do with C.
> As Adrian E. Lawrence notes, it's thinly disguised Occam.
> It's a lot nicer to read than Occam :-)
And that's why it is very misleading to say that Handel-C is C-like.
As someone else pointed out, Verilog expressions look like C expressions
but still they are very different languages. Handel-C is CSP headed
toward VHDL via Occam. (CSP and Occam are theoretically elegant, but
there's something that kept them from being generally useful. That's
a bad place to start from.)
Yes, one can use various libraries to provide a different execution
model in C. If that execution model is Verilog-like, you must staff
your project with people who think Verilog, but are reasonably
competent in C. The benefits of this approach over just using
Verilog are unclear. If the execution model is something else, it's
even worse.
I think that to use C to design hardware, you need to restrict C's
execution model, not extend it. (Yes, you need support for decent
bit operations; the Frontier folks have done some nice work in this
area.) Most of the restrictions are fairly obvious - they're a lot
like those imposed on embedded systems. They're all consequences
of the fact that hardware is static - you can't ask for more gates
or wires at run-time.
By restricting the execution model, "ordinary C programmers"
can produce hardware, and they don't have to think differently.
However, to "make timing", to make good hardware, they must do
what every other hardware designer must do. They must figure
out how to do the required computation with a set of operations
that can be performed "fast enough", "small enough", and with not
too much power.
No design language can ever eliminate that requirement.
For what it's worth, good software has to satisfy similar constraints,
so it's fairly easy for good programmers to make the transition.
(The world may be more forgiving of bad software.)
So, what's the point of using C? One advantage of the restricted
C model is that it eliminates heisenbugs. If there's a discrepancy
between the RTL-C and the synthesized hardware, it's a synthesizer
bug. (This eliminates the voodoo verilog involving #delays "to make
it work", the #delays that often come back to bite you later.)
It can also be transformed automatically for simulation on
cheap multi-processor boxes that take the place of expensive
emulation machines. (I don't know when VCS or Speedsim will
be able to do the same. Remember, the behavior must not change.)
I've also found that it's a more productive design language.
One could argue that the C restrictions are in some sense equivalent
to those of "good Verilog", which says that the possibility of
bad verilog wastes time.
I think that the restricted C execution model makes the design easier
to understand. There's absolutely no staring at code trying to figure
out what's happening, let alone "let's run it and see what happens".
All of the interactions are right in front of you, so you can think
about what you're trying to do instead of trying to understand what
you've done or how to do it.
-andy
Magnus Homann
Hello Andy,
Your posts about using a C as a hardware language are interesting. Do
you have any example with using C-code and storage elements? Who is
doing this kind of stuff?
Yours,
Magnus
--
Magnus Homann, M.Sc. CS & E
d0a...@dtek.chalmers.se
Andy Freeman
> you have any example with using C-code and storage elements?
Those of you who have written cycle-accurate simulators may have
seen something like this before. (The first design in C that I saw/
worked on started out as a cycle-accurate simulator.)
Suppose that you want to build a system consisting of two modules.
To keep things well behaved, I'm going to use flip-flops and
a single clock, and ignore all other connections to the outside
world. (Adding those connections should be obvious; latches
and tri-states are merely tedious.) Of course, each module does
produce inputs needed by the other.
One can design with registered inputs, registered outputs, or
both, or neither (with combinatorial logic on both sides of
storage elements in a module). I'm going to go with registered
inputs but it should be obvious how to do any of the others.
Unless one goes with "neither", each module can be expressed with
two procedures, so let's call the procedures for the first module
output_A and input_A and the procedures for the second module
output_B and input_B.
The names are intended to be a big give-away; the output_* procedures
read their module's storage elements, do any combinatorial operations,
and "return" the results. The input_* procedures take inputs and a
clock, and, if the clock has the correct value, store those inputs
in their module's storage elements. The input_* procedure's body can
look like:
if( posedge(clock) ) {
ff_1 = inp_1;
ff_2 = inp_2;
}
There are lots of ways to transfer values between these procedures.
Once you decide how you want to do it, you can build a system by
connecting them together appropriately. For simulation, you call
the output_* procedures then the input_* procedures; output_A feeds
input_B and output_B feeds input_A.
You'll also need a mechanism for associating a module's procedures
and storage elements with each other. If you also want to instantiate
a given module multiple times in a single design, you'll probably
decide to use C++ classes to express that association. (Since you'll
probably want to use C++ classes for other things, you'll also need a
mechanism for distinguishing module classes from other classes.)
Of course, you'll want to use subroutines to keep things manageable
and to allow code reuse. You'll also want some library support for
bit operations and arithmetic. (I've mentioned that Frontier Design
did something interesting in this area.)
Module hierarchies are fairly straightforward.
-andy