08-08-2017 11:15 AM
@chapman Vivado refuses to place a single ICAP instance at the bottom:
ERROR: [Place 30-99] Placer failed with error: 'The only ICAP instance cannot be placed in the bottom ICAP site. Please unplaced the instance, or lock it in the top site.'
08-08-2017 12:28 PM
Hi @chapman, i wanted to apply a slower clock to ICAP (10 MHZ). When I apply the same slower clock to ILA , it did not work . After providing the ILA a higher clock (20 MHZ) than ICAP, it started working, so I kept that. The ILA not working could even be something else. I forgot the exact error that occured. I remember, ILA not being starting at all.
I will try with the top site. I was looking at the simulation model provided by @simon to expand the FSM for config readback.
Thanks for always providing valuable direction .
08-09-2017 12:21 AM
1. in UG470 page 127, I can see that a SHUTDOWN command was issued in step 3, which you did not. do It looks as if it has something to do with CRC check.Just wanted to be sure its nothing essential in doing a complete readback.
2. You also ignored the RCRC, but I guess its something to do with ignoring CRC check which is particular to your application.
3. In step 8, both Type 1 and 2 Read commands were used in UG470, while you only used Type 1 Read. I guess its because the number 303 was small enough for putting in Type 1 instruction?
4. Your FAR Address is 2051A instead of all zeros. I guess its because you wrote onto that particular address initially and wanted to read only those 2 frames.
Hi @chapman, it looks like there is a small mistake in page 127 of UG470 where type 1 NOP is stated as 02000000.
08-09-2017 04:44 AM
1. The SHUTDOWN command will disable the device on the next CRC check, which is not what I want :)
2. The RCRC is the command to finish the SHUTDOWN from the previous command.
3. Correct, you can as well always generate a Type 2 instruction but why waste precious resources :)
4. Correct, frame 0x2051A is in the range I reserved for testing.
08-09-2017 08:37 AM
I was trying to do the readback test in simulation using a .rbt file.
But when I start behavioral simulation using VIvado Simulator, I see the following command
Error: Error: The configure rbt data file %s for ICAPE2 was not found. Use the SIM_CFG_FILE_NAME generic to pass the file name.
As a result, I mostly get bunch of HHHHH in the ICAP output. As I am told, simulation would not be perfect for readback, but I hope it would be helpful to see something happening before moving to the board.
I have put the .rbt file in several places that includes:
..\Project1.srcs\sources_1\new (along side the .vhd source file)
Any idea about this?
08-09-2017 08:44 AM
08-09-2017 08:46 AM
Hi, I thought the following already does that. Or something else needs to be changed?
generic map (
DEVICE_ID => x"0362D093",
ICAP_WIDTH => "X32", -- Specifies the input and output data width.
SIM_CFG_FILE_NAME => "normal.rbt"
port map (
O => dout_swapped, -- 32-bit output: Configuration data output bus
CLK => CLK_10, -- 1-bit input: Clock Input
CSIB => cs_l, -- 1-bit input: Active-Low ICAP Enable
I => d_swapped, -- 32-bit input: Configuration data input bus
RDWRB => r_wx -- 1-bit input: Read/Write Select input
08-09-2017 08:59 AM
Yes, that should be fine then.
So I presume the real question is: where to put it so that xsim finds it?
My answer to that is: in the same directory where xsim is executing.
And where is that, you might ask? No idea.
But not all is lost, as you can specify an absolute path there as well.
The file will simply be opened and read by the HDL code.
Hope this helps,
08-10-2017 12:46 AM
I tried different things but it (IDCODE read) just does not work on the board (only works in simulation). I am out of ideas to try right now. I feel that it could be something on the board. I am applying 10MHZ clock using the PLL. only single clock for the whole design and the top ICAP is used.
I have attached the .vhd, .xdc and also the vivado 2015.2 project directory just in case if someone have time to examine.
For simulation the following could be used
08-10-2017 04:02 AM
I've just noticed something in your VHDL and previously presented waveforms that could be causing your failure to read IDCODE.
You have de-asserted the enable (cs_l <= '1') as soon as you have presented the IDCODE read instruction 28018001. This means that the following NOOP 20000000 is NOT being written before you change from write to read mode. In my PicoBlaze reference design I write 2 NOOP after the IDCODE read instruction before changing to read mode. The sequence presented in Table 6-1 of UG470 also shows 2 NOOP between the read instruction and the actual read. I recommend that you include the two NOOP before changing your enable signal.
Admittedly, the simulation should match the hardware but ICAP is always a bit mysterious! I've always had the policy of 'if in doubt, write another NOOP in there' so now that I've noticed that you haven't written one at all I think this could be it.
08-10-2017 05:40 AM
The NOOPs aren't required, you can switch to read mode (CSIB high) in the cycle after the IDCODE read instruction (see my example and the resulting sequence).
08-10-2017 06:50 AM
Thanks for all your suggestions @hpoetzl. One of them will make it work and we already know some things have been altered for the better.
I'm not convinced it will work without the NOOP 20000000 in there. Have you seen your examples work in real silicon as well as simulation? Why do you bother setting the ICAP input to 20000000 if you are not actually writing anything? We shouldn't rule out a race condition between enable signal and the clock that results in the NOOP being used; ICAP is a rather unique block!
@tamzid Do put the NOOP's in there; you have little to lose and just maybe it's what you need to make it work.
08-10-2017 07:00 AM
@chapman I'm not convinced it will work without the NOOP 20000000 in there.
Have you seen your examples work in real silicon as well as simulation?
I don't trust simulation.
The output from my examples is captured from the serial port.
Why do you bother setting the ICAP input to 20000000 if you are not actually writing anything?
Because a NOOP is a nice default if something goes wrong with the timing. ;-)
Hope this clarifies,
08-10-2017 01:48 PM
Hi @chapman I tried writing extra NOOP before moving to readmode. Also tried with adding extra NOOP in other places.
Made sure that RDWR never toggles while CS is asserted.
After that, I tested by keeping the write to CMD, SYNC and other commands asserted for more than 1 cycle.
Finally I removed the ILA and used an LED to indicate if anything other than FFFFFFD9 appeared. Used a comparator logic which keeps the LED=1 asserted if other values appears. But it never happened in silicon.
I do not have another board to test it at the moment to check if its a board related issue. If any of you have time,resource and curiosity to test that, I would request to try out.
Thanks for the suggestions!
08-10-2017 02:28 PM
I do not have another board to test it at the moment to check if its a board related issue.
If any of you have time,resource and curiosity to test that, I would request to try out.
I have a Zybo somewhere ...
So if you pack up the entire project and upload it, I'll probably find the time to take a look.
08-10-2017 04:22 PM
Thanks a lot, this is a version that works in simulation.
I am applying 10MHZ clock using the PLL. only single clock for the whole design and the top ICAP is used.
I have attached the .vhd, .xdc and also the vivado 2015.2 project directory. The project also instantiates the ILA core.
For simulation the following could be used
For running in device, before programming, keep all the switches to 0.
Open the Project and open the hardware manager and program with the bitstream that is already generated.
Once programmed the following window should appear
You can see that the trigger condition is already set as IF RST==1. You just have to click on the highlighted area. If that is done the ILA would wait for the trigger condition to occur. At this point if you move the switch at PIN P15. to 1, the design will work and output will appear on ILA as the following.
Notice that the output from ICAP never changed.
Please let me know if something else is needed.
08-10-2017 07:12 PM
From the ILA wave and vhd, two NOOP commands are not written to ICAP, since ce is deasserted earlier two clock.
08-10-2017 09:17 PM
Hi @simon, are you referring to adding 2 NOOP after read command and before going to read mode? I tried that earlier but did not work. Hence I submitted the most concise one working in simulation. The one with the NOOPs is below. Thanks.
08-11-2017 08:56 AM
This is irritating me as much as you so today I grabbed your code (from your last posting) and added into a PicoBlaze design that I'm using to run experiments on a Spartan-7 device (XC7S50). I tried to leave your code alone as much as possible especially in the actual ICAPE2 interface and reader state machine. I removed the 'clk_wiz' and connect everything my 100MHz system clock. I removed the ILA and made connections that PicoBlaze could observe.
I added registers to capture the lower 8-bits of the data coming out of ICAP on successive clock cycles....
--Read will start from next clock
when 8 => data <= x"20000000";
cs_l <= '0'; r_wx <= '1';--Assert CE -- read Clock 1
when 9 => data <= x"20000000"; -- read Clock 2
cs_l <= '0'; r_wx <= '1';
idcode1 <= data_out(7 downto 0);
when 10 => data <= x"20000000"; -- read Clock 3
cs_l <= '0'; r_wx <= '1';
idcode2 <= data_out(7 downto 0);
when 11 => data <= x"20000000"; -- read Clock 4
cs_l <= '0'; r_wx <= '1';
idcode3 <= data_out(7 downto 0);
when 12 => data <= x"20000000"; -- read Clock 5
cs_l <= '0'; r_wx <= '1';
idcode4 <= data_out(7 downto 0);
I first proved that my 4 registers contained zero and that your state machine wasn't active (RIP=0). Then I triggered your state machine and saw that RIP went High. Given that your code never terminates state machine and it spins round and round forever that was a one-shot event! Anyway, the four registers then contained DB, DB, 00 and 93 indicating that IDCODE was indeed read from ICAPE2 and was captured during what you have called 'read clock 5' (the IDCODE of my device is X362F093).
So on the basis that your code works the issue must be related to either to some of your XDC constraints (I suggest you remove anything you don't absolutely need as my XDC file is pretty much only I/O pin and clock definitions) or whatever is configuring your device is not completing and letting go in a way that prevents ICAPE2 from being able to be accessed. It's a bit of a pain but try programming your Flash and booting in master mode so the FPGA is in charge.
Ok, I stand corrected, the NOOP's were not vital in this arrangement. On reflection, I recall noticing differences depending on whether the ICAP enable was pulsed (i.e. for one clock cycle at a time) rather than active for continuous cycles and/or combined with a free running clock or individual clock pulses. In other words, the ICAP enable does not truly act as a global clock enable and in the extremely controlled case you need the NOOPs to 'create' the clock cycles to propagate the ICAP state machine. Did you know that ICAP is one of the classes taught at Hogwarts?
08-11-2017 10:52 AM
@chapman Thank you very much. It was very crucial for me to know if that works on the board. Thanks a lot for the confirmation.
I would try as you suggested. As far as I understood the code pretty much works unaltered.
The things I could try is to remove ILA, clock wiz, unnecessary XDC stuff. If nothing works I will try to get hold of a different board.
For now I would accept this as solution.
I would update once things get done. :)
08-11-2017 10:53 AM
Have fun (with ICAP :),
01-22-2019 08:22 AM - edited 01-22-2019 08:23 AM
i am getting this when try to simulate it for kintex 7... i am using sequence from datasheet and trying to read device id------
01-22-2019 05:10 PM
32bit data needs to be byte swapped, and IDCODE register address is 01100.
01-24-2019 04:03 PM - edited 01-24-2019 04:05 PM
i am just trying to communicate with icape2 of kintex 7 . I have sent the command sequence to read id code from register 01100. but not getting any response. should i have to do byte swapped for reading id code....
01-24-2019 05:00 PM
Yes, you can try to test bit swap, table 5-4, 5-5 in ug470
01-25-2019 02:57 AM
i am trying to read ICAPE2 from kintex 7
I use this sequence to read id code x"20000000",x"FFFFFFFF",x"000000BB",x"11220044",x"FFFFFFFF",x"AA995566",x"20000000",x"2800E001" then read...
P_O_swapped data are the swapped byte....
but getting this error data ...(red in the picture).......
please give me suggestion what am I doing wrong.....