-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Jörg Sent: Tuesday, 16 February 2016 8:30 PM To: 'ETH Oberon and related systems' Subject: Re: [Oberon] FPGA-related Project Oberon Customizations

Hi

One idea to adopt the RISC5 to a RISC6 is to enlarge the addressable memory from 1MB to 2MB.

Better than this (i.e. 16MB) is already possible for RISC5. This has been available since last September as announced in the Oberon News: "Address bus width changed from 20 to 24" https://www.inf.ethz.ch/personal/wirth/news.txt Regards, Chris Chris Burrows CFB Software http://www.astrobe.com

How much of your I2C source can be easily ported to X86 & ARM ? It would be nice if the top-level was common, and only the bottom-level was specific to different CPU families. I'd like to test & use I2C on both x86 & ARM. == Chris Glur. ------------------------------------------------------------ Chris Burrows wrote:--- An I2C interface is moving closer to the top of my list of things to do. However, if somebody else beats me to it I won't complain :) This will open up connectivity to a wide range of peripheral devices e.g. accelerometers, EEPROMs, digital compasses, DACs, distance, gesture, altitude, temperature, barometric pressure and humidity sensors etc. etc. for use with embedded RISC5 target systems. We have already written driver software and simple examples of their use for a number of these devices in Oberon-07 for ARM Cortex-M3 and M4 microcontrollers.

As a professor I teach Programmable Logic at Universidad Tecnologica Nacional, Cordoba, Argentina, encouraging Synchronous Design for FGPAs. It is really useful your suggestions for corrections to the design of RISC5. I wonder if you or someone else have a VHDL version of RISC5, because we use VHDL in classes and it could be useful to use it as an application example. It could be useful a recipe version of your suggestion for reimplementing RISC5 in the Verilog version. I'm always been considering Wirth's LoLa as a tool but I could not use it in classes right now. And for Verilog, it was not chosen for the Digital Basics Courses and that's why we continue in our course with VHDL, that we consider more convenient for teaching. Sincerely yours, Pablo Cayuela On Tue, Feb 16, 2016 at 2:22 PM, Walter Gallegos <walter@waltergallegos.com> wrote:

I've waited long time before post this topic because could be misunderstood, believe me this is a positive post. Try to address a methodology issue in RISC 5 implementation.

The gold rule is "FPGA design must be synchronous". Have a clock do not means synchronous.

Building the hardware from Verilog description.

DCM_SP #( .CLK_FEEDBACK("NONE"), .CLKDV_DIVIDE(2.0), .CLKFX_DIVIDE(2), .CLKFX_MULTIPLY(5), .CLKIN_DIVIDE_BY_2("FALSE"), .CLKIN_PERIOD(16.667), .CLKOUT_PHASE_SHIFT("NONE"), .DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"), .DFS_FREQUENCY_MODE("LOW"), .DLL_FREQUENCY_MODE("LOW"), .DUTY_CYCLE_CORRECTION("TRUE"), .FACTORY_JF(16'hC080), .PHASE_SHIFT(0), .STARTUP_WAIT("FALSE") ) dcm ( .CLKIN(OSCIN), .CLKFX(clkfx), .CLKFB(1'b0), .RST(1'b0), .DSSEN(1'b0), .PSCLK(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0), .CLKDV(), .CLKFX180(), .CLK0(), .CLK2X(), .CLK2X180(), .CLK90(), .CLK180(), .CLK270(), .LOCKED(), .PSDONE(), .STATUS());

This implement a DCM with OSCIN as input clock to generate clkfx; for DCMs the XILINX recommend some period in reset with CLKIN active and stable. Work yes, recommended no. Is also a good practice rebuild the input clock with the DCM and not only generate a new one.

always @(posedge clkfx) begin clk0 <= ~clk0 & ~clk1; This implement a FF feeback = not clk0 and not clk1. clk1 <= clk0; clk1 is also another FF taking clk0 as data. pclk <= ~pclk; pclk is a FF feedback Q in D end

Please note, clk0, clk1 and pclk are not aligned, they are different FF with different placement and routing. If used as clock, this one of the worst cases, edges are closed, not the same, routed into uncontrolled skew general propose routing resources, don't forget of metastability.

Next,

always @(posedge clk0) clk <= ~clk;

"posedge" force the implementation tool to use the clock edge detection available in each FPGA FF; so, this sentence force the tool to connect a general purpose interconnection network as FF output is to the clock distribution tree.

And again a signal ( not a clock in the FPGA world ) is used as clock.

always @(posedge clk) .... end

There are also another hidden problem, the RISC clock clk, that was generated in the logic farm, is not aligned with clkfx by a variable unknown delay. This delay depend of several factor as temperature, power supply voltage and implementation run, that means in two implementation runs of same code as the tool could select different placement and routing could result in different delays.

The correct way to handle clock is with a clock manager; I strong recommend avoid clock dividers in logic. The challenge is select a correct oscillator and/or the appropriate multiply divide parameters.

And after correct this problems don't forget to modify :

assign SRwe0 = ~wr | clk, SRwe1 = SRwe0;

Here clk is used as signal, so if clk is a clock must not be connected to a LUT input.

Regards,

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

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

Walter, be careful here. The code you list is specific to OberonStation, it does not look like this on the original Digilent Spartan3 board nor on Pepino. This is the (somewhat messy) way OberonStation creates the 25 MHz CPU clock and the 75 MHz pixel clock for a 60 MHz input clock. Both the Digilent board and Pepino uses a 50 MHz input clock and the clock generation code is much simpler and looks like this: 25 MHz CPU clock (clk) is created by dividing the input clock by 2: /always @ (posedge CLK50M) clk <= ~clk;/ 75 MHz Pixel clock (pclk) is generated by multiplying the CPU clock by 3 using a DCM: /DCM #(.CLKFX_MULTIPLY(3), .CLK_FEEDBACK("NONE"), .CLKIN_PERIOD(40.000))// // dcm(.CLKIN(clk), .CLKFB(1'b0), .RST(1'b0), .PSEN(1'b0),// // .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk));/ Magnus On 2/16/2016 9:22 AM, Walter Gallegos wrote:

I've waited long time before post this topic because could be misunderstood, believe me this is a positive post. Try to address a methodology issue in RISC 5 implementation.

The gold rule is "FPGA design must be synchronous". Have a clock do not means synchronous.

Building the hardware from Verilog description.

DCM_SP #( .CLK_FEEDBACK("NONE"), .CLKDV_DIVIDE(2.0), .CLKFX_DIVIDE(2), .CLKFX_MULTIPLY(5), .CLKIN_DIVIDE_BY_2("FALSE"), .CLKIN_PERIOD(16.667), .CLKOUT_PHASE_SHIFT("NONE"), .DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"), .DFS_FREQUENCY_MODE("LOW"), .DLL_FREQUENCY_MODE("LOW"), .DUTY_CYCLE_CORRECTION("TRUE"), .FACTORY_JF(16'hC080), .PHASE_SHIFT(0), .STARTUP_WAIT("FALSE") ) dcm ( .CLKIN(OSCIN), .CLKFX(clkfx), .CLKFB(1'b0), .RST(1'b0), .DSSEN(1'b0), .PSCLK(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0), .CLKDV(), .CLKFX180(), .CLK0(), .CLK2X(), .CLK2X180(), .CLK90(), .CLK180(), .CLK270(), .LOCKED(), .PSDONE(), .STATUS());

This implement a DCM with OSCIN as input clock to generate clkfx; for DCMs the XILINX recommend some period in reset with CLKIN active and stable. Work yes, recommended no. Is also a good practice rebuild the input clock with the DCM and not only generate a new one.

