Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 147850

Article: 147850
Subject: Xilinx ISE12.1 IPCORE source code
From: doomsten <doom.zhang@gmail.com>
Date: Wed, 26 May 2010 20:50:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 147851
Subject: Re: crc16 with 16 bit inputs
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Thu, 27 May 2010 08:46:50 +0200
Links: << >>  << T >>  << A >>
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
Subject: Xilinx' partition flow in ISE12.1
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 27 May 2010 09:44:53 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: crc16 with 16 bit inputs
From: Florian <googlegroups@47110815.com>
Date: Thu, 27 May 2010 01:17:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Software bloat (Larkin was right)
From: "Fredxx" <fredxx@spam.com>
Date: Thu, 27 May 2010 09:44:54 +0100
Links: << >>  << T >>  << A >>

<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
Subject: Re: crc16 with 16 bit inputs
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 27 May 2010 11:14:50 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Software bloat (Larkin was right)
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 27 May 2010 10:46:02 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: crc16 with 16 bit inputs
From: "Fredxx" <fredxx@spam.com>
Date: Thu, 27 May 2010 13:56:22 +0100
Links: << >>  << T >>  << A >>

"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/crctool



Article: 147858
Subject: Re: MIG v3.0 inputs signal
From: "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com>
Date: Thu, 27 May 2010 11:00:30 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 147859
Subject: Re: Advice on Xilinx Spelunking
From: rickman <gnuarm@gmail.com>
Date: Thu, 27 May 2010 11:05:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 147860
Subject: Re: Using XMOS devices to replace FPGAs
From: rickman <gnuarm@gmail.com>
Date: Thu, 27 May 2010 11:18:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 147861
Subject: =?windows-1252?Q?Verifying=2Fcomparing_the_FFT_output_between_Xilinx_Co?=
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Thu, 27 May 2010 11:43:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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] 2875

Article: 147862
Subject: Re: MIG v3.0 inputs signal
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 27 May 2010 21:39:20 +0100
Links: << >>  << T >>  << A >>
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

- Brian

Article: 147863
Subject: Re: crc16 with 16 bit inputs
From: OutputLogic <evgenist@gmail.com>
Date: Thu, 27 May 2010 19:58:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Advice on Xilinx Spelunking
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 28 May 2010 03:32:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Block RAM unusually long setup time ?
From: Sharath Raju <brsharath@gmail.com>
Date: Fri, 28 May 2010 06:31:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Block RAM unusually long setup time ?
From: Sharath Raju <brsharath@gmail.com>
Date: Fri, 28 May 2010 06:47:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Block RAM unusually long setup time ?
From: Gabor <gabor@alacron.com>
Date: Fri, 28 May 2010 07:05:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 147868
Subject: Re: Programming Digilent Nexys 2 from Linux
From: Hauke D <haukex@zero-g.net>
Date: Fri, 28 May 2010 08:47:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 D

Article: 147869
Subject: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Fri, 28 May 2010 10:05:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 147870
Subject: Re: Advice on Xilinx Spelunking
From: rickman <gnuarm@gmail.com>
Date: Fri, 28 May 2010 10:17:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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...

Rick

Article: 147871
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Fri, 28 May 2010 10:29:25 -0700
Links: << >>  << T >>  << A >>
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 order

Article: 147872
Subject: Re: Advice on Xilinx Spelunking
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Fri, 28 May 2010 10:37:28 -0700
Links: << >>  << T >>  << A >>
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: 147873
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 28 May 2010 19:23:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob 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
Subject: Estimating resource utilization of cores (from Xilinx CoreGen)
From: "onkars" <onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu>
Date: Fri, 28 May 2010 14:55:04 -0500
Links: << >>  << T >>  << A >>


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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search