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
Hi, I interfaced a USB 8 bit data bus with a CPLD. I made a 48 bit buffer ( ser_buff ). I am loading the buffer at each falling edge of the USB clock. and then copying it into another 48 bit buffer ( Temp ) and the serially ouputting the Temp buffer in another process running on different clock. "inc" signal acts as a trigger signal to the other process to start parallel to serial conversion. The problem is that I am not seeing the right data coming out of the CPLD ( ser_out) port. If kept the USB data to zero but at the ser_out, I can still see some ones. Please adivce soon. My code is given below Thanks John Process (State) Begin Data_clk <= DPR_CLK; ser_clk<= count_A(0); second_clock<= count_A(0); Case State is When G0=> ser_buff ( 7 downto 0) <= USB_Data ( 7 downto 0 ); inc<='0'; Latch_ser_buff <='0'; nextstate <=G1; When G1 => ser_buff ( 15 downto 8) <= USB_Data ( 7 downto 0 ); inc <='0'; Latch_ser_buff <='0'; nextstate <=G2; When G2 => ser_buff ( 23 downto 16)<= USB_Data ( 7 downto 0 ); inc<='0'; Latch_ser_buff<='0'; nextstate <=G3; When G3 => ser_buff ( 31 downto 24)<= USB_Data ( 7 downto 0 ); inc <='0'; Latch_ser_buff <='0'; nextstate <=G4; When G4 => ser_buff ( 39 downto 32)<= USB_Data ( 7 downto 0 ); Latch_ser_buff <='0'; inc <='0'; nextstate <=G5; When G5 => ser_buff ( 47 downto 40)<= USB_Data ( 7 downto 0 ); Latch_ser_buff <='0'; inc <='0'; nextstate <=G6; When G6 => Latch_ser_buff <='1'; inc <='0'; nextstate <=G7; When G7 => Latch_ser_buff <='0'; inc <='1'; nextstate <=G7; When others => nextstate <=G0; End case; End Process; Process (USB_CLK, Reset_USB ) Begin If( Reset_USB = '1' OR Second_DPR_Reset = '1') Then LED_RESET_USB <= '1'; State <= G0; Else If( USB_CLK 'Event And USB_CLK = '0') Then LED_RESET_USB <= '0'; State <= nextstate; End If; End If; If( USB_CLK 'Event And USB_CLK = '0' ) Then If (Latch_ser_buff = '0' ) Then Temp <= (others => '0'); Else If (Latch_ser_buff= '1' ) Then Temp<= ser_buff; End If; End If; End If; End Process; Process ( DPR_CLK, Reset_DPR, inc ) Begin If( Reset_DPR = '1' OR Second_DPR_Reset = '1')Then LED_RESET_DPR<='1'; Tag<='1'; P2S_counter<="000000"; --count_A <= "00000"; Else If (DPR_CLK 'event And DPR_CLK='1')Then If ( inc='1' And P2S_counter /= "110000")Then Tag <='0'; LED_RESET_DPR <='0'; P2S_counter <=P2S_counter + 1; ser_out <= Temp ( to_integer( P2S_counter ) ) ; Else End If; End If; End If; If (DPR_CLK 'eventAnd DPR_CLK = '1' ) Then If ( P2S_counter ="110000" ) Then Second_DPR_Reset<= '1'; Else Second_DPR_Reset<= '0'; End If; End If; If ( DPR_CLK 'event And DPR_CLK='1' ) Then count_A<= count_A + 1; End If; End Process; End DPR_ARCH;Article: 94751
Antti, Our information is that they are really no different. Variations due to process can easily be +/- 10%. As well, the first ES parts of any technology are hardly "process controlled." You gets what you gets. And you are happy. I have no idea if the first ES parts were fast or slow... Austin Antti Lukats wrote: > Hi > > I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric > speeds? > > I have done some actual measurements and as far of the results the > LUT propagation delay seems to be about 10% bigger than in S3? > > This info seems to be obmitted in Spartan3e datasheets. > Oh well, it looks like will have to rely on our measurements when the > manufacturer does not publish the timing info. > > I was hoping to see a little speed improvment so seeing 10% decrease > was a small surprise. Well I have not tested all the S3e I have yet maybe > other parts are actually faster than the one used for LUT speed testing. >Article: 94752
Give more details: depth, width, clock rate for write and for read. Asynchronous clocks? Peter Alfke, XilinxArticle: 94753
Give more details: depth, width, clock rate for write and for read. Asynchronous clocks? Peter Alfke, XilinxArticle: 94754
"Antti Lukats" <antti@openchip.org> wrote in message news:dqiu52$ull$00$1@news.t-online.com... > finally the free Sample Pack info is available from Xilinx directly > > http://www.xilinx.com/products/boards/s3esamplepack/index.htm > I couldn't see how to "buy" it.Article: 94755
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:dqj55h$bv3@xco-news.xilinx.com... > Antti, > > Our information is that they are really no different. > > Variations due to process can easily be +/- 10%. > > As well, the first ES parts of any technology are hardly "process > controlled." You gets what you gets. And you are happy. > > I have no idea if the first ES parts were fast or slow... > > Austin > > Antti Lukats wrote: > >> Hi >> >> I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric >> speeds? >> Hi Austin, Ok, thats fair enough - I have 3 different S3e chips but I have not measured all of them, the first one I did measure did show 10% LUT delay increase compared to S3 slowest speed grade. Sure the 10% can be process variations and I need to measure more devices in order to see the actual difference if there is any. I was hoping to see speed increase, and as it wasnt there so I asked if there known the speed timing differences. AnttiArticle: 94756
Hi, I recently switched from Xilinx 6.3 to Xilinx 7.1.i4. After the first compilation, I was surprised to find that PCI input setup time is about 1.5 ns, excellent configuration! 66MHz PCI input setup time is 3.0 ns. Usually I got 2.9xxns from 6.3 version. But recently my compilation parameters changed and the PCI input setup time is returned back to around 3.0 ns, and most of time, it is beyond 3.0 ns that leads to an unsuccessful compilation result. Can you give some tips on which parameter setting caused the dramatic change for the PCI input setup time? Thank you. WengArticle: 94757
Hi, I have to initialize a Spartan3 with a Blackfin DSP. I was thinking to connect the CCLK and DIN pins to the serial port of the DSP (SPORT), but while the DIN is dual-purpose, the CCLK is dedicated. I'll then need, when all properly configured, FPGA and DSP to communicate with the SPORT once again for the normal work of the board. Here comes the issue because the CCLK used for the initialization has to be substituted with the serial protocol clock (as long as the former is a dedicated one and no more available after start-up). What do you suggest me to do? To put the 2 clock of the Spartan3 on the same path to the input pin of the SPORT clock on the DSP side, keeping the normal clock on high impedance during the configuration, ie when the initialization clock works, and the opposite after the setup process? Anyone had to solve similar issues? Thanks in advance, MarcoArticle: 94758
Pete Fraser wrote: > "Antti Lukats" <antti@openchip.org> wrote in message > news:dqiu52$ull$00$1@news.t-online.com... > > finally the free Sample Pack info is available from Xilinx directly > > > > http://www.xilinx.com/products/boards/s3esamplepack/index.htm > > > > I couldn't see how to "buy" it. Silica sells this kit for $69: http://www.silica.com/en/products/evaluationkits/xlxsp3e_ads.html It's a lot better than the free kit, and not much more expensive. LeonArticle: 94759
"Leon" <leon_heller@hotmail.com> schrieb im Newsbeitrag news:1137516834.592245.123440@o13g2000cwo.googlegroups.com... > > Pete Fraser wrote: >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:dqiu52$ull$00$1@news.t-online.com... >> > finally the free Sample Pack info is available from Xilinx directly >> > >> > http://www.xilinx.com/products/boards/s3esamplepack/index.htm >> > >> >> I couldn't see how to "buy" it. > > Silica sells this kit for $69: > > http://www.silica.com/en/products/evaluationkits/xlxsp3e_ads.html > > It's a lot better than the free kit, and not much more expensive. > > Leon > yes that Avnet is VERY good price for S3e kit, also includes USB chip, etc. this is the problem with the Xilinx "FREE" sample pack, you can not buy it all, you may get it for free from your distributor, but that doesnt seem to be valid in Europe :( -- Antti Lukats http://www.xilant.comArticle: 94760
Ben, I tried that and I didn't find anything specific for gates, just LUTs and logic elements. Am I missing something? Adam Ben Twijnstra wrote: > Adam Elbirt wrote: > > >>Is there any way to get gate counts for a Quartus implemented design? I >>know Xilinx will give gate counts out of place and route but I can't >>seem to figure out anything other than LUT counts and logic element >>usage from Quartus. > > > In the report window, click the 'Fitter' item, then select the "Resource > usage" item. > > Best regards, > > > BenArticle: 94761
Well, I have non continous 16 bits @66Mhz incoming data flow ( video ) which is send to a 32 bits @ 33Mhz bus which is not always available. I have to put a big FIFO between theses two busses, so I have to implement a FIFO using a SDRAM. Transmission data can be up to 32Mbits. Stéphane. "Peter Alfke" <peter@xilinx.com> a écrit dans le message de news: 1137514850.769502.197970@f14g2000cwb.googlegroups.com... > Give more details: > depth, width, clock rate for write and for read. Asynchronous clocks? > Peter Alfke, Xilinx >Article: 94762
Stephane, you did not say how big, but let me believe you that you need an external SDRAM. The speed you mention is slow by today's standards. I suggest you use a single read/write SDRAM interface and you inter-digitate (time-share) the read and write operations on that common SDRAM interface. The FPGA is then just the cintroller and arbiter between read and write operations. For simplicity, you could run the memory as a synchronous 2-stroke operation, always a read followed by a write. These two cycles would fit into your 15 ns period. Try to store ony one write word and one read word in the FPGA. But you can also communicate through one 32-bit wide BlockRAM, where you can use one half of the address space on one port as transmit buffer, the other half of the address space on the other port as receive buffer. The possibilities are endless... Peter Alfke, XilinxArticle: 94763
"Peter Alfke" <peter@xilinx.com> wrote in message news:1137519790.491285.321000@g47g2000cwa.googlegroups.com... > Stephane, > you did not say how big, but let me believe you that you need an > external SDRAM. > The speed you mention is slow by today's standards. I suggest you use a > single read/write SDRAM interface and you inter-digitate (time-share) > the read and write operations on that common SDRAM interface. The FPGA > is then just the cintroller and arbiter between read and write > operations. For simplicity, you could run the memory as a synchronous > 2-stroke operation, always a read followed by a write. > These two cycles would fit into your 15 ns period. Try to store ony one > write word and one read word in the FPGA. But you can also communicate > through one 32-bit wide BlockRAM, where you can use one half of the > address space on one port as transmit buffer, the other half of the > address space on the other port as receive buffer. > The possibilities are endless... > Peter Alfke, Xilinx > So in 15 ns he has to send a RAS, wait 2 clocks and then a CAS and a further 2 clocks to get the data. I know the write may be a bit quicker but you still need a couple of clocks for precharge after write. Are sure each operation can be done in 15ns. That's a mighty fast SDRAM. I think I'd use a burst of 4 words to reduce the "setting up" overhead of a random read or write. Otherwise yes I'd use a multiple of 33MHz using on board PLL and alternate reads and writes.Article: 94764
Fred, I agree. I was thinking in terms of external SRAM, where timing is so much easier and faster. If the external RAM has to be SDRAM (does it really, is the required depth so large?), it might make sense to convert the transfer to blocks of data, assembled in a BlockRAM. Then there is the question of allowed latency. Peter AlfkeArticle: 94765
Hello group,
I have used the new ISE 8.i simulator (nice propeller) to simulate
a 9 bit read-only-memory using a BRAM16 primitive. The code
is shown below. A number of new questions arise:
1) Is the code around the "begin" keyword, which maps the inputs
to the primitive RAMB16 (BRAM or Block RAM) acceptable or
is there a more concise/better method?
2) I initially went to the V4 library guide and found this primitive.
I did not see there the RAMB_Sx_Sy primitives of Spartan yore,
which lead me to believe that they are abandoned in Virtex-4.
The Xilinx Virtex-4 User Guide ( ug070.pdf ) page 133 would
lead one to believe that they are available. What is the story here?
3) Generally, I would like to transport my future designs between
Spartan3s and Virtex-4 effortlessly. Are their any tips, ap notes,
or other information out there on how to do this?
4) The INIT_xx => sytax is clumsy. Especially if I choose
to use the ninth bit. What alternatives do I have?
5) I have been searching Google for code examples with the words
RAMB16 and std_logic. Is there any primitive or keyword
specific to Virtex-4 that would further refine my search?
6) I did not see the INIT value on the ISE 8.1 simulation which
I expect to see at time 0. Is this a glitch in the 8.1 simulator?
Regards,
Brad Smallridge
aivision dot com
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity bram9p is
port (
clkb : IN std_logic;
enb : IN std_logic;
ssrb : IN std_logic;
regceb : IN std_logic;
addrb : IN std_logic_VECTOR(11 downto 0);
web : IN std_logic;
doutb : OUT std_logic_VECTOR( 8 downto 0) );
end bram9p;
architecture Behavioral of bram9p is
signal addrb15 : std_logic_vector(14 downto 0);
signal dob32 : std_logic_vector(31 downto 0);
signal dopb4 : std_logic_vector( 3 downto 0);
signal web4 : std_logic_vector( 3 downto 0);
begin
addrb15(14 downto 3) <= addrb;
addrb15( 2 downto 0) <= "000";
doutb(7 downto 0) <= dob32(7 downto 0);
doutb(8) <= dopb4(0);
-- Update all web bits,
-- otherwise only some addresses will be written.
web4(0) <= web;
web4(1) <= web;
web4(2) <= web;
web4(3) <= web;
-- RAMB16: Virtex-4 16k+2k Parity Paramatizable BlockRAM
-- Xilinx HDL Language Template version 8.1i
RAMB16_inst : RAMB16
generic map (
DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
DOB_REG => 0, -- Optional output registers on the B port (0 or 1)
INIT_A => X"000000000", -- Initial values on A output port
INIT_B => X"000000001", -- Initial values on B output port
INVERT_CLK_DOA_REG => FALSE, -- TRUE or FALSE
INVERT_CLK_DOB_REG => FALSE, -- TRUE or FALSE
RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
READ_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36
SIM_COLLISION_CHECK => "NONE", --
"ALL","WARNING_ONLY","GENERATE_X_ONLY,"NONE
SRVAL_A => X"000000000", -- Port A ouput value upon SSR assertion
SRVAL_B => X"000000002", -- Port B ouput value upon SSR assertion
WRITE_MODE_A => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_MODE_B => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_WIDTH_A => 9, -- 1,2,4,9,18 or 36
WRITE_WIDTH_B => 9, -- 1,2,4,9,18 or 36
-- The following INIT_xx declarations specify the initial contents of
the RAM
INIT_00 =>
X"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A09080706050403020100",
INIT_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_09 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_10 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_11 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_12 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_13 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_14 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_15 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_16 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_17 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_18 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_19 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_20 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_21 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_22 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_23 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_24 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_25 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_26 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_27 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_28 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_29 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_30 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_31 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_32 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_33 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_34 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_35 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_36 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_37 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_38 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_39 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
-- The next set of INITP_xx are for the parity bits
INITP_00 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000")
port map (
CASCADEOUTA => open, -- 1-bit cascade output
CASCADEOUTB => open, -- 1-bit cascade output
DOA => open, -- 32-bit A port Data Output
DOB => dob32, -- 32-bit B port Data Output
DOPA => open, -- 4-bit A port Parity Output
DOPB => dopb4, -- 4-bit B port Parity Output
ADDRA => (others=>'0'), -- 15-bit A port Address Input
ADDRB => addrb15, -- 15-bit B port Address Input
CASCADEINA => '0', -- 1-bit cascade A input
CASCADEINB => '0', -- 1-bit cascade B input
CLKA => '0', -- Port A Clock
CLKB => clkb, -- Port B Clock
DIA => (others=>'0'), -- 32-bit A port Data Input
DIB => (others=>'0'), -- 32-bit B port Data Input
DIPA => (others=>'0'), -- 4-bit A port parity Input
DIPB => (others=>'0'), -- 4-bit B port parity Input
ENA => '0', -- 1-bit A port Enable Input
ENB => enb, -- 1-bit B port Enable Input
REGCEA => '0', -- 1-bit A port register enable
input
REGCEB => regceb, -- 1-bit B port register enable
input
SSRA => '0', -- 1-bit A port Synchronous
Set/Reset Input
SSRB => ssrb, -- 1-bit B port Synchronous
Set/Reset Input
WEA => "0000", -- 4-bit A port Write Enable
Input
WEB => web4 ); -- 4-bit B port Write Enable
Input
end Behavioral;
Article: 94766Nice.... but how to order it? ------------------------------ Jaime Andrés Aranguren Cardona jaac@sanjaac.com SanJaaC Electronics Soluciones en DSP www.sanjaac.com "Antti Lukats" <antti@openchip.org> escribió en el mensaje news:dqiu52$ull$00$1@news.t-online.com... > finally the free Sample Pack info is available from Xilinx directly > > http://www.xilinx.com/products/boards/s3esamplepack/index.htm > > there is no note that there is no availability in Europe so it still makes > sense to contact the distributors also in Europe, maybe there is > availabily. > > After one more attempt to use the flashwriter.tcl it worked, so the > EDK/XMD/tcl method of programming the onboard flash also works. > > -- > Antti Lukats > http://www.xilant.com >Article: 94767
A Comment: http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=YZXW2V41IVXLGQSNDBESKHA?articleID=177100256 details the problems with standards. Here is one case where "equally disadvantaged" could not be achieved. AustinArticle: 94768
Antti, I would not expect any differences. As well, all of the parts you have are likely to come from the same lot (perhaps even the same wafer) and will not show any personality. Those 12" wafers are huge, and the 3SE die are so tiny... Austin Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:dqj55h$bv3@xco-news.xilinx.com... > >>Antti, >> >>Our information is that they are really no different. >> >>Variations due to process can easily be +/- 10%. >> >>As well, the first ES parts of any technology are hardly "process >>controlled." You gets what you gets. And you are happy. >> >>I have no idea if the first ES parts were fast or slow... >> >>Austin >> >>Antti Lukats wrote: >> >> >>>Hi >>> >>>I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric >>>speeds? >>> > > Hi Austin, > > Ok, thats fair enough - I have 3 different S3e chips but I have not measured > all of them, the first one I did measure did show 10% LUT delay increase > compared to S3 slowest speed grade. Sure the 10% can be process > variations and I need to measure more devices in order to see the > actual difference if there is any. > > I was hoping to see speed increase, and as it wasnt there so I asked > if there known the speed timing differences. > > Antti > >Article: 94769
Weng, Which part? Austin wtxwtx@gmail.com wrote: > Hi, > I recently switched from Xilinx 6.3 to Xilinx 7.1.i4. > > After the first compilation, I was surprised to find that PCI input > setup time is about 1.5 ns, excellent configuration! 66MHz PCI input > setup time is 3.0 ns. Usually I got 2.9xxns from 6.3 version. > > But recently my compilation parameters changed and the PCI input setup > time is returned back to around 3.0 ns, and most of time, it is beyond > 3.0 ns that leads to an unsuccessful compilation result. > > Can you give some tips on which parameter setting caused the dramatic > change for the PCI input setup time? > > Thank you. > > Weng >Article: 94770
"Marco" <marco@marylon.com> schrieb im Newsbeitrag news:1137516377.278102.203140@z14g2000cwz.googlegroups.com... > Hi, I have to initialize a Spartan3 with a Blackfin DSP. I was thinking > to connect the CCLK and DIN pins to the serial port of the DSP (SPORT), > but while the DIN is dual-purpose, the CCLK is dedicated. I'll then > need, when all properly configured, FPGA and DSP to communicate with > the SPORT once again for the normal work of the board. > Here comes the issue because the CCLK used for the initialization has > to be substituted with the serial protocol clock (as long as the former > is a dedicated one and no more available after start-up). > What do you suggest me to do? To put the 2 clock of the Spartan3 on the > same path to the input pin of the SPORT clock on the DSP side, keeping > the normal clock on high impedance during the configuration, ie when > the initialization clock works, and the opposite after the setup > process? > Anyone had to solve similar issues? > Thanks in advance, > Marco > 2 options 1) use Spartan3e there CCLK is dual purpose 2) add user IO in parallel to CCLK to be able to use it after configuration, the 'normal' clock is automatically tri stated when FPGA is not configured so it want matter, as long as the DSP can pull prog_b to force (re)configuration -- Antti Lukats http://www.xilant.comArticle: 94771
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:dqjfba$bv7@xco-news.xilinx.com... > Antti, > > I would not expect any differences. > > As well, all of the parts you have are likely to come from the same lot > (perhaps even the same wafer) and will not show any personality. > > Those 12" wafers are huge, and the 3SE die are so tiny... > > Austin hmmm.. I have following chips for testing: 100e 250e 500e are all of them from the same wafer ?? ROTFL that would be nice design, make one wafer and cut smaller pieces for smaller FPGAs hm that may not be impossible actually... just make whole wafer full of the fabric interlaced with IOB then cut out different rectangles and get different sized FPGAs ok, maybe not so reasonable :) -- Antti Lukats http://www.xilant.comArticle: 94772
Hi Austin, CONFIG PART = XC2V1500-FG676-5. I checked all my previous compilations. The best one is: TIMEGRP "PCI" OFFSET = IN 3 ns BEFORE COM | 3.000ns | 1.207ns | 0 It was generated in 1/5/2006, within 2 weeks. I didn't even set those settings of compilation parameters, and just used the default values. Now new result: TIMEGRP "PCI" OFFSET = IN 3 ns BEFORE COM | 3.000ns | 2.976ns | 1 It was generated today and you may see the dramatic differences between two compilation result. This settings of compilation parameters are set as the highest one. >From result 1, I knew there are short cuts for all PCI input signals, but I don't know which parameter plays the important role. Do you know it? WengArticle: 94773
-snip- > hmmm.. > I have following chips for testing: > > 100e > 250e > 500e > > are all of them from the same wafer ?? No, they are not. But they may all be from the same weeks, running the same process, on the same equipment, and thus very similar. > ROTFL that would be nice design, make one wafer and cut smaller pieces for > smaller FPGAs > > hm that may not be impossible actually... just make whole wafer full of the > fabric interlaced with IOB > then cut out different rectangles and get different sized FPGAs > > ok, maybe not so reasonable :) There are things that sound crazy, but then you end up thinking how to do them. This is one area where we are still looking for a way to make all our parts at once, and just slice off the ones you need. So far, there is no way to do this, but we are still thinking about it! AustinArticle: 94774
Antti, each of these devices comes from its own wafer. We do not mix different device sizes on the same wafer. Regarding speed: Spartan3E never claimed to be faster than Spartan3. Both use the same technology. For S3E, low cost was the primary objective. The S3E data sheet says: ...to meet the need of cost-sensitive consumer applications... ...more logic per I/O... ...new features improve system performance... ...more functionality and bandwidth per dollar... That's as close as any data sheet will ever come to stating: "This is not meant to be a speed demon". Peter Alfke
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