always @(posedge clkfx) begin clk0 <= ~clk0 & ~clk1; This implement a FF feeback = not clk0 and not clk1. clk1 <= clk0; clk1 is also another FF taking clk0 as data. pclk <= ~pclk; pclk is a FF feedback Q in D end

Please note, clk0, clk1 and pclk are not aligned, they are different FF with different placement and routing. If used as clock, this one of the worst cases, edges are closed, not the same, routed into uncontrolled skew general propose routing resources, don't forget of metastability.

Next,

always @(posedge clk0) clk <= ~clk;

"posedge" force the implementation tool to use the clock edge detection available in each FPGA FF; so, this sentence force the tool to connect a general purpose interconnection network as FF output is to the clock distribution tree.

And again a signal ( not a clock in the FPGA world ) is used as clock.

always @(posedge clk) .... end

There are also another hidden problem, the RISC clock clk, that was generated in the logic farm, is not aligned with clkfx by a variable unknown delay. This delay depend of several factor as temperature, power supply voltage and implementation run, that means in two implementation runs of same code as the tool could select different placement and routing could result in different delays.

The correct way to handle clock is with a clock manager; I strong recommend avoid clock dividers in logic. The challenge is select a correct oscillator and/or the appropriate multiply divide parameters.

And after correct this problems don't forget to modify :

assign SRwe0 = ~wr | clk, SRwe1 = SRwe0;

Here clk is used as signal, so if clk is a clock must not be connected to a LUT input.

Regards,

On 2/16/2016 11:52 AM, Walter Gallegos wrote:

Magnus,

/always @ (posedge CLK50M) clk <= ~clk;

/This is also a bad practice. clk edge are not aligned with CLK50M in a uncontrolled fashion. So, this is a kind of asynchronism for the rest of FPGA.

Walter

No, not bad practice at all! The input signal CLK50M is only used in one place and that is to create the signal clk. The signal clk does not need to be aligned with CLK50M in any fashion since it's never used by any logic clocked by CLK50M. If you believe there is a problem here then point us to the line in the code where this problem exist. Magnus

repost El 2016-02-16 a las 18:27, Walter Gallegos escribió:

Magnus,

The correct technique to solve this is use a DCM with 50MHZ connected to CLKIN, connect clk to CLKDIV and pclk to CLKFX. Setting the divider to 2 and M/D to 3/2. Is the same DCM used to generate the pixel clock, so have no sense use a "bad practice" solution when the correct is used in the project.

Regards, Walter

El 2016-02-16 a las 16:52, Walter Gallegos escribió:

...

Magnus,

/always @ (posedge CLK50M) clk <= ~clk;

/This is also a bad practice. clk edge are not aligned with CLK50M in a uncontrolled fashion. So, this is a kind of asynchronism for the rest of FPGA.

Walter

El 2016-02-16 a las 15:14, Magnus Karlsson escribió:

...

Walter, be careful here. The code you list is specific to OberonStation, it does not look like this on the original Digilent Spartan3 board nor on Pepino. This is the (somewhat messy) way OberonStation creates the 25 MHz CPU clock and the 75 MHz pixel clock for a 60 MHz input clock.

Both the Digilent board and Pepino uses a 50 MHz input clock and the clock generation code is much simpler and looks like this:

25 MHz CPU clock (clk) is created by dividing the input clock by 2: /always @ (posedge CLK50M) clk <= ~clk;/

75 MHz Pixel clock (pclk) is generated by multiplying the CPU clock by 3 using a DCM: /DCM #(.CLKFX_MULTIPLY(3), .CLK_FEEDBACK("NONE"), .CLKIN_PERIOD(40.000))// // dcm(.CLKIN(clk), .CLKFB(1'b0), .RST(1'b0), .PSEN(1'b0),// // .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk));/

Magnus

On 2/16/2016 9:22 AM, Walter Gallegos wrote:

...

I've waited long time before post this topic because could be misunderstood, believe me this is a positive post. Try to address a methodology issue in RISC 5 implementation.

The gold rule is "FPGA design must be synchronous". Have a clock do not means synchronous.

Building the hardware from Verilog description.

DCM_SP #( .CLK_FEEDBACK("NONE"), .CLKDV_DIVIDE(2.0), .CLKFX_DIVIDE(2), .CLKFX_MULTIPLY(5), .CLKIN_DIVIDE_BY_2("FALSE"), .CLKIN_PERIOD(16.667), .CLKOUT_PHASE_SHIFT("NONE"), .DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"), .DFS_FREQUENCY_MODE("LOW"), .DLL_FREQUENCY_MODE("LOW"), .DUTY_CYCLE_CORRECTION("TRUE"), .FACTORY_JF(16'hC080), .PHASE_SHIFT(0), .STARTUP_WAIT("FALSE") ) dcm ( .CLKIN(OSCIN), .CLKFX(clkfx), .CLKFB(1'b0), .RST(1'b0), .DSSEN(1'b0), .PSCLK(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0), .CLKDV(), .CLKFX180(), .CLK0(), .CLK2X(), .CLK2X180(), .CLK90(), .CLK180(), .CLK270(), .LOCKED(), .PSDONE(), .STATUS());

This implement a DCM with OSCIN as input clock to generate clkfx; for DCMs the XILINX recommend some period in reset with CLKIN active and stable. Work yes, recommended no. Is also a good practice rebuild the input clock with the DCM and not only generate a new one.

always @(posedge clkfx) begin clk0 <= ~clk0 & ~clk1; This implement a FF feeback = not clk0 and not clk1. clk1 <= clk0; clk1 is also another FF taking clk0 as data. pclk <= ~pclk; pclk is a FF feedback Q in D end

Please note, clk0, clk1 and pclk are not aligned, they are different FF with different placement and routing. If used as clock, this one of the worst cases, edges are closed, not the same, routed into uncontrolled skew general propose routing resources, don't forget of metastability.

Next,

always @(posedge clk0) clk <= ~clk;

"posedge" force the implementation tool to use the clock edge detection available in each FPGA FF; so, this sentence force the tool to connect a general purpose interconnection network as FF output is to the clock distribution tree.

And again a signal ( not a clock in the FPGA world ) is used as clock.

always @(posedge clk) .... end

There are also another hidden problem, the RISC clock clk, that was generated in the logic farm, is not aligned with clkfx by a variable unknown delay. This delay depend of several factor as temperature, power supply voltage and implementation run, that means in two implementation runs of same code as the tool could select different placement and routing could result in different delays.

The correct way to handle clock is with a clock manager; I strong recommend avoid clock dividers in logic. The challenge is select a correct oscillator and/or the appropriate multiply divide parameters.

And after correct this problems don't forget to modify :

assign SRwe0 = ~wr | clk, SRwe1 = SRwe0;

Here clk is used as signal, so if clk is a clock must not be connected to a LUT input.

Regards,

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

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

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

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88 El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

Magnus "This logic signal /clk/ is then connected to a clock buffer BUFG that will feed one of the global clock nets" My apologies, clk routing is : The logic clk signal -using general propose routing lines and connection matrix- is connected to a clock buffer to be able to be connected to FF edge detectors. This is the only way that the tool can address the HDL definition. So, RISC5 use general propose resources to routing a clock signal. Walter. El 2016-02-16 a las 16:06, Magnus Karlsson escribió:

On 2/16/2016 9:22 AM, Walter Gallegos wrote:

...

always @(posedge clk0) clk <= ~clk;

"posedge" force the implementation tool to use the clock edge detection available in each FPGA FF; so, this sentence force the tool to connect a general purpose interconnection network as FF output is to the clock distribution tree.

