[Oberon] Fwd: Re: RISC5 implementation issues.

Wed Feb 24 19:04:51 CET 2016

 >> With this DCM configuration : clk = CLK0 = CLKIN = 50 MHZ
No, I don't think so.  I set CLKIN_DIVIDE_BY_2 to TRUE which will divide 
the input clock by 2 before it enters the DCM, and the monitor is 
syncing at 1024x768 at 70 Hz so pclk is definitely not 150 MHz.

I fund the real problem though: what you call CLK25F90 is really clk 
shifted by 270 deg, not 90 deg!

I changed the DCM code to reflect this:

DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"), .CLKIN_PERIOD(20.000))
   dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0),
       .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), 
.CLK0(clk),
       .CLK270(clk270));

ODDR2 #(.INIT(1'b1))
   oddr2(.Q(wr_enable), .C0(clk270), .C1(~clk270), .CE(1'b1), .D0(1'b1),
       .D1(~wr), .R(1'b0), .S(1'b0));

assign SRwe = wr_enable;

And with that code change it now runs fine on the Pepino board.

So I guess we have four alternatives that seems to run fine:
* The original code where clk is generated by a flip-flop
* The fully-synchronous version where everything is clocked by a 75 MHz 
clock generated by DCM
* The version using DCM where the write-enable signal is generated by a 
50 MHz clock
* The version using DCM where the write-enable signal is generated using 
a DDR output buffer

Just pick and choose ;)

Cheers,
Magnus

On 2/24/2016 5:37 AM, Walter Gallegos wrote:
> You are welcome !
>
> With this DCM configuration : clk = CLK0 = CLKIN = 50 MHZ
>
> Here my simulation using Cypress SRAM VHDL simulation model with ALDEC 
> simulator.
>
> Label : "Potential Issue", If you read the SRAM and - in the next clk 
> cycle - try to write the same SRAM data bus we could wait some ns of 
> bus contention near this point.
> If RISC5 can read then write in consecutive clk cycles the issue is 
> easy worked capturing de SRAM data with 90° clock and releasing oen soon.
>
>
>
>
> About your solution is fully synchronous it's ok considering that both 
> clocks come from same DCM.
>
> Best regards,
> Walter
>
> El 2016-02-23 a las 14:28, Magnus Karlsson escribió:
>> Since the ETH Oberon mailing list seems to delay our posts by a few 
>> days I decided to send it directly to you as well.
>>
>> Magnus
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	Re: [Oberon] RISC5 implementation issues.
>> Date: 	Tue, 23 Feb 2016 08:49:05 -0800
>> From: 	Magnus Karlsson <magnus at saanlima.com>
>> To: 	ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
>>
>>
>>
>> Walter,
>>
>> I tried your proposed solution and couldn't make it work. It "almost" 
>> works in that it starts the boot process and reads from the SD-card, 
>> but then hangs with the LEDs showing 0x84.
>> Maybe I didn't do it correct, I instantiated the ODDR2 buffer 
>> directly at the top module and modified the DCM instantiation to 
>> create the clk90 clock.
>>
>> Here is the code, can you look it over and see if this is what you 
>> had in mind or if something is wrong:
>>
>> DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"), 
>> .CLKIN_PERIOD(20.000))
>>   dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0),
>>       .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), 
>> .CLK0(clk),
>>       .CLK90(clk90));
>>
>> ODDR2 #(.INIT(1'b1))
>>   oddr2(.Q(wr_enable), .C0(clk90), .C1(~clk90), .CE(1'b1), .D0(1'b1),
>>       .D1(~wr), .R(1'b0), .S(1'b0));
>>
>> assign SRwe = wr_enable;
>>
>>
>> wr is the active-high write signal from the RISC5 CPU, and SRwe is 
>> the short active-low write-enable signal to the SRAM.
>>
>> Just to recap, this is the code I used to generate the short write 
>> pulse, using a 2x clk instead.  This version seems to run fine:
>>
>> reg wr_enable;
>>
>> DCM #(.CLKFX_MULTIPLY(3), .CLKFX_DIVIDE(2), .CLKDV_DIVIDE(2), 
>> .CLKIN_PERIOD(20.000))
>>   dcm(.CLKIN(CLK50M), .CLKFB(clk2x), .RST(1'b0), .PSEN(1'b0),
>>       .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), 
>> .CLKDV(clk), .CLK0(clk2x));
>>
>> always @(negedge clk2x)
>>   wr_enable <= wr & ~wr_enable;
>>
>> assign SRwe = ~wr_enable;
>>
>>
>> Any idea what's wrong?
>> Magnus
>>
>>
>> On 2/19/2016 9:58 AM, Walter Gallegos wrote:
>>> Let us concentrate in the problem...
>>>
>>> How to generate an output pulse shorter than clock period?
>>>
>>> You can make a pulse shorter with help of DCM and DDR ( dual data 
>>> rate output registers ) see the simulation capture
>>>
>>>
>>>
>>> clk25f90 is the DCM clock output with 90° phase shift.
>>>
>>> The VHDL code is : ( without DCM instantiation )
>>>
>>> ENTITY PulseShaper IS
>>>     PORT  (CLK25F90 :  IN STD_LOGIC;
>>>              RESET :  IN STD_LOGIC;
>>>                 WE : IN STD_LOGIC;
>>>             WESRAM : OUT STD_LOGIC
>>>          );
>>> END PulseShaper;
>>>
>>> ARCHITECTURE RTL OF PulseShaper IS
>>>
>>>    CONSTANT zero : STD_LOGIC := '0';
>>>    CONSTANT one : STD_LOGIC := '1';
>>>
>>>    SIGNAL clk90n: STD_LOGIC;
>>>
>>> BEGIN
>>>
>>>    clk90n <= NOT(CLK25F90);  -- This is valid because the tool use 
>>> the clock inverter available in IOB
>>>
>>>    Dly : ODDR2
>>>    PORT MAP (
>>>       Q => WESRAM,
>>>       C0 => CLK25F90,
>>>       C1 => clk90n,
>>>       CE => one,
>>>       D0 => one,
>>>       D1 => WE,
>>>       R => zero,
>>>       S => zero
>>>    );
>>>
>>> END RTL;
>>>
>>> Someone know if exist a FPGA testbench for RISC5 ?
>>>
>>> Regards,
>>> Walter 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160224/114af867/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12112 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160224/114af867/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6951 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160224/114af867/attachment-0003.png>