OpenSPARC released

Art Stamness wrote:
>>Again, I don't see how writing always blocks is "unmaintainable." Maybe I haven't had enough experience
> 
> 
> Let met explain then. Here is the "proper RTL" as some other might
> right it :
> 
> wire [31:0] a ;
> wire [31:0] b ;
> reg [32:0] result ;
> always @(posedge clk) result <= a + b ;
> 
> Here is what you will find in many high end synthesizable RTL coding
> standard examples :
> 
> wire[31:0] a ;
> wire[31:0] b ;
> wire[32:0] a_plus_b ;
> 
> assign a_plus_b = a + b ;
> 
> my_dff #(33) a_plus_b_32_0 ( .out( result ), .clk(clk), .in(a_plus_b) )
> ;
> 
>

And here is what we use in our coding standard

wire [31:0] a;
wire [31:0] b;
reg  [32:0] result;
reg  [32:0] next_result;

always@(*)
   begin
   next_result = a + b ;
   end


always@(posedge clk)
   result[32:0] <= next_result[32:0];


This seperates the sequential from the combinational logic without impacting the ability
to understand the function. Plus it can be processed so we can do things like switch
between sync and async resets or add a clock enable signal to all flops.


Hand crafting rtl code is going the way of schematic capture. Yes, it gives you complete
control of every last detail in your design but chips have grown to the point where you
don't have the time to deal with all that detail in a normal product cycle. You have to
use more automated methodogies if you plan on finishing in a reasonable time.


John Eaton

Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs
can be .ie 20-120MHz is typical for unfriendly architectures.

If your not in that very small club of Intel, AMD, IBM, then even full
custom is also pretty limiting by the extreme expense of it all. The
top tier may still be directly instantiating transistors as well as
flops. But then transistor level design is still able to significantly
outperform standard cell logic using a variety of mostly nmos
differential techniques, I guess by a factor of 3. At Suns level, they
are much closer to full standard cell with synthesis with a fraction of
the clock of P4s but they make up for it by going to massive threading
and latency hiding to bring out the throughput.

Theres the clue there. The same can be done in FPGA cpu for
multithreading architecture to simplify the design so that you are not
limited to 32b carry ripples. In my Transputer design I was seeing
300MHz on the PEs because it could use 2 clocks per basic opcode and
used 8 clocks for 4 thread instructions, alot of cycle limiting logic
just vanishes, ie no hazard logic or register forwarding paths. The
hardware design of the MMU hasn't started so there is nothing to
release.

For information, my PE used 500 LUTs & 1 BlockRam and a few hundred LOC
in RTL Verilog. Given V4 can hold upto 554 BlockRams, means I coudl
instance quite a few of these PEs too. In some ways it is quite similar
similar to the Niagara/Sparc, whats the difference between slidy
register files with stack spilling v register files in memory but
cached on demand (process swapped) into register caches as the T9000
did.

If I wanted to see a Niagara core in FPGA I think I would go back to
the Sparc architecture documents and maybe LEON and see if a threaded
design could be done from scratch that executes the ISA but possibly
make some very different choices so the FPGA version wouldn't get
crippled. I wouldn't be constrained to 1 opcode per clock either, using
more clocks, lowers PE performance by clock but allows a much faster
clock and much less logic so more PE cores.

I am surprised that we haven't seen alot more native FPGA MTA designs
though,.

John Jakson
Transputer guy

I would have to disagree about hand crafted code going away.

I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL
based hand coded design methodologies for most all of their designs,
that I am aware of.

IP reusage models cut down on the actual number of lines of code
written by leveraging pre-built high level libraries, with fifo's,
memories, register files, and other constructs. Soc vendors are also
doing less and less design, as more of the code they actually produce
comes in the form of pre-verified IP, and their job is moved to
verification of the integrated system from verification of the
individual components.

I don't see however "whats next", as far as getting us away from hand
written code. We can save time by buying others hand written code, but
what other tools are you aware of that would take the place of Verilog
??

-Art

Art Stamness wrote:
> I would have to disagree about hand crafted code going away.
> 
> I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL
> based hand coded design methodologies for most all of their designs,
> that I am aware of.

Yes there is a lot of legacy code out there and a lot of design houses
are still hand coding more. They are also finding it harder and harder
to support this code as chips grow and processes shrink. You start finding
teams that are afraid to touch blocks that have been proven in silicon
for fear of introducing bugs. One of our standard practices is to
put in a new component but leave in the old version and give firmware
the ability to select which one is used at run time.

