FPGA Central

I just inserted an inferred ram module into my code, and all of a
sudden it takes forever to synthesize...I only inferred one
ramblock...is there anything I can do to get it down to a reasonable
time? I have a lot of warnings, but still...I went from a few seconds
to synth now taking minutes.....??

thanks for your help

On 16 Aug., 13:25, andersod2 <[email protected]> wrote:
> I just inserted an inferred ram module into my code, and all of a
> sudden it takes forever to synthesize...I only inferred one
> ramblock...is there anything I can do to get it down to a reasonable
> time? *I have a lot of warnings, but still...I went from a few seconds
> to synth now taking minutes.....??


We need more data:
- synthesis tool?
- language?
- taget technology?
- size of the ram?

Kolja

"andersod2" <[email protected]> wrote in message
news:91c3827f-cc64-485d-894d-7438de4673a4@b38g2000prf.googlegroups.com...
>
> I just inserted an inferred ram module into my code, and all of a
> sudden it takes forever to synthesize...I only inferred one
> ramblock...is there anything I can do to get it down to a reasonable
> time? I have a lot of warnings, but still...I went from a few seconds
> to synth now taking minutes.....??
>

Most likely you're not quite following the template (although you think you
are) and what is getting synthesized has to get implemented in logic cells
rather than internal memory.

Another cause than cause logic instead of internal memory to be used that
I've seen is that even though my code exactly followed the template I had to
manually add an attribute to the read address signal to prevent the signal
from getting changed. Whatever it was doing optimized it into some form
that the synthesis tool thought it needed logic cells and couldn't use
internal memory. Since adding (or not adding) an attribute to a signal does
absolutely nothing to the function of the code, it was just something that
needed to be done. I opened a case with the tool supplier, not fixed yet,
possibly soon.

KJ

Kolja,
Sorry it was late and I wasn't thinking right....
-Webpack ISE (9.x?)
-Verilog
-Spartan3a
-1 ram block = 18k bits partitioned at 72x256 (legal partition
according to docs...well some of them at least)



KJ,
Thanks a lot...I think you may be right because I'm getting a lot of
latch warnings, but didn't understand why. I am using inferred ram,
which the docs say will work the same as an explicit template
instantiation if I just use the typical "reg [w:x] mem[y:z];"
notation...do you think using a template is always the better way to
go? If this isn't evidence for that, then I don't know what is
because I'm not doing anything special. In fact I lifted the code for
my mem module from a verilog site...if there's a a way I can guarantee
that the inferred ram will be put in a block I would very much like to
know as I find it much easier to work with than the template. Is that
a constraints thing?
thanks again for your help

On Aug 17, 3:45 am, andersod2 <[email protected]> wrote:
> Kolja,
> Sorry it was late and I wasn't thinking right....
> -Webpack ISE (9.x?)
> -Verilog
> -Spartan3a
> -1 ram block = 18k bits partitioned at 72x256 (legal partition
> according to docs...well some of them at least)
>
> KJ,
> Thanks a lot...I think you may be right because I'm getting a lot of
> latch warnings, but didn't understand why. I am using inferred ram,
> which the docs say will work the same as an explicit template
> instantiation if I just use the typical "reg [w:x] mem[y:z];"
> notation...do you think using a template is always the better way to
> go? If this isn't evidence for that, then I don't know what is
> because I'm not doing anything special. In fact I lifted the code for
> my mem module from a verilog site...if there's a a way I can guarantee
> that the inferred ram will be put in a block I would very much like to
> know as I find it much easier to work with than the template. Is that
> a constraints thing?
> thanks again for your help

There is RAM and there is RAM. If you are inferring async RAM in an
FPGA, it is likely that this does not map to any existing feature in
the device. Most FPGAs use synchronous block RAM which requires a
registered model. Rather than getting generic RAM code from a VHDL
site, check the site for your FPGA supplier for code to infer a RAM
that works for their parts. Or at very least, check for a model from
the site for the synthesis tool you are using.

Rick

