cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
flux
Observer
Observer
473 Views
Registered: ‎02-02-2018

Memory Synth Change Vivado 2020.2 vs 2020.1

I have a simple 8x8 hardware sprite. The memory for the graphic and its initialization looks like this (DEPTH is 64):

    logic mem [DEPTH];  // 1 bit per pixel

    // load sprite graphic into memory (binary text format)
    initial begin
        if (SPR_FILE != 0begin
            $display("Creating sprite from file '%s'.", SPR_FILE);
            $readmemb(SPR_FILE, mem);
        end
    end
 

This worked fine in Vivado 2020.1. There was no warnings from Vivado, the design worked on actual hardware, and the following appeared in the synthesis log:

INFO: [Synth 8-3876] $readmem data file 'sprite.mem' is read successfully


In Vivado 2020.2 the same design doesn't work. I get the following messages in the synthesis log:

WARNING: [Synth 8-2898] ignoring malformed $readmem task: invalid memory name

Warning: Trying to implement RAM in registers. Block RAM or DRAM implementation is not possible for one or more of the following reasons :
1: Unable to determine number of words or word size in RAM.
2: No valid read/write found for RAM.
RAM dissolved into registers

A bitstream is generated, but the sprite doesn't work.

I have tried looking up the warning Synth 8-3876, but haven't found anything relevant. I could change to an explicit async ROM, but I'd like to understand what's happening here and what's been changed in Vivado 2020.2.

There is another question on the forum: Bram initilization using .mem file, but that didn't come to a firm conclusion.

Tags (2)
0 Kudos
5 Replies
markcurry
Scholar
Scholar
421 Views
Registered: ‎09-16-2009

Just as a test could you try changing your memory deceleration to:

logic mem [DEPTH-1:0];  // 1 bit per pixel
 
What you wrote should have worked.  But from the error message, it might imply that the changed deceleration will work.
 
Verilog has always used range specifications for both vector and array indices.  Somewhere, sometime - I'm even having trouble finding it now - the Systemverilog standard added the ability to just use a C-style size indices specification as you've used in your deceleration. I wasn't even aware of it at all, thinking it was still not allowed, until someone on these forums pointed it out to me.  But I remember digging into the standard fairly deeply to find it and see where it's allowed. 
 
(Edit I found it in the Systemverilog standard - only unpacked array dimensions are allowed to use the C-style size deceleration, instead of a range.) 
 
In any event, I'm guessing there was some errant revert of the tool that fails to parse your size unpacked dimension indices deceleration correctly.
 
As I said, just a guess, but I'd give it a try.
 
Regards,
Mark
 
 
0 Kudos
flux
Observer
Observer
417 Views
Registered: ‎02-02-2018

A good idea, but alas it didn't fix the problem. The error is the same as before:

[Synth 8-2898] ignoring malformed $readmem task: invalid memory name [.../sprite_v1.sv:29]

Regards,

Will

0 Kudos
markcurry
Scholar
Scholar
415 Views
Registered: ‎09-16-2009

Is SPR_FILE a parameter?  Try (temporarily) hardcoding the file name?  (This would be a terrible revert of the tools is such is the case...)

--Mark

0 Kudos
flux
Observer
Observer
400 Views
Registered: ‎02-02-2018

I've already tried hardcoding the depth and filename without any luck. Other things I've tried include reducing the depth to 16 and renaming the memory. I still get the warnings about "malformed $readmem task" and "Trying to implement RAM in registers" as in my original question.

Update: the warning about "Trying to implement RAM in registers" does occur in Vivado 2020.1, so perhaps that's not actually relevant?

Warning: Trying to implement RAM in registers. Block RAM or DRAM implementation is not possible for one or more of the following reasons :
1: Unable to determine number of words or word size in RAM.
2: No valid read/write found for RAM.
RAM dissolved into registers

Though this warning only appears in the synthesis log; it doesn't appear in the "Messages" panel like other warnings do. Perhaps its lack of prominence means other people are getting this warning, but not noticing?

0 Kudos
flux
Observer
Observer
275 Views
Registered: ‎02-02-2018

Quick update: I'm only seeing this problem with 1-bit wide data, so I'm assuming this is a bug.

I've worked around the problem by using an an async rom module:

projf-explore/rom_async.sv at master · projf/projf-explore (github.com)

In case anyone is having similar issues and wants to see complete designs: 

Hardware Sprites | Project F - FPGA Development

0 Kudos