14 replies to this topic

[Brett]

I'm playing with a couple of different examples on both a v2mb1000 board & a ml401 board. It seems that for both opb and fsl based projects I'm not able to get proper resets set up. I've put together an fsl demo for both boards to illustrate the problem.

1. v2mb1000 & 3DES fsl (from platform support package)
Following instructions in the PSP I get a build that will run correctly but won't reset. After resetting the output hangs before printing the results of the sw-only 3DES computation. Repeatedly pressing reset (think "monkey with a remote control") eventually causes the sw-only output to show up along with several "malloc failed!" outputs. I repeat with the ml401 (modded to fit that board) with the same results.

2. v2mb1000 & 3DES fsl with mods
This time i modify the fsl busses tying to the 3des (there are 3) to force the fsl_bus paramter "C_EXT_RESET_HIGH" to 0. This matches the setting of the opb bus in the same design. Now, I get the same behavior as #1 except that I _never_ get the output from the hardware 3DES computation. Again, I repeat with the ml401 build with the same results.

3. ml401 & 3DES fsl (active low reset flag set)
This time I modify the fsl busses to have "C_EXT_RESET_HIGH" set to 0 and modify the project->generate options in codeveloper to set "active-low reset". Same exact behavior as #2.

Help?

Brett

[RalphBodenner]

Hi Brett,

Thanks for the feedback. The reset signal for the FSL bus is currently not fully supported by Impulse C. We are working to resolve problems with resetting FSL-based designs, but do not have a schedule for when a fix would be available.

What reset issues do you see with OPB?

Regards,
Ralph

[GreenMountain]

Help?

Brett

Hi Brett,

Does the 3DES core have any ports listed in EDK? If so, what did you assign them to?

[Brett]

Hi Brett,

Does the 3DES core have any ports listed in EDK? If so, what did you assign them to?

From the mhs file:
PORT FSL_Clk = sys_clk_s
PORT co_clk = sys_clk_s

This is on an ml401 board, not the v2mb1000 the example was originally targetted for, so the co_clk isn't really necessary. The behavior is consistent on a v2mb1000 where the des core is downclocked using the off-chip 24MHz oscillator.

Brett

[GreenMountain]

From the mhs file:
PORT FSL_Clk = sys_clk_s
PORT co_clk = sys_clk_s

This is on an ml401 board, not the v2mb1000 the example was originally targetted for, so the co_clk isn't really necessary. The behavior is consistent on a v2mb1000 where the des core is downclocked using the off-chip 24MHz oscillator.

Brett

Take a look at the system.vhdl file generated by EDK to see what signal it tied to the reset port of the Impulse C module.

--Scott

[Brett]

Take a look at the system.vhdl file generated by EDK to see what signal it tied to the reset port of the Impulse C module.

--Scott

fsl_v20_0_OPB_Rst

The signal connects to the first fsl bus (the other two are open) and the fsl_des core (both on the FSL_Rst port). The SYS_Rst ports for all three fsl busses are tied to net_gnd0. I'm more than a little puzzled about this. So is this EDK fault for not using the resets or should codeveloper be generating a separate reset?

brett

[GreenMountain]

fsl_v20_0_OPB_Rst

The signal connects to the first fsl bus (the other two are open) and the fsl_des core (both on the FSL_Rst port). The SYS_Rst ports for all three fsl busses are tied to net_gnd0. I'm more than a little puzzled about this. So is this EDK fault for not using the resets or should codeveloper be generating a separate reset?

brett

Here's something you can try.

1. Delete the 3des core from the EDK System Assembly
2. Exit EDK
3. Locate the .mpd file for the 3des core under the pcores directory of the EDK project
4. Change the line PORT FSL_Rst = OPB_Rst, ... to PORT FSL_Rst = "", ...
5. Restart EDK and add the core back from the project repository
6. Click on the ports tab to see if the core now has a reset that you can assign to the system reset

--Scott

[Brett]

Here's something you can try.

1. Delete the 3des core from the EDK System Assembly
2. Exit EDK
3. Locate the .mpd file for the 3des core under the pcores directory of the EDK project
4. Change the line PORT FSL_Rst = OPB_Rst, ... to PORT FSL_Rst = "", ...
5. Restart EDK and add the core back from the project repository
6. Click on the ports tab to see if the core now has a reset that you can assign to the system reset

--Scott

Hmmm... ok, I tried that but now I'm back to the behavior where it seems like the hw core is always stuck.

Impulse C 3DES DEMO
Running encryption test on FPGA ...

It does this for both values of the "Active low reset" flag in codeveloper.

Brett

[Brett]

As a footnote, I regenerated the 3DES with the active low flag set and unset. I captured the contents of the pcores directory and ran a diff between the two variants.
The result:

CODE

diff -ur active high/fsl_des_v1_00_a/hdl/vhdl/3des_top.vhd active low/fsl_des_v1_00_a/hdl/vhdl/3des_top.vhd
--- active high/fsl_des_v1_00_a/hdl/vhdl/3des_top.vhd    Thu Feb  8 11:01:45 2007
+++ active low/fsl_des_v1_00_a/hdl/vhdl/3des_top.vhd    Thu Feb  8 10:28:04 2007
@@ -17,7 +17,7 @@