> 
> IP reusage models cut down on the actual number of lines of code
> written by leveraging pre-built high level libraries, with fifo's,
> memories, register files, and other constructs. Soc vendors are also
> doing less and less design, as more of the code they actually produce
> comes in the form of pre-verified IP, and their job is moved to
> verification of the integrated system from verification of the
> individual components.
> 
> I don't see however "whats next", as far as getting us away from hand
> written code. We can save time by buying others hand written code, but
> what other tools are you aware of that would take the place of Verilog
> ??
> 

Creating the design is 20% of the effort. Verification is the other 80%.
The industry is heading toward systems where you can specify the desired
behaviour and create the design and the testbench at the same time from the
same source. This goes well beyond providing a richer assortment of register
files. We are advancing from "assemblers" into "compilers"

But thats only the start. You want to design a component once and reuse it
over and over again. Each user should be able to reconfigure your component's
parameters for their exact needs and your tool set must be able to rebuild
both the rtl code and the testbench for these new parameters.

Futhermore the user will want to use this newly configured component as a
building block of another component in their chip. The tool set must be able
to "Plug&Play" the rtl code into the chip. This also involves building a chip
level testbench and documentation from all of the included components in a
fast and efficient manner.

Each stage should be able to verify that everything below it still works and
you can't spend weeks of engineering time fixing sims and hand placing components
to reach that point. The methodologies must be able to handle it.


John Eaton


















> -Art
> 

I agree that the 80% effort is in the verification. That is why the
verification tools have been improving so dramatically over the last
decade, where RTL design tools hasn't really changed all that much.

Vera, Specman, and now SystemVerilog Testbench are all nicer and higher
level way of verifying designs. Constraint based Random Verification
gets more bang for the buck out of your simulation dollar. They are
still costly in runtime ( read : slow ), but are definately an
improvement over the old style hand coded testbenches.

Assertion Based Verification using OVA, OVL, PSL, SVA types are
maturing and more mainstream, and this will definately help in the
reuse of IP, however the cost of use is high because, this verification
runs continuously in your simulation. In fact just a few temporal
assertions added to some interface can half your runtime performance (
from my experience on a 2MGate microprocessor core). Static assertions
are clearly more performance friendly but must more limited in there
checking.

I know companies like Real Intent have tools that try to use "Automatic
formal" ( which extracts the assertions, and formally proves they are
possible scenarios in which illegal behavior can be expressed) . This
also seems like a good thing, unfortunately I have found that this type
of work is typically done by the RTL designer, and increases his
workload, not decreases.

And the holy grail of "Spec -> RTL" tool still doesn't exist. But I
agree we have more tools to get us closer. I still don't see there
being any other way of describing large ASIC's in any other way than
hierarchical hand coded RTL. And these tools that try to make it easier
to verify, I haven't seen one yet, that actually implements your logic,
because usually the designer is the one who knows what to optimize for
: performance, speed, area, cost, manufacturability, testability . . .

So, at the end of the day, I don't think the job of the RTL designer is
going away any time soon. In fact most of these tools still require
more code to be written to describe the correct behavior. I don't think
these technology is driving RTL designers out of work.

-Art

JJ wrote:
> Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs
> can be .ie 20-120MHz is typical for unfriendly architectures.
> 
> If your not in that very small club of Intel, AMD, IBM, then even full
> custom is also pretty limiting by the extreme expense of it all. The
> top tier may still be directly instantiating transistors as well as
> flops. But then transistor level design is still able to significantly
> outperform standard cell logic using a variety of mostly nmos
> differential techniques, I guess by a factor of 3. At Suns level, they
> are much closer to full standard cell with synthesis with a fraction of
> the clock of P4s but they make up for it by going to massive threading
> and latency hiding to bring out the throughput.

I think you're being overly generous to Sun here.

> Theres the clue there. The same can be done in FPGA cpu for
> multithreading architecture to simplify the design so that you are not
> limited to 32b carry ripples. In my Transputer design I was seeing
> 300MHz on the PEs because it could use 2 clocks per basic opcode and
> used 8 clocks for 4 thread instructions, alot of cycle limiting logic
> just vanishes, ie no hazard logic or register forwarding paths. The
> hardware design of the MMU hasn't started so there is nothing to
> release.

I think this is pretty much well known, although no less true.  However, 
as Amdahl put it, "What would you rather use to plow a field?  Two oxen 
or a thusand chicken?".  In your world things are of course different as 
you're coming from a paradigm of many many threads.  However the rest of 
the world is only slooowly moving to multiple threads.

It is interesting though that by giving up half the speed on single 
thread performance, you can gain 3-4 times the throughput for free. 
I'll definitely play with that.