On Aug 17, 1:19*am, rickman <[email protected]> wrote:
> On Aug 17, 3:45 am, andersod2 <[email protected]> wrote:
>
>
>
> > Kolja,
> > Sorry it was late and I wasn't thinking right....
> > -Webpack ISE (9.x?)
> > -Verilog
> > -Spartan3a
> > -1 ram block = 18k bits partitioned at 72x256 (legal partition
> > according to docs...well some of them at least)
>
> > KJ,
> > Thanks a lot...I think you may be right because I'm getting a lot of
> > latch warnings, but didn't understand why. *I am using inferred ram,
> > which the docs say will work the same as an explicit template
> > instantiation if I just use the typical "reg [w:x] mem[y:z];"
> > notation...do you think using a template is always the better way to
> > go? *If this isn't evidence for that, then I don't know what is
> > because I'm not doing anything special. *In fact I lifted the code for
> > my mem module from a verilog site...if there's a a way I can guarantee
> > that the inferred ram will be put in a block I would very much like to
> > know as I find it much easier to work with than the template. *Is that
> > a constraints thing?
> > thanks again for your help
>
> There is RAM and there is RAM. *If you are inferring async RAM in an
> FPGA, it is likely that this does not map to any existing feature in
> the device. *Most FPGAs use synchronous block RAM which requires a
> registered model. *Rather than getting generic RAM code from a VHDL
> site, check the site for your FPGA supplier for code to infer a RAM
> that works for their parts. *Or at very least, check for a model from
> the site for the synthesis tool you are using.
>
> Rick

All Xilinx BlockRAMs are synchronous, they need a clock not only for
writing, but also for reading (the register the incoming address and
control information with a clock edge). In our documentation we often
say: "nothing happens without a clock".
Traditional RAMs may not have that requirement, and the distributed
(LUT-) RAM can read data without the use of a clock.
Peter Alfke, Xilinx

"andersod2" <[email protected]> wrote in message
news:99b1281a-a30f-4949-b6aa-bbf42c3824dc@y38g2000hsy.googlegroups.com...
>
>
>
> KJ,
> Thanks a lot...I think you may be right because I'm getting a lot of
> latch warnings, but didn't understand why. I am using inferred ram,
> which the docs say will work the same as an explicit template
> instantiation if I just use the typical "reg [w:x] mem[y:z];"
> notation...do you think using a template is always the better way to
> go?

To infer memory in any device you need to follow the template for that
device. For FPGAs, you typically have only synchronous memory (as rickman
and Peter have pointed out), the basic template for this type of memory, in
VHDL is...

process(clk)
begin
if rising_edge(clk) then
if (write_enable = '1') then
ram(write_address) <= write_data;
end if;
read_data <= ram(read_address);
end if;
end process;

> In fact I lifted the code for
> my mem module from a verilog site...

Hopefully one that produces synthesizable Verilog code.

> if there's a a way I can guarantee
> that the inferred ram will be put in a block I would very much like to
> know as I find it much easier to work with than the template. Is that
> a constraints thing?

