[casper] Operands to the || and operators must be convertible to logical scalar values
Hi all, I have a strange error that arises after a small change to a design: I have used the sync pulse to reset a counter, that in turn (together with a comparator coupled to a register) produces a higher frequency pulse for use in snap blocks i.e. to write the snap block data more frequently than simply using the sync pulse for synchronizing the data to the FFT windows. As soon as I do this I get the error in the subject line: Operands to the || and operators must be convertible to logical scalar values This does not happen if I use the sync pulse directly, without the counter. All the data types are identical after a port update. Does anyone have this problem with the 2014 July Casper toolflow? Thanks in advance... Charles Copley Cell: +27 (0) 84 430 1160 ---
Re: [casper] Operands to the || and operators must be convertible to logical scalar values
Hi. Maybe a boolean check box needs checked somewhere in your new logic? John Hi all, I have a strange error that arises after a small change to a design: I have used the sync pulse to reset a counter, that in turn (together with a comparator coupled to a register) produces a higher frequency pulse for use in snap blocks i.e. to write the snap block data more frequently than simply using the sync pulse for synchronizing the data to the FFT windows. As soon as I do this I get the error in the subject line: Operands to the || and operators must be convertible to logical scalar values This does not happen if I use the sync pulse directly, without the counter. All the data types are identical after a port update. Does anyone have this problem with the 2014 July Casper toolflow? Thanks in advance... Charles Copley Cell: +27 (0) 84 430 1160 ---
Re: [casper] Roach2 QDR
Hi Matt, The qdr_cal routine calibrates the relationship of clock and data signals in the link between the FPGA and QDR signals. Basically it writes test patterns and reads them back looking for glitches. It then changes the delay of IODELAY blocks so that data read from the QDR is captured reliably. If this calibration script runs successfully, I'm surprised you still see glitches with 32 bits of data swapped between read and write (both from PPC). This would (surely?) count as a glitch and cause the calibration routine to fail(?). Do you only see strange behaviour when you read from the FPGA fabric, or do straight write/reads from the CPU also misbehave? Is the behaviour the same on every read / write (i.e., not intermittent)? My experience with the QDR is that at high clock speeds (not sure how high, but I see this at 312 MHz) the read latency of the QDR interface isn't 10 clock cycles as it should be even with the minimum IODELAY configuration, and there are no reliable qdr_cal solutions. I solved this problem for my design by removing half a clock cycle latency from the interface, at which point the QDR would calibrate ok. What speed are you running your design at? To me, misordered 32-bit chunks of data sounds indicative of a latency problem in the qdr_cal solution, since the interface is 32 bit DDR, so half a clock cycle mangles 32-bit chunks of data. Good luck! Jack On Fri, 6 Mar 2015 at 23:54 Matt Strader mstra...@physics.ucsb.edu wrote: Hi all, I'm trying to use QDR on Roach2. I have a test design where I write to QDR either in firmware or with katcp, then read it out in the firmware and check the results with snapshot blocks. It mostly works, but with some interesting quirks. I know that katcp can only write 64 bits of the 72 bit QDR word, so I changed the bitbasher blocks in qdr_mask.m to move the inaccessible bits out of the way to the most significant bits. Now everything seems to work well, except that in some builds (seems to depend on clock rate?), the first 32 bits (of the 64 bits I'm writing in a cycle) get swapped with the last 32 bits sometime between writing the word and reading it back. And there is a sometimes a difference in whether I am writing in firmware or by katcp to whether this swap happens. Also, when I write with katcp starting at address zero, I find that when reading out, the write started at what seems to be address 1. Is the latency of QDR set to 10 cycles? I can live with all this, as long as it is repeatable for a given design, but I thought I'd ask if anyone knows what is causing these quirks. Also, I understand that we should run a software calibration for qdr, which seems to be qdr_cal() in qdr.py in the ska-sa:casperfpga repo. So, I run this first, which seems to work for my latest compiles, but I haven't noticed a difference in the results. What exactly does this calibration do? Thanks, Matt Strader UC Santa Barbara
Re: [casper] Operands to the || and operators must be convertible to logical scalar values
Hi, Charles, Is it when you click OK on a block's mask dialog or when you run update diagram or ??? Maybe you can find additional details in the model_sysgen.log or model_sysgen_warning.log or model_sysgen_error.log files? It would really help to know which block or file is causing this error. Thanks, Dave On Mar 9, 2015, at 6:24 AM, Charles Copley wrote: Hi all, I have a strange error that arises after a small change to a design: I have used the sync pulse to reset a counter, that in turn (together with a comparator coupled to a register) produces a higher frequency pulse for use in snap blocks i.e. to write the snap block data more frequently than simply using the sync pulse for synchronizing the data to the FFT windows. As soon as I do this I get the error in the subject line: Operands to the || and operators must be convertible to logical scalar values This does not happen if I use the sync pulse directly, without the counter. All the data types are identical after a port update. Does anyone have this problem with the 2014 July Casper toolflow? Thanks in advance... Charles Copley Cell: +27 (0) 84 430 1160 ---
