Superscalar Out-of-Order Processor on an FPGA

Xilinx block RAM is synchronous read. Is this the source of your
problem?

On Tue, 23 May 2006 00:37:22 -0700, Eric Smith wrote:

> "alpha" <zhg.liu@gmail.com> writes:
>> [I am not trying to make binary compatiable with R3000. No delay slot.
> [...]
>> [I need think about it, thanks anyway. Of course, I do not want to get
>> any trouble]
> 
> It appears that you've avoided the unaligned load/store instructions,
> which are patented.  

I'm not familiar with the MIPS architecture, but the Motorola 68020 used
unaligned load/store (e.g., reading/writing a 32-bit word to an address
that was on an odd byte boundary) operations in the early/mid '80s.  Do
you have a patent number at hand?  I'm curious as to when this was
patented and what MIPS does that makes this patentable.


    ~Dave~

Uncle Noah wrote:
> Xilinx block RAM is synchronous read. Is this the source of your
> problem?

[YES, design was based on Altera Apex chip when it got started. This is
why I need a newer altera board. Too expensive. Does anyone know if
there is any chance to borrow one form Altera ? :) ]

Dave wrote:
> On Tue, 23 May 2006 00:37:22 -0700, Eric Smith wrote:
>
> > "alpha" <zhg.liu@gmail.com> writes:
> >> [I am not trying to make binary compatiable with R3000. No delay slot.
> > [...]
> >> [I need think about it, thanks anyway. Of course, I do not want to get
> >> any trouble]
> >
> > It appears that you've avoided the unaligned load/store instructions,
> > which are patented.
>
> I'm not familiar with the MIPS architecture, but the Motorola 68020 used
> unaligned load/store (e.g., reading/writing a 32-bit word to an address
> that was on an odd byte boundary) operations in the early/mid '80s.  Do
> you have a patent number at hand?  I'm curious as to when this was
> patented and what MIPS does that makes this patentable.
>
>
>     ~Dave~

This subject of load store word alignment has been pretty well done on
c.a, google groups for John Mashey etc. He has several posts on it
since he was there. There was a recent posting by an ex Lexra guy too
who also went into the gory parts of it, Lexra was partly driven out of
business by this licencing issue.

I don't think MIPs did anything that wasn't already known about and
hadn't been done countless times before probably all the way back to
the earliest word machines. They almost admit as much, but the lawyers
I guess forced it on them and they lucked out, nobody refuted it back
then. I suspect it doesn't hurt anyone with a big enough patent
portfolio since they usually have something more important on the other
guy.

I believe the particular patent expires soon, end of the year IIRC, not
checking.

I'd ignore it since the lawyers go after money and or companies with
less patents, not experimenters. By the time they found out, they will
be on the end of their rope.

OTOH I can think of half a dozen instances of hardware software that I
have done that are essentially the same thing done in different
situations, boils down to mux demuxing of words and parts of.


I wonder if eventually when all the CRTs are gone and the FPDs only
have DVI Digital only ports, we won't be able to see anything on
homebrew cpu without the DRM. Also we are  starting to hear noise from
political idiots about hitting on programmers whose tools can be used
for hacking as well as good uses, that worries me more so.

John Jakson
transputer guy

I wrote:
> It appears that you've avoided the unaligned load/store instructions,
> which are patented.  

Dave wrote:
> I'm not familiar with the MIPS architecture, but the Motorola 68020 used
> unaligned load/store (e.g., reading/writing a 32-bit word to an address
> that was on an odd byte boundary) operations in the early/mid '80s.

Sure, and the IBM 7030 Data Processing System did it in 1961.

The point isn't that MIPS can do unaligned load and store, but HOW it
does it.  Unlike the MC68020, it doesn't happen automatically.  If
you try to use the regular load instruction with an unaligned address,
it doesn't do an unaligned load for you.

To do an unaligned load on a MIPS, you use a pair of special instructions,
one of which gets the "left" part from one word of memory, and one of
which gets the "right" part from the previous or next word of memory
(depending on the endianness).

The advantage is that there doesn't need to be a barrel shifter in
the data path used by normal loads (which might be in a critical path),
and there doesn't need to be sequencing logic for automatic unaligned
loads.

The disadvantage is that the programmer (or compiler) has to know up
front whether to expect that a load might be unaligned, and to generate
the appropriate instruction sequence.

> Do you have a patent number at hand?

No, not at hand.  Shouldn't be too hard to find it, though.

4,814,976
Hansen ,   et al.
March 21, 1989
Mips Computer Systems, Sunnyvale
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=5&f=G&l=50&co1=AND&d=PTXT&s1=unaligned.ABTX.&s2=instructions.ABTX.&OS=ABST/unaligned+AND+ABST/instructions&RS=ABST/unaligned+AND+ABST/instructions
or
http://tinyurl.com/fgjem


Easy to find this stuff, just use the search engine at uspto.gov for a 
"quick search."

Austin

Eric Smith wrote:
> I wrote:
>> It appears that you've avoided the unaligned load/store instructions,
>> which are patented.  
> 
> Dave wrote:
>> I'm not familiar with the MIPS architecture, but the Motorola 68020 used
>> unaligned load/store (e.g., reading/writing a 32-bit word to an address
>> that was on an odd byte boundary) operations in the early/mid '80s.
> 
> Sure, and the IBM 7030 Data Processing System did it in 1961.
> 
> The point isn't that MIPS can do unaligned load and store, but HOW it
> does it.  Unlike the MC68020, it doesn't happen automatically.  If
> you try to use the regular load instruction with an unaligned address,
> it doesn't do an unaligned load for you.
> 
> To do an unaligned load on a MIPS, you use a pair of special instructions,
> one of which gets the "left" part from one word of memory, and one of
> which gets the "right" part from the previous or next word of memory
> (depending on the endianness).
> 
> The advantage is that there doesn't need to be a barrel shifter in
> the data path used by normal loads (which might be in a critical path),
> and there doesn't need to be sequencing logic for automatic unaligned
> loads.
> 
> The disadvantage is that the programmer (or compiler) has to know up
> front whether to expect that a load might be unaligned, and to generate
> the appropriate instruction sequence.
> 
>> Do you have a patent number at hand?
> 
> No, not at hand.  Shouldn't be too hard to find it, though.
> 

Dave wrote:
> Do you have a patent number at hand?  I'm curious as to when this was
> patented and what MIPS does that makes this patentable.

It's the '976 patent, 4,814,976.  Lexra got the patent office to reexamine
it in 2001, suggesting that IBM's patent 3,916,388 was prior art.  But the
patent office upheld the '976 claims in 2002.

The patent application is dated December 1986, and issued in March 1989, so
it appears that it will expire this December.

AFAIK, this is the only patent on the basic 32-bit MIPS instruction set
architecture.  MIPS holds patents on various techniques used to implement
RISC processors efficiently, but it is possible to implement the MIPS
architecture without using those techniques.

MIPS also appears to have several patents that may apply to the "Thumb"
instruction set.  I haven't studied the patents or the Thumb ISA, so I'm
not certain.
	6,651,160
	6,714,197
	6,732,259
	6,826,681

Eric

alpha wrote:
> Uncle Noah wrote:
>> Xilinx block RAM is synchronous read. Is this the source of your
>> problem?
> 
> [YES, design was based on Altera Apex chip when it got started. This is
> why I need a newer altera board. Too expensive. Does anyone know if
> there is any chance to borrow one form Altera ? :) ]
> 

As far as I know, the newer Altera chips also use synchronous RAM 
blocks. (Input registers are mandatory, output registers are optional)

Henry Wong wrote:
> alpha wrote:
> > Uncle Noah wrote:
> >> Xilinx block RAM is synchronous read. Is this the source of your
> >> problem?
> >
> > [YES, design was based on Altera Apex chip when it got started. This is
> > why I need a newer altera board. Too expensive. Does anyone know if
> > there is any chance to borrow one form Altera ? :) ]
> >
>
> As far as I know, the newer Altera chips also use synchronous RAM
> blocks. (Input registers are mandatory, output registers are optional)

[YES, Xilinx's sync read give me trouble.]

Guys, Thank you all for the comment and concern on my processor.
I will rework my ISA to a totally customed one, then open source to
avoid any potential issue. My core has a very small and generic
internal instructuction set(total 16). Each of them takes 3 source
operands and one destination. Then all external instruction set will be
mapped into the internal one by hardware (note: not microcode). I can
modified the mapping logic to traget any ISA essentially (not x86). I
can post all current supported instructions if anyone is interested in
creating an ISA. My assembler is created by myself, It is easy to
change it, just software thing.

alpha wrote:

> My design is from scratch. Its instruction set is almost same as MIPS
> 3000 (without Multiplication). Lcc C compilier was ported.
> I can publish the source verilog files, do we have public domain for
> this purpose?

You could put it on opencores.org - there are quite a number of CPUs on
there (and other stuff)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C