Hi Jack, I don't believe the yellowblock is in any of the repositories. It's for a six channel twelve bit gigasample ADC.
-Alex On Thu, Jun 5, 2014 at 4:55 PM, Jack Hickish <[email protected]> wrote: > Hi Alex, > > You are correct -- missing those pcores will cause the compile to > fail. Clocking failure is likely to be something more subtle. > > The toolflow shouldn't optimize away the clock if that clock goes > somewhere, no matter whether you connect up the rest of your adc ports > to stuff. You say your yellow block is for a custom ADC, is this a > block that is not in the main casper repositories? > > Jack > > On 5 June 2014 16:38, Alex Zahn <[email protected]> wrote: > > Thanks for the suggestions. > > > > I have these exact pcores. I got them from > > > https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b > . > > > > I don't think I'm missing a pcore here though. In my limited knowledge of > > how the toolflow works, I think this would have caused compilation to > fail. > > > > The FPGA clock problem occurs with designs that don't just keep the > > yellowblock floating, but I still should try with a design that does > > something with it just to make sure that in the minimal test I tried the > > toolflow isn't optimizing it away. > > > > -Alex > > > > > > > > > > > > > > On Thu, Jun 5, 2014 at 9:18 AM, Kim Guzzino <[email protected]> wrote: > >> > >> Hi Alex, > >> Here is a copy of the opb cores that i used. (If you need them) just > >> put the in '???/mlib_devel/xps_base/XPS_Roach_base/pcores' > >> Not having the adc clock propagate to the fabric should not be cause > >> by not having the opb, The opb is usually usrf to talk to registers that > >> need to be set in the yellow block or to control the ADC somehow. Also > >> in most cases of yellowblocks there is an opb_yellowblockname????? in > >> pcore to talk to the opb. > >> So adding the opb pcores might not fix the problem. > >> In your log file there is no mention in the timing constraints for the > >> adc clock. And at the beginning there is a lot of unconnected inputs and > >> outputs which could optimize out the adc altogether. > >> Hope this helps. > >> Kim Guzzino > >> > >> > >> > >> On Thu, 2014-06-05 at 15:45 -0700, Alex Zahn wrote: > >> > I don't actually know what the OPB bus is, but there might be a few > >> > references to it in the compile log, all of which look like this: > >> > > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > +++++++++++++++++++++++ WARNING !!! +++++++++++++++++++++++++++++ > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > > >> > WARNING:EDK - Processor epb_opb_bridge_inst has no memory mapped at > >> > its reset > >> > vector. > >> > > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > > >> > > >> > Looking at the yellowblock's verilog, I don't see any mention of the > >> > OPB bus, though. > >> > > >> > > >> > -Alex > >> > > >> > > >> > > >> > > >> > On Thu, Jun 5, 2014 at 3:34 PM, Simon Scott <[email protected]> > >> > wrote: > >> > Hi Alex > >> > > >> > Just an idea: is this problem by any chance caused by Xilinx > >> > dropping support for the OPB bus in recent ISE versions? If > >> > you look around the CASPER mailing lists, I remember this > >> > being quite a big issue around 1-2 years ago. > >> > > >> > Maybe your yellow block makes use of this bus? > >> > > >> > Regards, > >> > Simon > >> > > >> > > >> > On 06/05/2014 03:07 PM, Alex Zahn wrote: > >> > > >> > > Hi all, > >> > > > >> > > > >> > > A progress update: > >> > > > >> > > > >> > > I tried to compile a very simple model using the problematic > >> > > yellowblock that just flashes an LED. Compilation completes > >> > > (and the design does not forward a clock to the FPGA), but I > >> > > do find some warning messages I don't understand: > >> > > > >> > > > >> > > Immediately after the "Running EDK backend" banner comes up, > >> > > there's a complaint about a couple of missing files: > >> > > > >> > > > >> > > Â Warning: File > >> > > > >> > > '/home/betacage/roach_designs/adc6x_test/minimal_model/XPS_ROACH_base/implementation/system.bit' > >> > > Â not found. > >> > > Â > In gen_xps_files at 663 > >> > > Â Â Â In casper_xps>run_Callback at 155 > >> > > Â Â Â In casper_xps at 88 > >> > > Â Â Â In > >> > > > >> > > @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)) > >> > > Â Warning: File > >> > > > >> > > '/home/betacage/roach_designs/adc6x_test/minimal_model/XPS_ROACH_base/implementation/download.bit' > >> > > Â not found. > >> > > Â > In gen_xps_files at 664 > >> > > Â Â In casper_xps>run_Callback at 155 > >> > > Â Â Â In casper_xps at 88 > >> > > Â Â Â In > >> > > > >> > > @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)) > >> > > > >> > > > >> > > A little further down after a series of revup messages, this > >> > > rather ominous text comes up: > >> > > > >> > > > >> > > Â Computing clock values... > >> > > Â INFO:EDK - Cannot determine the input clock associated > >> > > with port : > >> > > Â Â Â infrastructure_inst:epb_clk. Clock DRCs will not be > >> > > performed on this core > >> > > Â Â Â Â and cores connected to it. > >> > > Â INFO:EDK - Cannot determine the input clock associated > >> > > with port : > >> > > Â Â Â infrastructure_inst:epb_clk. Clock DRCs will not be > >> > > performed on this core > >> > > Â Â Â and cores connected to it. > >> > > Â INFO:EDK - Cannot determine the input clock associated > >> > > with port : > >> > > Â Â Â infrastructure_inst:epb_clk. Clock DRCs will not be > >> > > performed on this core > >> > > Â Â Â Â and cores connected to it. > >> > > Â INFO:EDK - Cannot determine the input clock associated > >> > > with port : > >> > > Â Â Â infrastructure_inst:epb_clk. Clock DRCs will not be > >> > > performed on this core > >> > > Â Â Â Â and cores connected to it. > >> > > Â INFO:EDK - Unable to trace clock connectivity for port : > >> > > adc_clk_out - > >> > > Â > >> > > Â Â > >> > > /home/betacage/roach_designs/adc6x_test/minimal_model/XPS_ROACH_base/system.m > >> > > Â Â Â hs line 278. Not performing Clock DRCs > >> > > Â INFO:EDK - Unable to trace clock connectivity for port : > >> > > fpga_clk - > >> > > Â > >> > > Â Â > >> > > /home/betacage/roach_designs/adc6x_test/minimal_model/XPS_ROACH_base/system.m > >> > > Â Â Â Â hs line 277. Not performing Clock DRCs > >> > > > >> > > > >> > > After that, a few blocks of clock related INFOs and warnings > >> > > that look similar appear. > >> > > > >> > > > >> > > I've attached the complete log file for reference. Any ideas > >> > > on what's causing this? > >> > > > >> > > > >> > > -Alex > >> > > > >> > > > >> > > > >> > > On Thu, Jun 5, 2014 at 1:55 PM, Alex Zahn > >> > > <[email protected]> wrote: > >> > > Hi Jack, > >> > > > >> > > > >> > > I'm using a yellowblock for a custom ADC on ROACH1; > >> > > it's not in any of the repositories. The ADC > >> > > consumes both ZDOK ports, and without changing > >> > > anything else, just reprogramming from an ISE 11 > >> > > compiled design to an ISE 14 compiled design appears > >> > > to cause the problem. > >> > > > >> > > > >> > > I did not know about xIUpdateModel(). I will try > >> > > that. I know we were using 11.1 when we got the > >> > > yellowblock, and last compiled a working design on > >> > > 11.5. I'm working with 14.7 now. > >> > > > >> > > > >> > > I didn't notice any warnings that looked off, though > >> > > I should probably look again. > >> > > > >> > > > >> > > > >> > > Later today I was going to try compiling a minimal > >> > > model using the yellowblock just to see if that > >> > > successfully forwards a clock to the FPGA or not. > >> > > > >> > > > >> > > Are there any ways a yellowblock can have issues on > >> > > a different version of ISE? > >> > > > >> > > > >> > > -Alex > >> > > > >> > > > >> > > > >> > > On Thu, Jun 5, 2014 at 10:30 AM, Jack Hickish > >> > > <[email protected]> wrote: > >> > > Hi Alex, > >> > > > >> > > Lots of questions for you! -- > >> > > Which adc yellow block are you using, and on > >> > > which board (Roach/Roach2)? > >> > > Are you certain nothing has changed in your > >> > > model between updates > >> > > (design is still clocked off adc0, adc is > >> > > still in the right zdok, > >> > > etc...)? > >> > > Did you run the matlab script > >> > > xlUpdateModel() on your design (which > >> > > supposedly brings all the old system > >> > > generator blocks up to date)? > >> > > Which version are you going from / to -- > >> > > 11.1 -> 14.7, or some other > >> > > combination? > >> > > Any suspicious warnings during the compile > >> > > process? > >> > > > >> > > Cheers, > >> > > Jack > >> > > > >> > > On 5 June 2014 01:27, Alex Zahn > >> > > <[email protected]> wrote: > >> > > > Hi all, > >> > > > > >> > > > I have a yellowblock for an ADC (made by > >> > > someone else--I don't know how to > >> > > > write yellowblocks) meant to clock the > >> > > design off adc0clk. > >> > > > > >> > > > Designs using this yellowblock work fine > >> > > with ISE 11, but with ISE 14 they > >> > > > manage to get through compilation > >> > > successfully, but when running don't seem > >> > > > to allow the FPGA to receive a clock. > >> > > > > >> > > > I suspect there is something wrong with > >> > > the yellowblock here, but I don't > >> > > > know where to look or what to look for. > >> > > Has anyone seen anything like this? > >> > > > > >> > > > -Alex > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >
