Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block rams not inferred with Vivado 2015.2 with user defined types #113

Closed
adamwalker opened this issue Jan 15, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@adamwalker
Copy link

commented Jan 15, 2016

Vivado 2015.2 fails to infer block ram when using the blockRamPow2 function when the type of element being stored is a user defined type. See:

https://gist.github.com/adamwalker/0b39f86bdb4925e918cf
Specifically, in the first case synthesis (in Vivado) runs forever which I presume is because it is synthesizing the entire array.

Perhaps it is not the intention to allow arbitrary types to be stored in block ram, but it is allowed by the type system and I couldn't find any documentation stating that you shouldn't do that.

Thanks
Adam

@christiaanb

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

It is supposed to work for arbitrary types, and I'm quite sure it works with Altera's Quartus tool. Still, I want to make sure it will work with Xilinx' tools also. I know how to fix this: I have to update the code-generator to only store bitvectors (std_logic_vector in VHDL) in blockRAMs.

Anyhow, as a work-around, I see two options:

  • Use seperate blockRam's for each field of your tuple
  • Have CLaSH generate Verilog instead of VHDL (using the :verilog command in interactive mode, or the --verilog flag in batch mode): in Verilog we only have bitvector basically, so it should work.

@christiaanb christiaanb added the bug label Jan 15, 2016

@adamwalker

This comment has been minimized.

Copy link
Author

commented Jan 15, 2016

I wouldn't be suprised if it works with Xilinx ISE. From what I understand, Vivado is a complete rewrite of ISE that is still lacking features and has bugs that do not exist in ISE.

@ggreif

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

@adamwalker If you find out that is a vivado bug, please make sure that it gets reported! Thanks!

@adamwalker

This comment has been minimized.

Copy link
Author

commented Jan 15, 2016

Haha. I'm guessing you haven't tried to report a bug to Xilinx before. It will be ignored :)

@ggreif

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

I am just running synthesis with Vivado 2015.3. It does seem to loop. Simulation was fast, though.

@christiaanb

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

I just tried with Altera Quartus Prime 15.1.0, I can go as high as a 2^14 number of elements in the blockRam (e.g. a write and read addres of Unsigned 14). Higher than that, and Quartus reports it ran out of memory. Indeed, for Unsigned 14 it was already using 6 GB (on my 8 GB machine).

The VHDL that I'm generating is almost an exact copy of both the Xilinx and Altera recommended VHDL for blockRam inference. I guess for blockRams with really large address spaces, you are forced to use something like Xilinx' Coregen.

I don't think there's an easy fix for the out-of-memory problem. Aside from generating Xilinx/Altera specific blockRam VHDL, instead of the current vendor-independent VHDL.

christiaanb added a commit that referenced this issue Sep 6, 2018

Add fixities for snat arithmetic ops (#113)
Corresponding to the fixities in Num and Integral
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.