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
> -------------- c.vhd --------------------------- > 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 c is > Port ( clk : in STD_LOGIC; > sys_clk_out: out std_logic; > q : out STD_LOGIC > ); > end c; > > architecture Behavioral of c is > signal aaaa : std_logic_vector(6 downto 0); > signal i_clk: std_logic; Part of the component declaration is missing here > port (I: in STD_LOGIC; > O: out STD_LOGIC); > end component; > begin > internalclock: bufg port map(clk,i_clk); The default port order of a BUFG is BUFG (O, I), so you either need to do explicit assignment or swap the clk and i_clk in the above. > process(i_clk) ----this counter is not work, why???? You've got no clock! > begin > if rising_edge(i_clk) then > aaaa<=aaaa+"0000001"; > end if; > end process; > Sys_Clk_out<=clk; > q<=aaaa(6); > end Behavioral; > > --------------end of c.vhd --------- Additionally In your original post you had out <= in. If that was the actual code it is possible that it didn't work because you used reserved VHDL words for port names. /MikhailArticle: 106226
Erik Verhagen wrote:
> Hello,
> I have a little problem, it is about real values in VHDL, and the way Quartus is managing them.
> I am describing a simple DSP function (filter) in VHDL to implement on a Stratix device. As you probabely know, these functions need to shift input values in a register bank (declared as "signal" in VHDL), applying coefficients (reals) to them. These signals must therefor be of real type.
> Quartus returns this error on compilation : <snip> Error (10414): VHDL error at iir_butterworth_3.vhd(49), at object "X": a real cannot be non-constant </snip> ("X" is such a register) Of course the filter coefficients (reals) are hardcoded as constants in a package, but these shift registers containing reals *are not* constants, they of course have to be signals to enable shifting.
> I have read about obscure floating point units implemented on Stratix devices, so I suppose it should be possible to manage real signals (floating/fixed point representation ?) in it.
> Does anyone have an idea about how I can use non-constant reals to create a DSP core on Stratix ? I think it is only a synthesis tool issue.
>
> Here is the code (no comment on the casts, I *AM* aware this is not the most elegant)
> A, B, C and D are the filter coefficients.
> This description simulates PERFECTLY with Modelsim...
>
> architecture testing of iir_butterworth_3 is
>
> type register_bank is array (0 to 2) of real;
> signal X : register_bank;
> signal Y : register_bank;
>
> ----------------------------------------------
> - Erik Verhagen (div: AB-BI) -
> - CERN, Geneva -
> - European Organisation for Nuclear Research -
> ----------------------------------------------
>
>
Erik,
You are trying to work at too high a level of abstraction. The hardware
design is digital bits. You need to convert the real numbers into
something that maps into bits. The easier way hardware-wise is to
convert the reals (which are actually floating point values) to fixed
point, and then those can be treated as integers. The other option is
to construct floating point hardware and convert the real into a
floating point format where the bit fields are accessible to the hardware.
For fixed point, the inputs and coefficients are integers with an
implied scaling of 2^k where k can be any convenient constant (it has to
be constant for all input samples). For example 0.3333 could be
represented as 0x5555 in 16 bit fixed point representation if there is
an implied radix point to the left of the leftmost bit (ie, a scaling of
2^-16). 0x5555 = 21845 * 2^-16 = 0.3333
Floating point arithmetic dedicates a few bits to identifying the
position of the radix point. Here, there might a 24 bit mantissa plus
an 8 bit exponent. The value is interpreted as mantissa * 2^exponent.
Both the mantissa and exponent are represented as integers so that they
map into hardware with a finite number of bits. Floating point
arithmetic takes quite a bit more complicated logic to implement because
it requires tracking of the scale, as well as adjusting the scale of the
operands to keep the maximum accuracy. The current state of the
synthesis technology does not infer floating point arithmetic. In order
to use it, you will have to design the details or use somebody else's
floating point hardware library.
I'd suggest getting familiar with number representation before
attempting this project, as without a firm understanding of how the
numbers are represented and dealt with, you are going to have a tough
time completing the project successfully. You might consider finding a
copy of Isreal Koren's computer arithmetic algorithms book:
http://www.amazon.com/exec/obidos/ASIN/1568811608/andraka/103-4809002-4164633
Article: 106227
ok, I have tried your advice, but not work...
Replaced, the original
internalclock: bufg port map(clk,i_clk);
with named pipes :
internalclock: bufg port map(i=>clk,o=>i_clk);
and not work....
and the original vesions, where I wrote out<=in is the example. I now,
reserved words usage as port names are not too fruitfully....
another thing is the Synthesizer not claims the multisource signals if
I not use named pipes for instantination.
MM wrote:
> > -------------- c.vhd ---------------------------
> > 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 c is
> > Port ( clk : in STD_LOGIC;
> > sys_clk_out: out std_logic;
> > q : out STD_LOGIC
> > );
> > end c;
> >
> > architecture Behavioral of c is
> > signal aaaa : std_logic_vector(6 downto 0);
> > signal i_clk: std_logic;
>
> Part of the component declaration is missing here
>
> > port (I: in STD_LOGIC;
> > O: out STD_LOGIC);
> > end component;
> > begin
> > internalclock: bufg port map(clk,i_clk);
>
> The default port order of a BUFG is BUFG (O, I), so you either need to do
> explicit assignment or swap the clk and i_clk in the above.
>
> > process(i_clk) ----this counter is not work, why????
>
> You've got no clock!
>
> > begin
> > if rising_edge(i_clk) then
> > aaaa<=aaaa+"0000001";
> > end if;
> > end process;
> > Sys_Clk_out<=clk;
> > q<=aaaa(6);
> > end Behavioral;
> >
> > --------------end of c.vhd ---------
>
> Additionally In your original post you had out <= in. If that was the actual
> code it is possible that it didn't work because you used reserved VHDL words
> for port names.
>
> /Mikhail
Article: 106228Antti wrote: > Michael Dreschmann schrieb: > > > Hi all, > > > > we are trying to implement a 100 MBit communication link witch uses > > manchester coding. The signal is generated by a CPLD (xc2c64a) and we > > hope we can receive it with an FPGA (Virtex4 for example). > > Because the CPLD design will work at 2.5V and should use minimal power > > (sensor node) my question is if it is possible to use a crystal with a > > NOT-gate in the CPLD for generating the oszillator frequency instead > > of an external oszillator. > > The second question concerns the reception of the datastream within > > the FPGA. My thought was to use a digital pll as mentioned here > > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html > > to generate a sample clock for the incomming bitstream. > > With the help of a DCM module I would generate two 300 MHz clocks, one > > shifted by 180 degree. Then I should be able to sample the incomming > > stream with 600 MHz and I hope this is enough to stay phase locked > > with the datastream. But I haven't done such a fast communication > > before, so I've no idea if this will work. Any comments from you would > > be nice. > > > > Thanks, > > Michael > > you can look at the USB DPLL get the sub phy from opencores as example > it uses 4x clock to deliver mid-bit clock enable to latch the data. > something > similar should work for manchester as well. > > cpld oscillator shure work, but you still need a resistor across not > gate in-out > it want oscillate otherwise. I have spent some time trying to get an > crystal > to swing on FPGA pins without external resistor but have not yet > succeeded. I am not familiar with USB data recovery designs, but I have worked with Manchester encoding before. A 4x clock is on the hairy edge for data recovery. The way Manchester encoding works, you start the bit in the opposite state and transition to the correct state in the middle of the bit. You can also see a transision at the start of a bit if it matches the previous bit. To sample the data you have only one half a bit time. You have to have a lockout period to prevent a false edge detection on the edge between bit cells. Since you have a one clock cycle uncertainty in the timing of the detection, you have trouble timing the length of the lockout period for detecting the edge in the next middle of bit cell. At 4x any timing error will result in eventual slips in timing. You need assure that you clock just a bit faster than 4x to never have the edge detector locked out when in the center of a bit cell. The logic of a Manchester encoder or decoder is simple. But you have to be careful to sample fast enough to make it work. A 4x clock will not work reliably. A 4.1x clock will.Article: 106229
santanu wrote:
> The program compiled fine, and the bitstream was generated
> and downloaded successfully. But the problem is now, how
> do I see the memory where the result is supposed to be present?
Either run a simulation or put a probe
on the c_lower pins.
-- Mike Treseler
Article: 106230
That problem is not solved yet. I did add one D flip-flop before RXD. I
copied parts UART code here. Please give me some comment. Is this
problem i put the wrong flip-flop.
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
-- UART MODUEL : BAUD RATE 115200 BPS
----------------------------------------------------------------------------------------------------
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 UARTNOBUF is
PORT(
SYSCLK : IN std_logic; --100 MHz from DCM
RS232_CTS_OUT : OUT std_logic;
RS232_RTS_IN : IN std_logic;
RS232_RX_DATA : IN std_logic;
RS232_TX_DATA : OUT std_logic;
RESET : IN std_logic;
READ : IN std_logic;
WRITE : IN std_logic;
DATAIN : OUT std_logic_vector(7 downto 0);
DATAOUT : IN std_logic_vector(7 downto 0);
RXRDY : OUT std_logic;
TXRDY : OUT std_logic;
parityerr : OUT std_logic;
framingerr : OUT std_logic
); --detail comments about these port, refer to
wrlogic component.
end UARTNOBUF;
architecture Behavioral of UARTNOBUF is
SIGNAL CLKX16 : std_ulogic;
SIGNAL TX,RX : std_logic;
SIGNAL txhold,txreg : std_logic_vector(7 DOWNTO
0); -- not dataintmp
SIGNAL txtag1,txtag2,txparity,TXCLK,TXDONE,paritycycle,txdatardy :
std_logic; -- tag bits for detecting
SIGNAL rxhold,rxreg : std_logic_vector(7 DOWNTO 0);-- Holds received
data for read
SIGNAL rxparity,paritygen,
rxstop,rxclk,rxidle,rxdatardy : std_logic; -- Parity bit of received
data
SIGNAL div2, div27a, div27b, LUTOUT : std_logic;
-----------------------------------------------------
signal writeb,readb,txrdyb : std_logic;
-----------------------------------------------------
signal txclkb,rxclkb : std_logic;
begin
rxdinst: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => rx,
C => SYSCLK,
CE => '1',
CLR => '0',
D => RS232_RX_DATA
);
txinst: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register
('0')
PORT MAP (
Q => RS232_TX_DATA,
C => SYSCLK,
CE => '1',
CLR => '0',
D =>tx
);
writebuf: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => writeb, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => write -- Data input
);
readbuf: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => readb, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => read -- Data input
);
RXRDYBUF: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => rxrdy, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => rxdatardy -- Data input
);
TXRDYBUF: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => txrdy, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => txrdyb -- Data input
);
------------------------------------------------------------------------------------------
--**************************************** BAUDRATE GENERATOR
************************************************************
-- use shift register and LUT to do the clock divide
clkprescale1: SRL16E --divide the signal with 27-- 16+11
GENERIC MAP (INIT => X"0000")
PORT MAP (
Q => div27a,
A0 => '1',
A1 => '1',
A2 => '1',
A3 => '1', --A = 1111, 16 bits
CE => '1',
CLK => SYSCLK,
D => div27b
);
clkprescale2: SRL16E --divide the signal with 27-- 16+11
GENERIC MAP (INIT => X"0001")
PORT MAP (
Q => div27b,
A0 => '0',
A1 => '1',
A2 => '0',
A3 => '1', --A = 1010, 11 bits
CE => '1',
CLK => SYSCLK,
D => div27a
);
clkprescale3: SRL16E --divide the signal with 2
GENERIC MAP (INIT => X"0001")
PORT MAP (
Q => div2,
A0 => '1',
A1 => '0',
A2 => '0',
A3 => '0', --A = 0001, 2 bits
CE => div27b, --using div27 as the enable signal
CLK => SYSCLK,
D => div2
);
LUT2_inst : LUT2
generic map ( INIT => X"9")
port map (
O => LUTOUT, -- LUT general output
I0 => div27b, -- LUT input
I1 => div2 -- LUT input
);
clkdiv1: FDCE
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => CLKX16, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => LUTOUT-- Data input
);
--**************************************** TRANSMITTING
************************************************************
...............................................................
Article: 106231Scott Schlachter wrote: > Don't worry about the speedgrade part of the device selection - the width > and depth are important though, so for rev D board, you'd normally want to > select the MT46V32M16P (either -5 or -75 like you did). MIG 1.5 won't allow > you to select putting all of the data, address and control pins into any > single bank (like bank 3). The .ucf file required to use the board's pinout > had to be very carefully crafted, and there were a few slight mods required > in the HDL for the single-ended system clock (we use the SMA connector), and > the high-going reset (we use the Button WEST pushbutton which is active high > and requires an internal pull-down). There was also some special design > tweaks that we had to do for the loop-back signal, which isn't present on > this board like how the MIG core typically requires it. > > We're getting ready to include a set of pre-canned S3E Starter Kit board > files for a Verilog version of the core in the next release of the MIG tool. > I don't have a release date for it though. In the MIG 1.5 tool's main > window, after selecting a Spartan-3E part, you'll see a button towards the > lower right that reads "No Board Files". In the next MIG version, that will > say something like "Spartan-3E Starter Kit files", and when you press it, it > will create a zip file. If you are interested, and can handle 5MB sized > attachments, I can send you a beta-copy of this Verilog design. Although I > can not support you with it, I'm happy to provide it to folks who are > interested. Send me an email direct to scott.schlachter@xilinx.com . > We're working on a VHDL version, but it's still in progress, and I can't > provide an ETA yet at this time. > > -Scott Schlachter > Xilinx Is this an issue only for MIG? In other words, is the UCF in the kit documentation not enough for an enterprising soul to write a DDR SRAM controller? An example using the DDR SDRAM, however trivial, would be most useful. TommyArticle: 106232
Mike Treseler wrote: > santanu wrote: > > > The program compiled fine, and the bitstream was generated > > and downloaded successfully. But the problem is now, how > > do I see the memory where the result is supposed to be present? > > Either run a simulation or put a probe > on the c_lower pins. I think he needs more help than that. Santanu, only a subset of Verilog is synthesizable. Initial contructs in particular have no meaning for synthesis and your example is pretty nearly a no-op. TommyArticle: 106233
THANKS ALL YOUR HELP. But this problem is not solved yet. I copied
part uart codes here. (This UART works well. I add some D-flip flop
before some signals ) Please point out what cause my maltalb would be
locked up.
---------------------------------------------------------------------------------------------------
-- UART MODUEL : BAUD RATE 115200 BPS
----------------------------------------------------------------------------------------------------
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 UARTNOBUF is
PORT(
SYSCLK : IN std_logic; --100 MHz from DCM
RS232_CTS_OUT : OUT std_logic;
RS232_RTS_IN : IN std_logic;
RS232_RX_DATA : IN std_logic;
RS232_TX_DATA : OUT std_logic;
RESET : IN std_logic;
READ : IN std_logic;
WRITE : IN std_logic;
DATAIN : OUT std_logic_vector(7 downto 0);
DATAOUT : IN std_logic_vector(7 downto 0);
RXRDY : OUT std_logic;
TXRDY : OUT std_logic;
parityerr : OUT std_logic;
framingerr : OUT std_logic
); --detail comments about these port, refer to
wrlogic component.
end UARTNOBUF;
architecture Behavioral of UARTNOBUF is
SIGNAL CLKX16 : std_ulogic;
SIGNAL TX,RX : std_logic;
SIGNAL txhold,txreg : std_logic_vector(7 DOWNTO
0); -- not dataintmp
SIGNAL txtag1,txtag2,txparity,TXCLK,TXDONE,paritycycle,txdatardy :
std_logic; -- tag bits for detecting
SIGNAL rxhold,rxreg : std_logic_vector(7 DOWNTO 0);-- Holds received
data for read
SIGNAL rxparity,paritygen,
rxstop,rxclk,rxidle,rxdatardy : std_logic; -- Parity bit of received
data
SIGNAL div2, div27a, div27b, LUTOUT : std_logic;
-----------------------------------------------------
signal writeb,readb,txrdyb : std_logic;
-----------------------------------------------------
signal txclkb,rxclkb : std_logic;
begin
rxdinst: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => rx,
C => SYSCLK,
CE => '1',
CLR => '0',
D => RS232_RX_DATA
);
txinst: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register
('0')
PORT MAP (
Q => RS232_TX_DATA,
C => SYSCLK,
CE => '1',
CLR => '0',
D =>tx
);
writebuf: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => writeb, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => write -- Data input
);
readbuf: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => readb, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => read -- Data input
);
RXRDYBUF: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => rxrdy, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => rxdatardy -- Data input
);
TXRDYBUF: FDCE_1
GENERIC MAP (INIT => '0') -- Initial value of register ('0')
PORT MAP (
Q => txrdy, -- Data output
C => SYSCLK, -- Clock input
CE => '1', -- Clock enable input
CLR => '0', -- Asynchronous clear input
D => txrdyb -- Data input
);
------------------------------------------------------------------------------------------
--**************************************** BAUDRATE GENERATOR
************************************************************
-----------------------------------------------------------------------------------
jtw wrote:
> "Jeff Cunningham" <jcc@sover.net> wrote in message
> news:44d7f7d1$0$6591$4d3efbfe@news.sover.net...
> > ZHI wrote:
> >> Thanks Mike Treseler
> >> I am not reading a vhdl netlist. I am reading a uart application
> >> codes. For example, the input signal (RXD signal) of FPGA firstly
> >> go through a IBUF then a BUFG. What's the uses of them respectively?
> >> Why need use these buffers? When need use them?
> >> Or we actually don't need to care these buffers at all.
> >
> > BUFG is a buffer which drives a global clock network.
> > IBUF is a buffer from the input pin.
> >
> > IBUF->BUFG would typically be used when an external pin is used to drive a
> > clock signal and the pin is NOT a dedicated clock input.
> >
> > Ideally a synthesizer would handle this automatically. Sometimes the tool
> > is not smart enough. Instantiating BUFG directly forces it to route the
> > signal on a global clock net.
> >
> Sometimes the tool is too smart, and sometimes what you need cannot be
> properly inferred.
>
> In a multiple clock design, I prefer to direct which clocks get which
> bufg's. I may also want to direct the naming to facilitate placement
> control in the constraints file. There are many potential reasons for doing
> direct VHDL instantation of a specific component.
>
> Nevertheless, I have difficulty with the idea of explicity instantiating
> hundreds of IBUFs and OBUFs in my code. The tools have matured to the
> extent that those key pieces will be inferred and created in the edif
> netlist. (It's the exceptions that merit explicit direction.)
>
> JTW
> > Having said that, treating a UART RXD signal as a global clock sounds
> > rather bizarre.
> >
> > -Jeff
Article: 106234"Jozsef" <bit_vector@tvn.hu> wrote in message news:1155136085.349443.185620@i3g2000cwc.googlegroups.com... > ok, I have tried your advice, but not work... > > Replaced, the original > > internalclock: bufg port map(clk,i_clk); > > with named pipes : > > internalclock: bufg port map(i=>clk,o=>i_clk); > > and not work.... I've run your code through a simulator just to make sure I haven't overlooked another bug. The counter should work. So, at this point I think you should look closer at your q pin assignment. Make sure it is actually soldered, not shorted, not connected to something else, etc... /MikhailArticle: 106235
Antti Lukats wrote: > http://www.sump.org/projects/analyzer/ > > (link info with thanks to Carsten) Ya know, I've had a concept for an FPGA-based logic analyzer kicking around for awhile now. It's actually quite simple. The only reason I haven't moved further with it is because writing host software is a problem for me. -aArticle: 106236
Andy Peters schrieb: > Antti Lukats wrote: > > http://www.sump.org/projects/analyzer/ > > > > (link info with thanks to Carsten) > > Ya know, I've had a concept for an FPGA-based logic analyzer kicking > around for awhile now. It's actually quite simple. > > The only reason I haven't moved further with it is because writing host > software is a problem for me. > > -a oh this is not the first one!! 2) there is another logic analyzer (uses picoblaze) at dulse website - and I have a PC host program for 3) I have converted the "eebit" to be useable as PCI device so it can be used with original C code what for options 2 and 3 the working solutions do exist at the moment only in some of my PC's. Antti PS making the host app is piece of cake.Article: 106237
Hiya group, I've got a design that is contained within a single VHDL file. It instantiates a component that is in an NGC format, so I have two files in my ISE project, one VHDL and one NGC. What I would like to be able to do is synthesise both to a single NGC by passing through the logical synthesis stage in ISE (XST). I'd like to get the estimated combined resource use and clock rate this way, and have a single logical netlist for the design to export it. Is there any easy way to do this? == tin-foil hat on == Is there anyway to return to VHDL from the NGC stage (even via EDIF)? == tin-foil hat off == Thanks, RobinArticle: 106238
I'm maybe sure, this is not the hardware problem, several tests are confirmed this (for example, tested on two boards & other pins). Except if the Spartan is faulty, but other operation modes works faulty in these situation too. Now the problem seems like syncronous network isn't work, or very faulty. I've seen the async clock forward works, but the counter isn't too... MM wrote: > "Jozsef" <bit_vector@tvn.hu> wrote in message > news:1155136085.349443.185620@i3g2000cwc.googlegroups.com... > > ok, I have tried your advice, but not work... > > > > Replaced, the original > > > > internalclock: bufg port map(clk,i_clk); > > > > with named pipes : > > > > internalclock: bufg port map(i=>clk,o=>i_clk); > > > > and not work.... > > I've run your code through a simulator just to make sure I haven't > overlooked another bug. The counter should work. So, at this point I think > you should look closer at your q pin assignment. Make sure it is actually > soldered, not shorted, not connected to something else, etc... > > > /MikhailArticle: 106239
heinerlitz@gmx.de wrote: >> >>I observed clk_count_rise and clk_count_fall using chipscope and found >>out that they never change which means they are defacto hardcoded. The >>delay is hence always the same even without hardcoding the value. If these values never change, then you don't have the same problem that I did. I think your only hope now is to use Chipscope to track down the failure, triggering on the error signal and trying to figure out what causes it. You say that you're running MIG 1.6, but the Xilinx site only shows MIG 1.5. Did it come with ISE8.2i? --- Joe Samson Pixel VelocityArticle: 106240
Weltraumbaer wrote: > Hi Gabor, > > As far as I know CardBus does only support 3,3V. In older PCMCIA > systems you could choose between 5V and 3,3V. Nevertheless my card is > based on 3,3V. > > Nico Actually table 3-1 "Card Detect and Voltage Sense Connections" in the PC card standard shows that Cardbus cards can request other voltages on the Vcore/Vpp pin. The main power is always 3,3V but you can for example jumper CVS2 to CCD2# and ground CCD1# and leave CVS1 open to request 1.8V Vpp without the possibility of change due to CIS configuration settings. I tried this with a PCI to Cardbus adapter and it did not power up my card because it could not supply 1.8V After grounding CVS1 the card powered on normally. I did not actually use the 1.8V, but my device was PCI and not stricly CardBus compliant, so I was hoping the fixed voltage strapping would prevent troubles from attempting to read non-existent cardbus configuration registers.Article: 106241
If all you want is to turn on a LED connected to the LED_CS_L then the
following should suffice (assuming it needs low level at the pin to turn
on):
entity main is
port (
LED_CS_L : out std_logic;
);
end main;
architecture Behavioral of main is
begin
LED_CS_L <= '0';
end Behavioral;
The tools might complain about pins assigned in the UCF file and not
existing in the design. You can either comment them out in the UCF, or
enable unmatched constraints in the tools...
The next step would be to implement a simple counter. This would allow you
to flash the LED.
/Mikhail
Article: 106242For all our loyal customers we are running a set of one week offers for August. First one out is the Raggedstone1 RS1-400. These offers will not be repeated this year so if you want one now is the time to buy. John Adair Enterpoint Ltd.Article: 106243
"Jozsef" <bit_vector@tvn.hu> wrote in message news:1155150446.484852.10870@p79g2000cwp.googlegroups.com... > > I'm maybe sure, this is not the hardware problem, several tests are > confirmed this (for example, tested on two boards & other pins). I am pretty sure, IT IS a hardware problem. > Except > if the Spartan is faulty, Very unlikely. > but other operation modes works faulty in > these situation too. What other modes and what situations are you referring to? > Now the problem seems like syncronous network isn't work, or very > faulty. I've seen the async clock forward works, but the counter isn't > too... What's the clock frequency? Is the board well designed and manufactured or is it a wire strapped prototype? /MikhailArticle: 106244
Clock frequency tested at 24MHz, 1MHz and approx 5 Hz (with pushbutton&smitt-trigger). these frequencies failed all... PCB is manufactured as a zero series proto board. MM wrote: > "Jozsef" <bit_vector@tvn.hu> wrote in message > news:1155150446.484852.10870@p79g2000cwp.googlegroups.com... > > > > I'm maybe sure, this is not the hardware problem, several tests are > > confirmed this (for example, tested on two boards & other pins). > > I am pretty sure, IT IS a hardware problem. > > > Except > > if the Spartan is faulty, > > Very unlikely. > > > but other operation modes works faulty in > > these situation too. > > What other modes and what situations are you referring to? > > > Now the problem seems like syncronous network isn't work, or very > > faulty. I've seen the async clock forward works, but the counter isn't > > too... > > What's the clock frequency? Is the board well designed and manufactured or > is it a wire strapped prototype? > > > /MikhailArticle: 106245
"Robin Bruce" <robin.bruce@gmail.com> wrote: >Hiya group, > >I've got a design that is contained within a single VHDL file. It >instantiates a component that is in an NGC format, so I have two files >in my ISE project, one VHDL and one NGC. What I would like to be able >to do is synthesise both to a single NGC by passing through the logical >synthesis stage in ISE (XST). I'd like to get the estimated combined >resource use and clock rate this way, and have a single logical netlist >for the design to export it. Is there any easy way to do this? > >== tin-foil hat on == >Is there anyway to return to VHDL from the NGC stage (even via EDIF)? >== tin-foil hat off == There is an ngc2edif tool shipped with ISE. I think I've walked this route once to turn an ngc into a vhdl file. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106246
"Jozsef" <bit_vector@tvn.hu> wrote in message news:1155152377.352375.135870@75g2000cwc.googlegroups.com... > Clock frequency tested at 24MHz, 1MHz and approx 5 Hz (with > pushbutton&smitt-trigger). these frequencies failed all... > PCB is manufactured as a zero series proto board. What's the FPGA's package? Is it a BGA? Can you inspect connections? /MikhailArticle: 106247
PQFP208... and inspected with microscope, no short circuit or floating pins found.... MM wrote: > "Jozsef" <bit_vector@tvn.hu> wrote in message > news:1155152377.352375.135870@75g2000cwc.googlegroups.com... > > Clock frequency tested at 24MHz, 1MHz and approx 5 Hz (with > > pushbutton&smitt-trigger). these frequencies failed all... > > PCB is manufactured as a zero series proto board. > > What's the FPGA's package? Is it a BGA? Can you inspect connections? > > /MikhailArticle: 106248
On Wed, 09 Aug 2006 15:16:03 -0400, MM wrote: > If all you want is to turn on a LED connected to the LED_CS_L then the > following should suffice (assuming it needs low level at the pin to turn > on): > Actually the LEDs (8 of them) are connected to the data bus D, which is shared with SRAM, SDRAM and FLASH at least. LED_CS_L is an enable bit for the LEDs. Also, some of these devices, including the LEDs, sit behind a bridge FPGA, whose current program should just pass the data bus through. But it makes it impossible to tell how the wiring works from the schematic. Also, the LEDs have a register in front of them. Hence, getting started with the board is taking some effort :) Thanks! alexArticle: 106249
You are right. But in practice I have never seen a Card Bus controller chipset that supports other then 3.3V/5V. By the way - during burst transfers the ac portion of the 3.3 supply voltage does really rock of about +-200 mA pp composed of all possible pc frequencies. Depending on the notebook the voltage swing is very different, as well as the frequency spectrum, so I do not believe that crosstalk on my card is the reason. But the card shell be used in different notebooks and the FPGA directly needs 3.3V, so I am also looking for a well working dc-filter (-circuit) or something else to reduce the voltage swing to a minimum. The old known things like filter capacitor, pi-filter or series inductor I have already tried, but the results were not satisfying me. Maybe you or someone else has had similar problems and some hints how to get manage. With kind regards Nico Presser
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