Hi Wojtek,

trying to [understand the hardware description] I am now puzzled with the individual byte access logic in RISC5 and RISC5top

See also "5.3. Implementing byte-access (RISC-3)" in "The Design of a RISC Architecture and its Implementation with an FPGA": https://people.inf.ethz.ch/wirth/FPGA-relatedWork/RISC.pdf HTH, Paul

Wojtek assign ben = p & ~q & v & ~stallX & ~stallL1; // byte enable If you look at above statement, this boils down to "ben = v". But "byte enable" is only valid for memory instructions (format F2: p=1, q=0) and the memory is not used by video (=stallX) and is in the correct cycle of LDR/STR (stallL1) br Jörg -----Original Message----- From: Oberon <oberon-bounces@lists.inf.ethz.ch> On Behalf Of Skulski, Wojciech Sent: Thursday, December 19, 2019 5:07 PM To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch> Subject: Re: [Oberon] FPGA RISC byte access Paul: thank you for the pointer! Yes, I did look at RISC.pdf before sending the e-mail. Section 3.5 says the following, quoted verbatim: "The only addition to the processor interface is the signal ben (byte enable) derived from the modifier bit v in memory instructions." The words "active high" are missing here too. "Derived from" can mean anything. Also, in the RISC5 ben was derived from p an q, not from v. So it is less than clear how this paper refers to RISC5. Thank you, Wojtek -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

Wojtek You’re right. Would be nice. Please remember: NWs RISC5 is not the Chip itself but the microcode defining the chip/instruction set. The exact timings are defined by the FPGA used and the FPGA routing SW when it positions the logic elements in the FPGA. As meanwhile the RISC5 microcode was implemented on different FPGAs, you would have to measure the signal timings yourself for your FPGA. br Jörg

Am 20.12.2019 um 05:51 schrieb Skulski, Wojciech <skulski@pas.rochester.edu>:

Joerg:

thank you!

RISC5, being a chip, would benefit from a data sheet. We worked for quite a while on interfacing RISC5 to the ZBT memory. This task would have been much easier if we knew the signal waveforms. I mean, what is the time relation between the strobes, addresses, and data, plotted against the clock. I know that setup and hold times will depend on the FPGA technology, so these may be hard to specify. But the basic time structure is determined by the RISC5 design. All chip vendors provide this kind of information for all their products.

The fact that even the polarities were not mentioned is just the tip of the iceberg. It is difficult to interface RISC5 with other components without knowing when the CPU is issuing the signals. Writing firmware without having this information is unnecessarily tough indeed.

Thanks you again, Wojtek ________________________________________ From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Joerg [joerg.straube@iaeth.ch] Sent: Thursday, December 19, 2019 12:10 PM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] FPGA RISC byte access

Wojtek

assign ben = p & ~q & v & ~stallX & ~stallL1; // byte enable

If you look at above statement, this boils down to "ben = v". But "byte enable" is only valid for memory instructions (format F2: p=1, q=0) and the memory is not used by video (=stallX) and is in the correct cycle of LDR/STR (stallL1)

br Jörg

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

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@lists.inf.ethz.ch> On Behalf Of Skulski, Wojciech Sent: Friday, December 20, 2019 2:41 PM To: ETH Oberon and related systems <oberon@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@lists.inf.ethz.ch> Oberon@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

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@lists.inf.ethz.ch] on behalf of Joerg [joerg.straube@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@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@01D5B74F.C92EE210] Jörg From: Oberon <oberon-bounces@lists.inf.ethz.ch> On Behalf Of Joerg Sent: Friday, December 20, 2019 2:45 PM To: 'ETH Oberon and related systems' <oberon@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@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@lists.inf.ethz.ch<mailto:oberon-bounces@lists.inf.ethz.ch>> On Behalf Of Skulski, Wojciech Sent: Friday, December 20, 2019 2:41 PM To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch<mailto:oberon@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@lists.inf.ethz.ch<mailto:Oberon@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=>

Paul: thank you for the note. I am facing a practical problem that I would like to use RISC5 and the rest of the FPGA Oberon System in practical situations. The limitation that it only works well with asynch RAM is a serious one. I wonder how easy it will be to convert RISC5 to a synchronous design. FYI, I am not sure if the present design works well with Pepino whose idea is almost the same as the original Spartan-3 board. It is the same memory connected to Spartan-6 rather than Spartan-3. I noticed that Oberon System frequently freezes on one Pepino which we have. I have not identified any pattern. Sometimes it works for days, and sometimes if freezes after a mouse click on a command like the Hilbert curve. I suspect a timing violation. Reengineering the CPU may help solve this problem. Thank you, Wojtek ________________________________________ From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Paul Reed [paulreed@paddedcell.com] Sent: Sunday, December 22, 2019 8:56 AM To: ETH Oberon and related systems Subject: [Oberon] FPGA RISC memory interfacing Hi Wojtek,

I want to connect ... to a memory chip ... IS61NLP102418B-200B3L. ... A quick look at the RISC5 code reveals that the state machines seem not be present in this code...So this design is quite interesting. Most of the RISC5 code is combinational...

Right, it's not a pipelined design. Also I think the intention is to explain its operation for a general audience, not for an electronics designer. Nevertheless it's pretty clear, certainly in comparison with most other designs out there. To see the effects of the combinational choice, you would need to do some more realistic simulation, e.g. post-synthesis, rather than just simulating the Verilog source, to see the effects of the actual delays in the real hardware, which are very significant. That ISSI synchronous memory chip would probably work better with a pipelined design like RISC-V. Prof. Wirth's RISC works well with asynchronous SRAM, as has already been discussed. HTH, Paul -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=Tx1UGPz8TogpRpOqG-9jGkA3iFSBaqq7bUaiszGBduo&s=ZRwIF_d5DOwFVue2jVfQBR55gFRovceVGTkKJveSuxw&e=

Magnus:

It could be something wrong with that board. You can send it back for a replacement board if this is a recurring problem.

After a few hours the System is still running on Pepino. Sierpinski.Draw looks good. Hilbert.Draw is outputting pieces all over the screen. I will have to look a bit deeper because the SD passed through many hands. I doubt anyone changed the SW, but who knows. I will order the new Pepino anyway. I am puzzled with your comment on github "Backing out the changes to make is synchronous". Does it mean that you tried to add proper clocking to the Verlilog design and you resigned from doing so? I now tend to believe that all RISC5 files need to be made synchronous. Any comment? Thank you, Wojtek