As I mentioned in the first post, I've found occasion where I had to add an
attribute to the 'read_address' signal in order to get the tool to use the
internal memory. I would suggest:
- Take the above snippet of code (or peruse Xilinx's website for their
template) and get that working in Verilog.
- Build just that module and see if it does indeed get built correctly using
the internal memory.
- Integrate that into your real design and rebuild and check that it also
gets built correctly (this is the point where I found that it wasn't and
needed the extra attribute attached to 'read_address).
- If all else fails, open a case with Xilinx.

KJ

On Aug 17, 8:21 pm, "KJ" <[email protected]> wrote:
> "andersod2" <[email protected]> wrote in message
>
> news:99b1281a-a30f-4949-b6aa-bbf42c3824dc@y38g2000hsy.googlegroups.com...
>
>
>
> > KJ,
> > Thanks a lot...I think you may be right because I'm getting a lot of
> > latch warnings, but didn't understand why. I am using inferred ram,
> > which the docs say will work the same as an explicit template
> > instantiation if I just use the typical "reg [w:x] mem[y:z];"
> > notation...do you think using a template is always the better way to
> > go?
>
> To infer memory in any device you need to follow the template for that
> device. For FPGAs, you typically have only synchronous memory (as rickman
> and Peter have pointed out), the basic template for this type of memory, in
> VHDL is...
>
> process(clk)
> begin
> if rising_edge(clk) then
> if (write_enable = '1') then
> ram(write_address) <= write_data;
> end if;
> read_data <= ram(read_address);
> end if;
> end process;
>
> > In fact I lifted the code for
> > my mem module from a verilog site...
>
> Hopefully one that produces synthesizable Verilog code.
>
> > if there's a a way I can guarantee
> > that the inferred ram will be put in a block I would very much like to
> > know as I find it much easier to work with than the template. Is that
> > a constraints thing?
>
> As I mentioned in the first post, I've found occasion where I had to add an
> attribute to the 'read_address' signal in order to get the tool to use the
> internal memory. I would suggest:
> - Take the above snippet of code (or peruse Xilinx's website for their
> template) and get that working in Verilog.
> - Build just that module and see if it does indeed get built correctly using
> the internal memory.
> - Integrate that into your real design and rebuild and check that it also
> gets built correctly (this is the point where I found that it wasn't and
> needed the extra attribute attached to 'read_address).
> - If all else fails, open a case with Xilinx.

Please keep in mind that when looking for templates, it is not the
logic vendor who sets the standard, it is the synthesis tool vendor.
So rather than looking at the Xilinx/Altera/Lattice site, I suggest
that you look at Synplicity/Mentor... depending on your tool.

Rick

On Aug 18, 10:06*am, rickman <[email protected]> wrote:
> On Aug 17, 8:21 pm, "KJ" <[email protected]> wrote:
>
> Please keep in mind that when looking for templates, it is not the
> logic vendor who sets the standard, it is the synthesis tool vendor.
> So rather than looking at the Xilinx/Altera/Lattice site, I suggest
> that you look at Synplicity/Mentor... depending on your tool.
>
> Rick

Good point, but in this particular instance the synthesis tool that is
being used is 'Webpack ISE' from Xilinx.

KJ

Ok, thanks much guys. Haven't had time to work on this the last
couple of days, so will get back to it soon. I was indeed using async
ram and had no idea that synchronous was required. I read in one of
the xilinx docs (can't remember which) that the above declaration I
posted was all I needed for inference. I think I will go the
instantiation route, though as that seems a bit more sure-fire. Will
post if I have more problems with that route.

On Aug 18, 5:10 pm, andersod2 <[email protected]> wrote:
> Ok, thanks much guys. Haven't had time to work on this the last
> couple of days, so will get back to it soon. I was indeed using async
> ram and had no idea that synchronous was required. I read in one of
> the xilinx docs (can't remember which) that the above declaration I
> posted was all I needed for inference. I think I will go the
> instantiation route, though as that seems a bit more sure-fire. Will
> post if I have more problems with that route.

Keep in mind that when using instantiation it can be hard, if not
impossible to view the contents of RAM since this is a black box to
the simulator. You will only be able to see the inputs and outputs.
If you infer the RAM, you can directly view it to see what was written
at any given time. I expect that inferred RAM will model correctly
when performing a post-route timing simulation.

Rick

rickman <[email protected]> writes:

> On Aug 18, 5:10 pm, andersod2 <[email protected]> wrote:
>> Ok, thanks much guys. Haven't had time to work on this the last
>> couple of days, so will get back to it soon. I was indeed using async
>> ram and had no idea that synchronous was required. I read in one of
>> the xilinx docs (can't remember which) that the above declaration I
>> posted was all I needed for inference. I think I will go the
>> instantiation route, though as that seems a bit more sure-fire. Will
>> post if I have more problems with that route.
>
> Keep in mind that when using instantiation it can be hard, if not
> impossible to view the contents of RAM since this is a black box to
> the simulator.

Certainly the Xilinx models are not black-box to the simulaator - they
are still written in VHDL. They can be a bit cryptic for the user,
especially if you've instantiated (or coregen'ed) a set of RAMs, one
for each data bit, but the info is all there.

Having said that, I haven't had the need to instantiate a RAM, except
in the case of a dual-port RAM with two different clocks, which my
current synth tools can't infer.

<snip>

Cheers,
Martin
--
[email protected]
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote:

>Having said that, I haven't had the need to instantiate a RAM, except
>in the case of a dual-port RAM with two different clocks, which my
>current synth tools can't infer.

Hmmmm.... I've been playing with a cache design that needs
rather wide data words. I decided I could get 72-bit wide
single-port memory out of just one BlockRAM by using both
ports simultaneously, with addresses that were identical
save for just one bit that was tied to 0 on one port and
tied to 1 on the other.

I wrote a nice inference model...

Two major synth tools correctly inferred the memory as
a write-first BlockRAM, but inferred two distinct RAM
blocks instead of using both ports, thereby wasting
half of each block.

ISE 8.2 (yeah, I know it's ancient, but I haven't got
around to installing anything newer yet) just locked-up
with 100% CPU usage, presumably because it failed to
infer the RAM from my description and was trying to
build a gazillion registers instead. Must go look up
the correct inference templates for XST :-)

Does anyone know how to pull this double-width/single-port
trick without using instantiation?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

was actually trying something very similar myself...perhaps same
problem...that's why I'm going for instantiation for now...tell me if
you find a good inference model...

On Tue, 19 Aug 2008 10:15:50 +0100, Jonathan Bromley wrote:

>ISE 8.2 (yeah, I know it's ancient, but I haven't got
>around to installing anything newer yet) just locked-up
>with 100% CPU usage, presumably because it failed to
>infer the RAM from my description and was trying to
>build a gazillion registers instead. Must go look up
>the correct inference templates for XST :-)

Ahah! Got it...

XST User Guide is a bit woolly about Verilog
RAM inference. It turns out that this form is OK:

always @(posedge clock)
if (enable) begin
if (write) begin
mem[address] <= write_data;
read_data <= write_data ;
end else begin
read_data <= mem[address];
end
end

but this form is not - it hangs XST:

always @(posedge clock)
if (enable) begin
if (write) begin
mem[address] = write_data;
end
read_data <= mem[address];
end

Despite what it says in the XST user guide, it seems
that the same story applies in VHDL: the memory store
must be a signal.

Have I missed something?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On Aug 19, 5:15 am, Jonathan Bromley <[email protected]>
wrote:
> On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote:
> >Having said that, I haven't had the need to instantiate a RAM, except
> >in the case of a dual-port RAM with two different clocks, which my
> >current synth tools can't infer.
>
> Hmmmm.... I've been playing with a cache design that needs
> rather wide data words. I decided I could get 72-bit wide
> single-port memory out of just one BlockRAM by using both
> ports simultaneously, with addresses that were identical
> save for just one bit that was tied to 0 on one port and
> tied to 1 on the other.
>
> I wrote a nice inference model...
>
> Two major synth tools correctly inferred the memory as
> a write-first BlockRAM, but inferred two distinct RAM
> blocks instead of using both ports, thereby wasting
> half of each block.
>
> ISE 8.2 (yeah, I know it's ancient, but I haven't got
> around to installing anything newer yet) just locked-up
> with 100% CPU usage, presumably because it failed to
> infer the RAM from my description and was trying to
> build a gazillion registers instead. Must go look up
> the correct inference templates for XST :-)
>
> Does anyone know how to pull this double-width/single-port
> trick without using instantiation?

I don't know for sure, but I expect you can make it work by inferring
a standard dual port memory where both ports access the same address
space. I expect the vendors have a template for that. Then just feed
the two addresses with the high bit set or clear depending on the
port. The source you show below may infer memory, but it is single
port. I don't see any reason to expect the tools to be able to
recognize that you are using half of two memories and they can combine
them into one dual port memory.

Rick

always @(posedge clock)
if (enable1) begin
if (write1) begin
mem[address1] <= write_data1;
read_data1 <= write_data1 ;
end else begin
read_data1 <= mem[address1];
end
end
if (enable2) begin
if (write2) begin
mem[address2] <= write_data2;
read_data2 <= write_data2 ;
end else begin
read_data2 <= mem[address2];
end
end


How about this as a dual port memory?

Rick

On Tue, 19 Aug 2008 06:20:51 -0700 (PDT), rickman wrote:

>
> always @(posedge clock)
> if (enable1) begin
> if (write1) begin
> mem[address1] <= write_data1;
> read_data1 <= write_data1 ;
> end else begin
> read_data1 <= mem[address1];
> end
> end
> if (enable2) begin
> if (write2) begin
> mem[address2] <= write_data2;
> read_data2 <= write_data2 ;
> end else begin
> read_data2 <= mem[address2];
> end
> end
>
>
>How about this as a dual port memory?

It's a fine model, but I can't find a synth tool that
will infer DP memory when both ports can write.

If only one of the two ports has write, it's OK.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On Aug 19, 4:03 am, Jonathan Bromley <[email protected]>
wrote:
> On Tue, 19 Aug 2008 10:15:50 +0100, Jonathan Bromley wrote:
> >ISE 8.2 (yeah, I know it's ancient, but I haven't got
> >around to installing anything newer yet) just locked-up
> >with 100% CPU usage, presumably because it failed to
> >infer theRAMfrom my description and was trying to
> >build a gazillion registers instead. Must go look up
> >the correct inference templates for XST :-)
>
> Ahah! Got it...
>
> XST User Guide is a bit woolly about VerilogRAMinference. It turns out that this form is OK:
>
> always @(posedge clock)
> if (enable) begin
> if (write) begin
> mem[address] <= write_data;
> read_data <= write_data ;
> end else begin
> read_data <= mem[address];
> end
> end
>
> but this form is not - it hangs XST:
>
> always @(posedge clock)
> if (enable) begin
> if (write) begin
> mem[address] = write_data;
> end
> read_data <= mem[address];
> end
>
> Despite what it says in the XST user guide, it seems
> that the same story applies in VHDL: the memory store
> must be a signal.
>

