OpenSPARC released

Looks like a parameter override. The standard specifies paranthesis around the number but I bet if only one number is used most tools accept one without a number. Is there parameter for the module "dff"?

No, the #4 matches the syntax of a delay specification. Parameter overrides alway have the ().

Delays specifications are legal between the "module" id and the instance name in an instantiation of a gate primitive or UDP, but not in a module instantiation.

dff isn't a gate primitive, so it must be a UDP. However, it seems that the standard only allows ordered parameter assignments and not named parameter assigments for UDPs.

Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it doesn't allow named parameter assignments for UDPs?

Regards, Allan

You're right. In some designs there is a weak correlation between Verilog line count and gate count. But unless you take that to an extreme, this is still quite a large design.

...

I must be missing something. Why is a named parameter assignment needed ? Isn't this an ordered parameter assignment ?

In the above code,

( .din(next_pv), .clk(clk), .q(park_vec), .se(se), .si(), .so() )

is a named parameter assignment.

An ordered parameter assignment would look more like

( next_pv, clk, park_vec, se )

Regards, Allan

Oh, you mean "named port connection" in which case you're correct. The port assignment of UDPs can only be done by order. "named parameter assignment" is something entirely different.

Uh, yes, you're right. Sorry, I copied the wrong bit out of the standard and confused myself.

Still, I don't understand why named port connection isn't allowed for a UDP.

Regards, Allan

There is no answer for that, it is very dependent on the designs and the application field. Processors and telecom chips have quite different needs for the FPGA for example.

In the telecom side usually there is enough DFFs and logic resources. And the FPGA size can be determined with the help of internal ram resources.

--Kim

I don't understand... What You mean? - Verilog is the problem (VHDL is better) or - "openSparc Verilog" is the problem (better other "soft-cpu") ?

Sandro

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.

Regards, Allan

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

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

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

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:

In article , at) hp . com (no spaces)"

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.