[Oberon] FPGA RISC byte access

[Skulski, Wojciech]

Joerg:

  thank you for the info. RISC.pdf is of course very interesting, but it does not replace the data sheet. It rather describes the internal working of the processor which is may be of interest to an EE student attending the processor architecture class. But I am designing a board. I want to connect wires to a memory chip and deliver signals in the order and time explained in the memory chip data sheet. (Here is the name of the chip: IS61NLP102418B-200B3L.)  For this I need to know the time sequence, polarity, and nominal duration of the signals emitted by the processor. I do not need to know WHY the processor emits these signals. I need to know WHAT and WHEN it is emitting rather than WHY. Ditto for the input signals: WHAT and WHEN. Neither the PO.Computer nor RISC.pdf can substitute for lack of the signal timing diagrams which are missing. (The example diagram from RISC.pdf page 20 is not the same as the signal timing.)

I attached the timing requirements for this chip (pages 19 1nd 20 from 61NLP_NVP102418B_51236B.pdf). Every chip vendor is providing such diagrams. The data sheet also shows the internal chip diagram on page 2, which is interesting but not very relevant. They could as well omit the internal block diagram. The sequence of pulses is everything what the designer needs to know.

So we need something like these diagrams. In principle it should be possible to extract this information from the RISC5 Verilog code. In most HDL designs the nominal signal sequencing is usually produced by state machines. This concept is explained in the NW textbook on digital circuit design. Another good reference is the Xilinx ISE help available in the ISE environment.

A quick look at the RISC5 code reveals that the state machines seem not be present in this code. I cannot locate the state machine design pattern or the state variable definition.  I am also puzzled not seeing the output signals being assigned their values inside the clocked process at the end.

So this design is quite interesting. Most of the RISC5 code is combinational, while the clocked portion consists of only twelve lines at the end. Most other HDL code which I have seen tends to be the opposite. 

Thanks,
Wojtek

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Joerg [joerg.straube at iaeth.ch]
Sent: Friday, December 20, 2019 10:08 AM
To: 'ETH Oberon and related systems'
Subject: Re: [Oberon] FPGA RISC byte access

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!
[cid:image001.jpg at 01D5B74F.C92EE210]

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.
[cid:image002.jpg at 01D5B74F.C92EE210]
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)



[cid:image004.png at 01D5B74E.026F2C30]



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.



--

Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwMFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=QqtCiX3Fvk5f-xiNtevzwfzpcq_PkrO-jn5m9qB9orE&s=za7ELz140lxdpo2aC0VcMIn2gIzb-pUFb8cZojBbbow&e=>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Read_cycle_diagram.png
Type: image/png
Size: 155451 bytes
Desc: Read_cycle_diagram.png
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191222/80e84fb8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Write_cycle_diagram.png
Type: image/png
Size: 162833 bytes
Desc: Write_cycle_diagram.png
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191222/80e84fb8/attachment-0003.png>