Lattice Diamond EBR with registered output issues - Page 1
Forum section: electronics / general

author: MorgothCreator
author_rank: Contributor
timestamp: June 16, 2018, 11:44:59 am
content: Hy, I am new in this forum,I have a problem and I want to know if somebody has do some workaround for this issue.The issue is with RAM/ROM mapped in EBR with registered outputs, I know that Lattice has the IPxpress utility, but I do not want to use it, I want to use generic modules.What I try to implement is this for ROM:Code:module rom #(parameter ADDR_ROM_BUS_WIDTH = 14,parameter ROM_PATH = "NONE") (input clk,input [ADDR_ROM_BUS_WIDTH-1:0] a,output reg[15:0]d);(* ram_style="block" *)reg [15:0] mem [(2**ADDR_ROM_BUS_WIDTH)-1:0];initial beginif (ROM_PATH != "NONE")$readmemh(ROM_PATH, mem);endalways @ (posedge clk)begind <= mem;endendmoduleAnd this for RAM:Code:module ram #(parameter ADDR_BUS_WIDTH = 13, /* < in address lines */parameter DATA_BUS_WIDTH = 8,parameter RAM_PATH = "NONE") (input clk,input we,input re,input [ADDR_BUS_WIDTH - 1:0] a,input [DATA_BUS_WIDTH - 1:0] d_in,output [DATA_BUS_WIDTH - 1:0] d_out);(* ram_style="block" *)reg [DATA_BUS_WIDTH - 1:0] mem [(2**ADDR_BUS_WIDTH-1):0];initial beginif (RAM_PATH != "NONE")$readmemh(RAM_PATH, mem);endalways@(posedge clk) beginif(we)mem <= d_in;endreg [DATA_BUS_WIDTH - 1:0]d_out_tmp;always@(posedge clk) begind_out_tmp <= mem;endassign d_out = re ? d_out_tmp : 'bz;endmoduleHow can be seed are very generic modules for RAM and ROM implementations.The Lattice Diamond simulate and synthesize this modules correctly (the project work perfectly on simulation), but when I upload the configuration, all memory with registered output give 0 at output.When I implemented this two modules with unregistered outputs I have the expected values at output( for ROM ).This two modules work perfectly on XILINX, but I need to port the project on single chip solution, and the only devices with internal nonvolatile memory configuration and cheap are those from LATTICE.This two modules are integrated in MEGA/XMEGA open source core IP developed by me found here:https://git.morgothdisk.com/MorgothCreator/XMEGA-CORE-IP-TST

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 16, 2018, 05:17:27 pm
content: Not quite sure what you are after.Registered outputs have a one-clock cycle lag due to the registering. Did you account for that? (I suspect this may be the issue since it seems to work without registering).

author: MorgothCreator
author_rank: Contributor
timestamp: June 17, 2018, 11:53:55 am
content: Yes I accounted that, the problem is that in registered output mode seems that the output register does not load the data from EBR on positive edge, seems that the output register is always in reset mode.In IPxpress the plugin generate a reset signal for output register that can be tied to 0, but in my approach I do not use that signal and by default the synthesizer will tie this signal to 0, in reality is possible not to be the case ( the output register reset signal is an asynchronous signal active high ), because the output value of the output register is always 0 on every address I read.On attach I have two print screen of the same module but different settings, the first is the ROM using EBR, the second is the ROM using LOGIC, the same module two different results on hardware implementation.

author: Bassman59
author_rank: Super Contributor
timestamp: June 17, 2018, 03:32:31 pm
content: Quote from: MorgothCreator on June 17, 2018, 11:53:55 amI don’t have access to the Lattice Diamond tools at the moment, but I recall that the polarity of the output-register reset is programmable and it’s not quite obvious as to its state. Look for an inversion bubble on the reset pin. And the signal names generated by the IPExpress don’t indicate polarity.Sorry for the noise (I'm confusing Lattice tools with Microsemi's). The output registers for the embedded memories in MachXO2 devices have active high resets, and reset polarity is not programmable. That said, when you write HDL to infer the memory, if your code uses an active-low reset, an inverter will be inferred and placed at the EBR's RST input.The reset can be synchronous or asynchronous.

