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
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 endpArticle: 147851
Eric Smith <spacewar@gmail.com> writes: > 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 If you have 65536x16 = 1Mb of sufficiently fast RAM to spare in your FPGA you can do the CRC by simply looking up your 16-bit input word into the RAM, and to a single 16-bit xor and you're done. Something like this, but in HDL: http://groups.google.no/group/comp.lang.lisp/msg/8a475821a85b331c?hl=no Petter -- .sig removed by request.Article: 147852
Hi *, has anyone had any success with the "new" partion flow in ISE12.1? I've been fiddling around with this for a few hours, but whatever I try, the design fails to even finish routing on the first pass as soon as I enable partitions. The error messages vary, mostly it's complaining about hundreds of unroutable nets and just quits. I've read ug748, which mentions several prerequisites that need to be met, all of which I believe I do meet. One that is not mentioned in the documentation is that you need to set "keep_hierarchy" to YES during synthesis, or it won't even find the modules you want to declare as partitions. This at least seems kind of "logical", but still it should be in the documentation... I remember in earlier ISE versions they mentioned that the partition flow had problems with GENERATE statements and GENERICs, both of which I do use extensively. Could that be the problem? Success or failure stories, anyone? :) cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 147853
On May 26, 1:55=A0pm, "bdurr" <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote:
> Can I do crc16 16 bits at a time, rather than a byte at a time?
> Thanks.
>
> Bill
Hi Bill,
a time ago I need a CRC16 with 16 bit input data in one clock cycle.
I developed this with public informations like Google and Wikipedia
and so on.
But my comments are not very extensive.
Here is the VHDL source:
VidCrcGen: for i in VID_CRC_H'range generate
begin
process(VID_CLK, RESET)
variable crc_temp: std_logic_vector(15 downto 0);
begin
if (RESET =3D '1') then
VID_CRC_C(i) <=3D (others =3D> '0');
VID_CRC_H(i) <=3D (others =3D> '0');
elsif (rising_edge(VID_CLK)) then
if (VID_CRC_Ctrl(i)(2) =3D '1') then -- Valid
if (VID_CRC_Ctrl(i)(1) =3D '1') then -- Stop
if (VID_CRC_Ctrl(i)(0) =3D '1') then -- Start
-- End of Image
VID_CRC_H(i) <=3D VID_CRC_C(i);
end if;
VID_CRC_C(i) <=3D (others =3D> '0');
else
-- STOP =3D 0
crc_temp :=3D VID_CRC_C(i);
for j in 15 downto 0 loop
if (VID_CRC_Data(i)(j) /=3D crc_temp(15)) then
crc_temp :=3D (crc_temp(14 downto 0) & '0') xor x"1021";
else
crc_temp :=3D crc_temp(14 downto 0) & '0';
end if;
end loop;
VID_CRC_C(i) <=3D crc_temp;
end if;
end if; -- if (VID_CRC_Ctrl(i)(2) =3D '1') then --
Valid
end if; -- elsif (rising_edge(VID_CLK)) then
end process;
end generate VidCrcGen;
The _C is the calculation register, _H is a hold register which holds
the data for an asynchronous transfer to a microcontroller.
You can ignore the (i) parameter, there are 2 independent data pathes.
The control sognals are commented.
I think the CRC calculation is CCITT (x"1021"), you can verify it at
Wikipedia.
On a Spartan-3A it runs with 80 MHz, maybe 100 is also possible.
Maybe that helps.
Have fun
Florian
Article: 147854<krw@att.bizzzzzzzzzzzz> wrote in message news:6vfrv5tn7amr16jqeaav62fr5hp4sre227@4ax.com... > 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. Its always been broken in some way or another. I get frustrated at the number of times I get an error message where the software has tied itself up in knots and inviting me to open a webcase. And while Xilinx know what the error code is, there's no help available on the site to help the cause. It's usually a piece of code, which is of correct syntax, but something ISE can't cope with and throws the baby out with the bath water. The code can be isolated by commenting chunks out, and there's always been a work around, but it's not untypical for their webcase to take a month to sort out.Article: 147855
In comp.arch.fpga, Eric Smith <spacewar@gmail.com> wrote: > On May 26, 5:36 am, Jon Beniston <j...@beniston.com> wrote: >> On 26 May, 13:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: >> >> > 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? > > 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.) That was my initial thought as well, but try the generator that the before mentioned search turned up: http://www.electronicdesignworks.com/utilities/crc_generator/crc_generator.htm Set data bus width to 16, select CRC-16-CCITT polynomial (or any other if you wish), leave others at default and press the generate VDL button. View the generated VHDL and ... -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Hear about the Californian terrorist that tried to blow up a bus? Burned his lips on the exhaust pipe.Article: 147856
Just to even things up, I've used A and X devices in the last few years and know and prefer the Altera tools much more, but..... A client was hoping to use Altera's PCI Lite (free master/target 32bit/33MHz) core for a project I'm currently working on. November/December last year I tried integrating it in the SOPC system I was building but it was broken. The values set in the configuration pages changed when you saved it and opened it again and when apparently built cleanly, meeting all timing constraints, the PCI card froze the PC I was testing on. It was clear that there had been very litte verification/quality control on this which is unlike Altera, their software mostly just works. IMHO Nial.Article: 147857
"bdurr" <bdurr.ch@n_o_s_p_a_m.verizon.net> wrote in message news:weydncnFP5W0kWDWnZ2dnUVZ_gKdnZ2d@giganews.com... > 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. > I'm surprised no one has mentioned this web tool. I've used it a few times and happy with the results. http://www.easics.com/webtools/crctoolArticle: 147858
And someone can help me with an example for write a random data into any address, I mean an example of how should be the module with the input signals. Thanks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147859
On May 26, 12:39=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > The reset logic was sequential, i.e. reset address 0, then reset addres= s 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 t= he 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. How can a sync ram be used at all if an async reset is specified in the HDL? There is no way to "add" an async reset to a sync memory. RickArticle: 147860
I took a harder look at the XMOS parts and the power consumption is pretty high. I guess the per/MHz figure is no so bad, but at 160 mA typ, it is no improvement over the FPGA on the board, in fact, it is worse. RickArticle: 147861
I am using the Xilinx FFT core v6.0 from ISE 10.1 and I am trying to verify my values with a FFT calculation run on Matlab. My FFT ISIM simulation runs fine and the simulation values match with the bit accurate model provided by Xilinx. But the order of data is very different from Matlab. My Xilinx FFT block is configured as 4096 pt Pipelined steaming I/O with natural order for floating point values. On Matlab, I use the fft function to determine my values. For example: This is the result obtained from Xilinx Logicore v6.0 FFT bit accurate model. LHS are the Xilinx values and the Matlab values are on the right. Though the first value matches, everything else differs. But on closer observation, the 64th value obtained from Xilinx simulation is same as the 2nd value, i.e. xk_re[64] 6002.34 = Matlab:f2_r[1] 6002.34 Xilinx CoreGen FFT real value xk_re xk_re[0] 117467 Matlab:f2_r[0] 117467 xk_re[1] 1180.82 Matlab:f2_r[1] 6002.34 xk_re[2] 789.918 Matlab:f2_r[2] 126.469 xk_re[3] -548.049 Matlab:f2_r[3] -3516.04 xk_re[4] 3580.31 Matlab:f2_r[4] 1111.52 xk_re[5] -2871.39 Matlab:f2_r[5] 2287.02 xk_re[6] -1346.19 Matlab:f2_r[6] 753.863 xk_re[7] 137.655 Matlab:f2_r[7] 1865.09 xk_re[8] 372.955 Matlab:f2_r[8] 26.8989 xk_re[9] -914.218 Matlab:f2_r[9] -167.196 xk_re[10] -463.463 Matlab:f2_r[10] 788.141 xk_re[11] -875.82 Matlab:f2_r[11] 977.657 xk_re[12] -56.4141 Matlab:f2_r[12] 1087.54 xk_re[13] -544.345 Matlab:f2_r[13] 617.382 xk_re[14] -526.662 Matlab:f2_r[14] 397.022 xk_re[15] -333.39 Matlab:f2_r[15] 181.981 xk_re[16] 216.825 Matlab:f2_r[16] 938 xk_re[17] -1274.68 Matlab:f2_r[17] 237.049 xk_re[18] -521.784 Matlab:f2_r[18] 256.72 xk_re[19] -670.137 Matlab:f2_r[19] 897.621 xk_re[20] -82.1999 Matlab:f2_r[20] 9.97936 xk_re[21] -119.689 Matlab:f2_r[21] 180.858 xk_re[22] -905.393 Matlab:f2_r[22] 1481.65 xk_re[23] -276.808 Matlab:f2_r[23] 557.669 xk_re[24] -219.717 Matlab:f2_r[24] 823.101 xk_re[25] -261.175 Matlab:f2_r[25] 272.421 xk_re[26] -850.324 Matlab:f2_r[26] 552.726 xk_re[27] -263.26 Matlab:f2_r[27] 960.132 xk_re[28] -235.821 Matlab:f2_r[28] 678.96 xk_re[29] 35.2347 Matlab:f2_r[29] 859.29 xk_re[30] -72.7756 Matlab:f2_r[30] 731.413 xk_re[31] -518.872 Matlab:f2_r[31] 378.714 xk_re[32] -249.704 Matlab:f2_r[32] 829 xk_re[33] -296.007 Matlab:f2_r[33] 378.714 xk_re[34] -117.027 Matlab:f2_r[34] 731.413 xk_re[35] -695.503 Matlab:f2_r[35] 859.29 xk_re[36] 172.311 Matlab:f2_r[36] 678.96 xk_re[37] -165.246 Matlab:f2_r[37] 960.132 xk_re[38] -249.19 Matlab:f2_r[38] 552.726 xk_re[39] 42.4766 Matlab:f2_r[39] 272.421 xk_re[40] 229.6 Matlab:f2_r[40] 823.101 xk_re[41] -318.204 Matlab:f2_r[41] 557.669 xk_re[42] 266.831 Matlab:f2_r[42] 1481.65 xk_re[43] -1009.16 Matlab:f2_r[43] 180.858 xk_re[44] -735.485 Matlab:f2_r[44] 9.97936 xk_re[45] -297.726 Matlab:f2_r[45] 897.621 xk_re[46] -294.509 Matlab:f2_r[46] 256.72 xk_re[47] 762.229 Matlab:f2_r[47] 237.049 xk_re[48] 699.253 Matlab:f2_r[48] 938 xk_re[49] -213.069 Matlab:f2_r[49] 181.981 xk_re[50] -413.187 Matlab:f2_r[50] 397.022 xk_re[51] -349.572 Matlab:f2_r[51] 617.382 xk_re[52] -63.1866 Matlab:f2_r[52] 1087.54 xk_re[53] -845.444 Matlab:f2_r[53] 977.657 xk_re[54] -965.319 Matlab:f2_r[54] 788.141 xk_re[55] 70.1314 Matlab:f2_r[55] -167.196 xk_re[56] -157.18 Matlab:f2_r[56] 26.8989 xk_re[57] -646.377 Matlab:f2_r[57] 1865.09 xk_re[58] -2769.69 Matlab:f2_r[58] 753.863 xk_re[59] -2634.43 Matlab:f2_r[59] 2287.02 xk_re[60] -1729.81 Matlab:f2_r[60] 1111.52 xk_re[61] -2057.06 Matlab:f2_r[61] -3516.04 xk_re[62] -5549.6 Matlab:f2_r[62] 126.469 xk_re[63] -3951.05 Matlab:f2_r[63] 6002.34 xk_re[64] 6002.34 Matlab:f2_r[64] 555.219 xk_re[65] 3082.1 Matlab:f2_r[65] 2875Article: 147862
On Thu, 27 May 2010 11:00:30 -0500, "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com> wrote: >And someone can help me with an example for write a random data into any >address, I mean an example of how should be the module with the input >signals. There should be one in the files you generated with Coregen when you created the MIG design - BrianArticle: 147863
Hi, This article - http://outputlogic.com/?p=158 - discusses different ways and tradeoffs of CRC implementation with HDL. There is an online CRC generation tool as well. Thanks.Article: 147864
On May 27, 2:05=A0pm, rickman <gnu...@gmail.com> wrote: > > How can a sync ram be used at all if an async reset is specified in > the HDL? =A0There is no way to "add" an async reset to a sync memory. > > Rick >From the original poster 2 messages before yours: "The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until the entire thing was done." Nothing asynchronous here.Article: 147865
Hello, We are working on a project which involves using BLOCK RAMs. Since we were new to Block RAMs, I (my colleague actually) instantiated a BLOCK RAM in VHDL using Xilinx's Block RAM IP core. The question is regarding timing: The datasheet for the target Spartan 3ADSP XC3SD1800-4 device specifies the best case (setup + hold) time to be less than 1 ns, and the maximum frequency of operation to be 280 MHz. Worst case figures are not specified. However, we checked the static timing report and found the setup times for the data, address and control signals to be approximately 4 ns. Why is there such a substantial difference ?Article: 147866
I am afraid I forgot to include the code in the previous email: DBR : Core512 port map ( -- Ram A ena =3D> ENA, enb =3D> ENA, wea =3D> WE, web =3D> WE, ssra =3D> SSR, ssrb =3D> SSR, clka =3D> CLOCK, clkb =3D> CLOCK, addra =3D> addr_1, addrb =3D> addr_2, douta =3D> DOUT(71 downto 36), doutb =3D> DOUT(35 downto 0), dina =3D> DIN(71 downto 36), dinb =3D> DIN(35 downto 0) ); -- Address Declaration addr_1 <=3D '0' & ADDR(7 downto 0); addr_2 <=3D '1' & ADDR(7 downto 0); The code isn't much. Essentially, I am trying to pretend to have a 256 locations X 72 bits deep memory, whereas the BLOCK RAM is physically a 512 locations X 36 bits wide. On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > Hello, > > We are working on a project which involves using BLOCK RAMs. Since we > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > RAM in VHDL using Xilinx's Block RAM IP core. > > The question is regarding timing: > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > specifies the best case (setup + hold) time to be less than 1 ns, and > the maximum frequency of operation to be 280 MHz. Worst case figures > are not specified. > > =A0However, we checked the static timing report and found the setup > times for the data, address and control signals to be approximately 4 > ns. > > Why is there such a substantial difference ?Article: 147867
On May 28, 9:47=A0am, Sharath Raju <brshar...@gmail.com> wrote: > I am afraid I forgot to include the code in the previous email: > > DBR : Core512 port map ( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 -- Ram A > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ena =3D> ENA, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enb =3D> ENA, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wea =3D> WE, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web =3D> WE, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssra =3D> SSR, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssrb =3D> SSR, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clka =3D> CLOCK, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clkb =3D> CLOCK, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addra =3D> addr_1, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addrb =3D> addr_2, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 douta =3D> DOUT(71 downto= 36), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doutb =3D> DOUT(35 downto= 0), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dina =3D> DIN(71 downto 3= 6), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dinb =3D> DIN(35 downto 0= ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > > -- Address Declaration > addr_1 <=3D '0' & ADDR(7 downto 0); > addr_2 <=3D '1' & ADDR(7 downto 0); > > The code isn't much. Essentially, I am trying to pretend to have a 256 > locations X 72 bits deep memory, whereas the BLOCK RAM is physically a > 512 locations X 36 bits wide. > > On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > > > Hello, > > > We are working on a project which involves using BLOCK RAMs. Since we > > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > > RAM in VHDL using Xilinx's Block RAM IP core. > > > The question is regarding timing: > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > specifies the best case (setup + hold) time to be less than 1 ns, and > > the maximum frequency of operation to be 280 MHz. Worst case figures > > are not specified. > > > =A0However, we checked the static timing report and found the setup > > times for the data, address and control signals to be approximately 4 > > ns. > > > Why is there such a substantial difference ? > > The static timing report includes clock to output delays of the driver as well as routing delays in addition to the actual Tsu of the RAM itself. This should be broken into individual parts and well described in the timing report. Generally speaking, you should always assume that routing delays will constitute a significant portion of your timing budget for any path. According to Xilinx, the tools target 60% / 40% as a goal for logic delay / routing delay. HTH, GaborArticle: 147868
A while back, Andy Ross posted a Perl script that pulls together the many steps required to program a Digilent Nexys2 board under Linux: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/c7557a7b4bc9900c I just wanted to let everyone know that this script, along with the firmware it uses, is hosted at the "ixo-jtag" project on SourceForge: http://ixo-jtag.sourceforge.net/ Regards, -- Hauke DArticle: 147869
I am looking at reducing the cost of a board while improving the performance and one way is to add a processor to offload the low bandwidth portions of an FPGA design and then reduce the capacity of the FPGA. Using an FPGA with 5 volt tolerant I/Os will let me remove a couple of quick switch parts as well. This has potential of saving a few bucks off the top and greatly improving the usable capacity of the device. However... there just don't seem to be *any* FPGAs that fit the bill. 5 volt tolerance (a potential bonus, but not required) small package/low pin count, not BGA, ~32 usable I/Os, 48 TQFP ideal 500 LUTs and 256 bits of memory Price <$5 Currently the entire design is in a Lattice XP device with 3k LUTs, but is 90% utilized with a recent capability upgrade. I can't even go with a larger FPGA without also going to a BGA package which drives the price up. I don't like BGAs because they take extra space for fanout of the signals and they are harder to probe than QFPs. I don't think any two of these three requirements can be found in the same part. Well, maybe CPLDs come in smaller packages at a low cost... I'm just surprised that there isn't more demand for FPGAs in low pin count packages. I guess I'm getting to be a dinosaur in my preference for QFPs. Still, I don't think you can even find a FPGA under $10 in a BGA package because the pin count is typically higher which drives the part cost up. Just some thoughts about my continued frustration in reaching design goals. RickArticle: 147870
On May 28, 6:32=A0am, John_H <newsgr...@johnhandwork.com> wrote: > On May 27, 2:05=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > How can a sync ram be used at all if an async reset is specified in > > the HDL? =A0There is no way to "add" an async reset to a sync memory. > > > Rick > > From the original poster 2 messages before yours: "The reset logic was > sequential, i.e. reset address 0, then reset address > 1, one per clock until the entire thing was done." =A0Nothing > asynchronous here. That shouldn't prevent a memory from being used then. That's just logic driving the RAM. I would guess there was something about the code that couldn't be done with a ram. Actually, looking at his code, I don't see where he is writing to the ram ram_dat. fir_cascade is written, but I don't see where it is initialized. I don't get his code. It looks more like software than hardware. I'm used to debugging hardware... RickArticle: 147871
On 5/28/2010 10:05 AM, rickman wrote: > I am looking at reducing the cost of a board while improving the > performance and one way is to add a processor to offload the low > bandwidth portions of an FPGA design and then reduce the capacity of > the FPGA. Using an FPGA with 5 volt tolerant I/Os will let me remove > a couple of quick switch parts as well. This has potential of saving > a few bucks off the top and greatly improving the usable capacity of > the device. However... there just don't seem to be *any* FPGAs that > fit the bill. > > 5 volt tolerance (a potential bonus, but not required) > small package/low pin count, not BGA, ~32 usable I/Os, 48 TQFP ideal > 500 LUTs and 256 bits of memory > Price<$5 > > Currently the entire design is in a Lattice XP device with 3k LUTs, > but is 90% utilized with a recent capability upgrade. I can't even go > with a larger FPGA without also going to a BGA package which drives > the price up. I don't like BGAs because they take extra space for > fanout of the signals and they are harder to probe than QFPs. I don't > think any two of these three requirements can be found in the same > part. Well, maybe CPLDs come in smaller packages at a low cost... > > I'm just surprised that there isn't more demand for FPGAs in low pin > count packages. I guess I'm getting to be a dinosaur in my preference > for QFPs. Still, I don't think you can even find a FPGA under $10 in > a BGA package because the pin count is typically higher which drives > the part cost up. > > Just some thoughts about my continued frustration in reaching design > goals. > > Rick My problem with QFPs is that those long leads on 0.5mm pitch are perfect solder wicks. Our BGA soldering yield is 100%, whereas we have to clear at least one bridge on QFPs about half the time. I'd love a 49 ball, 1mm pitch part. With 6/6 rules you could route out all but the inner 9 balls on the top layer; with 5/5 you could route out all but the center (which in a sensible world would be ground anyhow). That would put it at about 8mm on a side while still providing enough IO pins to do something interesting. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147872
On 5/28/2010 10:17 AM, rickman wrote:
> On May 28, 6:32 am, John_H<newsgr...@johnhandwork.com> wrote:
>> On May 27, 2:05 pm, rickman<gnu...@gmail.com> wrote:
>>
>>
>>
>>> How can a sync ram be used at all if an async reset is specified in
>>> the HDL? There is no way to "add" an async reset to a sync memory.
>>
>>> Rick
>>
>> From the original poster 2 messages before yours: "The reset logic was
>> sequential, i.e. reset address 0, then reset address
>> 1, one per clock until the entire thing was done." Nothing
>> asynchronous here.
>
> That shouldn't prevent a memory from being used then. That's just
> logic driving the RAM. I would guess there was something about the
> code that couldn't be done with a ram. Actually, looking at his code,
> I don't see where he is writing to the ram ram_dat. fir_cascade is
> written, but I don't see where it is initialized. I don't get his
> code. It looks more like software than hardware. I'm used to
> debugging hardware...
>
> Rick
ram_dat gets written in the IIR state and the RESET state.
---
if msd_rdy then
-- Update the stored data and advance the
-- write pointer. Also decrement the FIR index, which
-- we're just using to count IIR stages at this point.
ram_dat(TO_INTEGER(write_idx)) <= y;
---
when RESET =>
-- Initialize the states for both filters
ram_dat(TO_INTEGER(write_idx)) <= (others => '0');
--
Looking through the XST report, it was definitely generating ram_dat as
a RAM. But it for some reason it was insisting that the reset
implementation happen on it's very own dedicated write port, which was
exploding the logic requirements 4-fold.
Ultimately the answer was just to trust the Xilinx global reset on
powerup to zero out the RAMs and forgo the runtime reset. Which will
work, it's just a little less elegant/portable.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Article: 147873Rob Gaddi <rgaddi@technologyhighland.com> wrote: > My problem with QFPs is that those long leads on 0.5mm pitch are perfect > solder wicks. Our BGA soldering yield is 100%, whereas we have to clear > at least one bridge on QFPs about half the time. > I'd love a 49 ball, 1mm pitch part. With 6/6 rules you could route out > all but the inner 9 balls on the top layer; with 5/5 you could route out > all but the center (which in a sensible world would be ground anyhow). > That would put it at about 8mm on a side while still providing enough IO > pins to do something interesting. Some spare rows between the center supply and the IO pins on the outer rows could also make a two layer enabled BGA package. Otherwise the XC3S50A-VQ100 with a small SPI flash could could be what the original poster asked for... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 147874
Hi, How can I estimate the resoures used by a core generated by CoRE GEn ---- I guess the resource utilization report should give this right? What do the percentages in the resource utilization report of CoreGEN indicate --- is it the percentage of total FPGA resource OR is it percentage with respect to the total core size? Where can I get more details on reading/understanding the resource utilization report? Also how can I find the speed performance of the core -- just an estimate -- for the core in isolation is also OK. Thank you. Regards, Onkar --------------------------------------- Posted through http://www.FPGARelated.com
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