Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hello,
I'm curious to know if there is a way we could tell the synthesizer to use
registered mode of BRAM when using ram_style "block" attribute.
The registered mode otherwise can be enabled by instantiating a BRAM with
DOA_REG, DOB_REG set to 1 and REGCEA, REGCEB set to '1'.
For example, the VHDLcode below infers a BRAM. However, it does not enable
the registered mode. To get around with it, I've added a process which
registers the output wherever this memory is instantiated. This added
register occupies a slice. Is there a way I can tell the synthesizer to use
the register inside of BRAM (that way I could save resources).
====
attribute ram_style : string;
attribute ram_style of RAM : signal is "block";
begin
process (clk)
begin
if clk'event and clk = '1' then
if en = '1' then
if we = '1' then
RAM(conv_integer(addr)) <= di;
end if;
do <= RAM(conv_integer(addr));
end if;
end if;
end process;
end;
=====
Thanks,
Shantesh
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 147826On Tue, 25 May 2010 14:32:59 -0700, Rob Gaddi <rgaddi@technologyhighland.com> wrote: >I've got a Spartan 6 design that I'm working with under ISE 11.5. A >code block that I would expect to take up about 200 LUTs is taking 800 >instead. 600 LUTs wouldn't be the end of the world, except I'm planning >to replicate this block 32 times, which puts me well over the top. > >So the question becomes where are all of the LUTs going? > Then I tried looking >through the technology schematic instead. The viewer took forever to >open the schematic, and when I finally got it open it took better than a >minute any time I wanted to refresh the screen. Needless to say, this >got me nowhere. Rather than use the technology viewer, I've had better luck reading the post-synthesis netlist in a text editor! I'm not necessarily recommending that approach, but it has its uses. You could quickly search for the first few instances of "ram_k_hi", then every instance of "ram_k_hi<whatever>(63) to see if e.g. the LUT RAMs have been duplicated to give you enough ports. But my recommendation would be divide and conquer on that block; it's not large. For example, comment or "generate" out the coefficient readback module and see how the size changes. Or "generate" out the whole lot then re-introduce it a block at a time, comparing the synth result with your expectations. Have you allowed for the size of the coefficient rams - 3x64-bit as far as I can tell from the posted code? Or how are the 4 ports of the quad port RAM organised? With more than 1 write port, that can get complex and inefficient... - BrianArticle: 147827
On 5/25/2010 5:36 PM, Brian Drummond wrote: > On Tue, 25 May 2010 14:32:59 -0700, Rob Gaddi > <rgaddi@technologyhighland.com> wrote: > >> I've got a Spartan 6 design that I'm working with under ISE 11.5. A >> code block that I would expect to take up about 200 LUTs is taking 800 >> instead. 600 LUTs wouldn't be the end of the world, except I'm planning >> to replicate this block 32 times, which puts me well over the top. >> >> So the question becomes where are all of the LUTs going? > >> Then I tried looking >> through the technology schematic instead. The viewer took forever to >> open the schematic, and when I finally got it open it took better than a >> minute any time I wanted to refresh the screen. Needless to say, this >> got me nowhere. > > Rather than use the technology viewer, I've had better luck reading the > post-synthesis netlist in a text editor! > > I'm not necessarily recommending that approach, but it has its uses. You > could quickly search for the first few instances of "ram_k_hi", then > every instance of "ram_k_hi<whatever>(63) to see if e.g. the LUT RAMs > have been duplicated to give you enough ports. > > But my recommendation would be divide and conquer on that block; it's > not large. For example, comment or "generate" out the coefficient > readback module and see how the size changes. Or "generate" out the > whole lot then re-introduce it a block at a time, comparing the synth > result with your expectations. > > Have you allowed for the size of the coefficient rams - 3x64-bit as far > as I can tell from the posted code? Or how are the 4 ports of the quad > port RAM organised? With more than 1 write port, that can get complex > and inefficient... > > - Brian The quad port only became a quad port because XST decided to implement the reset logic on it's own dedicated write port rather than just have one write port and feed it from an AND gate. It turns out that, if I just comment out the reset logic, the utilization drops to 236 LUTs. It must have been implementing something truly awful to try to get that extra write port in. Why it thought it needed it in the first place I'll never know, but at least I'm back on track now. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147828
> It turns out that, if I just comment out the reset logic, the utilization drops to 236 LUTs. It > must have been implementing something truly awful to try to get that extra write port in. Why it > thought it needed it in the first place I'll never know, but at least I'm back on track now. Rob, some(/most) templates for inferring RAMs don't work if you have a reset defined. Nial.Article: 147829
John Larkin wrote: > On Tue, 25 May 2010 09:12:05 -0700 (PDT), d_s_klein > <d_s_klein@yahoo.com> wrote: > >> >> I've had *very* good responses when I've called Altera and said that >> I was wanting to migrate. >> >> That said, no matter which side of the fence (A<->X) I'm on, it >> always looks greener on the other side :) >> >> RK > > Xilinx probably has better silicon, and it works great. The software > is a train wreck. > It seems nothing much has changed in the past decade or more! Shame Xilinx don't make more effort with their software, then they'd win on both counts.Article: 147830
On May 25, 7:47=A0pm, "shantesh" <shantesh84@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Hello, > > I'm curious to know if there is a way we could tell the synthesizer to us= e > registered mode of BRAM when using ram_style "block" attribute. > > The registered mode otherwise can be enabled by instantiating a BRAM with > DOA_REG, DOB_REG set to 1 and REGCEA, REGCEB set to '1'. > > For example, the VHDLcode below infers a BRAM. However, it does not enabl= e > the registered mode. To get around with it, I've added a process which > registers the output wherever this memory is instantiated. This added > register occupies a slice. Is there a way I can tell the synthesizer to u= se > the register inside of BRAM (that way I could save resources). > > =3D=3D=3D=3D > =A0 attribute ram_style =A0 =A0 =A0 =A0: string; > =A0 attribute ram_style of RAM : signal is "block"; > > begin > > =A0 process (clk) > =A0 begin > =A0 =A0 if clk'event and clk =3D '1' then > =A0 =A0 =A0 if en =3D '1' then > =A0 =A0 =A0 =A0 if we =3D '1' then > =A0 =A0 =A0 =A0 =A0 RAM(conv_integer(addr)) <=3D di; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 do =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<=3D RA= M(conv_integer(addr)); > =A0 =A0 =A0 end if; > =A0 =A0 end if; > =A0 end process; > > end; > =3D=3D=3D=3D=3D > > Thanks, > Shantesh =A0 =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Rather than adding a process, have you tried simply adding a register stage in the process where the RAM is inferred? Somethimes synthesizers understand your intentions better when they're all together.Article: 147831
On Tue, 25 May 2010 17:45:33 -0700, Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On 5/25/2010 5:36 PM, Brian Drummond wrote: >> On Tue, 25 May 2010 14:32:59 -0700, Rob Gaddi >> <rgaddi@technologyhighland.com> wrote: >> >>> I've got a Spartan 6 design that I'm working with under ISE 11.5. A >>> code block that I would expect to take up about 200 LUTs is taking 800 >>> instead. >> Or how are the 4 ports of the quad >> port RAM organised? With more than 1 write port, that can get complex >> and inefficient... >The quad port only became a quad port because XST decided to implement >the reset logic on it's own dedicated write port rather than just have >one write port and feed it from an AND gate. > >It turns out that, if I just comment out the reset logic, the >utilization drops to 236 LUTs. Glad you found it. Implementing the reset externally as you described, is the sort of trick that is occasionally necessary to get round XST limitations. Or eliminating the reset, and writing all those zeroes across the wishbone bus. If you think that XST can be usefully improved in this area, submit a testcase to Webcase. - BrianArticle: 147832
Hello, I am trying to implement several crc generator/checkers in vhdl in an fpga. The crc32 seems to work ok, a byte at a time. Can I do crc16 16 bits at a time, rather than a byte at a time? Thanks. Bill --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147833
In comp.arch.fpga, bdurr <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote: > Hello, > > I am trying to implement several crc generator/checkers in vhdl in an fpga. > The crc32 seems to work ok, a byte at a time. > > Can I do crc16 16 bits at a time, rather than a byte at a time? Yes, but... Doing CRC16 8 bit at the time requires a 256 entry 16-bit lookup table. For 16 bit at the time you require a 64k entry 16-bit LUT. Easiest implementation is 1 bit at the time, requires no LUT at all. Why do you require 16-bit at the time? Speed? If so, how many clocks do you have for the calculation? -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) It looks like blind screaming hedonism won out.Article: 147834
On 26 May, 13:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: > In comp.arch.fpga, > > bdurr <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote: > > Hello, > > > I am trying to implement several crc generator/checkers in vhdl in an f= pga. > > =A0The crc32 seems to work ok, a byte at a time. > > > Can I do crc16 16 bits at a time, rather than a byte at a time? > > Yes, but... > Doing CRC16 8 bit at the time requires a 256 entry 16-bit lookup table. > For 16 bit at the time you require a 64k entry 16-bit LUT. Surely better just to implement directly as logic rather than a LUT? JonArticle: 147835
On May 26, 2:36=A0pm, Jon Beniston <j...@beniston.com> wrote: > On 26 May, 13:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: > > > In comp.arch.fpga, > > > bdurr <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote: > > > Hello, > > > > I am trying to implement several crc generator/checkers in vhdl in an= fpga. > > > =A0The crc32 seems to work ok, a byte at a time. > > > > Can I do crc16 16 bits at a time, rather than a byte at a time? > > > Yes, but... > > Doing CRC16 8 bit at the time requires a 256 entry 16-bit lookup table. > > For 16 bit at the time you require a 64k entry 16-bit LUT. > > Surely better just to implement directly as logic rather than a LUT? > > Jon CRC calculation can be easily implemented with combinational logic and no LUT's. Simply google 'VHDL crc generator' (or HDL/Verilog) and use the code you will get from your custom settings. In some cases you will need to check bit ordering, but this way you will be able to perform crc calculations with as many bits in the input as you wish. wojtekArticle: 147836
In comp.arch.fpga, wojtek <wojtekpowiertowski@gmail.com> wrote: > On May 26, 2:36 pm, Jon Beniston <j...@beniston.com> wrote: >> On 26 May, 13:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: >> >> > In comp.arch.fpga, >> >> > bdurr <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote: >> > > Hello, >> >> > > I am trying to implement several crc generator/checkers in vhdl in an fpga. >> > > The crc32 seems to work ok, a byte at a time. >> >> > > Can I do crc16 16 bits at a time, rather than a byte at a time? >> >> > Yes, but... >> > Doing CRC16 8 bit at the time requires a 256 entry 16-bit lookup table. >> > For 16 bit at the time you require a 64k entry 16-bit LUT. >> >> Surely better just to implement directly as logic rather than a LUT? > > CRC calculation can be easily implemented with combinational logic and > no LUT's. Simply google 'VHDL crc generator' (or HDL/Verilog) and use > the code you will get from your custom settings. In some cases you > will need to check bit ordering, but this way you will be able to > perform crc calculations with as many bits in the input as you wish. Whoeps, I was thinking too much in the software direction, did the LUT thing there. In VHDL, I only did 1-bit serial direct approach. Sorry and thanks for the search term, the first hit is e really wonderful page! -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) You never have to change anything you got up in the middle of the night to write. -- Saul BellowArticle: 147837
Here is a nice paper showing how XMOS devices can replace FPGAs in many applications: http://www.xmos.com/system/files/wp-xmos-fpga.pdf LeonArticle: 147838
On 5/26/2010 1:54 AM, Nial Stewart wrote: >> It turns out that, if I just comment out the reset logic, the utilization drops to 236 LUTs. It >> must have been implementing something truly awful to try to get that extra write port in. Why it >> thought it needed it in the first place I'll never know, but at least I'm back on track now. > > > Rob, some(/most) templates for inferring RAMs don't work if you have a > reset defined. > > > Nial. > The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until the entire thing was done. The intention being that the entire thing would take place on the normal write port of the RAM, which wasn't being used while it was in the reset state. Apparently it didn't work out that way. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147839
On May 26, 11:12=A0am, Leon <leon...@btinternet.com> wrote: > Here is a nice paper showing how XMOS devices can replace FPGAs in > many applications: > > http://www.xmos.com/system/files/wp-xmos-fpga.pdf > > Leon Interesting paper. I've looked at the XMOS parts before and never been impressed, but that may have been because of no special need or I just didn't spend much time at it. I have a design idea I am batting around that the XMOS might be suitable for. Your paper doesn't say much about program storage; I gather that other than the 8 kB OTP it is off chip. You might want to include some links in your paper to the web site. That would make it easier to get additional info. RickArticle: 147840
> The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until > the entire thing was done. The intention being that the entire thing would take place on the > normal write port of the RAM, which wasn't being used while it was in the reset state. Apparently > it didn't work out that way. Oh right, that's odd. I wonder if the ram inference and reset were too tightly integrated for the synthesis tool to extract the RAM? Taking the reset functionality out made its job easier. Nial.Article: 147841
On May 26, 11:05=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 5/26/2010 1:54 AM, Nial Stewart wrote: > > >> It turns out that, if I just comment out the reset logic, the utilizat= ion drops to 236 LUTs. =A0It > >> must have been implementing something truly awful to try to get that e= xtra write port in. =A0Why it > >> thought it needed it in the first place I'll never know, but at least = I'm back on track now. > > > Rob, some(/most) templates for inferring RAMs don't work if you have a > > reset defined. > > > Nial. > > The reset logic was sequential, i.e. reset address 0, then reset address > 1, one per clock until the entire thing was done. =A0The intention being > that the entire thing would take place on the normal write port of the > RAM, which wasn't being used while it was in the reset state. > Apparently it didn't work out that way. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Rob, In the the report generated by the Xilinx map application, see "Section 14 - Utilization by Hierarchy." This will give you a hierarchical resource breakdown (including LUTs), though it may not have the detail your after. Darol KlawetterArticle: 147842
I had a board which mounted Virtex 155. I've changed the FPGA to Virtex 220. The support engineer of Xilinx sales company said both FPGAs were compatible and there was no problem. But all 4 board I changed FPGA don't work at all. Even JTAG interface doesn't work. Are they actually compatible? Or do we need to modify the board to mount Virtex 220? KazuArticle: 147843
On 26 May, 17:23, rickman <gnu...@gmail.com> wrote: > On May 26, 11:12=A0am, Leon <leon...@btinternet.com> wrote: > > > Here is a nice paper showing how XMOS devices can replace FPGAs in > > many applications: > > >http://www.xmos.com/system/files/wp-xmos-fpga.pdf > > > Leon > > Interesting paper. =A0I've looked at the XMOS parts before and never > been impressed, but that may have been because of no special need or I > just didn't spend much time at it. =A0I have a design idea I am batting > around that the XMOS might be suitable for. =A0Your paper doesn't say > much about program storage; I gather that other than the 8 kB OTP it > is off chip. =A0You might want to include some links in your paper to > the web site. =A0That would make it easier to get additional info. > > Rick It's not my paper! I just thought it might be of interest. For programs larger than 8k, off-chip flash has to be used for program storage. The XMOS web site is here: http://www.xmos.com/ Leon LeonArticle: 147844
On May 26, 12:52=A0pm, Kazu <cygnet.s...@gmail.com> wrote: > I had a board which mounted Virtex 155. I've changed =A0the FPGA to > Virtex 220. > The support engineer of Xilinx sales company said both FPGAs were > compatible and there was no problem. > But all 4 board I changed FPGA don't work at all. Even JTAG interface > doesn't work. > Are they actually compatible? Or do we need to modify the board to > mount Virtex 220? > > Kazu Virtex 5 devices in the same package should be pin compatible. Note that Virtex 5 LX and LXT parts are not pin compatible, but their packages are also slightly different. For example if you had the V5LX155T you can't go to a V5LX220 (no "T"). If that's not the issue, I would suggest taking a look at your power supplies to be sure you have enough current for the larger part. Regards, GaborArticle: 147845
On May 26, 2:02=A0pm, Leon <leon...@btinternet.com> wrote: > On 26 May, 17:23, rickman <gnu...@gmail.com> wrote: > > > > > On May 26, 11:12=A0am, Leon <leon...@btinternet.com> wrote: > > > > Here is a nice paper showing how XMOS devices can replace FPGAs in > > > many applications: > > > >http://www.xmos.com/system/files/wp-xmos-fpga.pdf > > > > Leon > > > Interesting paper. =A0I've looked at the XMOS parts before and never > > been impressed, but that may have been because of no special need or I > > just didn't spend much time at it. =A0I have a design idea I am batting > > around that the XMOS might be suitable for. =A0Your paper doesn't say > > much about program storage; I gather that other than the 8 kB OTP it > > is off chip. =A0You might want to include some links in your paper to > > the web site. =A0That would make it easier to get additional info. > > > Rick > > It's not my paper! I just thought it might be of interest. > > For programs larger than 8k, off-chip flash has to be used for program > storage. > > The XMOS web site is here: > > http://www.xmos.com/ > > Leon > > Leon Sorry, I figured you were an XMOS employee... jumped the gun on that one. RickArticle: 147846
On Apr 14, 1:05=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > OK thanks I will take a look at the zip file but UG254 seems quite old so > I'm not sure if this is the files I need. > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com The last one published: <http://www.xilinx.com/support/answers/ 24140.htm> You need to register with Xilinx, and get permission from IBM. Or something like that. RKArticle: 147847
On Wed, 26 May 2010 10:06:00 +0100, "Fredxx" <fredxx@spam.com> wrote: >John Larkin wrote: >> On Tue, 25 May 2010 09:12:05 -0700 (PDT), d_s_klein >> <d_s_klein@yahoo.com> wrote: >> >>> >>> I've had *very* good responses when I've called Altera and said that >>> I was wanting to migrate. >>> >>> That said, no matter which side of the fence (A<->X) I'm on, it >>> always looks greener on the other side :) >>> >>> RK >> >> Xilinx probably has better silicon, and it works great. The software >> is a train wreck. >> > >It seems nothing much has changed in the past decade or more! Shame Xilinx >don't make more effort with their software, then they'd win on both counts. I was using Xilinx' software (ISE) a couple of years ago. It seemed to work fairly well, but was a PITA to use (far more complicated than it needed to be). Ten years ago it was far worse (Synplicity was a must). According to John, it's back to broken. Dunno, I'm not likely to use Xilinx for some time.Article: 147848
On May 26, 5:36=A0am, Jon Beniston <j...@beniston.com> wrote: > On 26 May, 13:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: > > > In comp.arch.fpga, > > > bdurr <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote: > > > Hello, > > > > I am trying to implement several crc generator/checkers in vhdl in an= fpga. > > > =A0The crc32 seems to work ok, a byte at a time. > > > > Can I do crc16 16 bits at a time, rather than a byte at a time? > > > Yes, but... > > Doing CRC16 8 bit at the time requires a 256 entry 16-bit lookup table. > > For 16 bit at the time you require a 64k entry 16-bit LUT. > > Surely better just to implement directly as logic rather than a LUT? > > Jon Implementing a parallel CRC with random logic rather than LUT RAM is probably going to take more LUTs than the LUT RAM would! The tables for parallel CRC are large, and the content doesn't have a simple pattern that can be significantly reduced by logic minimization. (If it did, the CRC function wouldn't be as useful.) EricArticle: 147849
1.the format of encrypted file can_v3_2/can_tl_bsp.vhd as an example. a)the first 8 bytes XlxV62EB is version code,From ISE11.1 Xilinx use AES. b)the first 8bytes of line2 is the length of the ciphertext.=EF=BC=8Cit mea= ns that the next segment of ciphertext is after 3300H c)from 18h bytes is ciphertext which is made by the Zlib compress then AES encrypted. 00000000h: 58 6C 78 56 36 32 45 42 20 20 20 20 66 61 30 30 ; XlxV62EB fa00 00000010h: 20 20 20 20 33 33 30 30 79 69 0B DB A6 74 14 DA ; 3300yi.=E9=83=90t.? 00000020h: 46 FE 2C 93 15 2C 28 A1 22 55 3A AA 55 20 4A DB ; F??,(?U:=E7=8C= =86 J? 00000030h: 40 4D 51 E1 EA 28 AB AD 61 F5 57 7F 2B F4 CA 26 ; @MQ=E5=BD=A1(= =EE=81=AAa=E9=AE=93=7F + =E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3= =80=82=E3=80=82 00003310h: B9 64 BE 7E 02 BB 0F 56 58 6C 78 56 36 32 45 42 ; =E7=AD=AA=E7= =B7=99.? VXlxV62EB 00003320h: 20 20 20 20 36 38 35 63 20 20 20 20 31 34 66 30 ; 685c 14f0 00003330h: AF 07 8F 0F 8D F2 0E E6 50 1F 2F 71 0B 5A 80 A9 ; ??=E5=B6=92.= =E9=8D=BC./ q.Z 2.how to decrypt a)With AES, each 16bytes block is encrypted under same AES key(256bit Key)=E3=80=82 if the ciphertext can't be divided evenly,don't process these left bytes=E3=80=82 b)XOR with the 16bytes initial data c)replace the initial XOR data with this 16bit ciphertext. d)go to a e=EF=BC=89combine to a file 3.download ZLIB fromhttp://www.zlib.net/ a=EF=BC=89call the unpress function ; b)the we got the source code : 4.how to find the key uasm the libisl_iostreams.dll with IDA pro we find .text:10004D50 private: void __thiscall isl::iostreams::filter::xp_decrypt<class isl::iostreams::filter::xp_aes_keys>::process_block_data(void) .text:10004D50 ; CODE XREF: sub_1000C9E0+3D=19p .text:10004D50 .text:10004D50 var_18 =3D dword ptr -18h .text:10004D50 var_14 =3D dword ptr -14h .text:10004D50 var_10 =3D dword ptr -10h .text:10004D50 var_C =3D dword ptr -0Ch .text:10004D50 var_4 =3D dword ptr -4 .text:10004D50 .text:10004D50 push 0FFFFFFFFh .text:10004D52 push offset loc_1001B6D8 .text:10004D57 mov eax, large fs:0 .text:10004D5D push eax .text:10004D5E sub esp, 0Ch .text:10004D61 push ebx .text:10004D62 push ebp .text:10004D63 push esi .text:10004D64 push edi .text:10004D65 mov eax, dword_10032908 .text:10004D6A xor eax, esp .text:10004D6C push eax .text:10004D6D lea eax, [esp+2Ch+var_C] .text:10004D71 mov large fs:0, eax .text:10004D77 mov edi, ecx .text:10004D79 lea ecx, [edi+9] .text:10004D7C call ? get_block_bytes@xp_header@detail@filter@iostreams@isl@@QBEIXZ ; isl::iostreams::filter::detail::xp_header::get_block_bytes(void) .text:10004D81 xor ebp, ebp .text:10004D83 mov esi, eax .text:10004D85 lea ebx, [edi+21h] .text:10004D88 mov [esp+2Ch+var_18], ebp .text:10004D8C mov [esp+2Ch+var_14], ebp .text:10004D90 mov [esp+2Ch+var_10], ebp .text:10004D94 lea eax, [esi+1] .text:10004D97 push eax .text:10004D98 lea ecx, [esp+30h+var_18] .text:10004D9C mov [esp+30h+var_4], ebp .text:10004DA0 call data_mv .text:10004DA5 mov ecx, [edi] .text:10004DA7 mov edx, [esp+2Ch+var_18] .text:10004DAB push ebp .text:10004DAC push ecx .text:10004DAD push edx .text:10004DAE push esi .text:10004DAF push ebx .text:10004DB0 call aes_process <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dthis function .text:10004DB5 mov eax, [esp+40h+var_18] .text:10004DB9 movsx ecx, byte ptr [eax+esi-1] .text:10004DBE add esp, 14h .text:10004DC1 sub esi, ecx .text:10004DC3 push esi .text:10004DC4 add edi, 8 .text:10004DC7 push eax .text:10004DC8 mov ecx, edi .text:10004DCA call ? set_block@xp_header_reader@detail@filter@iostreams@isl@@QAEXPBDI@Z ; isl::iostreams::filter::detail::xp_header_reader::set_block(char const *,uint) .text:10004DCF mov ecx, edi .text:10004DD1 call ? append_output@xp_header_reader@detail@filter@iostreams@isl@@QAEXXZ ; isl::iostreams::filter::detail::xp_header_reader::append_output(void) .text:10004DD6 lea ecx, [esp+2Ch+var_18] .text:10004DDA mov [esp+2Ch+var_4], 0FFFFFFFFh .text:10004DE2 call sub_10004F40 .text:10004DE7 mov ecx, [esp+2Ch+var_C] .text:10004DEB mov large fs:0, ecx .text:10004DF2 pop ecx .text:10004DF3 pop edi .text:10004DF4 pop esi .text:10004DF5 pop ebp .text:10004DF6 pop ebx .text:10004DF7 add esp, 18h .text:10004DFA retn .text:10004DFA ? .text:10004BC0 aes_process proc near ; CODE XREF: isl::iostreams::filter::xp_decrypt<isl::iostreams::filter::xp_aes_keys>::pr= ocess_block_data(void) +60=19p .text:10004BC0 ; isl::iostreams::filter::xp_encrypt<isl::iostreams::filter::xp_aes_keys>::pr= ocess_block_data(void) +D2=19p .text:10004BC0 .text:10004BC0 var_158 =3D byte ptr -158h .text:10004BC0 var_64 =3D byte ptr -64h .text:10004BC0 var_60 =3D byte ptr -60h .text:10004BC0 var_44 =3D byte ptr -44h .text:10004BC0 var_40 =3D byte ptr -40h .text:10004BC0 var_4 =3D dword ptr -4 .text:10004BC0 arg_0 =3D dword ptr 4 .text:10004BC0 arg_4 =3D dword ptr 8 .text:10004BC0 arg_8 =3D dword ptr 0Ch .text:10004BC0 arg_C =3D dword ptr 10h .text:10004BC0 arg_10 =3D byte ptr 14h .text:10004BC0 .text:10004BC0 sub esp, 158h .text:10004BC6 mov eax, dword_10032908 .text:10004BCB xor eax, esp .text:10004BCD mov [esp+158h+var_4], eax .text:10004BD4 push ebx .text:10004BD5 mov ebx, [esp+15Ch+arg_8] .text:10004BDC push ebp .text:10004BDD mov ebp, [esp+160h+arg_0] .text:10004BE4 push esi .text:10004BE5 mov esi, [esp+164h+arg_4] .text:10004BEC push edi .text:10004BED mov edi, [esp+168h+arg_C] .text:10004BF4 mov eax, [edi] .text:10004BF6 mov edx, [eax] .text:10004BF8 lea ecx, [esp+168h+var_44] .text:10004BFF push ecx .text:10004C00 mov ecx, edi .text:10004C02 call edx .text:10004C04 cmp [esp+168h+arg_10], 0 .text:10004C0C mov ecx, edi .text:10004C0E jz short loc_10004C2C .text:10004C10 mov edx, [edi] .text:10004C12 lea eax, [esp+168h+var_158] .text:10004C16 push eax .text:10004C17 mov eax, [edx+8] .text:10004C1A call eax .text:10004C1C push eax .text:10004C1D lea ecx, [esp+16Ch+var_40] .text:10004C24 push ecx .text:10004C25 call enckeyexp .text:10004C2A jmp short loc_10004C46 .text:10004C2C ; --------------------------------------------------------------------------- .text:10004C2C .text:10004C2C loc_10004C2C: ; CODE XREF: aes_process+4E=18j .text:10004C2C mov eax, [edi] .text:10004C2E lea edx, [esp+168h+var_158] .text:10004C32 push edx .text:10004C33 mov edx, [eax+8] .text:10004C36 call edx .text:10004C38 push eax .text:10004C39 lea eax, [esp+16Ch+var_40] .text:10004C40 push eax .text:10004C41 call deckeyexp <=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DHere we will find the key .text:10004C46 .text:10004C46 loc_10004C46: ; CODE XREF: aes_process+6A=18j .text:10004C46 mov edx, [edi] .text:10004C48 mov edx, [edx+4] .text:10004C4B add esp, 0Ch .text:10004C4E lea eax, [esp+164h+var_60] .text:10004C55 push eax .text:10004C56 mov ecx, edi .text:10004C58 call edx .text:10004C5A mov eax, esi .text:10004C5C and eax, 0Fh .text:10004C5F sub esi, eax .text:10004C61 push eax ; Size .text:10004C62 lea eax, [esi+ebp] .text:10004C65 push eax ; Src .text:10004C66 lea ecx, [ebx+esi] .text:10004C69 push ecx ; Dst .text:10004C6A call memcpy .text:10004C6F add esp, 0Ch .text:10004C72 cmp [esp+168h+arg_10], 0 .text:10004C7A jz short loc_10004C8D .text:10004C7C push 1 .text:10004C7E lea edx, [esp+16Ch+var_64] .text:10004C85 push edx .text:10004C86 lea eax, [esp+170h+var_158] .text:10004C8A push eax .text:10004C8B jmp short loc_10004C9C .text:10004C8D ; --------------------------------------------------------------------------- .text:10004C8D .text:10004C8D loc_10004C8D: ; CODE XREF: aes_process+BA=18j .text:10004C8D push 0 .text:10004C8F lea ecx, [esp+16Ch+var_64] .text:10004C96 push ecx .text:10004C97 lea edx, [esp+170h+var_158] .text:10004C9B push edx .text:10004C9C .text:10004C9C loc_10004C9C: ; CODE XREF: aes_process+CB=18j .text:10004C9C push esi .text:10004C9D push ebx .text:10004C9E push ebp .text:10004C9F call aes_blk <=3D=3D=3D=3D=3D=3D=3D= =3D=3Din this function XOR seeds .text:10004CA4 mov ecx, [esp+180h+var_4] .text:10004CAB add esp, 18h .text:10004CAE pop edi .text:10004CAF pop esi .text:10004CB0 pop ebp .text:10004CB1 pop ebx .text:10004CB2 xor ecx, esp .text:10004CB4 call sub_1001A14C .text:10004CB9 add esp, 158h .text:10004CBF retn .text:10004CBF aes_process endp
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z