author: MorgothCreator
author_rank: Contributor
timestamp: June 17, 2018, 03:50:17 pm
content: Oh, I discovered that anything that have something in common with EBR and distributed RAM is a mess.And off course that the Lattice guys close the official forum and let all people with no support and a bunch of datasheets that tell nothing, good guys.I try everything, the implementation of EBR and distributed RAM in Lattice Diamond is a mess.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 17, 2018, 09:51:14 pm
content: Well, not sure why you don't want to use IPexpress. Never really had issues with it.You could still use it to generate an example IP code and take a look at the generated code to see how it uses EBR modules. There could be a bug or a limitation in the modules that they work around with IPexpress.

author: MorgothCreator
author_rank: Contributor
timestamp: June 18, 2018, 05:38:32 am
content: You are right, but I am very frustrated that the Lattice guys was working to a plugin to generate the correct code to be understood by the implementation to correctly implement EBR and distributed ram instead of fixing these for generic usage.I need those memory modules to be parameterized, and if I use IPexpress the result code is a mess again, with individual EBR's and multiplexers and parameterized data and all package of weird stuff.And is bad because are the cheapest devices and the only with internal nonvolatile memory with that can be made entire project in a single chip, is the best FPGA for small projects, I love it but........ .I come from C/C++ world and I am accommodate with porting codes from one platform to another without changes

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 18, 2018, 01:18:33 pm
content: Quote from: MorgothCreator on June 18, 2018, 05:38:32 amGood point.Generic code usually stops at the "IP" generation level of most FPGA tools. That's a (slight) annoyance since it can't even be automated.

author: MorgothCreator
author_rank: Contributor
timestamp: June 18, 2018, 01:59:11 pm
content: Oh, I love XILINX VIVADO, do such a love job, understand everything

author: daveshah
author_rank: Unknown
timestamp: June 18, 2018, 02:01:27 pm
content: I think the 'bz is possible confusing things? What if you try 'bx, or removing it altogether?

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 18, 2018, 02:21:38 pm
content: Quote from: MorgothCreator on June 18, 2018, 01:59:11 pmHaven't tried it yet. Unfortunately it doesn't support the Spartan 6 line, which bites.

author: MorgothCreator
author_rank: Contributor
timestamp: June 18, 2018, 04:32:47 pm
content: Quote from: daveshah on June 18, 2018, 02:01:27 pm'bz is a three state, 'bx is undefined state?

author: Bassman59
author_rank: Super Contributor
timestamp: June 18, 2018, 05:35:51 pm
content: Quote from: MorgothCreator on June 18, 2018, 04:32:47 pmActually, now that I look at the first post, I have to ask -- why this assignment:Code:assign d_out = re ? d_out_tmp : 'bz;If this is inside the chip, you should see synthesis complaints about internal tristates and possible conversions to muxes. Remember, the MachXO2 doesn't have internal tristates. Synplify will add logic to convert them to muxes; I don't know if the Lattice Synthesis Engine will do so. But in any case, if you instantiate multiple EBRs, say for depth expansion, you should code up the mux yourself (use higher-order address bits as the select, add a register to the output of the mux if necessary). Don't rely on the synthesis tool to get this right.

author: MorgothCreator
author_rank: Contributor
timestamp: June 18, 2018, 06:26:28 pm
content: Ok, thank you for the advice.I use MachXO3LF but thank you again for the advice.QuoteI have no choice, I will code the RAM and ROM from individual EBR's with MUX's at output and REG's.My problem is that the ROM memory need to be initialized from a file ( and is a mess to parse data from file to each EBR ), and RAM memory is not the only one on the data bus, the RAM data output I need to be three state on re == 0.

author: daveshah
author_rank: Unknown
timestamp: June 18, 2018, 07:30:57 pm
content: FPGAs haven't had internal tristate buffers for a long time, probably the last parts like that were released around 2000. Although synthesis tools may infer muxes from tristate logic, I don't know how standardised this behaviour is so it is probably better to avoid it and use explicit mux type constructs - less likely to end up with simulation/formal/synthesis mismatches this way too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 18, 2018, 08:21:18 pm
content: Quite right. Just a small article on this:http://fpgasite.blogspot.com/2017/05/fpga-internal-tri-state-buses.html