[Oberon] FPGA - Colour Support

Sat Oct 7 22:20:59 CEST 2017

Wojtek

Thanx for the info.

So, a proper design would look something like this.

According to the Xilinx text, the main problem seems to be the skew. As RISC-5 only runs at 25 MHz, it might be that there is a lot of time reserve and the different arrival times of the clk signal do not matter so much…

br

Jörg

Am 07.10.17, 22:12 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces at lists.inf.ethz.ch im Auftrag von skulski at pas.rochester.edu>:

    Joerg:

    Here is the wording from "Spartan-6 FPGA Clocking Resources", User Guide UG382 (v1.10) June 19, 2015, page 12.

    "BUFGMUX can multiplex between two global clock sources or be used as a simple BUFG

    clock buffer. The clock buffer can only directly drive the global clock routing resources,

    which can only drive clock inputs. However, clock inputs on the FPGA logic flip-flops can

    also come from general-purpose routing, although their use should be limited due to

    higher skew."

    The way I understand these words is that you are allowed to route the derived clock via BUFG (which physically is the same as BUFGMUX), but you are then impacting the performance of your design. From my experience, achieving a glitch-free operation of the FPGA design will be much more iffy when the design is invoking any grief from the Xilinx tools in the clocking arena. The design may work, but it may also generate corrupt bits, if there is any unresolved clocking warning from the tools. Based on my experience, I would stay away from any simplistic tricks where the clock signals are involved.

    If I ever used the code like RISC5, then I would spend ample time analyzing the translation warnings. In practice it is much better to write the code according to the Xilinx User Guides then to try a seemingly simple code which leads to potentially iffy translation into the hardware.

    And this is why LOLA and its resulting seemingly simple Verilog should not be treated like a gospel. Reliable FPGA design requires reading through Xilinx User Guides for the particular family you are using. These will be different for Spartan-3, Spartan-6, or Series-7. Do not rely on Spartan-3 User Guide when working with Artix!

    And then there are also silicon bugs and undocumented features which you discover the hard way yourself, or read read on the Xilinx Developer Zone where the Q&A records are numbered in tens-of-thousands. 

    Do not get discouraged. It all can be done! But not necessarily with just LOLA.

    W.

    ________________________________________

    From: Skulski, Wojciech

    Sent: Saturday, October 7, 2017 3:52 PM

    To: ETH Oberon and related systems

    Subject: RE: [Oberon] FPGA - Colour Support

    Joerg:

      your diagram is entirely fine. However, you canot run any Q, Q#, AND (Q,Q#), or anything like this into the CLK inputs of the other flip-flops. I mean, the inputs marked with triangles.

    The intent of the code snippet which you posted was to generate clocking signals of half the frequency, which are then routed to some flip flops in the design. This is not allowed because there is no direct connection from the flip-flop outputs, or from the AND gate output, to any of the flip-flop clocking inputs anywhere. These triangle inputs are on an entirely separate "clocking tree".

    You may use the derived clock by connecting it to the clocking tree. This should be done explicitly like the following. The "derived_clock" is routed via the BUFG, which physically is a very strong current driver, to the "clocking tree" connected to the output "O". As far as I know, Xilinx does not recommend this practice. They rather recommend using "clock enable" inputs of the flip-flops. These inputs were not shown in your diagram.

    Note that the connection via the BUFG can be inserted by the Xilinx tools themselves, without you being aware. If this happens then you will be notified in the translation reports. Not looking into these, you may stay under the impression that the clock derivation is a simple thing to write in the code. You may not be aware that your design is consuming these BUFG drivers to achieve the goal.

    -- global clock buffer for signal processing

    clk100_buf: BUFG

     port map(

    I  => derived_clock,

    O => system_clock

    );

    W.

    ________________________________________

    From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]

    Sent: Saturday, October 7, 2017 3:12 PM

    To: ETH Oberon and related systems

    Subject: Re: [Oberon] FPGA - Colour Support

    Hi Wojtek

    Are you saying FPGA can not implement this:?

    [cid:image001.png at 01D33FB0.F72AFD20]

    Am 07.10.17, 20:26 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces at lists.inf.ethz.ch im Auftrag von skulski at pas.rochester.edu>:

        Joerg:

        These clock manipulations look interesting. I wonder how ISE or Vivado translate these into logic. Combinatorial clocks cannot be used in FPGA designs. Combinatorial means "derived from logic equations" like the ones we see below. The reason is that the clocking inputs to flip flops are seldom (if ever) directly connected to the fabric, where such equations are implemented in hardware. And even if such connections exist (I doubt they do), using them is strongly discouraged by the FPGA manufacturers. Maybe ISE tools are smart enough to somehow pack these equations into the Digital Clock Manager (DCM)?

        So it is an interesting piece of HDL which is calling either for a rework or for examination of the translation report to find out, how it is implemented by the tools. If you want to divide the clock by five, then I am pretty sure the DCM will need to be used.

        Concerning the SPI, it can run at a wide range of frequencies. Perhaps some part has some special requirements, which then need to be dealt with locally in the respective HDL module.

        W.

        ________________________________________

        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.

        --

        Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

        https://lists.inf.ethz.ch/mailman/listinfo/oberon

    --

    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/5c35e11e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 25214 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171007/5c35e11e/attachment-0001.png>