( ESNUG 291 Item 9 ) ----------------------------------------------- [5/27/98]
Subject: ( ESNUG 290 #8 ) The Differences Between RTL & Behavioral Code ?
> Behavioral code is more abstract than RTL (Register Transfer) code.
> Language constructs like loops (for), initial-blocks or events are pure
> behavioral Verilog. RTL code is written with synthesis in mind, since
> tools like Synopsys can map RTL code much better than behavioral (most
> synthesis tools accept only a subset of an HDL).
>
> - Lars Rzymianowicz
> University of Mannheim Germany
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
John:
It seems the discussion about RTL vs. behavioural was mixing up semantic
domains. Most HDLs (e.g. Verilog, VHDL) were defined to have a simulation
semantic (i.e. meaning). Their meaning was defined in terms of what a chunk
of code does when it runs in a simulator.
When the term RTL is introduced and we start to talk about synthesisable
code then we are talking about a synthesis semantic. That is, what the code
means in terms of a hardware implementation.
Between these two we have behavioural synthesis (BS). Given that we do not
(yet) have a standard and open synthesis semantic for RTL synthesis it is
going to be a while before we have one for higher levels of abstraction. The
tricky thing with BS is defining not only what we want the h/w to do be
under what constraints (e.g. how many clock cycles, when to input data
arrives, when do you want the output and in what form).
Current BS tools infer an FSM, a set of operation units and storage units.
RTL infers registers, latches and combinational logic blocks.
Current HDLs as they were defined infer a set of interacting processes
commicating via events on signals.
We need a new language or extensions to the existing HDLs before we can
fully exploit the possibilities of BS technology. One key issue is
the separation of interface from function:
// interface
@(posedge A)
@(posedge clock)
@(posedge clock)
@(posedge clock)
// function
b = !b
The big question is: do we extend or start afreesh. Given the reluctance
of h/w designers to change language, I would assume we are looking at
extensions. In a sense, imposing a synthesis semantic on a simulation
based language constitues an extension. What do the other ESNUGers think?
- Dyson Wilkes
Ericsson
P.S. I was highly ammused to see all the different views on the simulation
sematics of a small chunk of Verilog code. Not one e-mailer quoted the
LRM? I now question anyone who says Verilog is easy to learn!!
|
|