I've found the XST user guide pretty helpful for these templates.
However,
beware some nasty potholes.

XST can get confused with the enables to the RAMS. Don't have the
docs in front of me right now - but I believe the BRAMs have seperate
read/write enables - as opposed to a global "enable" and seperate
read/write strobe or similar. XST could build enable logic different
than your description. For one of my cases, the way I had the
enables couldn't actually be mapped to a BRAM. Problem on my part -
however
XST happily went and built something anyway - which was incorrect.
i.e. didn't match the description, and didn't throw any
error/warning. Just happily tied the enables is some wrong fashion.

I've also had issues with getting XST to infer the"read first/write
first" attribute
correctly. This one really bit me once - 3, or 4 days of lab debug to
figure out
XST had inferred "write first", when the description was
read first.

Other than that - the RAM inferrence in XST seems to work.

For the two write port RAMS, what I've got is the memory
being written two in two seperate procedural blocks (normally a no-
no):
i.e.

always @( posedge clk1)
if( wren1 )
mem[ addr1 ] <= data1;
...


always @( posedge clk2)
if( wren2 )
mem[ addr2 ] <= data2;
...

Although I confess, I haven't used this one in XST yet, just sims.

Regards,

Mark

On Aug 19, 5:27*pm, "[email protected]" <[email protected]> wrote:
> On Aug 19, 4:03 am, Jonathan Bromley <[email protected]>
> wrote:
>
>
>
> > On Tue, 19 Aug 2008 10:15:50 +0100, Jonathan Bromley wrote:
> > >ISE 8.2 (yeah, I know it's ancient, but I haven't got
> > >around to installing anything newer yet) just locked-up
> > >with 100% CPU usage, presumably because it failed to
> > >infer theRAMfrom my description and was trying to
> > >build a gazillion registers instead. *Must go look up
> > >the correct inference templates for XST :-)
>
> > Ahah! Got it...
>
> > XST User Guide is a bit woolly about VerilogRAMinference. It turns out that this form is OK:
>
> > * always @(posedge clock)
> > * * if (enable) begin
> > * * * if (write) begin
> > * * * * mem[address] <= write_data;
> > * * * * read_data <= write_data ;
> > * * * end else begin
> > * * * * read_data <= mem[address];
> > * * * end
> > * * end
>
> > but this form is not - it hangs XST:
>
> > * always @(posedge clock)
> > * * if (enable) begin
> > * * * if (write) begin
> > * * * * mem[address] = write_data;
> > * * * end
> > * * * read_data <= mem[address];
> > * * end
>
> > Despite what it says in the XST user guide, it seems
> > that the same story applies in VHDL: the memory store
> > must be a signal.
>
> I've found the XST user guide pretty helpful for these templates.
> However,
> beware some nasty potholes.
>
> XST can get confused with the enables to the RAMS. *Don't have the
> docs in front of me right now - but I believe the BRAMs have seperate
> read/write enables - as opposed to a global "enable" and seperate
> read/write strobe or similar. *XST could build enable logic different
> than your description. *For one of my cases, the way I had the
> enables couldn't actually be mapped to a BRAM. Problem on my part -
> however
> XST happily went and built something anyway - which was incorrect.
> i.e. didn't match the description, and didn't throw any
> error/warning. *Just happily tied the enables is some wrong fashion.
>
> I've also had issues with getting XST to infer the"read first/write
> first" attribute
> correctly. *This one really bit me once - 3, or 4 days of lab debug to
> figure out
> XST had inferred "write first", when the description was
> read first.
>
> Other than that - the RAM inferrence in XST seems to work.
>
> For the two write port RAMS, what I've got is the memory
> being written two in two seperate procedural blocks (normally a no-
> no):
> i.e.
>
> always @( posedge clk1)
> * if( wren1 )
> * * mem[ addr1 ] <= data1;
> * *...
>
> always @( posedge clk2)
> * if( wren2 )
> * * mem[ addr2 ] <= data2;
> * *...
>
> Although I confess, I haven't used this one in XST yet, just sims.
>
> Regards,
>
> Mark