And again a signal ( not a clock in the FPGA world ) is used as clock.

always @(posedge clk) .... end

No, this is not the way it works. The tool is smart enough to understand what you really mean and will instantiate the appropriate modules as needed.

In the Pepino case, this is how the clock path looks like (as evident by looking at the fully routed design in Xilinx FPGA Editor): The CPU clock signal clk is created by a flip-flop that divides the input clock CLK50M by 2. This logic signal /clk/ is then connected to a clock buffer BUFG that will feed one of the global clock nets. The global clock signal is called /clk_BUFG/ and is used every where you use it as a clock in the code, as in the /always @(posedge clk)/ statement.

...

And after correct this problems don't forget to modify :

assign SRwe0 = ~wr | clk, SRwe1 = SRwe0;

Here clk is used as signal, so if clk is a clock must not be connected to a LUT input.

Again, not a problem. The tool is smart enough to understand that when you use the signal clk as a logic signal it will use the non-buffered signal /clk/ and not the buffered signal /clk_BUFG/.

Magnus

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

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88 El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

On 2/16/2016 12:33 PM, Magnus Karlsson wrote:

On 2/16/2016 11:37 AM, Walter Gallegos wrote:

...

Magnus

"This logic signal /clk/ is then connected to a clock buffer BUFG that will feed one of the global clock nets"

My apologies, clk routing is :

The logic clk signal -using general propose routing lines and connection matrix- is connected to a clock buffer to be able to be connected to FF edge detectors. This is the only way that the tool can address the HDL definition.

So, RISC5 use general propose resources to routing a clock signal.

Walter.

There is absolutely nothing wrong with generating a clock signal like this. Yes, the output from the flip-flop is routed using general routing resources, there is no other option. But after it's sent through the BUFG it's a perfectly legit clock signal.

I have created a small project to demonstrate this, it's available on GitHub and it will only take ISE a few seconds to generated a bit file. *ISE will go through this project without a single warning being generated.* Anyone with ISE experience will tell you that it will generate warning for every little detail it will find questionable.

The project is available here: https://github.com/Saanlima/Pepino/tree/master/Projects/Pepino_clktest

Magnus

This can of course also be done using dedicated clocking resources like a DCM or a PLL instead of just a simple flip-flip, and I guess Paul Reed is the correct person to defend why it was done like this but I have a pretty good hunch why. The SRAM interface is asynchronous in nature and care must be taken so that the timing of the write signal is such that it prevents accidental writes to other memory locations during a write cycle. If all the signals controlling the SRAM (like address, chip enable, read, write, and output enable) are generated synchronously using the CPU clock then the timing of the write signal relative to the other control signals are uncertain and can vary depending on the routing of the chip. By gating the write signal with the "early" version of the clk signal (i.e. the clk version of the signal, not the clk_BUFG version) which is guaranteed to lead the clk_BUFG signal by the delay caused by the buffer, then the write signal to the memory is guaranteed to be removed before the other signals can change. If the clk signal is generated by a DCM or a PLL then this early version of the clk signal is not available like Walter pointed out and the write timing must be controlled by some other mechanism, like a state machine clocked at say 2x or 4x the CPU clock. Magnus

Hi Paul, My apologies for this off topic, ProjectOberon is basically a learning tool some hardware comments should not be bad. Yes the tool add the clock buffers because FF clock edge detectors must be connected to clock distribution tree, this do no correct the issue. The problem is, to connect a FF output, as clk signal is, to the clock buffer input the signal need be routed by general propose lines and interconnection matrix. This generate an uncontrolled delay. This issue has minor effect in RISC5 because is very special case where all project is self contained. A correct technique could be, RISC5 use a DCM to generate 75MHZ, use the same DCM to generate both 25MHZ (CLKDV) and 75MHZ (CLKFX) from 50MHZ (CLKIN). Regards, Walter El 2016-02-17 a las 06:39, Paul Reed escribió:

Hi Walter,

...

So, RISC5 use general propose resources to routing a clock signal. I agree with Magnus, the tools add the relevant clock buffer as part of their job, and the source code is kept simple and clear.

FPGAs are a little off-topic for many Oberoners, but hopefully the below simple hardware LED counter for the Spartan 3 board (easily adapted to almost any other board!) might be indulged, and interesting for enough people :)

If you create a project in Xilinx ISE for the xc3s200-4ft256 and add these source files, then "Generate Programming File", then as far as I can see from the reports, the tools add the appropriate clock buffers and global resources - correct me if I'm wrong!

Cheers, Paul

(test.v)

`timescale 1ns / 1ps

module TestTop( input CLK50M, //50MHz output [7:0] leds);

reg clk; reg [31:0] cnt;

assign leds = cnt[31:24];

always @(posedge clk) //25MHz cnt <= cnt + 1;

always @(posedge CLK50M) clk <= ~clk;

endmodule

(test.ucf)

NET "CLK50M" LOC = "T9" ; NET "leds[0]" LOC = "K12"; NET "leds[1]" LOC = "P14"; NET "leds[2]" LOC = "L12"; NET "leds[3]" LOC = "N14"; NET "leds[4]" LOC = "P13"; NET "leds[5]" LOC = "N12"; NET "leds[6]" LOC = "P12"; NET "leds[7]" LOC = "P11";

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

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

Magnus, Some of messages was delayed; so, I continue from here to not overload the list. If I understand you correctly, you justify a uncontrolled delay because they simplify the SRAM handling. Sorry, is as using the old circuit with an and/inverted to generate a pulse. If you need a delayed signal you should use the DCM 90°, 180° or 270° clock outputs and keep all under control, I think don't need a state machine in this case. About ISE warnings, be careful, non warning do not means good methodology. About XILINX docs; really, I don't remember. Doing training, first as Xilinx ATP and now as independent consultant, I touch this problem in my trainings. Have an uncontrolled delay in clock is a big door to random problems. FPGA design must be synchronous all times; no exceptions. Regards, Walter El 2016-02-17 a las 14:41, Magnus Karlsson escribió:

Walter,

I agree with you that the "pure" way of doing this is as you stated, with a DCM to directly generate both clk and pclk. So how come Paul didn't do that? It's not like he doesn't know how to use the DCM, after all the current code generates pclk from clk using a DCM, and there would probably be less code to do it like you suggest. No, the reason for this is very subtle and is easy to miss if you just take a quick look at the code, and it has to the asynchronous SRAM interface.

One of the most critical aspects of using SRAM is to control the write signal - ideally the write signal should be asserted after all other control signals (like address, data, byte-enable, read, oe) are valid, and should be de-asserted well before any of the other control signals go invalid, to avoid spurious writes. However, this is not that easy to do in a synchronous system where all signals change at the clock edge. The most common way to do this is to have a state machine that is clocked at say 4x the CPU clock so that you can divided the SRAM access cycle into several phases and assert the write signal on some of those phases.

However, this is not the way Paul choose to do it, instead he choose to do a less "pure" clock generation by generating clk from a flip-flop rather than from a DCM. By doing so, he actually generates an early version of the clock signal called clk that is leading the global clock signal clk_BUFG by the delay of the BUFG buffer. Since this early version of the clock signal is generated like any other logic signal, he could use this signal to gate the write signal to the SRAM such that write signal will be de-asserted well before the other control signals (clocked by clk_BUFG) will change, and thus avoiding the need to have a state machine controlling the write signal. The price for this is that the clock signal is now generated in a less "pure" way, but still a valid way as long as you know what you are doing. The BUFG clock driver can be driven from a PLL, a DCM or from the logic fabric. The first two are speed optimized paths going directly from the PLL or DCM to the BUFG and can be clock at much higher clock rate, while the logic fabric path is limited by the maximum clock rate of the logic fabric. However, at the clock rate we use (25 MHz) this is not an issue. When you do this there are no warnings generated by ISE that this is not a good idea, and I have not read anywhere in the Xilinx clocking resource guide that you should avoid doing this. Basically, the BUFG clock driver is designed to do this, the tool will allow you to do it and at the clock rate we use it has no performance implications. As I see it, this is another place where the goal of simplification has driven the implementation of the system at the expense of a slightly less "pure" clock generation.

Just my 2c

Magnus

On 2/17/2016 4:18 AM, Walter Gallegos wrote:

...

Hi Paul,

My apologies for this off topic, ProjectOberon is basically a learning tool some hardware comments should not be bad.

Yes the tool add the clock buffers because FF clock edge detectors must be connected to clock distribution tree, this do no correct the issue. The problem is, to connect a FF output, as clk signal is, to the clock buffer input the signal need be routed by general propose lines and interconnection matrix. This generate an uncontrolled delay. This issue has minor effect in RISC5 because is very special case where all project is self contained.

A correct technique could be, RISC5 use a DCM to generate 75MHZ, use the same DCM to generate both 25MHZ (CLKDV) and 75MHZ (CLKFX) from 50MHZ (CLKIN).

Regards, Walter

El 2016-02-17 a las 06:39, Paul Reed escribió:

...

Hi Walter,

...

So, RISC5 use general propose resources to routing a clock signal. I agree with Magnus, the tools add the relevant clock buffer as part of their job, and the source code is kept simple and clear.

FPGAs are a little off-topic for many Oberoners, but hopefully the below simple hardware LED counter for the Spartan 3 board (easily adapted to almost any other board!) might be indulged, and interesting for enough people :)

If you create a project in Xilinx ISE for the xc3s200-4ft256 and add these source files, then "Generate Programming File", then as far as I can see from the reports, the tools add the appropriate clock buffers and global resources - correct me if I'm wrong!

Cheers, Paul

(test.v)

`timescale 1ns / 1ps

