Target FPGA board and Xilinx primitives

[sauc]

I'm having troubles while running a simulation of the JPEG Encoder (jpeg.encoder.hw.Encoder in the JPEG orc-apps repo). The behavioral simulation is correct, but, in the post-synthesis one, some tokens are not correctly stored into the BRAMs (timing is ok). I'm working with Vivado 2015.2 and questasim 10.4 and I'm targeting an Artix-7 xc7a100tcsg324-2. I've noticed that Xronos adopts a Virtex II xc2vp30-7-ff1152 FPGA and the related primitives by default. Is it possible that my problem is related to the primitive simulation models that are not matching from behavioral (where a Virtex II primitive is adopted) to post-synthesis (where Artix-7 primitives are istantiated)? Is there a way to change the referenced FPGA so that Xronos can insert the correct primitive?

[endrix]

Hello Carlo,
That's a weird bug, normally the synthesis tool replaces the BRAM16 to
BRAM36 found on the Atrix.
Replacing BRAM16 to BRAM18 requires a lot of engineering effort on the
Openforge part of Xronos, which is kind on hold for the moment.

Please confirm to me that you are launching the post-synthesis simulation
from Vivado and from my scripts.

On Mon, Jul 11, 2016 at 5:42 PM, Carlo Sau notifications@github.com wrote:

I'm having troubles while running a simulation of the JPEG Encoder
(jpeg.encoder.hw.Encoder in the JPEG orc-apps repo). The behavioral
simulation is correct, but, in the post-synthesis one, some tokens are not
correctly stored into the BRAMs (timing is ok). I'm working with Vivado
2015.2 and questasim 10.4 and I'm targeting an Artix-7 xc7a100tcsg324-2.
I've noticed that Xronos adopts a Virtex II xc2vp30-7-ff1152 FPGA and the
related primitives by default. Is it possible that my problem is related to
the primitive simulation models that are not matching from behavioral
(where a Virtex II primitive is adopted) to post-synthesis (where Artix-7
primitives are istantiated)? Is there a way to change the referenced FPGA
so that Xronos can insert the correct primitive?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7, or mute the thread
https://github.com/notifications/unsubscribe/AAX9ERr3hiV5JE8KoZmQ80hJr7EFcrDHks5qUmRggaJpZM4JJf9T
.

[sauc]

Hello Endri,

thank you for the quick answer.
Maybe my first comment was not very clear. The BRAMs are properly replaced by the synthesis tool, but they are not working well (in post-synthesis) since some tokens are lost. I've noticed for instance that the first token of the Y input is not written in the corresponding rasterToMB actor internal memory.
I'm launching the post-synthesis functional simulation from Vivado and from your scripts.
I've chosen the jpeg.encoder.hw.Encoder design since it should be working with Xronos. Is it true or maybe it can be the problem?

[sauc]

Dear Endri,

I tried yesterday to reimplement all the system with all your scripts. Nothing has changed. I'm still getting the same problem: the first token of the rasterToMB actor is lost. Any idea on how to solve it? Should I change the high level design? I'm using the hw encoder in the orc-apps repo (https://github.com/orcc/orc-apps/blob/master/JPEG/src/jpeg/encoder/hw/EncoderHW.xdf). Is it the same that you used in http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6850387?
Thanks in advance.

Carlo