OpenSPARC released

J o h n _ E a t o n (at) hp . com (no spaces) wrote:
> Michael wrote:
> 
>> Weng Tianxiang wrote:
>>
>>> Hi Pablo,
>>> Thank you for your useful information.
>>>
>>> Weng
>>
>>
>>
>> The problem is "System Requirements": "SPARC CPU based system"
>>
> 
> Is that for the software development environment?. Seems like the
> verilog rtl code should be pretty generic. From the description it
> sounds more like a big compute farm engine rather than something
> you would put in a fpga for an embedded system.
> 
> 
> 
> John Eaton

Why not? This would be a great teaching tool for fpga design and/or 
computer system design courses at college level.

~jz

Jason Zheng wrote:
> J o h n _ E a t o n (at) hp . com (no spaces) wrote:
> 
>> Michael wrote:
>>
>>> Weng Tianxiang wrote:
>>>
>>>> Hi Pablo,
>>>> Thank you for your useful information.
>>>>
>>>> Weng
>>>
>>>
>>>
>>>
>>> The problem is "System Requirements": "SPARC CPU based system"
>>>
>>
>> Is that for the software development environment?. Seems like the
>> verilog rtl code should be pretty generic. From the description it
>> sounds more like a big compute farm engine rather than something
>> you would put in a fpga for an embedded system.
>>
>>
>>
>> John Eaton
> 
> 
> Why not? This would be a great teaching tool for fpga design and/or 
> computer system design courses at college level.
> 
> ~jz


Only if it can fit into an FPGA. Anybody have a gatecount?

John Eaton

Personally I think the best textbook on logic design is AMD
PAL Device Handbook. All my logic training was based on the book, read
by myself, not taught at any classes.

I bought 5 VHDL books, but only the AMD book really teaches me how to
program in logic.

The open CPU source code is an excellent contributions to the
generations of logic designers by Sun Microsystem.

It would be much wonderful If there is an retired engineer from Sun who
deeply invovled in the code making writes a book with the opened source
code. It would be more valuable than any Verilog books available in the
market.

Teaching by example is the best way to teach a language and related
technique.

Real design examples give you really deep insights on what the
designers were thinking about and how nicely they handle the difficult
situations.

I appreciate Sun's efforts to open its source code.

Thank you, Sun Microsystem.

Weng

The source comes with scripts for Design Compiler. I guess they want
you to use that tool; which is for targetting ASICs.

Oh, and I don't have a gate count but the design is quite large:

[gliss@precision design]$ find ~/opensparc/design -name "*.v" -exec cat
{} \; | wc -l
 323957

There are over 320,000 lines of Verilog and the support scripts are
built for a DC ASIC synthesis environment... good luck getting that to
fit in an FPGA.

Chris,

Brings up a question for the group:  how many lines of verilog can you 
fit in any given FPGA?

Anyone out there in the ASIC emulation world care to comment?

Being a 'hardware' type, I am just ignorant...

Austin

chrisbw@gmail.com wrote:

> Oh, and I don't have a gate count but the design is quite large:
> 
> [gliss@precision design]$ find ~/opensparc/design -name "*.v" -exec cat
> {} \; | wc -l
>  323957
> 
> There are over 320,000 lines of Verilog and the support scripts are
> built for a DC ASIC synthesis environment... good luck getting that to
> fit in an FPGA.
> 

Austin Lesea wrote:
> Chris,
> 
> Brings up a question for the group:  how many lines of verilog can you 
> fit in any given FPGA?

It's a meaningless question without considering the exact nature of
the Verilog code.

For example, a complex control FSM described in several pages of
code may require less than 100 gates. On the other hand, a simple
(but wide) flip-flop intensive data path, described in a few lines,
may require 10000 gates or more.

As for the SPARC code, it seems like an extreme example. I wouldn't
call this RTL code. It's more like a manually generated technology-
independent netlist. For example, they don't even use flip-flop
inference. And they do have excessive hierarchy.

I suspect that it should be possible to gain at least an order
of magnitude in terms of lines of code by using a proper RTL
style. And the synthesis results might be better. (Excessive
hierarchy tends to yield suboptimal synthesis results).

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Jan,

OK, that makes sense.  I had thought the "law of large numbers" would 
take over with enough code, but if this code is handcrafted for ASIC 
cell applications (with extremely primitive cells), then it would 
synthesize very poorly for anything but that application.

Austin

Jan Decaluwe wrote:

> Austin Lesea wrote:
> 
>> Chris,
>>
>> Brings up a question for the group:  how many lines of verilog can you 
>> fit in any given FPGA?
> 
> 
> It's a meaningless question without considering the exact nature of
> the Verilog code.
> 
> For example, a complex control FSM described in several pages of
> code may require less than 100 gates. On the other hand, a simple
> (but wide) flip-flop intensive data path, described in a few lines,
> may require 10000 gates or more.
> 
> As for the SPARC code, it seems like an extreme example. I wouldn't
> call this RTL code. It's more like a manually generated technology-
> independent netlist. For example, they don't even use flip-flop
> inference. And they do have excessive hierarchy.
> 
> I suspect that it should be possible to gain at least an order
> of magnitude in terms of lines of code by using a proper RTL
> style. And the synthesis results might be better. (Excessive
> hierarchy tends to yield suboptimal synthesis results).
> 
> Regards,
> 
> Jan
> 

I found this in  design/sys/iop/sparc/ifu/rtl/sparc_ifu_rndrob.v

   ....
   assign  next_pv[0] = pv[0] | reset;

   dff #4  park_reg(.din  (next_pv),
      .clk  (clk),
      .q    (park_vec),
      .se   (se), .si(), .so());

   ....

I don't see how the #4 is legal is Verilog 2001.
Can someone explain to me under what it means,
and under what circumstances this is legal?
Is this construct part of Verilog 2001, or is it vendor specific?

-- IDB

Plain ol' verilog udp?