> I am surprised that we haven't seen alot more native FPGA MTA designs
> though,.

In addition to what I mentioned, there's surely more inertia issues and 
the complication of multi-threaded software (assuming you can even take 
advantage of it).

My $0.01
Tommy

In article <442b7087$0$58081$742ec2ed@news.sonic.net>,
Tommy Thorn  <foobar@nowhere.void> wrote:
>JJ wrote:
>> I am surprised that we haven't seen alot more native FPGA MTA designs
>> though,.

>In addition to what I mentioned, there's surely more inertia issues and 
>the complication of multi-threaded software (assuming you can even take 
>advantage of it).

I've worked on FPGA based NPs.  It is a no-brainer for this case, each
packet can be treated as a separate thread.  With enough buffering it's
feasible to have 16 threads, which conveniently matches the size of Xilinx
SRL16s.  A simple micro-engine will run at 200 MHz with this technique, and
ends up being the same physical size as the single-threaded version.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

In article <442acdf6$1@usenet01.boi.hp.com>,
at) hp . com  (no spaces)" <"J o h n _ E a t o n  (at) hp . com  (no spaces <"J o h n _ E a t o n  (at) hp . com  (no spaces)"> wrote:

>And here is what we use in our coding standard

>wire [31:0] a;
>wire [31:0] b;
>reg  [32:0] result;
>reg  [32:0] next_result;

>always@(*)
>   begin
>   next_result = a + b ;
>   end

>always@(posedge clk)
>   result[32:0] <= next_result[32:0];

I've often wanted a Verilog refactoring tool which would convert between
Mealy and Moore: this is because I usually like everything to be in a single
clocked always block (much less typing, easier to read, forces you to
pipeline), but sometimes you decide later that you really need that Mealy
output...

I'm know the rules and take advantage of bug-free synthesis tools.  For
example:

always @(posedge clk)
  begin
    x <= 1; // x is a flip flop
    q = input + 3; // q is a wire
    if (condition)
      q = q + 1;
    if (other_condition)
      x <= q;
  end

This Verilog has perfectly defined behavior, but many ASIC designers can't
deal with it because of their experience with buggy tools (no mixed
block/unblocking assigns, no non-blocking assignments to the same register).
But these same designers are perfectly willing to use full_case and
parallel_case, which absolutely can cause synthesis/simulation mismatch.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Yes the networking, communications, and DSP industries are thouroughly
into the simple idea of timesharing, latency hiding etc and thats where
I have been since leaving Inmos 20yrs ago. I also use those SRL16s to
keep 4 sets of instruction fetch state over 8 clocks so that variable
length opcodes can interleave without confusion. Without those, I'd be
looking at 50% more LUTs per PE.

As a Transputer person I want as many threads as possible for a thread
pool, and these can then be effectively allocated on demand to the
concurrent language threads. Of course for idle threads, I would push
all threads onto busy PEs and shut down fully idle PEs, so power
consumption follows work done. In the Niagara case, the goals are
different, continuous threaded server loads. One thing I did realize is
that the after doing all the MTA, MMU work, any old instruction set
could be used even that damned x86 but since this is an FPGA design,
its still better to tune for that and go KISS at speed.

Its really a question of trading the single threaded Memory Wall
problem for a Thread Wall problem. A problem for single threaded C
guys, not so for the CSP people out there. Amdahls law has done more to
set back parallel computing than who knows what, if its serial, then
its serial, but there usually room to mix seq & par at many levels.
Even if a task has 2 or 3 threads, MTA still comes out ahead on
hardware cost.

The paper I gave on this Transputer design at CPA2005 last sep, is
finally available at wotug.org for anyone thats interested.


Regards

John Jakson

PS Perhaps oneday somebody out there could make a nano CC size FPGA
card but with some RLDRAM on it for a TRAM replacement.

Joseph H Allen wrote:

> I'm know the rules and take advantage of bug-free synthesis tools.  For
> example:
> always @(posedge clk)
>   begin
>     x <= 1; // x is a flip flop
>     q = input + 3; // q is a wire
>     if (condition)
>       q = q + 1;
>     if (other_condition)
>       x <= q;
>   end
> This Verilog has perfectly defined behavior, but many ASIC designers can't
> deal with it because of their experience with buggy tools (no mixed
> block/unblocking assigns, no non-blocking assignments to the same register).

Yes. This works fine.
If others don't use it, that's to your advantage.
Note if you name the block, you can declare
your wire inside it:

  always @(posedge clk)
    begin : my_block
    reg q; // q is a wire

      -- Mike Treseler