[Oberon] FPGA - Colour Support

[Jörg]

Wojtek

You’re obviously right. In my previous mail, I only spoke about the CPU speed assuming the other clocks stay the same.

For the OberonStation, RISC5Top.v looks like this:
always @(posedge clk0) clk <= ~clk;

always @(posedge clkfx) begin
  clk0 <= ~clk0 & ~clk1; clk1 <= clk0;
  pclk <= ~pclk;
end
clkfx runs at 150 MHz
pcclk runs at 75 MHz (VGA timing)
clk0 runs at 50 MHz
clk runs at 25 MHz

So, instead of dividing by 3 and then by 2 to get to clk, we would need to divide clkfx by 5.
Of course the SPI divider „tick“ needs to adopted from 63 to 75 and so on. (400 kHz = 25MHz / 63 = 30 MHz / 75)
Sorry, I forgot to mention these details.

br
Jörg

> Am 07.10.2017 um 16:23 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
>> The RISC-5 can do the memory access, the instruction decoding and register calculations 
>> in 40 ns, as it runs today at 25 MHz. If we overclock it 30 MHz it has to do the same things 
>> in 33 ns. Perhaps Magnus knows if the FPGA implementation of RISC-5 can handle this speed.
> 
> Beware: After "overclocking" the VGA signal timing will change and the monitor may have problems synchronizing. If so then the SoC video controller will need modifications. Now read the following.
> 
> Chris has run RISC5 at 50 MHz without extensive changes to the CPU code. However, the CPU ran completely embedded. It worked with the on-chip BRAM, which is several times faster than the off-chip RAM. Chris has demonstrated that the CPU can run faster even in its present form.
> 
> The FPGA Oberon is not just CPU, however. It is the whole thing with all the peripherals, including the memory controller. The modern name for such a design is System On Chip, SoC. The whole SoC can run as fast as permitted by its slowest part.
> 
> In this case the speed limit comes from the Asynchronous RAM (ASRAM) memory, whose nominal speed "10 ns" is a bit misleading. The memory chip cannot perform back-to-back read-write access. If the CPU changes the transfer direction, the RAM chip needs time to settle. This is the reason why you cannot easily ramp up the speed of the SoC in its present form. This code is running about as fast as it can. ASRAM timing is extensively discussed by Chu in his "Prototyping...." books, which should become required reading for all interested in the FPGA Oberon future. Very well written! Browsing through these books will remove the aura of mystery surrounding this technology. The info is at the end.
> 
> Some options to speed up the Oberon SoC running on the ASRAM memory are the following.
> 
> 1. Replace the "10 ns" chips with "8 ns" chips and run a little bit faster. Specifically, AS7C34096A-8TIN. These chips are not stocked at DigiKey, but may be available elsewhere. Beware of VGA timing consequences.
> 
> 2. Redesign the SoC and move the color memory to BRAM inside the FPGA. Not a very viable solution because you will need a lot of BRAM. Only high end FPGA offer enough of this resource.
> 
> 3. Follow Pong P. Chu recommendation from his SRAM memory discussion. Overclock not the whole design, but just the memory timing strobes. The strobes can run on a 5 ns grid rather than 10 ns, effectively halving the turn-around ASRAM timing. Chu does not provide a tested code, but his proposition looks solid.
> 
> 4. Replace ASRAM with ZBT RAM. This will require a new PCB. I can post the schematic. I developed the PCB layout, but I am not going to make this board "as is" because in my infinite stupidity I used the LX9 chip in gull wing footprint. A very stupid choice! But I can circulate the design if you are interested.
> 
> 5. Move the entire SoC to Pipistrello. 
> 
> 6. Choose one of the commercial boards from Digilent (Arty?) or Xilinx (expensive). 
> 
> 7. Find some other board, which would be more ideal for the project. 
> 
> 8. Wait till I release my own boards, which is limited by the amount of time I can devote to this project. 
> 
> Options 5 through 7 will require a thorough SoC redesign, which should happen eventually anyway.
> 
> In conclusion, you cannot just change the clock and obtain the same, but running faster. It is a technology, where pieces need to be consistent among themselves. Some design work is required.... 
> 
> W.
> 
> PS: Project Oberon lacks references to FPGA literature. The Project does not (should not) live in vacuum. It is a part of a lively field with rich literature. Lack of references can be misleading.
> 
> ------------ The Books -----------
> These books should become standard reference material for supporters of FPGA Oberon. I recommend having both VHDL and Verilog versions, because Verilog can be very demanding and potentially misleading in practice. VHDL offers a much safer coding style for casual FPGA programmers like myself. I do believe that the entire Oberon SoC should be converted to VHDL. I also do believe that LOLA coding with subsequent translation to Verilog has served its role and needs be retired.
> 
> Pong P. Chu, "FPGA Prototyping By Verilog Examples: Xilinx Spartan-3 Version"
> Pong P. Chu, "FPGA Prototyping By VHDL  Examples: Xilinx Spartan-3 Version"
> Pong P. Chu, "FPGA Prototyping by VHDL Examples: Xilinx Microblaze MCS Soc" (just released....)
> Pong P. Chu, "FPGA Prototyping by Verilog Examples: Xilinx MicroBlaze MCS SoCApr 3, 2018" (next year....)
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171007/201813e1/attachment.html>