Hi Heystek,

How big is the bram? Is it smaller than the length of `buf`? If so, I
think that would give you the error you see.
Relatedly, this code looks like it's going to write packed floats to
the FPGA. Is this really what you want? (It might be, but most designs
are set up for fixed point computation)

Cheers
Jack

On Tue, 2 Nov 2021 at 11:19, Heystek Grobler <[email protected]> wrote:
>
> Good day everyone
>
> I have spent some time on this and it comes down to one final error. It seems 
> that I am not packing the array correctly in binary form.
>
> I have used these methods:
>
> sinA_x=np.arange(0,2*np.pi,step_size)
> sinA_y=np.sin(sinA_x)
> sinA_y
>
> array_l=len(sinA_y)
>
> ss0 = []
> for i in a_sin[0:array_l:100000]:
>     ss0.append(i)
>
> #sp0 = struct.pack('%f',ss0)
> #sp0 = struct.pack('%sf' % len(ss0), *ss0)
> #sp0 = struct.pack(f'{len(ss0)}f', *ss0)
> #sp0 = struct.pack('f' * len(ss0), *ss0)
> #sp0 = struct.pack('f' * len(ss0), *ss0)
> #sp0 = struct.pack(str(len(ss0)) + 'f', *ss0)
> #sp0 = struct.pack("{0}f".format(len(ss0)), *ss0)
> #sp0 = struct.pack("%sf" % len(ss0), *ss0)
> #sp0 = struct.pack(f'{len(ss0)}f', *ss0)
>
> buf = bytes()
> for val in ss0:
>        buf += struct.pack('f', val)
>
> Then I use:
>
> fpga.write('bram_a_sin',buf,0)
>
> But I keep getting the following error:
>
> KatcpRequestFail                          Traceback (most recent call last)
> <ipython-input-37-a8e906611ce1> in <module>()
> ----> 1 fpga.write('bram_a_sin',buf,0)
>
> /home/dserver/anaconda2/lib/python2.7/site-packages/casperfpga/casperfpga.pyc 
> in write(self, device_name, data, offset)
>     227         :return:
>     228         """
> --> 229         self.blindwrite(device_name, data, offset)
>     230         new_data = self.read(device_name, len(data), offset)
>     231         if new_data != data:
>
> /home/dserver/anaconda2/lib/python2.7/site-packages/casperfpga/katcp_fpga.pyc 
> in blindwrite(self, device_name, data, offset)
>     269         self.katcprequest(name='write', request_timeout=self._timeout,
>     270                           require_ok=True,
> --> 271                           request_args=(device_name, str(offset), 
> data))
>     272
>     273     def bulkread(self, device_name, size, offset=0):
>
> /home/dserver/anaconda2/lib/python2.7/site-packages/casperfpga/katcp_fpga.pyc 
> in katcprequest(self, name, request_timeout, require_ok, request_args)
>     161                     'Request %s on host %s failed.\n\t'
>     162                     'Request: %s\n\tReply: %s' %
> --> 163                     (request.name, self.host, request, reply))
>     164             elif reply.arguments[0] == katcp.Message.INVALID:
>     165                 raise KatcpRequestInvalid(
>
> KatcpRequestFail: Request write on host 192.168.33.11 failed.
>
> Am I missing the way the array should be packed? All that I want to to do is 
> to give a sine wave to the bram.
>
> Thank you for the help!
>
> Heystek
>
> On 19 Oct 2021, at 14:17, [email protected] wrote:
>
>
> Hi, Heystek,
>
> I tried to use the Sine Wave module in the xilinx blockset to generate a 
> positive or cosine signal, and then use the casper snapshot module to read 
> the generated signal value and verify the result. I think you can start with 
> a simple example like this. the bram details are as David said.
>
> Hope this helps,
> Duan
> ________________________________
> ========================================
> 段雪峰(Duan Xuefeng)
> 中国科学院新疆天文台
> Xinjiang Astronomical Observatory (XAO), CAS
> 乌鲁木齐市新市区科学一街150号,830011
> 150 Science 1-Street, Urumqi, 830011, China
> 电话(Tel):0991-3689068 15719983612
>
>
> From: David Harold Edward MacMahon
> Date: 2021-10-19 19:37
> To: casper
> CC: fvdheever
> Subject: Re: [casper] Help to program BRAM blocks.
> Hi, Heystek,
>
> The CPU/KATCP/CasperFpga data path to the "Shared BRAM" is 32 bits wide, so 
> in the end you will be writing/sending an array of 32 bit integers.  The data 
> path on the FPGA side of the "shared BRAM" may be wider (e.g. 64 bits) or 
> narrower (e.g  8 or 16 bits) or the same (i.e. 32 bits).  Thing are most 
> straightforward when the FPGA data path is 32 bits since location 0 is the 
> same for either side, but one important detail is that the values in the 
> Shared BRAM are stored in "big endian" format (aka "network byte order"), 
> which is opposite from the x86_64 convention.  When the widths differ between 
> the two sides, some care is required to ensure that the data is ordered 
> properly to get the desired output order.  The "Block RAM Address Mapping" 
> section of UG363 
> (https://www.xilinx.com/content/dam/xilinx/support/documentation/user_guides/ug363.pdf)
>  describes this mapping.  The one detail that is not covered there is when 
> the FPGA data port is 64 bits wide.  In that case, you need to convert the 
> 64-bit value to big endian, but then swap the low 32-bits and high-32 bits, 
> though sometimes the gateware designer will be "clever" and do this swap for 
> you (which is convenient if you know about it).
>
> Hope this helps,
> Dave
>
> On Oct 19, 2021, at 12:55, Heystek Grobler <[email protected]> wrote:
>
> Good day everyone.
>
> I was hoping that someone can perhaps help me or can point me in the right 
> direction.
>
> I want to write sine and cosine waves to BRAM blocks in order to implement a 
> local oscillator. I have a basic idea of how to do this by making use of a 
> struct that needs to be packed, but in practice I have not done this before 
> and can't seem to find a good example to follow.
>
> Thank you for the help!
>
> Heystek
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "[email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALWRf%3DQOnhWbZdRXntDDcnySHu1oZcd7c%2BEi7jd1zpVrm-k5MQ%40mail.gmail.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "[email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/27B96FF5-A8A4-49C4-B6DF-A55480FF6D98%40berkeley.edu.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "[email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/2021101920172100228164%40xao.ac.cn.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "[email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/57377954-1222-4156-8471-DDBC9B43E8DB%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmU5PezUzBJ5tvt0REOi-w%2B-7aZEZg2wxjWTM1eFYBb6Q%40mail.gmail.com.

Reply via email to