Regarding Enables:
All Xilinx BlockRAMs have a Clock Enable input that, if inactive,
stops all writing and reading. There is also a Read/Write input that
selects between reading and writing. That means, there is no explicit
overriding "write enable" or "read enable" or "write strobe" or "read
strobe". You can always do what you want to get done by following the
rules (except you cannot read or write without a clock).
Peter Alfke

On Aug 19, 10:22 am, Jonathan Bromley <[email protected]>
wrote:
> On Tue, 19 Aug 2008 06:20:51 -0700 (PDT), rickman wrote:
>
> > always @(posedge clock)
> > if (enable1) begin
> > if (write1) begin
> > mem[address1] <= write_data1;
> > read_data1 <= write_data1 ;
> > end else begin
> > read_data1 <= mem[address1];
> > end
> > end
> > if (enable2) begin
> > if (write2) begin
> > mem[address2] <= write_data2;
> > read_data2 <= write_data2 ;
> > end else begin
> > read_data2 <= mem[address2];
> > end
> > end
>
> >How about this as a dual port memory?
>
> It's a fine model, but I can't find a synth tool that
> will infer DP memory when both ports can write.
>
> If only one of the two ports has write, it's OK.

I used the Synplify tool that came with the Lattice package and got
this message from the code below.


--------------------------------------------------------------------------------
Found multi-write port RAM mem, number of write ports=2, depth=128,
width=18
--------------------------------------------------------------------------------


