Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Status
Not open for further replies.

whack

Member level 5
Joined
Feb 25, 2006
Messages
81
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,288
Activity points
2,258
I am implementing address translation for old nibble-mode DRAM input signals. This DRAM receives address in two halves, MSB half on falling edge of /RAS and then the LSB half on /CAS falling edge. After /CAS going down the first time DRAM outputs data. /CAS will go down three more times (for a total of four times) to get consecutive data out, but now DRAM chip shall ignore the address bus and increment the address in register/latch. This is called "nibble-mode" because the chip receives the address once but outputs four times in series.

The edge events are in order as follows /RAS, /CAS, /CAS, /CAS, /CAS, <don't care>, /RAS, /CAS, /CAS, /CAS, /CAS, <don't care>, etc...
Inside <don't care> there could be /CAS edge events, they are either DRAM refresh (CAS-before-RAS), those need to be ignored!

Timing diagram in datasheet:
https://www.jameco.com/Jameco/Products/ProdDS/41398TI.pdf
Note: we can't use page mode, only nibble-mode!!!

The destination memory is PSRAM on my FPGA board. The FPGA is a Spartan3E. PSRAM has a 23-bit parallel address bus, no halves here.
If you are confused now, we are taking nibble-mode DRAM control signals as input, and translating them into signals for PSRAM.

The following snippet of Verilog code is the FSM for getting full address (18-bit) and incrementing it for nibble-mode output. The "shift" bus is the I/O bus of my FPGA board. "Adr" register stores the full address.
Code:
always @(negedge RAS, negedge CAS) begin
	case(state)
		0: begin
			if (~RAS & CAS) begin
				Adr[8:0] = shift[25:17];
				state <= 1;
			end
		end
		1: begin
			if (~CAS) begin
				Adr[17:9] = shift[25:17];
				state <= 2;
			end
		end
		2: begin
			if (~CAS) begin
				Adr = Adr+1;
				state <= 3;
			end
		end
		3: begin
			if (~CAS) begin
				Adr = Adr+1;
				state <= 4;
			end
		end
		4: begin
			if (~CAS) begin
				Adr = Adr+1;
				state <= 0;
			end
		end
	endcase
end
However when I try to synthesize it, I get the following errors:
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[8]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[7]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[6]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[5]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[4]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[3]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[2]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[1]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[0]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[17]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[16]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[15]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[14]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[13]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[12]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[11]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[10]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <Adr[9]> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
ERROR:Xst:899 - "remote_sources/_/ram_test.v" line 137: The logic for <state> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
I'm not sure what it's not liking about these registers (they are not driven anywhere else), and better yet, how to rewrite this to make it synthesizable?

Thanks in advance!

PS the hardware design I can't change. It's an old machine with nibble-mode DRAM interface.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

you have two edges where it is not clear that one is a clock and on is a reset/set. Look at the XST manual for describing clocked logic with an async reset/set/load.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

you have two edges where it is not clear that one is a clock and on is a reset/set. Look at the XST manual for describing clocked logic with an async reset/set/load.

I'm not sure I understood you. There is no clock signal in that FSM, as far as I can see. It does one transition on one signal edge and does four others on another signal edge. Not really a reset either.

Can you point me to a page in the manual you are referring to?

Thanks!
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

The way you have written the code implies two clocks - RAS and CAS.
I suggest using a system clock many times faster than RAS and CAS so that they can be sampled.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

posedge, negedge are used to see if an edge has occured, i.e. like a clock edge. If you use them outside of them being a reset or actual clocks then you will end up with something that is not synthesizable.


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// basic FF
always @ (posedge clk) begin
  q <= d;
end
 
// FF with asynchronous active low reset
always @ (posedge clk, negedge rst) begin
  if (!rst) begin
    q <= 0;
  end else begin
    q <= d;
  end
end
 
// FF with synchronous active low reset
always @ (posedge clk) begin
  if (!rst) begin
    q <= 0;
  end else begin
    q <= d;
  end
end

 

Re: FSM for nibble-mode DRAM not synthesizable &quot;no known FF or Latch template&quot;

Thanks guys!

I've read up on edge detection methods and I think I will run the FSM on just clk input.

A question though, I made measurements on the input signals using a digital oscilloscope and found that /CAS stays low for only about 50ns, and that's when my output should be enabled. The clk on my FPGA board is 50MHz (20ns period). Do you think it would be realistic to sample the /CAS signal with the FPGA I have or should I give now?

In the past I've only worked with relatively slow signals where timings were forgiving, but I'm not so sure if this FPGA at this clock can do it. I'd like an experienced opinion on that.

Thanks!

- - - Updated - - -

Actually the FPGA board has a socket for a second oscillator. According to datasheet FPGA XC3S1200E speed grade -4 and stepping 1 can have up to 240MHz clock input. Would getting the faster clock be necessary to reliably sample the active-low signal that lasts 50ns? Or would the 50MHz included clock be adequate?
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Rereading your original post it appear to me you are trying to implement a bridge from a nibble mode DRAM interface (from some other device, which I presume can not be modified?) to a PSRAM device?

I don't think you want to sample with a clock that has a period that has only a 2.5x ratio to the 50 ns. You could sample using the clk2x output of the DCM which will give you a 5x ratio. And 100 MHz clock in a spartan 3e shouldn't be too bad to work with.
 
  • Like
Reactions: whack

    whack

    Points: 2
    Helpful Answer Positive Rating
Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Rereading your original post it appear to me you are trying to implement a bridge from a nibble mode DRAM interface (from some other device, which I presume can not be modified?) to a PSRAM device?
Exactly correct! (And I also made a mistake mapping row/column bits to PSRAM address, I will post corrected FSM once I test it).

