OpenSPARC released

You also aren't going to get an accurate FPGA gate count after ASIC
synthesis.
If I synthesized this OpenSparc processor with DC, targetted a certain
ASIC cell library and got a count of 1 million gates for instance, that
might be resynthesized for a Virtex2 part and be 2 million gates.
Just as an example, I have no clue about these numbers except FPGA
gates will be more.

Is it not possible to use DC and target an FPGA library, say Altera's
Stratix family? I was thinking that's possible.

Or does one need to use DC FPGA?

Thanks,
Shyam

Jan Decaluwe wrote:

> 
> 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).
> 



That's what I was afraid of. Structural netlists are useful for transmitting
an intact design without revealling the "real source" code. That code is what
you need if you really want to understand or modify the design.

This is like compiling a C file into a linked assembler file and releasing
that as "open source". You can create an executable but that's about it.

Thanks but no thanks.


John Eaton

I have been playing around with opensparc some using xst. I did manage
to get a build without errors, but since I did not have a clock defined
 everything got optimized away.  So no gate counts. One thing I did
learn is to not import the files using Project Navigator. It just locks
it up.

A build using an xst script worked. There was one file that had a
function defined that was causing xst to fail. However when I removed
it I got no more complaints.

It may not be possible to synthesize with 8 cores, but I thought I saw
something in the docs about being to specify fewer cores.

I will probably play around with it some more as free time allows and
see how far I can get with it.




Shyam wrote:
> Allan Herriman wrote:
>
> > It appears openSparc Verilog is written to target an ASIC, not an
> > FPGA.  Whilst it might be possible to get it to compile and even fit
> > into an FPGA, the performance would probably not be stunning.
> >
> > In that sense, a different soft-cpu designed to be used on an FPGA
> > would probably be better.
>
> ---It's interesting to see "SoftCores for Multicore FPGA
> implementations" listed as an example research area that can be
> explored with OpenSPARC technology, at
> http://opensparc.sunsource.net/nonav/research.html. Not sure what
> area/delay/power one would end up with if this core is implemented on
> an FPGA as is. Perhaps certain enhancements/simplifications may be
> carried out to the present core in order to make it useful within an
> FPGA. Since they have released a variety of hardware/software tools
> (and their sources) I guess it becomes possible to study the
> performance impact of any architectural modifications.
>
> Has anybody already started working on implementing this on an FPGA? I
> would be very interested to know the results.I want to try to do this
> but am presently hampered because I don't have Synopsys DC (which is
> the recommended synthesis environment) appropriately set up.
> 
> Thanks,
> Shyam

J o h n _ E a t o n (at) hp . com (no spaces) wrote:
>> Why not? This would be a great teaching tool for fpga design and/or 
>> computer system design courses at college level.
> 
> Only if it can fit into an FPGA. Anybody have a gatecount?

Even if it didn't - having source to a modern commercial processor would 
still be useful - I recall someone was asking about this on the group a 
little while ago.

Jeremy

javaguy11111@gmail.com wrote:
> I have been playing around with opensparc some using xst. I did manage
> to get a build without errors, but since I did not have a clock defined
>  everything got optimized away.  So no gate counts. One thing I did
> learn is to not import the files using Project Navigator. It just locks
> it up.
>
> A build using an xst script worked. There was one file that had a
> function defined that was causing xst to fail. However when I removed
> it I got no more complaints.
>
> It may not be possible to synthesize with 8 cores, but I thought I saw
> something in the docs about being to specify fewer cores.
>
> I will probably play around with it some more as free time allows and
> see how far I can get with it.
>

OK, Thanks very much for the information. I also tried to synthesize
using Altera's Quartus II but gave up when I got many errors. Thought I
would try it out with DC first and see what I get. 

-Shyam

I got a little further into poking around with the opensparc code. I
realized that I did not have any defines enabled for any of the cores
to synthesize. I enabled 1 core and the xst sucked up all the memory my
system had and then failed for lack of memory.

So I guess if I am going to play with this anymore I need to up my
system memory from 1G to 4G memory at least.  For now I will just have
to stick to openrisc experimenting.