library ieee;
use ieee.std_logic_1164.all;
Use ieee.numeric_std.all;

library xp;
use xp.components.all;

Library Common;
Use Common.Stuff.all;
Use Common.conversions.all;

Library Hardware;
Use Hardware.IRIG_Defs.all;

entity RAM_TEST is
port (
SysClk : in std_logic;
enable1 : in std_logic;
write1 : in std_logic;
address1 : in std_logic_vector (6 downto 0);
write_data1 : in std_logic_vector (17 downto 0);
read_data1 : out std_logic_vector (17 downto 0);

enable2 : in std_logic;
write2 : in std_logic;
address2 : in std_logic_vector (6 downto 0);
write_data2 : in std_logic_vector (17 downto 0);
read_data2 : out std_logic_vector (17 downto 0)
);
end RAM_TEST;

architecture RTL of RAM_TEST is
subtype RAM_Word is std_logic_vector (17 downto 0);
type RAM is array (127 downto 0) of RAM_Word;
signal mem : RAM;
begin
Mem: process (SysClk) begin
if (rising_edge(SysClk)) then
if (enable1 = '1') then
if (write1 = '1') then
mem(to_int(address1)) <= write_data1;
read_data1 <= write_data1 ;
else
read_data1 <= mem(to_int(address1));
end if;
end if; -- enable1
if (enable2 = '1') then
if (write2 = '1') then
mem(to_int(address2)) <= write_data2;
read_data2 <= write_data2 ;
else
read_data2 <= mem(to_int(address2));
end if;
end if; -- enable2
end if; -- rising_edge(SysClk
end process Mem;

end RTL;


Does this work for the Xilinx and Altera versions of the Synplify
tool?

Rick

On Aug 20, 2:45*am, rickman <[email protected]> wrote:
> On Aug 19, 10:22 am, Jonathan Bromley <[email protected]>

> Does this work for the Xilinx and Altera versions of the Synplify
> tool?
>
> Rick- Hide quoted text -
>

Quartus didn't like it when targetting a Cyclone II device, it got
implemented with logic cells. When it sees the second path in the
code for writing to memory (i.e. enable2 and write2) it can't map it
into the internal memory of the device.

KJ

On Aug 20, 7:50 am, KJ <[email protected]> wrote:
> On Aug 20, 2:45 am, rickman <[email protected]> wrote:
>
> > On Aug 19, 10:22 am, Jonathan Bromley <[email protected]>
> > Does this work for the Xilinx and Altera versions of the Synplify
> > tool?
>
> > Rick- Hide quoted text -
>
> Quartus didn't like it when targetting a Cyclone II device, it got
> implemented with logic cells. When it sees the second path in the
> code for writing to memory (i.e. enable2 and write2) it can't map it
> into the internal memory of the device.

What is the synthesis tool that Quartus uses? I don't recall that
Altera has written their own. Instead I want to say that Altera uses
one of the commercial tools for synthesis.

Rick

On Wed, 20 Aug 2008 06:41:29 -0700 (PDT), rickman wrote:

>What is the synthesis tool that Quartus uses? I don't recall that
>Altera has written their own. Instead I want to say that Altera uses
>one of the commercial tools for synthesis.

Quartus can use third-party synthesis tools, but has its
own synthesis engine. AFAIK its front-end is from
Verific.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On Aug 20, 7:50 am, KJ <[email protected]> wrote:
> On Aug 20, 2:45 am, rickman <[email protected]> wrote:
>
> > On Aug 19, 10:22 am, Jonathan Bromley <[email protected]>
> > Does this work for the Xilinx and Altera versions of the Synplify
> > tool?
>
> > Rick- Hide quoted text -
>
> Quartus didn't like it when targetting a Cyclone II device, it got
> implemented with logic cells. When it sees the second path in the
> code for writing to memory (i.e. enable2 and write2) it can't map it
> into the internal memory of the device.

I tried it with the full ispLever tool and this generates so much
logic that it won't fit in the chip. I guess the fact that Synplify
makes a ram component doesn't mean it gets mapped to an EBR. When I
make it a single port interface it does use an EBR.

My local FAE suggested an attribute to map it to a block ram, but that
didn't work either.

Rick