I don't think you want to sample with a clock that has a period that has only a 2.5x ratio to the 50 ns. You could sample using the clk2x output of the DCM which will give you a 5x ratio. And 100 MHz clock in a spartan 3e shouldn't be too bad to work with.
Wow, that's really cool. I didn't know I could do clock multiplication on the device... I need to play around with this. So is there any advantage of using a 100MHz clock for sampling versus say 200MHz (DCM seems to be capable of it)?
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Spartan 3e DCM is pretty limited. You can get 0, 90, 180, and 270 degree phase shifted outputs of the input clock and 2x 0 and 180 degree phase shifted clocks, a lower frequency (than input clock) FX clock, and finally a divided output. It's pretty limited, so no you can't multiply by 4 and doing so by cascading DCMs will give you a large amount of clock jitter.

Now if you were using a Spartan 6 you wouldn't be stuck with such limitations as you would have a CMT (DCM+PLL).
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Oh, yeah. I was looking at the general overview of DCM and didn't see differences in specific device capabilities. Well, this should be good enough for now. I can always add that oscillator with higher frequency, right?

I'm happy to report that I implemented the clock doubling DCM and it works as expected. My oscilloscope only goes up to 20MHz so for testing I generated a 5MHz from 50MHz clock using a counter, and fed the 5MHz as input into the DCM. I assigned the 5MHz and 10MHz clocks to output pins and measured both frequencies with the oscilloscope as expected.

I will continue on now. Will be back with more questions. Thanks a bunch!
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

You can use the DDR or SERDES mode to oversample inputs/outputs if needed or possible.

I'm not sure if you are acting as a driver of this module or something else. The first post makes it sound like you have this device attached to the FPGA. CAS isn't an input to the FPGA in normal applications -- it is an output of the FPGA.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

You can use the DDR or SERDES mode to oversample inputs/outputs if needed or possible.
I'll have to look into that. Extra sampling rate never hurts. Thanks!
I'm not sure if you are acting as a driver of this module or something else. The first post makes it sound like you have this device attached to the FPGA. CAS isn't an input to the FPGA in normal applications -- it is an output of the FPGA.
No, not driver. Just emulating external memory for an old machine. RAS and CAS signals are in fact inputs, along with write enable and the row/column address bus.

I built a 48-pin 5V-tolerant level shifter module to interface the FPGA board to 5V logic and picked a project to try it out, figuring emulating memory would be trivial. Due to specifics of this type of memory it didn't turn out to be trivial, but at this point I don't really want to abandon it if I can finish it. I have understood the logic and provided I don't run into some limitation of my hardware all I have left to do is describe the logic and synthesize it.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Ok, so turnaround time is a requirement. Ta(c) is 40ns. oversampling in the manner I describe doesn't appear helpful. The clocked approach still appears feasible, unless there are more requirements you haven't mentioned.

The alternative is to implement the state machine in two parts, with one using ras as a clock and one using cas as a clock. This could work for slow enough logic. It only works because the clocks cannot fall at the same time, and a combination of rising cas and falling ras is invalid. Defining timing constraints between the two "clocks" is more difficult as well. However, the signals are slow, and do have defined setup/hold relative to each other when one is clocking the other.

There is another alternative, but it is much worse.

(on a small aside, it is better to convert 50MHz to 100Mhz and use 100Mhz to generate the output 10Mhz. FPGA's have some dedicated routing and resources for clocking -- DCM's, BUFGs, the clock network. A logic-based divider moves the clock source into the FPGA fabric. The delay from "wherever the tools place it" to the final BUFG can change with each build. It is also more affected by process/voltage/temperature. It also creates more jitter and width imbalance. For single, low-rate clock designs this works well enough. Most commercial designs use multiple higher rate clocks where all of these issue matter. In the FPGA industry, there is a very strong preference to keep the clocks on dedicated resources only. This is also why I don't like the idea of using RAS/CAS as clocks directly. However, the design is such that I know it is technically possible to do this.)
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Is it possible for two signals that are in sync to be arriving 60-70ns out of sync when routed through the FPGA? I'm sampling at 100MHz right now giving me theoretical 10ns accuracy... I measured those two signals rising and falling 60-70ns apart, yet on my oscilloscope they are exactly in sync. Specifically the two signals are CAS for lower and upper bytes of the 16-bit data word. For whatever reason they exist as two separate signals yet I have never seen them have different value on the oscilloscope.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Is it possible for two signals that are in sync to be arriving 60-70ns out of sync when routed through the FPGA?
Hardly by routing and logic cell delays only. More likely the delay is caused by sequential logic implemented in your FPGA. Possibly unintentionally, but according to your actual code.
 

Re: FSM for nibble-mode DRAM not synthesizable "no known FF or Latch template"

Hardly by routing and logic cell delays only. More likely the delay is caused by sequential logic implemented in your FPGA.
Glitches in the signal were the culprit. As a matter of fact I am getting a lot of glitches on all of the input signal lines. I turned my FPGA board into a logic analyzer and recorded signal values into RAM. I then read back the RAM and graphed the data on my computer. There are too many glitches. That's what caused me to think that signals were out of sync when in fact the input glitches were causing my FSM to transition states prematurely.

Now, the glitches are always positive, meaning I get a 1 where 0 should be, but never the other way. From electrical standpoint, what could be the cause of such glitches and how to fix the problem?

(PSRAM writing FSM is well tested by the way)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top