Spartan® Family FPGAs

[eteam00]

1. Why register the address and data on the trailing edge, and not on a leading edge?

Check the datasheet timing specifications and waveform diagram for the bus signals.  Welcome to hardware design!

The address and data to be written must be already available on their buses when the MCU asserts tha mcu_wr_n signal.

Only if the MCU datasheet guarantees this timing.

2. As I see it, the mcu_wr_n signal is not asynchronous to the FPGA. It is synchronows to the input clock from the mcu - the mcu_clk, and this exact clock is used for the base of the main clock clk2x, which the FPGA uses, i.e, synchronous to every second rising edge of the clk2x.

In one datasheet (perhaps not the correct datasheet), the BCLK -> mcu_wr_n delay is a maximum of 30nS.  The minimum delay is unspecified, and must be presumed to be as little as 0 nS.  The difference between the maximum and minimum delay represents timing uncertainty.  The system clock (clk2x) is 100MHz.  Clock period is 10nS, much shorter than the timing uncertainy in the mcu_wr_n signal. Clearly the phase relationship of the mcu_wr_n signal relative to the clk2x clock edge is indeterminate, and register setup and hold time requirements of the FPGA cannot be guaranteed.

Even using the MCU's BCLK output clock to register the mcu_wr_n signal in the FPGA is a problem.  The BCLK -> mcu_wr_n maximum delay (30nS) exceeds the minimum BCLK clock period (20nS @ 50MHz).  At roughly 30MHz or higher BCLK frequency, mcu_wr_n must be considered asynchronous with respect to BCLK (much less clk2x).

But wait... there's more!

In the same RX62N datasheet I have been using, MCU data output is not guaranteed to be valid at either the leading edge or the trailing edge of the mcu_wr_n pulse, if the BCLK frequency is high enough.  I have updated the Verilog code posted in this thread to overcome this revelation.

The signals from the MCU must be treated as asynchronous with respect to the system clock clk2x.  Welcome to hardware design!

Note that you did not specify the MCU device you are using, nor did you provide a link to the MCU datasheet.  The first RX62N datasheet I found is what I used, so feel free to provide more specific and representative information.

... Then, if all the above is true, than something like this would work:

It's clear that all of the above may -- or may not -- be true, but let's slog forward...

always @(negedge mcu_wr_n)
 if(~mcu_cs_n)  begin
  mcu_wr_data <=mcu_data; // my datasheet does not guarantee mcu_data valid at leading edge of mcu_wr_n
  mcu_wr_addr <=mcu_addr;
  mcu_wrreq <=~mcu_wrreq;
 end

The signal mcu_wrreq is used in your read/write state machine, which is clocked by clk2x.  What is the phase relationship between mcu_wrreq and clk2x ? (and yes, you need to show your work if this is a proper design review)

-- Bob Elkind

[bassman59]

I just finished up something that's similar to what you're trying to do. It's a Silicon Labs C8501F120 connected to a Spartan 3AN using the micro's EMIF bus. This bus is basically the standard 8051 16-bit address/8-bit data bus with read and write enables. (SiLabs gives you the option to do a non-multiplexed bus, so there's no need for the address latch.)

The bus is synchronous to the micro's SYSCLK, which is derived from its input clock (or an onboard oscillator). My FPGA has a 100 MHz global clock input; that's divided down to 20 MHz and fed to the micro's clock input, and the micro's internal PLL bumps the clock back up. So the EMIF is basically asychromous to the FPGA's clock.

The EMIF can be programmed for 0 through 3 clocks (the micro's SYSCLK, not the FPGA clock) of setup time, which is the time between the assertion of an address and write data (if a write) before the assertion of the write or read strobe. You can program up to 16 clocks of read or write low (active) time, followed by 0 to 3 clocks of hold after the rising edge of the read or write strobe. Write data remain driven throughout the cycle; read data are captured into the micro on the rising edge of the read strobe.

So in the FPGA, I synchronize everything -- address, write data, read and write strobes -- to the FPGA clock. I decode the address as necessary. If writing, I simply use the assertion of the write enable as a clock enable for the selected registers I define. No need to find an edge, because we know the write data are valid before and after the write enable is asserted. For reads, the address is decoded as a big mux select. The mux output is driven onto the data bus while the read enable (the version synched to the FPGA clock) is asserted. So the read enable (gated by the address) is the data bus output enable. Since the synchronized version of the read enable goes away after the micro captures the read data, everything's fine.

The point, then, is synchronize your bus to the FPGA clock, decode the address, and write to the addressed registers while the write enable is asserted, and drive the bus back to the micro when the read enable is asserted.

[sparkybg]

Oh, now I see! :) Obviously I had many wrong assumptions about what happens at the mcu buses.

As for the datasheet - it is the same document for all RX62N and RX621 devices. The times are 30ns for the smaller RX62x devices (upto 100 pin) and 15ns for the 144pin device I am planning to use. The maximum BCLK clock for the smaller devices is 50Mhz, and for the 144 pin device it is 100Mhz. In real life, with widely available crystals, device runs at 96Mhz, and the BCLK I am using is 48Mhz.

However, pointing out what to look at cleared some things out. Thanks again.

Here is it:

I hope to be able to write with the the CSON=0 and WRON, WDON, WDOFF, CSWWAIT and CSWOFF equal to one - this is the absolute minumum the datasheet permits, and this gives 3 clock cycles per read. And for the 144 pin device Tad=Tbcd=Tsd=Twrd=Twdd=15ns max. And the Twdh is 0ns min. At 48Mhz BCLK and this is a little less than 21ns clock cycle. And this assures there will be a valid data and address at the trailing(positive) edge of the WR# signal (at least 5ns before it), and it will be available at least 5ns after the edge (at maximim Twrd of 15ns and minimum Twdh of 0ns). Am I right on this?

If so, I will have to register the address and data on that edge, and then synchronise this data along with the write request to FPGA clock - your first approach before the update you have made to the code.

[bassman59]

---

sparkybg wrote:

Oh, now I see! :) Obviously I had many wrong assumptions about what happens at the mcu buses.