entity des is
   port (
-    reset : in std_ulogic;
+    reset_n : in std_ulogic;
     sclk : in std_ulogic;
     clk : in std_ulogic;
     p_des_test_config_out_en : in std_ulogic;
@@ -67,8 +67,10 @@
   signal p_des_ic_blocks_out_en : std_ulogic;
   signal p_des_ic_blocks_out_eos : std_ulogic;
   signal p_des_ic_blocks_out_data : std_ulogic_vector (7 downto 0);
+  signal reset : std_ulogic;
   signal local_reset : std_ulogic;
begin
+  reset <= not reset_n;
   local_reset <= reset;

   des_ic0: des_ic
diff -ur active high/fsl_des_v1_00_a/hdl/vhdl/fsl_des.vhd active low/fsl_des_v1_00_a/hdl/vhdl/fsl_des.vhd
--- active high/fsl_des_v1_00_a/hdl/vhdl/fsl_des.vhd    Thu Feb  8 11:01:45 2007
+++ active low/fsl_des_v1_00_a/hdl/vhdl/fsl_des.vhd    Thu Feb  8 10:28:04 2007
@@ -39,7 +39,7 @@
architecture impl of fsl_des is
   component des is
     port (
-    reset : in std_ulogic;
+    reset_n : in std_ulogic;
     sclk : in std_ulogic;
     clk : in std_ulogic;
     p_des_test_config_out_en : in std_ulogic;
@@ -69,11 +69,13 @@
   signal p_des_test_input_stream_en : std_ulogic;
   signal p_des_test_input_stream_eos : std_ulogic;
   signal p_des_test_input_stream_idata : std_ulogic_vector (7 downto 0);
+  signal FSL_Rst_n : std_ulogic;


   -- fsl signals
   -- end fsl signals
begin
+  FSL_Rst_n <= not FSL_Rst;
   FSL0_S_Clk <= FSL_Clk;
   p_des_test_config_out_if: fsl_to_stream
     generic map (
@@ -127,7 +129,7 @@

   des_0: des
     port map (
-      FSL_Rst,
+      FSL_Rst_n,
       FSL_Clk,
       co_clk,
       p_des_test_config_out_en,

So, the active low option only affects the vhdl wrappers on the actual core, and it inverts the reset twice! The inverted signal is never used, so the active low flag has no real effect.

Brett

[GreenMountain]

Hmmm... ok, I tried that but now I'm back to the behavior where it seems like the hw core is always stuck.

It does this for both values of the "Active low reset" flag in codeveloper.

Brett

What signal is associated to the reset in the system.vhd file now?

--Scott

[Brett]

What signal is associated to the reset in the system.vhd file now?

--Scott

sys_rst_s which is active low and the core design expects active high, so it doesn't work.

After my previous note on how the fsl resets don't seem to be setup by codeveloper correctly, I'm trying my own mod by inverting the FSL_Rst inside the fsl_des.vhd file (no "Active low reset" flag).
...
...
...
And it works.

thanks for the heads up on where to look for this stuff.

Forgive the curiosity (and ignorance), but was what I just did a fluke? Is there some other reason Codeveloper hasn't been fixed to properly generate fsl resets (other than time and people)?

Brett

[GreenMountain]

sys_rst_s which is active low and the core design expects active high, so it doesn't work.

After my previous note on how the fsl resets don't seem to be setup by codeveloper correctly, I'm trying my own mod by inverting the FSL_Rst inside the fsl_des.vhd file (no "Active low reset" flag).
...
...
...
And it works.

thanks for the heads up on where to look for this stuff.

Forgive the curiosity (and ignorance), but was what I just did a fluke? Is there some other reason Codeveloper hasn't been fixed to properly generate fsl resets (other than time and people)?

Brett

I think you are the first person to report the problem. Thanks for you help in finding a fix.

--Scott

[RalphBodenner]

It looks like the problem was two-fold:

1. FSL_Rst was connected to an OPB signal in the MPD file, so you couldn't easily tie it to sys_rst_s.

2. The active-low option was "duplicated" at the bus wrapper level (fsl_des.vhd) and in the Impulse C core (des_top.vhd), causing the reset to be inverted first in the wrapper, then again in the core. The result was that the core's reset got the wrong polarity if the system reset was active-low, regardless of whether the "Active-low reset" project option was set.

I've whipped up a solution to both issues in the bus wrapper generation script. You'll have to connect the FSL_Rst to the reset of your choice in EDK. The "Active-low reset" option should work as expected for FSL (and FSL only--other buses must use active-high resets).

After more testing, these fixes should make it into our next release. In the meantime, I'll attach the patched script, which you can copy to %IMPULSEC_HOME%\Architectures\VHDL\Xilinx\.

Brett, please give this patch a try and let us know if it works for you. Thanks for working out the details of this issue with Scott.

Regards,
Ralph

Attached File(s)

•  genbus.zip (15.14K)
  Number of downloads: 2

[Brett]

It looks like the problem was two-fold:

1. FSL_Rst was connected to an OPB signal in the MPD file, so you couldn't easily tie it to sys_rst_s.

2. The active-low option was "duplicated" at the bus wrapper level (fsl_des.vhd) and in the Impulse C core (des_top.vhd), causing the reset to be inverted first in the wrapper, then again in the core. The result was that the core's reset got the wrong polarity if the system reset was active-low, regardless of whether the "Active-low reset" project option was set.

I've whipped up a solution to both issues in the bus wrapper generation script. You'll have to connect the FSL_Rst to the reset of your choice in EDK. The "Active-low reset" option should work as expected for FSL (and FSL only--other buses must use active-high resets).

After more testing, these fixes should make it into our next release. In the meantime, I'll attach the patched script, which you can copy to %IMPULSEC_HOME%\Architectures\VHDL\Xilinx\.

Brett, please give this patch a try and let us know if it works for you. Thanks for working out the details of this issue with Scott.

Regards,
Ralph

Great! Excellent turnaround. I checked out this patch and it appears to work correctly.

Brett

[Brett]

Great! Excellent turnaround. I checked out this patch and it appears to work correctly.

Brett

I've upgraded a machine to 8.1 and it doesn't seem to like the rst pin not having a default vaslue. I set this one to net_gnd (not sure what a good default value is).