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
"Nico Coesel" <nico@puntnl.niks> wrote in message news:4aa42b18.1299851468@news.planet.nl... > Mike Treseler <mtreseler@gmail.com> wrote: > >>Jon wrote: >>> Sure, VHDL is better for a new user. Writing the same thing again and >>> again and again and again helps you remember it. >> >>I will admit that most vhdl users do not >>use functions and procedures for this, >>but it is possible -- both for synthesis >>and simulation code. > > Just for fun: google for code for a priority encoder. 9 out of 10 > write it as seperate equations for each condition. If you create a > procedure, its only 3 lines of code! > I just double click, insert 74148. Job done. 0 lines of code.Article: 142901
"Mark McDougall" <markm@vl.com.au> wrote in message news:4aa459df$0$27631$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > Nico Coesel wrote: > >> Like C# is replacing C/C++. > > ROTFL!!! You're taking the p*ss, right??? He is. Have a look at this article, http://www.embedded.com/design/218600142 I am glad to be a man :-) Hans www.ht-lab.com > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142902
Hello, I would like to as a question if anyone could help me. I was wondering does anyone ever worked with multiple system generator block in xilinx system generator. I don't know how to make a simulation. I've done this. I created two blocks (subsystems). The first one should work on 133MHz. I put system generator block in this subsystem and I set right properties of the module that this block demands. Another module (subsystem) should work at 40Mhz. this module also contain system generator block with regularly set parameters. both modules are placed in same simulation model file and multiple system generator block is set regularly. I wrote a testbench that will generate input variables for simulation. but when I start it, some error is occurred. I got the message :"All Xilinx Blocks must be contained in a level of hierarchy with a System Generator Token". i tried to put system generator Token or whatever it names is in the top level of the simulation model but I got the same error. have anyone ever worked with different colock domains in system generator and multiple system generator module. please help if you can thank you ZoranArticle: 142903
On Mon, 07 Sep 2009 09:18:42 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Fri, 04 Sep 2009 17:35:28 GMT, Nico Coesel wrote: I've tried to stay out of this language thread .. how'm I doing? (I did want to second your comments on VHDL vs Verilog and System-Verilog though) >>The only real difference is that a CPU executes a program >>sequentially and an FPGA executes its program in parallel. > >Neither of those things is necessarily true these days. Definitely... >As I've said before many times, I completely fail to >understand why there has been so little take-up in the >software community of languages that explicitly support >parallel execution (occam, Ada...). And why there are so many "Grand Challenge" efforts to replace them with approaches based on sequential programming languages... >The usual argument is >that it's easier to reason about sequential than about >concurrent programs. That argument is, in my opinion, >baseless; in the languages I've mentioned, concurrency is >well-managed and easy to reason about. As VHDL successfully demonstrates. (I guess Verilog too, [non]-blocking assignments apart) Occam ... well it relied too heavily on a specific machine; their fate was too closely connected. Ada, I think, was ahead of its time. Perhaps it tried to do too much whereas Modula-2 tried to do too little. Anyway it could allegedly bring a 1980's era workstation to its knees, and that was just the compiler. But if C++ has given the software world one positive thing, it is this: You can no longer coherently argue that Ada is too large, complex, obscure or inefficient to be useful. And it gives you mostly what C++ offers - but with straightforward syntax, pretty good compile-time error detection, and without a million little gotchas that only announce themselves at runtime... Ada-95 and Ada-2005 have shown that you can add OO features (including Java-like interfaces) in a clean reliable type-safe manner - which VHDL could possibly adopt (System-VHDL perhaps?) and the similarities to VHDL are helping me in both directions. I am just learning Ada in odd spare moments; the commonality to VHDL helps a lot. Then I find myself thinking in software lines, and wondering why the same trick doesn't work in VHDL : often it does! (like overloading "rem") So my VHDL is also slowly improving through this process. And now, the ability to loop creating n tasks and safely interacting with them could finally give Ada the advantage it lacked some 25 years ago (when you didn't have n-1 cores sitting around idle). And Gnat gives anyone the chance to learn Ada for free. Maybe - just maybe, there is a chance to improve software practice, instead of bringing hardware practice down to its level. (Don't laugh; one article I read on C-to-hardware quoted a Microsoft engineer as saying we would have to learn to live with unreliable hardware...) - BrianArticle: 142904
I have made serveral experiments and I found that if I limit the DCI I/ O less than 20, the FPGA works fine. The 1.8V power supply is derived from 3.3V with a capacity of 6 Amp, and I think this is quite beyond the need,. I did not add any termination resistor on the DQ bus since I think DCI is enough. However if I can not use DCI feature on the DQ bus(because that is too much and FPGA always crashes), is there any fix-up available for my hardware to work? According to SI analysis, I found even without termination resistors at FPGA end, with ODT activated, there is little difference of signal quality between the DCI version and the non-DCI version. Now I change the DQ bus from SSTL18_II_DCI to SSTL18_II, and I download the MIG2.3 DDR2 example design bitstream with Chipscope. I found that phy_init_done is zero but the dbg_calib_done = 4'b1111 and dbg_calib_err = 4'b0000. What is the situation that phy_init_done is false with all physical calibration is passed?Article: 142905
On Mon, 07 Sep 2009 12:46:38 +0100, Brian Drummond wrote: >I've tried to stay out of this language thread .. how'm I doing? <grin> At least we haven't started a slanging match yet. >> in the languages I've mentioned, concurrency is >>well-managed and easy to reason about. > >As VHDL successfully demonstrates. (I guess Verilog too, > [non]-blocking assignments apart) Well.... I'm not so sure. Verilog's concurrency model is like the Wild West - everyone is allowed to shoot from the hip any time they feel like it. Nonblocking assignments get you within reach of VHDL's model if you want it, but of course nothing is enforced. VHDL is OK - the loopholes are well-documented and few in number, and the discrete-event model works well enough for hardware modelling - but it's not easy to encapsulate process-to-process signalling protocols in an elegant way, and such signalling is not built in to the language and therefore you can't reason about it unless you've developed a calculus for whatever signalling protocol you choose to use. Of course, in practice much of this is obviated by the existence of standard interface protocols at various levels of any design - but it's kinda sad that we can't communicate between blocks by something as clean as my_output_channel!value ->->->-> my_input_channel?variable and be secure in our understanding of precisely what that means. Which brings us back to.... >Occam ... well it relied too heavily on a specific machine; >their fate was too closely connected. Commercially, of course, you're right. From a theoretical point of view, though, occam was just an implementation of CSP - which really does have a life of its own, and even has a live-and-kicking HDL based on it right now (Haste, from Handshake Solutions). >You can no longer coherently argue that Ada is too large, >complex, obscure or inefficient to be useful. Tee hee. It made me giggle when the C/C++ community, who had been whining for years about their dislike of the complexity of Ada and most particularly of generics, suddenly decided that templates were cool - and built a whole new pinnacle of complexity all their own. >Maybe - just maybe, there is a chance to improve software practice, >instead of bringing hardware practice down to its level. Seems to me that the two disciplines still have an awful lot to learn from one another. A bit more humility, on both sides, would do no harm. But, for sure, I will not be told by some Javascript-hacking weenie that I've been doing hardware all wrong for the past three decades. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 142906
"HT-Lab" <hans64@ht-lab.com> wrote:
>
>"Mark McDougall" <markm@vl.com.au> wrote in message
>news:4aa459df$0$27631$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>> Nico Coesel wrote:
>>
>>> Like C# is replacing C/C++.
>>
>> ROTFL!!! You're taking the p*ss, right???
>
>He is. Have a look at this article,
>
>http://www.embedded.com/design/218600142
Perhaps for very small microcontrollers but the bigger stuff is no
longer written in C / C++. This partly due to the fact that schools no
longer produce people that know how to program in C/C++. The main
problem with that is that it takes another 10 years before you can
call yourself a good C programmer.
Also projects tend to get bigger / more complex. All the projects I've
been doing lately have a network interface. Just a 32k flash / 8k ram
ARM controller with a tcp/ip stack, dhcp client, http, etc and an
application. Customers no longer know how to interface at a low level.
Some of our customers even use flash (through http) to talk to our
modules directly. Programmming large projects in C/C++ becomes too
tedious.
You can see the same in the FPGA world. With ever increasing sizes
languages like Verilog and VHDL are no longer sufficient.
Another good example is Lego. The models they had 20 years ago all
looked bricky. Now the Lego models look much better and contain much
more specialized parts that allow faster construction and better
results. That is where our kids are going. Like it or not.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142907
Hello,
I've run into a problem bit bang loading (Slave serial) the Spartan 3
from an MCU. The Spartan 3 is setup with M0,M1 & M2 tied high
(verified). I can verify the active CCLK and DIN during programming,
and I can see transitional changes to INIT_L and DONE during
programming.
I follow the instructions at http://www.fpga-faq.com/FAQ_Pages/0038_Config_FPGA_from_a_processor.htm
Apply FPGA power
Wait 2ms
Set PROG_B to L
Wait 5us
Wait for INIT_L and DONE to be both L
Set PROB_B to H
Wait for INIT_L to transition to H
Wait 5us
Loop
Set CCLK to L
Set DIN to appropriate bit
SET CCLK to H
If DONE is H, break from loop
If INIT_L is L, break from loopendloop
Endloop
The problem occurs within the loop above. When DIN bits are correctly
injected (what I believe is correct), the DONE transitions to H before
the data is complete. This DONE high occurs at nibble 805842; whereas
the data size is 805873 nibbles (31 nibble difference). Furthermore,
if I send the data bit swapped (incorrect), the INIT_L drops low at
the same nibble 805842. If I feed the data in completely backwards, I
make it completely through the loop, never see an INIT_L to L signal,
but never see a DONE H either.
Two notes: First, I would expect the FPGA would flag a CRC or framing
error long before nibble 805842 when the data is deliberately
malformed. Second, it seems that the Xilinx ISE prom image generated
from iMPACT is too large (by 31 nibbles, or 124 bits). Also note that
the trailing bit data is NOT 'ff', as was specified in iMPACT.
// first 3 lines of nibble data generated as "hex no-swap"
const UNS_8 promData[] =
"ffffffffaa995566300080010000000730016001"
"000000643001200140003fe53001c00111428093"
"3000c00100000000300080010000000930002001"
.
.
.
// last 3 lines of nibble data generated as "hex no-swap".
"200000002000000030008001000000053000a001"
"000000003000000100005f57300080010000000d"
"200000002000000020000000200000000";
Any suggestions??
-W
Article: 142908On Mon, 07 Sep 2009 19:51:22 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Mon, 07 Sep 2009 12:46:38 +0100, Brian Drummond wrote: > >>I've tried to stay out of this language thread .. how'm I doing? > ><grin> At least we haven't started a slanging match yet. > >>> in the languages I've mentioned, concurrency is >>>well-managed and easy to reason about. >> >>As VHDL successfully demonstrates. (I guess Verilog too, >> [non]-blocking assignments apart) > >Well.... I'm not so sure. Verilog's concurrency model is like >the Wild West - everyone is allowed to shoot from the hip any >time they feel like it. OK, I'm not competent to comment on Verilog, having never used it. >VHDL is OK - the loopholes are well-documented and few in >number, and the discrete-event model works well enough for >hardware modelling - but it's not easy to encapsulate >process-to-process signalling protocols in an elegant way, ... right, any handshaking etc is up to you, the language merely provides the primitives to build it safely. >Of course, in practice much of this is obviated by the >existence of standard interface protocols at various >levels of any design - but it's kinda sad that we can't >communicate between blocks by something as clean as > > my_output_channel!value ->->->-> my_input_channel?variable > >and be secure in our understanding of precisely what >that means. and I haven't ever attempted to encapsulate anything like a channel in VHDL. (Hmmm...) >>You can no longer coherently argue that Ada is too large, >>complex, obscure or inefficient to be useful. > >Tee hee. It made me giggle when the C/C++ community, who had >been whining for years about their dislike of the complexity >of Ada and most particularly of generics, suddenly decided >that templates were cool - and built a whole new pinnacle >of complexity all their own. Ditto with namespaces, as another example of something other languages had been getting right for a decade. Again it's another layer on top of (and not replacing) the original mess of .h[pp] files, "static/extern/blah", and even if you DO use namespaces the compiler still can't infer all the other files you are using; you STILL need Makefiles to do that. Unfortunately some VHDL tools seem to be designed along the same lines, by people who apparently don't understand what VHDL library and use clauses (or embedded configurations) are for. As a result VHDL libraries etc are sometimes treated as unnecessary verbage at best, and simply don't work properly in at least one major toolchain. >>Maybe - just maybe, there is a chance to improve software practice, >>instead of bringing hardware practice down to its level. > >Seems to me that the two disciplines still have an awful lot >to learn from one another. A bit more humility, on both sides, >would do no harm. But, for sure, I will not be told by some >Javascript-hacking weenie that I've been doing hardware >all wrong for the past three decades. :-) humility does have its proper place! - BrianArticle: 142909
Just to be sure - you're generating the headerless bitfile, not the one with the header? I've got a board that does what you're doing, and I have to generate the headerless bitfile for it to work properly.Article: 142910
On 9=D4=C27=C8=D5, =C9=CF=CE=E74=CA=B145=B7=D6, Sean Durkin <news_MO...@tux= root.de> wrote: > vcar wrote: > > I have found something else. > > I used 4 DDR2 components to make a 64bits wide memory width. If I only > > add serveral DCI IOs, e.g. the dqs_p/dqs_n pair (16 DCI IOs), FPGA > > works fine. > > However if I add 64 bits wide DQ, the FPGA crashes. > > if I add only half of the DQ bus (32 bits wide), the FPGA will work > > for a while and then crashes. and the JTAG chain remains functional > > after programming, and becomes unaccessable after dozens of seconds. > > > So does this means I could not have 64 SSTL18_II_DCI and 16 > > DIFF_SSTL18_II_DCI in a Virtex5 LXT50 FF665 package? > > Theoretically this should be possible. You might run into SSO problems > and active cooling might be neccessary, but there's no restriction on > the number of IOs using DCI that I know of. > > Maybe you have a power supply problem. DCI uses quite a lot of power. > Have you measured your supply voltages in the three cases you mentioned? > Are they stable and at nominal value in all cases? Does maybe the > IO-supply drop when all DCI are enabled? > > A drop in the IO supply voltage should not impact the internal > functionality, though, neither should the JTAG interface be affected > (unless the IO bank 0 with the configuration pins uses the same voltage). > > cu, > Sean You are right. My power supply has something wrong definitely. Now even I can run the DDR2 example design without DCI on the DQ bus, and DDR2 operation also turns out to be right, I found that the FPGA will still crash after about five minitues or so. And then I found that all my power supply DC/DC circuit is very hot. It is quite abnormal because the system total powe disspation is 12V @ 0.5A at that time. While my DC/DC circuit is designed to handle 3.3V @ 10A (other power rails is similar). If there is a problem in my DC/DC circuit, which one would it be more likely? The VCCO1.8V or VCCINT or VCCAUX or VCC3.3V? Since at every crash the JTAG is unaccessable, should VCCAUX be suspected? Since DCI is related to VCCO1.8V, should VCCO1.8V be suspected?Article: 142911
After programming an FPGA, XC3S250EVQ100, via Slave Parallel through
an FTDI USB translator and a CPLD, XC2C64AVQ100, which synchronize
data and fpga_cclk into the FPGA the done pin goes high. The problem I
am having is the bidirectional does not release and allow the FPGA to
drive the data bus to CPLD and then finally into an external 8 LED
bank. I am fairly confident that the FPGA is loaded correctly with the
bin file, by accident I reprogrammed the CPLD releasing the bus the
FPGA, having been programmed, drove the bidirectional data bus and the
lit the 8 LED bank appropriately. Any help on this issues would be
apprciated, thank you. CODE:
----------------------------------------------------------------------------------
-- Company: Electronic Realization L.L.C.
-- Engineer: Cy Drollinger
-- Create Date: 10:44:37 07/08/2009
-- Design Name: USB/FPGA Spartan3E Develpoement
-- Module Name: CPLD - Behavioral
-- Project Name:
-- Target Devices: XC2C64A VQ100
-- Tool versions:
-- Description:
-- Dependencies:
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;
entity CPLD is
Port ( --CPLD LOCATIONS
--Master clock oscillator 50 MHz CTS - CB3
mclk : in STD_LOGIC; --pin 22
mclk_ce : out STD_LOGIC; --pin 70 Logic
--Xilinx Spartan 3E VQ100 mode and variant
Variant : out STD_LOGIC_VECTOR (2 downto 0); --pin 34, 33, 30
Mode : out STD_LOGIC_VECTOR (2 downto 0); --pin 42, 39, 36
--Xilinx Spartan 3E VQ100
FPGA_MOSI : out STD_LOGIC; --pin 90 this is also CSI_B
FPGA_BUSY : in STD_LOGIC; --pin 91 if clk is less than 50 MHz
FPGA_INITB : in STD_LOGIC; --pin 92
FPGA_CSO_B : inout STD_LOGIC; --pin 94
FPGA_cclk : out STD_LOGIC:='0'; --pin 27
FPGA_done : inout STD_LOGIC; --pin 28
FPGA_prog_B: inout STD_LOGIC; --pin 99
FPGA_HSWAP: out STD_LOGIC; --pin 24
FPGA_D: inout STD_LOGIC_VECTOR(7 downto 0); --pin 89 81 79 78 77
41 40 35
--Numonyx M25P16
SPI_flash_HOLD : out STD_LOGIC; --pin 76 SPI '1'
SPI_flash_W : out STD_LOGIC; --pin 97 SPI '1'
--FTDI FT245RL USB to parallel output
usb_pwren : inout STD_LOGIC; --pin 43
usb_wr : in STD_LOGIC; --pin 49
usb_rd : inout STD_LOGIC; --pin 50
data : inout STD_LOGIC_VECTOR (7 downto 0); --pin 56 53 55 61 52
60 58 64
usb_tx : in STD_LOGIC; --pin 67
usb_rx : in STD_LOGIC; --pin 68 when low data ready
usb_rst : inout STD_LOGIC; --pin 14
--User I/O
LEDs : out STD_LOGIC_VECTOR (8 downto 1); --pin 1-4 and 6-9
SW : inout STD_LOGIC_VECTOR (2 downto 0)); --pin 71, 72, 74 need
to be
end CPLD;
architecture Behavioral of CPLD is
--FPGA Configuration
signal SW_0_hi :std_logic; --CPLD is in a all I/O pullups
signal SW_1_hi :std_logic; --CPLD is in a all I/O pullups
signal SW_2_hi :std_logic; --CPLD is in a all I/O pullups
Signal fpga_timing : integer range 0 to 256 :=0;
Signal bidir_bus :std_logic_vector (7 downto 0);
Signal bidir_reg :std_logic_vector (7 downto 0);
Signal done :std_logic;
--FTDI USB chip overhead
signal usb_dry :std_logic; --signal is a synchronized
signal previous_usb_dry :std_logic; --signal is the value of
signal previous :std_logic;
Signal usb_timing : integer range 0 to 256 :=4;
BEGIN
--------------------------------------------------------------------------------------------------------------------------------------
-- Author : Cy Drollinger
-- Date : 7-16-09
-- Description : synchronizing asynchronous inpoputs usb data ready
line(sub_rx), SW(0), SW(1), and SW(2)
--------------------------------------------------------------------------------------------------------------------------------------
--SIGNAL ASSIGNMENT
--HARDWARE SYSTEM ON PCB --TECHNICAL COMMENTS
--------------------------------------------------------------------------------------------------------------------------------------
Synchronize_inputs: process(mclk)
begin
if rising_edge(mclk) then
if usb_rx = '0' then -- RXF# is an active
usb_dry <= '1';
else
usb_dry <= '0';
end if;
previous <= usb_dry;
previous_usb_dry <= previous;
if SW(0) = '1' then
SW_0_hi <= '1';
else
SW_0_hi <= '0';
end if;
if SW(1) = '1' then
SW_1_hi <= '1';
else
SW_1_hi <= '0';
end if;
if SW(2) <= '1' then
SW_2_hi <= '1';
else
SW_2_hi <= '0';
end if;
end if;
end process;
--------------------------------------------------------------------------------------------------------------------------------------
-- Author : Cy Drollinger
-- Date : 7-16-09
-- Description : Upon SW(1) going low the FGPA_prog_b pulses (ONE
SHOT) high for two mclks.
--------------------------------------------------------------------------------------------------------------------------------------
--SIGNAL ASSIGNMENT
--HARDWARE SYSTEM ON PCB --TECHNICAL COMMENTS
--------------------------------------------------------------------------------------------------------------------------------------
Pulse_Prog_B: process (mclk) --
begin
if rising_edge(mclk) then
if SW_1_hi = '0' and FPGA_timing < 22 then
FPGA_timing <= FPGA_timing + 1;
if fpga_timing > 0 and fpga_timing < 21 then
fpga_prog_b <= '0';
else
fpga_prog_b <= '1'; -- fpga_prog_b held low for
end if;
else if SW_1_hi = '1' then
fpga_timing <= 0;
end if;
end if;
end if;
end process;
--------------------------------------------------------------------------------------------------------------------------------------
-- Author : Cy Drollinger
-- Date : 7-16-09
-- Description : providing timing for usb_rd through usb_data_rdy Data
sheet DSFT245R1 pg. 12 fifo read
--------------------------------------------------------------------------------------------------------------------------------------
--SIGNAL ASSIGNMENT
--HARDWARE SYSTEM ON PCB --TECHNICAL COMMENTS
--------------------------------------------------------------------------------------------------------------------------------------
Load_FPGA_Slave_Parallel: process(mclk) --
begin
if rising_edge(mclk) then
if usb_dry = '1' and previous_usb_dry ='0' and fpga_initb = '1'
then
usb_timing <= 0;
elsif usb_timing < 5 then
usb_timing <= usb_timing + 1;
end if;
case usb_timing is
when 0 =>
usb_rd <='0';
when 1 =>
usb_rd <='0';
when 2 =>
usb_rd <='0';
when 3 =>
usb_rd <='0';
fpga_cclk <= '1';
when 4 =>
usb_rd <='1';
fpga_cclk <= '0';
when others =>
end case;
end if;
end process;
--------------------------------------------------------------------------------------------------------------------------------------
-- Author : unknown
-- Date : 9-7-09
-- Description : LED MUX between initial programming of FPGA and data
out of FPGA
--------------------------------------------------------------------------------------------------------------------------------------
--SIGNAL ASSIGNMENT
--HARDWARE SYSTEM ON PCB --TECHNICAL COMMENTS
--------------------------------------------------------------------------------------------------------------------------------------
Bidirectional_FF: PROCESS(mclk)
BEGIN
IF rising_edge(mclk) THEN -- Creates the flipflops
bidir_reg <= data;
LEDs <= not(bidir_bus);
END IF;
END PROCESS;
Bidirectional_Bus PROCESS (FPGA_done, FPGA_d) --
Behavioral representation
BEGIN -- of tri-states.
IF FPGA_done = '1' THEN
FPGA_d <= "ZZZZZZZZ";
bidir_bus <= FPGA_d;
ELSE
FPGA_d <= bidir_reg;
bidir_bus <= FPGA_d;
END IF;
END PROCESS;
--------------------------------------------------------------------------------------------------------------------------------------
-- Author : Cy Drollinger
-- Date : 6-18-09
-- Description : Hardwiring the CPLD for the board configuration of
the usb and fpga
--------------------------------------------------------------------------------------------------------------------------------------
--SIGNAL ASSIGNMENT
--HARDWARE SYSTEM ON PCB --TECHNICAL COMMENTS
--------------------------------------------------------------------------------------------------------------------------------------
--Master clock oscillator 50 MHz CTS - CB3
mclk_ce <= '1'; --enables the 50 MHz
-- Xilinx Spartan 3E VQ100 mode and variant
Mode <= "110"; --mode Slave Parallel
--Xilinx Spartan 3E Slave Parallel
fpga_mosi <= '0';
--FTDI USB PARALLEL
usb_rst <= SW_0_hi;
end Behavioral;
Article: 142912On Sep 7, 6:33 pm, vcar <hi...@163.com> wrote: > On 9=D4=C27=C8=D5, =C9=CF=CE=E74=CA=B145=B7=D6, Sean Durkin <news_MO...@t= uxroot.de> wrote: > > > > > > > vcar wrote: > > > I have found something else. > > > I used 4 DDR2 components to make a 64bits wide memory width. If I onl= y > > > add serveral DCI IOs, e.g. the dqs_p/dqs_n pair (16 DCI IOs), FPGA > > > works fine. > > > However if I add 64 bits wide DQ, the FPGA crashes. > > > if I add only half of the DQ bus (32 bits wide), the FPGA will work > > > for a while and then crashes. and the JTAG chain remains functional > > > after programming, and becomes unaccessable after dozens of seconds. > > > > So does this means I could not have 64 SSTL18_II_DCI and 16 > > > DIFF_SSTL18_II_DCI in a Virtex5 LXT50 FF665 package? > > > Theoretically this should be possible. You might run into SSO problems > > and active cooling might be neccessary, but there's no restriction on > > the number of IOs using DCI that I know of. > > > Maybe you have a power supply problem. DCI uses quite a lot of power. > > Have you measured your supply voltages in the three cases you mentioned= ? > > Are they stable and at nominal value in all cases? Does maybe the > > IO-supply drop when all DCI are enabled? > > > A drop in the IO supply voltage should not impact the internal > > functionality, though, neither should the JTAG interface be affected > > (unless the IO bank 0 with the configuration pins uses the same voltage= ). > > > cu, > > Sean > > You are right. > My power supply has something wrong definitely. > > Now even I can run the DDR2 example design without DCI on the DQ bus, > and DDR2 operation also turns out to be right, I found that the FPGA > will still crash after about five minitues or so. And then I found > that all my power supply DC/DC circuit is very hot. It is quite > abnormal because the system total powe disspation is 12V @ 0.5A at > that time. While my DC/DC circuit is designed to handle 3.3V @ 10A > (other power rails is similar). > > If there is a problem in my DC/DC circuit, which one would it be more > likely? The VCCO1.8V or VCCINT or VCCAUX or VCC3.3V? > > Since at every crash the JTAG is unaccessable, should VCCAUX be > suspected? > Since DCI is related to VCCO1.8V, should VCCO1.8V be suspected?- Hide quo= ted text - > > - Show quoted text - In order to debug this you will need to get a scope probe in on each of the power supplies to see what is going on. Ed McGettigan -- Xilinx Inc.Article: 142913
Nico Coesel wrote: > Perhaps for very small microcontrollers but the bigger stuff is no > longer written in C / C++. This partly due to the fact that schools no > longer produce people that know how to program in C/C++. The main Yes it is. Usually big things have also long history, and language is something that is not changed easily. Also tools for other languages are not that good. Think about all kinds of ICE debuggers, 3rd party compilers for all exotic processor architectures etc. Also the problem with c#/java etc. are realtime systems. Think about realtime + automatic memory allocation or garbage collection etc. Also how about c# stack for arm or PPC and tools for that, not so easy to find. > modules directly. Programmming large projects in C/C++ becomes too > tedious. It comes problematic in any language. > You can see the same in the FPGA world. With ever increasing sizes > languages like Verilog and VHDL are no longer sufficient. But what would be the new language, and what would it look like. The restrictions are quite different in FPGA compared to traditional processor arctitectures. > Another good example is Lego. The models they had 20 years ago all > looked bricky. Now the Lego models look much better and contain much > more specialized parts that allow faster construction and better > results. That is where our kids are going. Like it or not. I hate the new legos. You can't easily build your own things with all those specialized parts. In the past the biggest fun was to create own designs. --KimArticle: 142914
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > With Digikey, the SP601 is is on status "Call"... Phoned Trenz yesterday, got the message " a few on stock, order fast", ordered yesterday and now I have it on the desk :-) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142915
I have a custom board that uses usb and has 2 fpgas (spartan3 200 - spartan 3 4000) I am using Xilinx platform cable USB II to program the fpga I am using windows xp pro I am using Xilinx 9.1.03i When I press initialize chain button in impact tool some popup question says=> "There are many unknown devices being detected. Press yes to continue or Press NO to stop" If I say yes. It finds too many devices (above 100) If I say no it gives an error => ERROR: IMPACT:585 A problem may exist in the hardware configuration. Check that the cable, scan chain, ... Sometimes impact tool shows the chain with 1 device missing out of 4 (2 fpga 2 prom ) There was no problem with the programming before. I programmed some other fpga and then it started. So I do not think that it is a hardware related problem on my side. I can program the fpga, if i disconnect and connect again (many times) my custom board and platform cable and change the location of the usb they are connected in my computer. ------------------------------------------------IMPACT COMMAND LINE ----------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------- Welcome to iMPACT // *** BATCH CMD : setMode -bs // *** BATCH CMD : setMode -bs GUI --- Auto connect to cable... // *** BATCH CMD : setCable -port auto AutoDetecting cable. Please wait. PROGRESS_START - Starting Operation. Connecting to cable (Parallel Port - LPT1). Checking cable driver. Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997 - 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811. Cable connection failed. Connecting to cable (Parallel Port - LPT2). Checking cable driver. Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997 - 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811. Cable connection failed. Connecting to cable (Parallel Port - LPT3). Checking cable driver. Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997 - 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811. Cable connection failed. Connecting to cable (Parallel Port - LPT4). Checking cable driver. Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997 - 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811. Cable connection failed. Connecting to cable (Usb Port - USB21). Checking cable driver. Driver xusbdfwu.sys version: 1021 (1027). Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997 - 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811. Cable PID = 0008. Max current requested during enumeration is 300 mA. Cable Type = 3, Revision = 0. Cable Type = 0x0004. Setting cable speed to 6 MHz. Cable connection established. Firmware version = 2301. CPLD file version = 0012h. CPLD version = FFFEh. PROGRESS_END - End Operation. Elapsed time = 2 sec. Attempting to identify devices in the boundary-scan chain configuration...// *** BATCH CMD : Identify PROGRESS_START - Starting Operation. Identifying chain contents ....'1': : Manufacturer's ID =Xilinx xc3s4000, Version : 0 INFO:iMPACT:1777 - Reading C:/Xilinx91i/spartan3/data/xc3s4000.bsd... INFO:iMPACT:501 - '1': Added Device xc3s4000 successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '2': : Manufacturer's ID =Xilinx xcf32p, Version : 15 INFO:iMPACT:1777 - Reading C:/Xilinx91i/xcfp/data/xcf32p.bsd... INFO:iMPACT:501 - '1': Added Device xcf32p successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '3': : Manufacturer's ID =Xilinx xc3s200, Version : 0 INFO:iMPACT:1777 - Reading C:/Xilinx91i/spartan3/data/xc3s200.bsd... INFO:iMPACT:501 - '1': Added Device xc3s200 successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '4': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '5': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '6': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '7': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '8': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '9': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '10': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '11': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '12': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- '13': : Manufacturer's ID =Unknown INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- ERROR:iMPACT:585 - A problem may exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the specified scan chain configuration matches the actual hardware, and that the power supply is adequate and delivering the correct voltage. ---------------------------------------------------------------------- ---------------------------------------------------------------------- ---------------------------------------------------------------------- PROGRESS_END - End Operation. Elapsed time = 8 sec. // *** BATCH CMD : identifyMPMArticle: 142916
Hi, we're trying to evaluate the behavior of our FPGA-based multi-core system regarding energy use. To do this, we measure the current for the core voltage (1.2V) on our Spartan 3S500E starter kit (http://www.xilinx.com/products/devkits/HW- SPAR3E-SK-US-G.htm) using a shunt resistor (1 Ohm) on the current measurement pins provided on the board. Here, we experience a behavior that I can't explain - even with a non- configured FPGA, we get more-or-less regular surges of current use from the FPGA. The current jumps from ca. 20mA to about 60mA for several microseconds (see http://multicores.org/3S500E_current.jpg). With a two-core system configured, the frequency of these peaks and the maximum current varies with the freuqency supplied to the CPU cores. We also measured this effect on an identical board, this time the base current was twice as high (about 40mA). To make sure the measurement equipment was working correctly, we double-checked with a different scope. When measuring the core current of our Virtex IIpro XUP board, there are no such peaks observable. I can't imagine what causes this behavior - is there any literature on FPGA current use or can someone give me a hint as to what might be going on here? Thanks, MichaelArticle: 142917
Serkan <oktem@su.sabanciuniv.edu> wrote: > I have a custom board that uses usb and has 2 fpgas (spartan3 200 - > spartan 3 4000) > I am using Xilinx platform cable USB II to program the fpga > I am using windows xp pro > I am using Xilinx 9.1.03i > When I press initialize chain button in impact tool some popup > question says=> > "There are many unknown devices being detected. Press yes to continue > or Press NO to stop" > If I say yes. It finds too many devices (above 100) > If I say no it gives an error => ERROR: IMPACT:585 A problem may exist > in the hardware configuration. Check that the cable, scan chain, ... > Sometimes impact tool shows the chain with 1 device missing out of 4 > (2 fpga 2 prom ) > There was no problem with the programming before. I programmed some > other fpga and then it started. So I do not think that it is a > hardware related problem on my side. > I can program the fpga, if i disconnect and connect again (many times) > my custom board and platform cable and change the location of the usb > they are connected in my computer. Test the adapter with some other board. If the other board doesn't program, fix the adapter. But the error looks like some error in your JTAG chain. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142918
Michael Engel <engel@multicores.org> wrote: > Hi, > we're trying to evaluate the behavior of our FPGA-based multi-core > system regarding energy use. > To do this, we measure the current for the core voltage (1.2V) on our > Spartan 3S500E starter kit (http://www.xilinx.com/products/devkits/HW- > SPAR3E-SK-US-G.htm) using a shunt resistor (1 Ohm) on the current > measurement pins provided on the board. The resistor looks very high. Very mA will drop the supply for 1 mV. With sereval hundred mA you will git the low voltage reset limit of the FPGA. Rething the current measurement... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142919
On Sep 8, 4:09=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Serkan <ok...@su.sabanciuniv.edu> wrote: > > I have a custom board that uses usb and has 2 fpgas =A0(spartan3 200 - > > spartan 3 4000) > > I am using Xilinx platform cable USB II to program the fpga > > I am using windows xp pro > > I am using Xilinx 9.1.03i > > When I press initialize chain button in impact tool some popup > > question says=3D> > > "There are many unknown devices being detected. Press yes to continue > > or Press NO to stop" > > If I say yes. It finds too many devices (above 100) > > If I say no it gives an error =3D> ERROR: IMPACT:585 A problem may exis= t > > in the hardware configuration. Check that the cable, scan chain, ... > > Sometimes impact tool shows the chain with 1 device missing out of 4 > > (2 fpga 2 prom ) > > There was no problem with the programming before. I programmed some > > other fpga and then it started. So I do not think that it is a > > hardware related problem on my side. > > I can program the fpga, if i disconnect and connect again (many times) > > my custom board and platform cable and change the location of the usb > > they are connected in my computer. > > Test the adapter with some other board. If the other board doesn't progra= m, > fix the adapter. =A0But the error looks like some error in your JTAG chai= n. > > Bye > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- I have tested the adapter it programs the other boards. What I cant understand is what happens when I unplug the board or adapter from my computer and plug again? how can it start to work/ program again what is it got to with the chain?Article: 142920
Serkan <oktem@su.sabanciuniv.edu> wrote: ... > I have tested the adapter it programs the other boards. > What I cant understand is what happens when I unplug the board or > adapter from my computer and plug again? how can it start to work/ > program again what is it got to with the chain? I don't understand what you want to say with the last sentence. But broken hardware, e.g. a JTAG Pin not soldered right can give a lott of problems, especially work from time to time and don't work else... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142921
wdeninger wrote: > Hello, > <snip> > Two notes: First, I would expect the FPGA would flag a CRC or framing > error long before nibble 805842 when the data is deliberately > malformed. Second, it seems that the Xilinx ISE prom image generated > from iMPACT is too large (by 31 nibbles, or 124 bits). Also note that > the trailing bit data is NOT 'ff', as was specified in iMPACT. > <snip> The flow chart in the data sheet indicates that the CRC is checked after the configuration data frames are loaded, not on a frame by frame basis. The extra bits are part of the startup sequence. The DONE timing can be changed with BitGen options, but basically, if you have DONE, and you have shifted all of the bits, then you are good to go. Don't just stop when you see DONE high, or you won't startup correctly. CurtArticle: 142922
> I don't understand what you want to say with the last sentence. Even though I cant program the fpga most of the times, I found a weird solution to program it sometimes. It is like this: I just unplug Xilinx platform cable USB II from my computer and and plug to another usb port, (after 10 tries it works) I cant understand the reason behind this.Article: 142923
Hi all,
I have an SDRAM interface buried deep inside the hierarchy.
I was able to instantiate OBUF for the control & address signals and
traverse the hierarchy from the UCF file to tie the signals to the
FPGA pins.
However, when I try to do something similar for the IOBUFs, I get an
error of the type
INFO:NgdBuild:889 - Pad net 'eight_chan_gen/u1/external_sdram/U1/
DQ<0>' is not connected to an external port in this design. A new
port 'DQ<0>' has been added and is connected to this signal.
Example of a successful OBUF:
--VHDL file (inside the submodule)
obuf_sdram_a0: OBUF port map (O => sdram_a0, I => A(0));
--.UCF file
NET "eight_chan_gen/u1/external_sdram/U1/A<0>" LOC="D14";
Example of a failing IOBUF:
--VHDL file (inside the submodule)
IOBUF_inst0 : IOBUF
generic map (
DRIVE => 12,
IOSTANDARD => "LVCMOS25",
SLEW => "SLOW")
port map (
O => DQ_OUT(0),
IO => DQ(0),
I => DQ_IN(0),
T => nDQ_OE);
--UCF file
NET "eight_chan_gen/u1/external_sdram/U1/DQ<0>" LOC = "A4";
Any suggestions?
Thanks in advance!
Article: 142924On Sep 8, 12:13=A0pm, Telenochek <elet.mir...@gmail.com> wrote: > Hi all, > > I have an SDRAM interface buried deep inside the hierarchy. > I was able to instantiate OBUF for the control & address signals and > traverse the hierarchy from the UCF file to tie the signals to the > FPGA pins. > > However, when I try to do something similar for the =A0IOBUFs, I get an > error of the type > > INFO:NgdBuild:889 - Pad net 'eight_chan_gen/u1/external_sdram/U1/ > DQ<0>' is not connected to an external port in this design. =A0A new > port 'DQ<0>' has been added and is connected to this signal. > > Example of a successful OBUF: > > --VHDL file (inside the submodule) > > obuf_sdram_a0: =A0 =A0OBUF port map (O =3D> sdram_a0, I =3D> A(0)); > > --.UCF file > > NET "eight_chan_gen/u1/external_sdram/U1/A<0>" LOC=3D"D14"; > > Example of a failing IOBUF: > > --VHDL file (inside the submodule) > > =A0 =A0IOBUF_inst0 : IOBUF > =A0 =A0generic map ( > =A0 =A0 =A0 DRIVE =3D> 12, > =A0 =A0 =A0 IOSTANDARD =3D> "LVCMOS25", > =A0 =A0 =A0 SLEW =3D> "SLOW") > =A0 =A0port map ( > =A0 =A0 =A0 =A0 O =3D> DQ_OUT(0), > =A0 =A0 =A0 IO =3D> DQ(0), > =A0 =A0 =A0 I =3D> DQ_IN(0), > =A0 =A0 =A0 T =3D> nDQ_OE); > > --UCF file > > NET "eight_chan_gen/u1/external_sdram/U1/DQ<0>" =A0 LOC =3D "A4"; > > Any suggestions? > > Thanks in advance! How did you instantiate the modules between this and the top? Are all connections "inout" through the whole hierarchy including the top level port?
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