Shyam wrote:
> javaguy11111@gmail.com wrote:
> > I have been playing around with opensparc some using xst. I did manage
> > to get a build without errors, but since I did not have a clock defined
> >  everything got optimized away.  So no gate counts. One thing I did
> > learn is to not import the files using Project Navigator. It just locks
> > it up.
> >
> > A build using an xst script worked. There was one file that had a
> > function defined that was causing xst to fail. However when I removed
> > it I got no more complaints.
> >
> > It may not be possible to synthesize with 8 cores, but I thought I saw
> > something in the docs about being to specify fewer cores.
> >
> > I will probably play around with it some more as free time allows and
> > see how far I can get with it.
> >
>
> OK, Thanks very much for the information. I also tried to synthesize
> using Altera's Quartus II but gave up when I got many errors. Thought I
> would try it out with DC first and see what I get. 
> 
> -Shyam

In article <44285364@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:
>Jan Decaluwe wrote:

>> 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).

>That's what I was afraid of. Structural netlists are useful for transmitting
>an intact design without revealling the "real source" code. That code is what
>you need if you really want to understand or modify the design.

I've looked at the code: it's not machine generated at all.  It was actually
written in this style.  All of the logic is in 'assign' statements and all
of the flip flops are instantiated primitives.

There is an advantage to coding this way, even in FPGAs.  If you want to
hand place everything, you get no (or almost no) synthesis generated names. 
This will preserve your placement work if you need to re-synthesize.

-- 
/*  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]]);}

Joseph H Allen wrote:
> In article <44285364@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:
> 
>>Jan Decaluwe wrote:
> 
> 
>>>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).
> 
> 
>>That's what I was afraid of. Structural netlists are useful for transmitting
>>an intact design without revealling the "real source" code. That code is what
>>you need if you really want to understand or modify the design.
> 
> 
> I've looked at the code: it's not machine generated at all.  It was actually
> written in this style.  All of the logic is in 'assign' statements and all
> of the flip flops are instantiated primitives.

Note that I called it a *manually* generated technology-independent
netlist.

> There is an advantage to coding this way, even in FPGAs.  If you want to
> hand place everything, you get no (or almost no) synthesis generated names. 
> This will preserve your placement work if you need to re-synthesize.

That sounds like a weak argument to me. Hand place everything?
With the complexity of today's and future FPGAs, I believe there's
little choice but assuming that synthesis and layout tools work fine -
they should by now.

Even if there would be real advantage to that coding style (I don't
know it), the price you pay is very large: unmaintainable, unreadable
code which is probably an order of magnitude larger than proper RTL.
And again, better code may well synthesize better and therefore
be easier to layout :-)

Jan

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

In article <44299C60.5030105@jandecaluwe.com>,
Jan Decaluwe  <jan@jandecaluwe.com> wrote:
>Joseph H Allen wrote:

>> I've looked at the code: it's not machine generated at all.  It was actually
>> written in this style.  All of the logic is in 'assign' statements and all
>> of the flip flops are instantiated primitives.

>Note that I called it a *manually* generated technology-independent
>netlist.

>> There is an advantage to coding this way, even in FPGAs.  If you want to
>> hand place everything, you get no (or almost no) synthesis generated names. 
>> This will preserve your placement work if you need to re-synthesize.

>That sounds like a weak argument to me. Hand place everything?
>With the complexity of today's and future FPGAs, I believe there's
>little choice but assuming that synthesis and layout tools work fine -
>they should by now.

>Even if there would be real advantage to that coding style (I don't
>know it), the price you pay is very large: unmaintainable, unreadable
>code which is probably an order of magnitude larger than proper RTL.
>And again, better code may well synthesize better and therefore
>be easier to layout :-)

Well they might not have any choice but hand placement for high performance
CPUs, but I don't really know.  I've not had to opportunity to make a
multi-GHz design.  Otherwise I agree with, especially about FPGAs.  I did
one hand placed design in Virtex-E: 175 MHz (with hand made DDR macros). 
But it was very simple.  However, bad things did happen when you changed
versions of the synthesis tools.  Synplicity frequently likes to change how
their machine generated names are generated.

For anything more complicated, the tools are better than hand hand-placed,
and the benefits of having clean verilog obviously are going to outweigh any
imagined gain, so I basically agree with you.

Anyway, I've been trying to figure out if this SPARC is superscalor or not.
It does not appear to have any dataflow management logic and the main
register file is only 5 ports, so I suspect not.  Also, I've heard that the
real high performance chips use latches and dynamic logic.  I've always
wondered how this showed up in RTL, but this chip appears to only use plain
old d-flip flops.  It's cool to look at the floating point unit.

-- 
/*  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]]);}