As for the datasheet - it is the same document for all RX62N and RX621 devices. The times are 30ns for the smaller RX62x devices (upto 100 pin) and 15ns for the 144pin device I am planning to use. The maximum BCLK clock for the smaller devices is 50Mhz, and for the 144 pin device it is 100Mhz. In real life, with widely available crystals, device runs at 96Mhz, and the BCLK I am using is 48Mhz.

However, pointing out what to look at cleared some things out. Thanks again.

Here is it:

I hope to be able to write with the the CSON=0 and WRON, WDON, WDOFF, CSWWAIT and CSWOFF equal to one - this is the absolute minumum the datasheet permits, and this gives 3 clock cycles per read. And for the 144 pin device Tad=Tbcd=Tsd=Twrd=Twdd=15ns max. And the Twdh is 0ns min. At 48Mhz BCLK and this is a little less than 21ns clock cycle. And this assures there will be a valid data and address at the trailing(positive) edge of the WR# signal (at least 5ns before it), and it will be available at least 5ns after the edge (at maximim Twrd of 15ns and minimum Twdh of 0ns). Am I right on this?

If so, I will have to register the address and data on that edge, and then synchronise this data along with the write request to FPGA clock - your first approach before the update you have made to the code.

---

I suppose if the BCLK output is available on a micro pin, you can bring that into the FPGA on a global clock and use it.

Synchronization therefore isn't necessary because the signals are already on the clock.

For micro write cycles, again, just code so that the register write in your FPGA occurs whenever WR# is low. According to the data sheet, there's some amount of clock-to-out, but who cares -- what matters is that WR# is low (as is CS#) and the data and address are valid on a rising edge of BCLK. According to that data sheet, the write data (and address and CS#) remain valid after WR# goes away, so things are simple.  You also have gobs of setup time before the rising edge of BCLK.

Literally, it's like this (I speak VHDL):

    RegisterWrite : process (BCLK) is

    begin

        if rising_edge(BCLK) then

            if wr_l = '0' and cs_l = '0' and addr = MYREGADDR then

                myreg <= data;

            end if;

        end if;

    end process RegisterWrite;

Hope this helps.

[sparkybg]

Thanks.

BCLK is available on a MCU pin, and I am using it to generate all the clocks I need in the FPGA. That's one of the reasons I had some bad assupmtions about synchronous/asynchronous nature of the input signals, and my biggest mistake was to assume that both address and data from the mcu are already available on the falling edge of the WR signal, which is, obviously,  not true.

The BCLK can be 24Mhz  dual edge (the things happen on rising and falling edge) or 48Mhz single edge (all happens on the rising edge). Than I multiple this clock by 4 if 24Mhz and by 2 if 48Mhz, and the resulting 96Mhz clock is the main global clock of the FPGA. The BCLK is used also for generating the clock for the LCD, and it should be around 6-7Mhz for a 320x240 LCD and around 30-35Mhz for a 800x480 LCD.

[rcingham]

"48MHz single edge"

That's the one to go for! FPGA F/Fs are single edge, except for DDR I/O buffers.

[sparkybg]

Yes.

By the way, registering on the rising edge of the WR signal appears to me to be very easily to use as clock signal to block RAM. The block RAM is 36 bits wide, which is exactly 20 bit address and 16 bit data I am using, so one block will be enough. And if the WR signal is connected as a clock to the one port of the block ram, the CE connected as a "write enable" of the same port, the data will be easily registered on the block ram, and two FPGA clocks later it will be for sure available for writing to SRAM. Very easy way to implement a write cache FIFO.

...but I will try this after I have a working project.

[bassman59]

---

sparkybg wrote:

. And if the WR signal is connected as a clock to the one port of the block ram, the CE connected as a "write enable" of the same port, the data will be easily registered on the block ram, and two FPGA clocks later it will be for sure available for writing to SRAM. Very easy way to implement a write cache FIFO.

---

No, don't do that. Connect the BCLK to the BRAM's clock input. Connect bus' WR signal to the BRAM's write input. Connect the bus' CE to the BRAM's EN input.

[sparkybg]

I've decided to use external crystal oscillator for FPGA and not use the MCU clock output at all. Anything looks good on simulation. Only the signals from MCU are asynchronous. Everything else uses the FPGA clock (including FIFO-s). This way, it looks exactly as SRAM to the MCU, and no clock from the MCU is connected.

Here's another question - is it better to use for example 100Mhz directly, or a 50Mhz oscillator and DCM to get 100Mhz.

Maybe I'll try a 120Mhz later, if all works. 120Mhz also looks ok on the simulation. I have used a 96Mhz MCU clock and 100Mhz FPGA clock on simulation in order MCU and FPGA to be asynchronous on simulation, and still it looks OK.

[eteam00]

How will your design be simplified by adding another clock?

-- Bob Elkind