module TestTop( input CLK50M, //50MHz output [7:0] leds);

reg clk; reg [31:0] cnt;

assign leds = cnt[31:24];

always @(posedge clk) //25MHz cnt <= cnt + 1;

always @(posedge CLK50M) clk <= ~clk;

endmodule

(test.ucf)

NET "CLK50M" LOC = "T9" ; NET "leds[0]" LOC = "K12"; NET "leds[1]" LOC = "P14"; NET "leds[2]" LOC = "L12"; NET "leds[3]" LOC = "N14"; NET "leds[4]" LOC = "P13"; NET "leds[5]" LOC = "N12"; NET "leds[6]" LOC = "P12"; NET "leds[7]" LOC = "P11";

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

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

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

Hi Magnus, You are welcome to continue with FPGA specific topics by private e-mail if you want. Regards Walter El 2016-02-17 a las 18:30, Magnus Karlsson escribió:

Hi Walter,

Since this is really Paul's design, I guess it would be more appropriate to discuss it with him, I was just trying to explain why it looks like it does.

Cheers, Magnus

On 2/17/2016 1:15 PM, Walter Gallegos wrote:

...

Magnus,

Some of messages was delayed; so, I continue from here to not overload the list.

If I understand you correctly, you justify a uncontrolled delay because they simplify the SRAM handling. Sorry, is as using the old circuit with an and/inverted to generate a pulse. If you need a delayed signal you should use the DCM 90°, 180° or 270° clock outputs and keep all under control, I think don't need a state machine in this case.

About ISE warnings, be careful, non warning do not means good methodology.

About XILINX docs; really, I don't remember. Doing training, first as Xilinx ATP and now as independent consultant, I touch this problem in my trainings. Have an uncontrolled delay in clock is a big door to random problems. FPGA design must be synchronous all times; no exceptions.

Regards, Walter

El 2016-02-17 a las 14:41, Magnus Karlsson escribió:

...

Walter,

I agree with you that the "pure" way of doing this is as you stated, with a DCM to directly generate both clk and pclk. So how come Paul didn't do that? It's not like he doesn't know how to use the DCM, after all the current code generates pclk from clk using a DCM, and there would probably be less code to do it like you suggest. No, the reason for this is very subtle and is easy to miss if you just take a quick look at the code, and it has to the asynchronous SRAM interface.

One of the most critical aspects of using SRAM is to control the write signal - ideally the write signal should be asserted after all other control signals (like address, data, byte-enable, read, oe) are valid, and should be de-asserted well before any of the other control signals go invalid, to avoid spurious writes. However, this is not that easy to do in a synchronous system where all signals change at the clock edge. The most common way to do this is to have a state machine that is clocked at say 4x the CPU clock so that you can divided the SRAM access cycle into several phases and assert the write signal on some of those phases.

However, this is not the way Paul choose to do it, instead he choose to do a less "pure" clock generation by generating clk from a flip-flop rather than from a DCM. By doing so, he actually generates an early version of the clock signal called clk that is leading the global clock signal clk_BUFG by the delay of the BUFG buffer. Since this early version of the clock signal is generated like any other logic signal, he could use this signal to gate the write signal to the SRAM such that write signal will be de-asserted well before the other control signals (clocked by clk_BUFG) will change, and thus avoiding the need to have a state machine controlling the write signal. The price for this is that the clock signal is now generated in a less "pure" way, but still a valid way as long as you know what you are doing. The BUFG clock driver can be driven from a PLL, a DCM or from the logic fabric. The first two are speed optimized paths going directly from the PLL or DCM to the BUFG and can be clock at much higher clock rate, while the logic fabric path is limited by the maximum clock rate of the logic fabric. However, at the clock rate we use (25 MHz) this is not an issue. When you do this there are no warnings generated by ISE that this is not a good idea, and I have not read anywhere in the Xilinx clocking resource guide that you should avoid doing this. Basically, the BUFG clock driver is designed to do this, the tool will allow you to do it and at the clock rate we use it has no performance implications. As I see it, this is another place where the goal of simplification has driven the implementation of the system at the expense of a slightly less "pure" clock generation.

Just my 2c

Magnus

On 2/17/2016 4:18 AM, Walter Gallegos wrote:

...

Hi Paul,

My apologies for this off topic, ProjectOberon is basically a learning tool some hardware comments should not be bad.

Yes the tool add the clock buffers because FF clock edge detectors must be connected to clock distribution tree, this do no correct the issue. The problem is, to connect a FF output, as clk signal is, to the clock buffer input the signal need be routed by general propose lines and interconnection matrix. This generate an uncontrolled delay. This issue has minor effect in RISC5 because is very special case where all project is self contained.

A correct technique could be, RISC5 use a DCM to generate 75MHZ, use the same DCM to generate both 25MHZ (CLKDV) and 75MHZ (CLKFX) from 50MHZ (CLKIN).

Regards, Walter

El 2016-02-17 a las 06:39, Paul Reed escribió:

...

Hi Walter,

...

So, RISC5 use general propose resources to routing a clock signal. I agree with Magnus, the tools add the relevant clock buffer as part of their job, and the source code is kept simple and clear.

FPGAs are a little off-topic for many Oberoners, but hopefully the below simple hardware LED counter for the Spartan 3 board (easily adapted to almost any other board!) might be indulged, and interesting for enough people :)

If you create a project in Xilinx ISE for the xc3s200-4ft256 and add these source files, then "Generate Programming File", then as far as I can see from the reports, the tools add the appropriate clock buffers and global resources - correct me if I'm wrong!

Cheers, Paul

