[Oberon] FPGA RISC byte access

[Joerg]

Wojtek

 

Here NW describes the CPU for a Harvard architecture (his RISC1).

He mentions the important detail that “adr” is stable in the second half of
the cycle and “wr” has to be ored with “clk” and that the signals are active
low!



 

And here he describes what had to be modified to cover the von Neumann
architecture (his RISC2). The speed had to be reduced to 25 MHz.



Jörg

 

From: Oberon <oberon-bounces at lists.inf.ethz.ch> On Behalf Of Joerg
Sent: Friday, December 20, 2019 2:45 PM
To: 'ETH Oberon and related systems' <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] FPGA RISC byte access

 

Hi Wojtek

I tried to just roughly dump my view of how the RISC5 CPU’s timing looks
like (qualitative not quantitative)

 



 

On every positive edge of the clk, the IR (instruction register) is latched
from codebus (=memory or cache if implemented).

Decoding and execution starts.

Above, you see the timing for a register instruction: “adr” for the next
cycle points to the next instruction.

If the Decode finds LDR/STR, “adr” for the next cycle points to the memory
location where the register is read from or written to. In other words
LDR/STR need two cycles.

If the Decode steps finds a multiplication/division, the CPU stalls itself
as it expects the Execution lasts longer than 40 ns.

 

If for some reason RISC5Top.v finds that the memory is occupied
(inbus/codebus not ready) be it as VID.v needs a memory access or a cache
has to be filled (if implemented), RISC5Top has the possibility to stall the
CPU (stallX=1)

If you don’t want to stall the RISC5, fast memory is key, so the
inbus/codebus is ready in time for the next cycle.

 

br

Jörg 

 

 

-----Original Message-----
From: Oberon <oberon-bounces at lists.inf.ethz.ch
<mailto:oberon-bounces at lists.inf.ethz.ch> > On Behalf Of Skulski, Wojciech
Sent: Friday, December 20, 2019 2:41 PM
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch
<mailto:oberon at lists.inf.ethz.ch> >
Subject: Re: [Oberon] FPGA RISC byte access

 

Joerg:

 

> You’re right. Would be nice [to have a data sheet -- WS]. Please remember:
NWs RISC5 is not the Chip itself but the microcode defining the
chip/instruction set.

 

Functionally it is a chip. Fact that it is soft does not change its
functionality. It is as real as an ASIC would have been, if someone is not
changing its Verilog.

 

>The exact timings are defined by the FPGA used and the FPGA routing SW when
it positions the logic elements in the FPGA.

 

Exact yes. Nominal no.

 

> As meanwhile the RISC5 microcode was implemented on different FPGAs, you
would have to measure the signal timings yourself for your FPGA.

 

Yes for exact, no for nominal. By "nominal" I mean the sequence of signals
issued by the RISC5 chip relative to clock. For example, the chip is issuing
a read strobe "rd". Then it expects to receive the data from memory. Nominal
specs are saying "in the same clock cycle", "next clock cycle", "two clocks
later", etc. 

 

Every chip vendor provides this kind of info, usually in a form of a
diagram. Take any data sheet for any memory chip (for example) and you will
see such diagrams. They are needed to write the interface code.

 

The PO documents describe the history of development in detail, as well as
the design decisions. But the product itself is undocumented. As a designer
of the interface logic I would like to know inputs, outputs, their polarity,
and the nominal sequencing of the in/out wires in terms of clock cycles.
This information is missing. It would be good to know in order to use this
chip in other designs.

 

W.

 

--

 <mailto:Oberon at lists.inf.ethz.ch> Oberon at lists.inf.ethz.ch mailing list for
ETH Oberon and related systems
<https://lists.inf.ethz.ch/mailman/listinfo/oberon>
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191220/79d46db4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 20038 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191220/79d46db4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 50373 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191220/79d46db4/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 61617 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191220/79d46db4/attachment-0003.jpg>