(test.v)

`timescale 1ns / 1ps

module TestTop( input CLK50M, //50MHz output [7:0] leds);

reg clk; reg [31:0] cnt;

assign leds = cnt[31:24];

always @(posedge clk) //25MHz cnt <= cnt + 1;

always @(posedge CLK50M) clk <= ~clk;

endmodule

(test.ucf)

NET "CLK50M" LOC = "T9" ; NET "leds[0]" LOC = "K12"; NET "leds[1]" LOC = "P14"; NET "leds[2]" LOC = "L12"; NET "leds[3]" LOC = "N14"; NET "leds[4]" LOC = "P13"; NET "leds[5]" LOC = "N12"; NET "leds[6]" LOC = "P12"; NET "leds[7]" LOC = "P11";

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

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

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

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

Have a solid and coherent clock distribution is basic for FPGA design, my proposition was keep both 25MHZ and 75MHZ, generated by DCM. Run all in 75 MHZ is unnecessary; also, clock enable approach add unnecessary complexity to the design. Make a design synchronous don't necessary means use the same clock for all the design. Continue using 25MHZ for the core and peripherals, the only concern is the CDC (clock domain crossing). As both clock was generated by the same DCM is minor problem; correspondent rising edges are aligned by design in DCMs; metastability is not an issue. Using DCMs and constraining input clock (50MHZ) the constraints propagation rules constraint both clocks, 25MHZ and 75MHZ. If no methodology errors all design are constrained from first to last register element in the chain. Beware of combinational logic in outside this elements. In my opinion, taking care of CDC keep both clock is the appropriate solution. Best regards, Walter El 2016-02-18 a las 19:58, Magnus Karlsson escribió:

So I have been thinking about this some more and decided to modify/update the design to remove all the concerns raised by Walter and Wojtek.

Just to recap, Walter's concern is that the clocks are generated using flip-flops and use logic fabric interconnect instead of dedicated clocking elements and pathways, and that all clocks should be generated by a DCM module instead (DCM = Digital Clock Manager). Wojtek's concern is that there are unspecified timing relations between the 25MHz and the 75MHz clock domains.

Both concerns are valid and in my opinion the correct way to fix both issues is to make the design completely synchronous. This means that all clocked elements in the design (like flip-flops, memories etc.) should be clocked with a single clock signal, which in this case is the 75MHz clock. The CPU and I/O subsystem, which before was clocked by a separate 25MHz clock, are now also clocked by the 75MHz clock but are only enabled to be clocked on every third clock cycle. This means that all "always @ (posedge clk)" statements have been changed to include "If (enable) ...", where "enable" is a signal that is true on every third clock cycle. The asynchronous SRAM interface is also changed so that the write signal is asserted on the middle-third clock phase of the three clock CPU cycle.

While the Verilog changes to do this are very straight forward, one complication here is that the Xilinx ISE tool used to create the bit file for the FPGA do not understand that the CPU and I/O subsystem are only clocked on every third clock and will basically try to make the CPU run at 75MHz, and will fail since this is too fast the FPGA. The solution to this problem is to tell the tool that all clock paths in the CPU and I/O subsystem can actually take three clocks to complete (this is called multi-cycle paths). With the multi-cycle paths added to the .ucf file the design compiles with no timing violations

With those changes the 75MHz clock is now generated by a DCM and the unspecified timing relations that Wojtek brought up are now gone since everything is clocked with a single clock. The modified design have been tested on Pepino and seems to run fine.

The complete ISE project with those changes are available at the Pepino GitHub repository: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino

Any comments or critique are welcome.

Cheers, Magnus

On 2/17/2016 2:16 PM, Walter Gallegos wrote:

...

Hi Magnus,

You are welcome to continue with FPGA specific topics by private e-mail if you want.

Regards Walter

El 2016-02-17 a las 18:30, Magnus Karlsson escribió:

...

Hi Walter,

Since this is really Paul's design, I guess it would be more appropriate to discuss it with him, I was just trying to explain why it looks like it does.

Cheers, Magnus

On 2/17/2016 1:15 PM, Walter Gallegos wrote:

...

Magnus,

Some of messages was delayed; so, I continue from here to not overload the list.

If I understand you correctly, you justify a uncontrolled delay because they simplify the SRAM handling. Sorry, is as using the old circuit with an and/inverted to generate a pulse. If you need a delayed signal you should use the DCM 90°, 180° or 270° clock outputs and keep all under control, I think don't need a state machine in this case.

About ISE warnings, be careful, non warning do not means good methodology.

About XILINX docs; really, I don't remember. Doing training, first as Xilinx ATP and now as independent consultant, I touch this problem in my trainings. Have an uncontrolled delay in clock is a big door to random problems. FPGA design must be synchronous all times; no exceptions.

Regards, Walter

El 2016-02-17 a las 14:41, Magnus Karlsson escribió:

...

Walter,

I agree with you that the "pure" way of doing this is as you stated, with a DCM to directly generate both clk and pclk. So how come Paul didn't do that? It's not like he doesn't know how to use the DCM, after all the current code generates pclk from clk using a DCM, and there would probably be less code to do it like you suggest. No, the reason for this is very subtle and is easy to miss if you just take a quick look at the code, and it has to the asynchronous SRAM interface.

One of the most critical aspects of using SRAM is to control the write signal - ideally the write signal should be asserted after all other control signals (like address, data, byte-enable, read, oe) are valid, and should be de-asserted well before any of the other control signals go invalid, to avoid spurious writes. However, this is not that easy to do in a synchronous system where all signals change at the clock edge. The most common way to do this is to have a state machine that is clocked at say 4x the CPU clock so that you can divided the SRAM access cycle into several phases and assert the write signal on some of those phases.

However, this is not the way Paul choose to do it, instead he choose to do a less "pure" clock generation by generating clk from a flip-flop rather than from a DCM. By doing so, he actually generates an early version of the clock signal called clk that is leading the global clock signal clk_BUFG by the delay of the BUFG buffer. Since this early version of the clock signal is generated like any other logic signal, he could use this signal to gate the write signal to the SRAM such that write signal will be de-asserted well before the other control signals (clocked by clk_BUFG) will change, and thus avoiding the need to have a state machine controlling the write signal. The price for this is that the clock signal is now generated in a less "pure" way, but still a valid way as long as you know what you are doing. The BUFG clock driver can be driven from a PLL, a DCM or from the logic fabric. The first two are speed optimized paths going directly from the PLL or DCM to the BUFG and can be clock at much higher clock rate, while the logic fabric path is limited by the maximum clock rate of the logic fabric. However, at the clock rate we use (25 MHz) this is not an issue. When you do this there are no warnings generated by ISE that this is not a good idea, and I have not read anywhere in the Xilinx clocking resource guide that you should avoid doing this. Basically, the BUFG clock driver is designed to do this, the tool will allow you to do it and at the clock rate we use it has no performance implications. As I see it, this is another place where the goal of simplification has driven the implementation of the system at the expense of a slightly less "pure" clock generation.

Just my 2c

Magnus

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

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88 El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

OK, so I decided to try to implement the clocking as Walter suggested, i.e. with a DCM that generates both 25MHz and 75MHz clocks. The write-enable signal is generated by using a 50 MHz output from the DCM. The code looks like this: 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; The DCM in VID.v is removed and replaced with an input clock pclk. All the changes to make the design full synchronous has been backed out. The latest code is available at the Pepino github repository: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino As before, any comments or critique are welcome. Magnus On 2/19/2016 6:33 AM, Magnus Karlsson wrote:

In all fairness, since I have generated and tested code for one way to solve the problem, can you then give us your code proposal for generating the SRAM write signal, with 25MHz and 75MHz generated by a DCM? The write signal must be asserted after all other SRAM control signals are valid, and be de-asserted before any of the control signals go invalid, and last for at least 5 nS. The SRAM control signals are generated by the 25MHz clock and last for one clock cycle.

I will be more than happy to try it out on a board and report the result.

Magnus

On 2/19/2016 4:57 AM, Walter Gallegos wrote:

...

Have a solid and coherent clock distribution is basic for FPGA design, my proposition was keep both 25MHZ and 75MHZ, generated by DCM.

Run all in 75 MHZ is unnecessary; also, clock enable approach add unnecessary complexity to the design. Make a design synchronous don't necessary means use the same clock for all the design.

Continue using 25MHZ for the core and peripherals, the only concern is the CDC (clock domain crossing). As both clock was generated by the same DCM is minor problem; correspondent rising edges are aligned by design in DCMs; metastability is not an issue. Using DCMs and constraining input clock (50MHZ) the constraints propagation rules constraint both clocks, 25MHZ and 75MHZ. If no methodology errors all design are constrained from first to last register element in the chain. Beware of combinational logic in outside this elements.

In my opinion, taking care of CDC keep both clock is the appropriate solution.

Best regards, Walter

El 2016-02-18 a las 19:58, Magnus Karlsson escribió:

...

So I have been thinking about this some more and decided to modify/update the design to remove all the concerns raised by Walter and Wojtek.

Just to recap, Walter's concern is that the clocks are generated using flip-flops and use logic fabric interconnect instead of dedicated clocking elements and pathways, and that all clocks should be generated by a DCM module instead (DCM = Digital Clock Manager). Wojtek's concern is that there are unspecified timing relations between the 25MHz and the 75MHz clock domains.

Both concerns are valid and in my opinion the correct way to fix both issues is to make the design completely synchronous. This means that all clocked elements in the design (like flip-flops, memories etc.) should be clocked with a single clock signal, which in this case is the 75MHz clock. The CPU and I/O subsystem, which before was clocked by a separate 25MHz clock, are now also clocked by the 75MHz clock but are only enabled to be clocked on every third clock cycle. This means that all "always @ (posedge clk)" statements have been changed to include "If (enable) ...", where "enable" is a signal that is true on every third clock cycle. The asynchronous SRAM interface is also changed so that the write signal is asserted on the middle-third clock phase of the three clock CPU cycle.

While the Verilog changes to do this are very straight forward, one complication here is that the Xilinx ISE tool used to create the bit file for the FPGA do not understand that the CPU and I/O subsystem are only clocked on every third clock and will basically try to make the CPU run at 75MHz, and will fail since this is too fast the FPGA. The solution to this problem is to tell the tool that all clock paths in the CPU and I/O subsystem can actually take three clocks to complete (this is called multi-cycle paths). With the multi-cycle paths added to the .ucf file the design compiles with no timing violations

With those changes the 75MHz clock is now generated by a DCM and the unspecified timing relations that Wojtek brought up are now gone since everything is clocked with a single clock. The modified design have been tested on Pepino and seems to run fine.

The complete ISE project with those changes are available at the Pepino GitHub repository: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino

Any comments or critique are welcome.

Cheers, Magnus

On 2/17/2016 2:16 PM, Walter Gallegos wrote:

...

Hi Magnus,

You are welcome to continue with FPGA specific topics by private e-mail if you want.

Regards Walter

El 2016-02-17 a las 18:30, Magnus Karlsson escribió:

...

Hi Walter,

Since this is really Paul's design, I guess it would be more appropriate to discuss it with him, I was just trying to explain why it looks like it does.

Cheers, Magnus

On 2/17/2016 1:15 PM, Walter Gallegos wrote:

...

Magnus,

Some of messages was delayed; so, I continue from here to not overload the list.

If I understand you correctly, you justify a uncontrolled delay because they simplify the SRAM handling. Sorry, is as using the old circuit with an and/inverted to generate a pulse. If you need a delayed signal you should use the DCM 90°, 180° or 270° clock outputs and keep all under control, I think don't need a state machine in this case.

About ISE warnings, be careful, non warning do not means good methodology.

About XILINX docs; really, I don't remember. Doing training, first as Xilinx ATP and now as independent consultant, I touch this problem in my trainings. Have an uncontrolled delay in clock is a big door to random problems. FPGA design must be synchronous all times; no exceptions.

Regards, Walter

El 2016-02-17 a las 14:41, Magnus Karlsson escribió: > Walter, > > I agree with you that the "pure" way of doing this is as you > stated, with a DCM to directly generate both clk and pclk. So > how come Paul didn't do that? It's not like he doesn't know how > to use the DCM, after all the current code generates pclk from > clk using a DCM, and there would probably be less code to do it > like you suggest. No, the reason for this is very subtle and is > easy to miss if you just take a quick look at the code, and it > has to the asynchronous SRAM interface. > > One of the most critical aspects of using SRAM is to control the > write signal - ideally the write signal should be asserted after > all other control signals (like address, data, byte-enable, > read, oe) are valid, and should be de-asserted well before any > of the other control signals go invalid, to avoid spurious > writes. However, this is not that easy to do in a synchronous > system where all signals change at the clock edge. The most > common way to do this is to have a state machine that is clocked > at say 4x the CPU clock so that you can divided the SRAM access > cycle into several phases and assert the write signal on some of > those phases. > > However, this is not the way Paul choose to do it, instead he > choose to do a less "pure" clock generation by generating clk > from a flip-flop rather than from a DCM. By doing so, he > actually generates an early version of the clock signal called > clk that is leading the global clock signal clk_BUFG by the > delay of the BUFG buffer. Since this early version of the clock > signal is generated like any other logic signal, he could use > this signal to gate the write signal to the SRAM such that write > signal will be de-asserted well before the other control signals > (clocked by clk_BUFG) will change, and thus avoiding the need to > have a state machine controlling the write signal. The price > for this is that the clock signal is now generated in a less > "pure" way, but still a valid way as long as you know what you > are doing. The BUFG clock driver can be driven from a PLL, a DCM > or from the logic fabric. The first two are speed optimized > paths going directly from the PLL or DCM to the BUFG and can be > clock at much higher clock rate, while the logic fabric path is > limited by the maximum clock rate of the logic fabric. However, > at the clock rate we use (25 MHz) this is not an issue. When > you do this there are no warnings generated by ISE that this is > not a good idea, and I have not read anywhere in the Xilinx > clocking resource guide that you should avoid doing this. > Basically, the BUFG clock driver is designed to do this, the > tool will allow you to do it and at the clock rate we use it has > no performance implications. As I see it, this is another place > where the goal of simplification has driven the implementation > of the system at the expense of a slightly less "pure" clock > generation. > > Just my 2c > > Magnus

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

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

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

El 2016-02-19 a las 11:33, Magnus Karlsson escribió:

...

In all fairness, since I have generated and tested code for one way to solve the problem, can you then give us your code proposal for generating the SRAM write signal, with 25MHz and 75MHz generated by a DCM? The write signal must be asserted after all other SRAM control signals are valid, and be de-asserted before any of the control signals go invalid, and last for at least 5 nS. The SRAM control signals are generated by the 25MHz clock and last for one clock cycle.

I will be more than happy to try it out on a board and report the result.

Magnus

On 2/19/2016 4:57 AM, Walter Gallegos wrote:

...

Have a solid and coherent clock distribution is basic for FPGA design, my proposition was keep both 25MHZ and 75MHZ, generated by DCM.

Run all in 75 MHZ is unnecessary; also, clock enable approach add unnecessary complexity to the design. Make a design synchronous don't necessary means use the same clock for all the design.

Continue using 25MHZ for the core and peripherals, the only concern is the CDC (clock domain crossing). As both clock was generated by the same DCM is minor problem; correspondent rising edges are aligned by design in DCMs; metastability is not an issue. Using DCMs and constraining input clock (50MHZ) the constraints propagation rules constraint both clocks, 25MHZ and 75MHZ. If no methodology errors all design are constrained from first to last register element in the chain. Beware of combinational logic in outside this elements.

In my opinion, taking care of CDC keep both clock is the appropriate solution.

Best regards, Walter

El 2016-02-18 a las 19:58, Magnus Karlsson escribió:

...

So I have been thinking about this some more and decided to modify/update the design to remove all the concerns raised by Walter and Wojtek.

Just to recap, Walter's concern is that the clocks are generated using flip-flops and use logic fabric interconnect instead of dedicated clocking elements and pathways, and that all clocks should be generated by a DCM module instead (DCM = Digital Clock Manager). Wojtek's concern is that there are unspecified timing relations between the 25MHz and the 75MHz clock domains.

Both concerns are valid and in my opinion the correct way to fix both issues is to make the design completely synchronous. This means that all clocked elements in the design (like flip-flops, memories etc.) should be clocked with a single clock signal, which in this case is the 75MHz clock. The CPU and I/O subsystem, which before was clocked by a separate 25MHz clock, are now also clocked by the 75MHz clock but are only enabled to be clocked on every third clock cycle. This means that all "always @ (posedge clk)" statements have been changed to include "If (enable) ...", where "enable" is a signal that is true on every third clock cycle. The asynchronous SRAM interface is also changed so that the write signal is asserted on the middle-third clock phase of the three clock CPU cycle.

While the Verilog changes to do this are very straight forward, one complication here is that the Xilinx ISE tool used to create the bit file for the FPGA do not understand that the CPU and I/O subsystem are only clocked on every third clock and will basically try to make the CPU run at 75MHz, and will fail since this is too fast the FPGA. The solution to this problem is to tell the tool that all clock paths in the CPU and I/O subsystem can actually take three clocks to complete (this is called multi-cycle paths). With the multi-cycle paths added to the .ucf file the design compiles with no timing violations

With those changes the 75MHz clock is now generated by a DCM and the unspecified timing relations that Wojtek brought up are now gone since everything is clocked with a single clock. The modified design have been tested on Pepino and seems to run fine.

The complete ISE project with those changes are available at the Pepino GitHub repository: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino

Any comments or critique are welcome.

Cheers, Magnus

On 2/17/2016 2:16 PM, Walter Gallegos wrote:

...

Hi Magnus,

You are welcome to continue with FPGA specific topics by private e-mail if you want.

Regards Walter

El 2016-02-17 a las 18:30, Magnus Karlsson escribió:

...

Hi Walter,

Since this is really Paul's design, I guess it would be more appropriate to discuss it with him, I was just trying to explain why it looks like it does.

Cheers, Magnus

On 2/17/2016 1:15 PM, Walter Gallegos wrote: > Magnus, > > Some of messages was delayed; so, I continue from here to not > overload the list. > > If I understand you correctly, you justify a uncontrolled delay > because they simplify the SRAM handling. > Sorry, is as using the old circuit with an and/inverted to > generate a pulse. If you need a delayed signal you should use > the DCM 90°, 180° or 270° clock outputs and keep all under > control, I think don't need a state machine in this case. > > About ISE warnings, be careful, non warning do not means good > methodology. > > About XILINX docs; really, I don't remember. Doing training, > first as Xilinx ATP and now as independent consultant, I touch > this problem in my trainings. Have an uncontrolled delay in > clock is a big door to random problems. FPGA design must be > synchronous all times; no exceptions. > > Regards, > Walter > > > El 2016-02-17 a las 14:41, Magnus Karlsson escribió: >> Walter, >> >> I agree with you that the "pure" way of doing this is as you >> stated, with a DCM to directly generate both clk and pclk. So >> how come Paul didn't do that? It's not like he doesn't know how >> to use the DCM, after all the current code generates pclk from >> clk using a DCM, and there would probably be less code to do it >> like you suggest. No, the reason for this is very subtle and is >> easy to miss if you just take a quick look at the code, and it >> has to the asynchronous SRAM interface. >> >> One of the most critical aspects of using SRAM is to control >> the write signal - ideally the write signal should be asserted >> after all other control signals (like address, data, >> byte-enable, read, oe) are valid, and should be de-asserted >> well before any of the other control signals go invalid, to >> avoid spurious writes. However, this is not that easy to do in >> a synchronous system where all signals change at the clock >> edge. The most common way to do this is to have a state >> machine that is clocked at say 4x the CPU clock so that you can >> divided the SRAM access cycle into several phases and assert >> the write signal on some of those phases. >> >> However, this is not the way Paul choose to do it, instead he >> choose to do a less "pure" clock generation by generating clk >> from a flip-flop rather than from a DCM. By doing so, he >> actually generates an early version of the clock signal called >> clk that is leading the global clock signal clk_BUFG by the >> delay of the BUFG buffer. Since this early version of the >> clock signal is generated like any other logic signal, he could >> use this signal to gate the write signal to the SRAM such that >> write signal will be de-asserted well before the other control >> signals (clocked by clk_BUFG) will change, and thus avoiding >> the need to have a state machine controlling the write signal. >> The price for this is that the clock signal is now generated in >> a less "pure" way, but still a valid way as long as you know >> what you are doing. The BUFG clock driver can be driven from a >> PLL, a DCM or from the logic fabric. The first two are speed >> optimized paths going directly from the PLL or DCM to the BUFG >> and can be clock at much higher clock rate, while the logic >> fabric path is limited by the maximum clock rate of the logic >> fabric. However, at the clock rate we use (25 MHz) this is not >> an issue. When you do this there are no warnings generated by >> ISE that this is not a good idea, and I have not read anywhere >> in the Xilinx clocking resource guide that you should avoid >> doing this. Basically, the BUFG clock driver is designed to do >> this, the tool will allow you to do it and at the clock rate we >> use it has no performance implications. As I see it, this is >> another place where the goal of simplification has driven the >> implementation of the system at the expense of a slightly less >> "pure" clock generation. >> >> Just my 2c >> >> Magnus

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

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

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

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

Apologies, Spanish typo in my post. "de" => "the". El 2016-02-24 a las 11:07, Walter Gallegos escribió:

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));

clk = CLK0 = CLKIN = CLK50M. Can this version of RISC5 run at 50MHZ as is ?

Here my simulation using de 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 at this point. If RISC5 can read then write in consecutive clk cycles the issue is easy worked capturing de SRAM data with 90° clock rising_edge and releasing oen soon. Important note : This functional simple test bench do not take in count internal RISC5 timing issues.

Question to RISC5 fathers and adopters : Someone build an "official" test bench set for RISC5 ? That means module by module plus one total. Is the test bench available ?

I'm more interested in practical uses; as an -industrial grade- embedded RISC5; how many in this list, in addition to those we already know, walk in the same direction ?

Best regards Walter

El 2016-02-23 a las 13:49, Magnus Karlsson escribió:

...

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

El 2016-02-19 a las 11:33, Magnus Karlsson escribió:

...

In all fairness, since I have generated and tested code for one way to solve the problem, can you then give us your code proposal for generating the SRAM write signal, with 25MHz and 75MHz generated by a DCM? The write signal must be asserted after all other SRAM control signals are valid, and be de-asserted before any of the control signals go invalid, and last for at least 5 nS. The SRAM control signals are generated by the 25MHz clock and last for one clock cycle.

I will be more than happy to try it out on a board and report the result.

Magnus

On 2/19/2016 4:57 AM, Walter Gallegos wrote:

...

Have a solid and coherent clock distribution is basic for FPGA design, my proposition was keep both 25MHZ and 75MHZ, generated by DCM.

Run all in 75 MHZ is unnecessary; also, clock enable approach add unnecessary complexity to the design. Make a design synchronous don't necessary means use the same clock for all the design.

Continue using 25MHZ for the core and peripherals, the only concern is the CDC (clock domain crossing). As both clock was generated by the same DCM is minor problem; correspondent rising edges are aligned by design in DCMs; metastability is not an issue. Using DCMs and constraining input clock (50MHZ) the constraints propagation rules constraint both clocks, 25MHZ and 75MHZ. If no methodology errors all design are constrained from first to last register element in the chain. Beware of combinational logic in outside this elements.

In my opinion, taking care of CDC keep both clock is the appropriate solution.

Best regards, Walter

El 2016-02-18 a las 19:58, Magnus Karlsson escribió:

...

So I have been thinking about this some more and decided to modify/update the design to remove all the concerns raised by Walter and Wojtek.

Just to recap, Walter's concern is that the clocks are generated using flip-flops and use logic fabric interconnect instead of dedicated clocking elements and pathways, and that all clocks should be generated by a DCM module instead (DCM = Digital Clock Manager). Wojtek's concern is that there are unspecified timing relations between the 25MHz and the 75MHz clock domains.

Both concerns are valid and in my opinion the correct way to fix both issues is to make the design completely synchronous. This means that all clocked elements in the design (like flip-flops, memories etc.) should be clocked with a single clock signal, which in this case is the 75MHz clock. The CPU and I/O subsystem, which before was clocked by a separate 25MHz clock, are now also clocked by the 75MHz clock but are only enabled to be clocked on every third clock cycle. This means that all "always @ (posedge clk)" statements have been changed to include "If (enable) ...", where "enable" is a signal that is true on every third clock cycle. The asynchronous SRAM interface is also changed so that the write signal is asserted on the middle-third clock phase of the three clock CPU cycle.

While the Verilog changes to do this are very straight forward, one complication here is that the Xilinx ISE tool used to create the bit file for the FPGA do not understand that the CPU and I/O subsystem are only clocked on every third clock and will basically try to make the CPU run at 75MHz, and will fail since this is too fast the FPGA. The solution to this problem is to tell the tool that all clock paths in the CPU and I/O subsystem can actually take three clocks to complete (this is called multi-cycle paths). With the multi-cycle paths added to the .ucf file the design compiles with no timing violations

With those changes the 75MHz clock is now generated by a DCM and the unspecified timing relations that Wojtek brought up are now gone since everything is clocked with a single clock. The modified design have been tested on Pepino and seems to run fine.

The complete ISE project with those changes are available at the Pepino GitHub repository: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino

Any comments or critique are welcome.

Cheers, Magnus

On 2/17/2016 2:16 PM, Walter Gallegos wrote: > Hi Magnus, > > You are welcome to continue with FPGA specific topics by private > e-mail if you want. > > Regards > Walter > > El 2016-02-17 a las 18:30, Magnus Karlsson escribió: >> Hi Walter, >> >> Since this is really Paul's design, I guess it would be more >> appropriate to discuss it with him, I was just trying to >> explain why it looks like it does. >> >> Cheers, >> Magnus >> >> >> On 2/17/2016 1:15 PM, Walter Gallegos wrote: >>> Magnus, >>> >>> Some of messages was delayed; so, I continue from here to not >>> overload the list. >>> >>> If I understand you correctly, you justify a uncontrolled >>> delay because they simplify the SRAM handling. >>> Sorry, is as using the old circuit with an and/inverted to >>> generate a pulse. If you need a delayed signal you should use >>> the DCM 90°, 180° or 270° clock outputs and keep all under >>> control, I think don't need a state machine in this case. >>> >>> About ISE warnings, be careful, non warning do not means good >>> methodology. >>> >>> About XILINX docs; really, I don't remember. Doing training, >>> first as Xilinx ATP and now as independent consultant, I touch >>> this problem in my trainings. Have an uncontrolled delay in >>> clock is a big door to random problems. FPGA design must be >>> synchronous all times; no exceptions. >>> >>> Regards, >>> Walter >>> >>> >>> El 2016-02-17 a las 14:41, Magnus Karlsson escribió: >>>> Walter, >>>> >>>> I agree with you that the "pure" way of doing this is as you >>>> stated, with a DCM to directly generate both clk and pclk. So >>>> how come Paul didn't do that? It's not like he doesn't know >>>> how to use the DCM, after all the current code generates pclk >>>> from clk using a DCM, and there would probably be less code >>>> to do it like you suggest. No, the reason for this is very >>>> subtle and is easy to miss if you just take a quick look at >>>> the code, and it has to the asynchronous SRAM interface. >>>> >>>> One of the most critical aspects of using SRAM is to control >>>> the write signal - ideally the write signal should be >>>> asserted after all other control signals (like address, data, >>>> byte-enable, read, oe) are valid, and should be de-asserted >>>> well before any of the other control signals go invalid, to >>>> avoid spurious writes. However, this is not that easy to do >>>> in a synchronous system where all signals change at the clock >>>> edge. The most common way to do this is to have a state >>>> machine that is clocked at say 4x the CPU clock so that you >>>> can divided the SRAM access cycle into several phases and >>>> assert the write signal on some of those phases. >>>> >>>> However, this is not the way Paul choose to do it, instead he >>>> choose to do a less "pure" clock generation by generating clk >>>> from a flip-flop rather than from a DCM. By doing so, he >>>> actually generates an early version of the clock signal >>>> called clk that is leading the global clock signal clk_BUFG >>>> by the delay of the BUFG buffer. Since this early version of >>>> the clock signal is generated like any other logic signal, he >>>> could use this signal to gate the write signal to the SRAM >>>> such that write signal will be de-asserted well before the >>>> other control signals (clocked by clk_BUFG) will change, and >>>> thus avoiding the need to have a state machine controlling >>>> the write signal. The price for this is that the clock >>>> signal is now generated in a less "pure" way, but still a >>>> valid way as long as you know what you are doing. The BUFG >>>> clock driver can be driven from a PLL, a DCM or from the >>>> logic fabric. The first two are speed optimized paths going >>>> directly from the PLL or DCM to the BUFG and can be clock at >>>> much higher clock rate, while the logic fabric path is >>>> limited by the maximum clock rate of the logic fabric. >>>> However, at the clock rate we use (25 MHz) this is not an >>>> issue. When you do this there are no warnings generated by >>>> ISE that this is not a good idea, and I have not read >>>> anywhere in the Xilinx clocking resource guide that you >>>> should avoid doing this. Basically, the BUFG clock driver is >>>> designed to do this, the tool will allow you to do it and at >>>> the clock rate we use it has no performance implications. As >>>> I see it, this is another place where the goal of >>>> simplification has driven the implementation of the system at >>>> the expense of a slightly less "pure" clock generation. >>>> >>>> Just my 2c >>>> >>>> Magnus

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

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

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

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

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

--

Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAILwalter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88

El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.

-- Walter Daniel Gallegos Programmable Logic & Software Consultoría, Diseño, Entrenamiento. Montevideo, Uruguay EMAIL walter@waltergallegos.com Tel +598 26 23 44 60 | Cel +598 99 18 58 88 El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited.