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
Tim Good wrote:
> Jeremy Wood wrote:
>
>> Greetings everyone,
>>
>> I've recently started working on FPGA designs and was wondering if
>> there is a way to get timing reports and synthesis results from the
>> Xilinx software that don't include I/O pin mapping. I'm trying to
>> constrain several blocks for testing purposes, but these modules will
>> all be internal to the design and won't be connected directly to the
>> pins. However, it seems the tools automaically assume these
>> connections, which is adding extra delay than what will really be
>> there. Is there a way to tell the tool to ignore physical pin
>> connections and use, say, simulated register I/O connections instead?
>>
>> Sorry if this seems like a silly question, I'm still getting the hang
>> of synthesis yet.
>>
>> Thanks in advance,
>> Jeremy
>
>
> Hi Jeremy,
>
> Under Synthesis properties (right hand click synthesis in the tool
> chain view), select the Xilinx Specific Options tab then untick "Add
> I/O buffers" and you should be where you want to be!
>
> As a note you may also wish to select "Advanced options" to allow more
> control over the tools (from the menu bar Edit > Preferences >
> Processes > PropertyDisplayLevel change to Advanced).
>
> However, more realistic timing can often be obtained by placing you
> design unit (presumably will ultimately be located deep within your
> design, eg a super fast multiplier) between registers, adding timing
> constraints and use the static timing report....
>
> All the best,
>
> Tim
Just want to add, when you disable IO to be added by XST you need to let
MAP know not to trim out all the design (for MAP a design with no
external connections doesn't make sense) by giving -u as a comand line
option, or from ISE by displaying the MAP process proprieties and
disable the "Trim unconnected signals".
Aurash
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 92176Hi!, I am a new pg student working on parallelism and FPGA programming. My interest is working at the highest level possible, at algorithmic and system level. I have been looking at libraries as JHDL and SustemC, and languages as Handel-C and Verilog. I am involved in a research project for developing IP core using a hardware/software approach (co-design and co-simulation). Because I must start as soon a s possible and want to use the latest about techniques, methods, methodologies and technology I need someone helps giving some information about the following: 1. What Is Runtime reconfiguration, partial reconfiguration or dynamic reconfiguration?. 2. How Does dynamic reconfiguration works at hardware and software level? 3. To take advantage of dynamic reconfiguration Do I need the software tool or fpga board supports dynamic reconfigration?. 4. Is it possible to exploit dynamic reconfiguration at high level Programming level ? I mean, Can programmer users do this? 5. Does SystemC support dynamic reconfiguration? and Handel-C? Can I develop applications using rutime reconfiguration with SystemC? 6. May someone recommend me any FPGA Board from Xilinx, Altera or Celoxica supports runtime reconfiguration? 7. What about any FPGA Development Kit supports runtime reconfiguration based on C/C++? I thank if you can help explaining me all about this or giving me documents or links to find this. I trust your advice. I am sorry for the troubles in advance. Thanks a lot. CarlosArticle: 92177
Adrian Knoth wrote: > Wouldn't rising_edge (update_input) do the job? Or falling_edge (), > if I need to know whether a signal was once set and is now off Not for synthesis. Here is a similar example with just one clock. http://home.comcast.net/~mike_treseler/rise_count.vhd Note the synthesis template at the end of the file. -- Mike TreselerArticle: 92178
Nju Njoroge wrote: > Hello, > > Is there an existing flow for simulating PLB DDR in ModelSim using EDK > 7.1 SP2 in a full system (PPCs, pcores,etc)? The instructions are being > stored in BRAMs, as to avoid DDR initialization hassles. I have been > simulating the data-only DDR using BRAMs, however, to get a more > accurate depiction of the system, I would like to use DDR in > simulation. Sure you can simulate that. Do you have the DDR memory simulation models? If not, Micron provides good models on their web site for the individual chips. Other than that, a specific question of what it is you are having trouble with would help; your question is too vague to me (or maybe I am overlooking something).Article: 92179
<allanherriman@hotmail.com> wrote in message news:1132755671.168114.85490@g49g2000cwa.googlegroups.com... > allanherri...@hotmail.com wrote: >> Fred wrote: >> > <allanherriman@hotmail.com> wrote in message >> > news:1132749283.568506.23210@g49g2000cwa.googlegroups.com... >> > > allanherri...@hotmail.com wrote: >> > >> You either wait for the next rev of VHDL (and then wait a couple of >> > >> years for the tools to catch up), or you use a temporary variable. >> > >> I >> > >> don't know of any other way. >> > > >> > > Another way would be to use Verilog. >> > > >> > >> > Unfortunately in the UK you're more employable if you know VHDL. I >> > have >> > written in Verilog and quite like the C type structure. Since I'd like >> > to >> > pay my bills I feel tied to VHDL. >> >> You're even more employable if you have a strong knowedge of both. > > ... and even more employable if you can spell. > Even more more so it can see your own mistakes before anyone else!Article: 92180
Hi Francesco, I've recently used XST without problems on a Spartan-II with 99% logic utilisation. That's using VHDL. Max. clock speed was 100Mhz. So XST gets my vote. Alan francesco_poderico@yahoo.com wrote: > Hi all, > I wish to have an idea about how many people here uses Synlify or > Leonardo and how many people uses XST. > The purpose of that is undesrtand how many people here beleave that XST > is a mature product and it can be trusted or not. > At moment I'm tryng to use XST for a small FPGA (spartan 2E 150) and > I'm having a lot of trouble. > (I have several years of experience and I made design very complex) > > For example the xapp807 has source file in VHDL and in Verilog. when I > use the verilog version it works fine, but when I use the VHDL version > it is unrelaible. > > Hope to have feedback from you. > FrancescoArticle: 92181
And then there is this: cam1_dcmfx2 : dcmfx2 port map( clkin_n_in => gpio_exp_hdr2(6), -- cam1_xclk, clkin_p_in => gpio_exp_hdr2(7), -- cam1_xclk, rst_in => reset, clkfx_out => cam1_clk7x, clkin_ibufgds_out => open, clk0_out => cam1_xclk, locked_out => cam1_lock7x ); generated clock with external differential inputs selectedArticle: 92182
Vladimir, at the frequencies mentioned, the decision-making flip-flop will go metastable, which means it will occasionally have an unpredictable extra delay. It will have an extra 2.0 ns delay statistically once every 2 weeks. It will have an extra 2.5 ns extra delay roughly once every 20 000 years. For every extra 100 ps additional delay, the mean-time-between-failure (MTBF) increases by more than a factor 10. See my Xilinx app note XAPP094 for more details. Don't worry about strange levels. It's the unpredictable extra delay that is the problem. Peter Alfke, Xilinx ApplicationsArticle: 92183
Thanks for the help guys, its exactly what I was looking for. And Tim is right, I won't be getting realistic timing results unless I load my inputs and outputs with registers. But at least I won't have to worry about 132 I/O pin mappings that won't even be there affecting my delay. Thanks again JeremyArticle: 92184
On Wed, 23 Nov 2005 12:05:56 -0000, "Fred" <fred@nowhere.com> wrote: >For simplicity I would like to do the following > >CASE (bit1 & bit2 & bit3) IS case SLV3'(bit1 & bit2 & bit3) is where SLV3 is subtype SLV3 is std_logic_vector(2 downto 0); or just put in the full subtype expression instead of SLV3 if you want to. HTH RickArticle: 92185
This can be done if you manually encode the state-machine and then in
the testbench apply descriptive ASCII text to the state-machine states
in a separate variable.
For instance, if you describe the following state-machine in your source
code:
parameter START = 3'b0001;
parameter WAIT = 3'b0010;
parameter START_OVER = 3'b0100;
(* FSM_ENCODING="USER" *) reg [2:0] state = BEGIN;
always@(posedge CLK) begin
if (RST) begin
state <= START;
state_out <= 1'b0;
end
else
case (state) (* FULL_CASE, PARALLEL_CASE *)
START : begin
if (state_input)
state <= WAIT;
else
state <= START;
state_out <= 1'b0;
end
WAIT : begin
if (!state_input)
state <= START_OVER;
else
state <= WAIT;
state_out <= 1'b0;
end
START_OVER : begin
state <= START;
state_out <= 1'b1;
end
endcase
And add the following to your testbench:
reg [8*10:0] state_decode;
always @(testbench.uut.state)
if (testbench.uut.state == 3'h001)
state_decode = "BEGIN";
else if (testbench.uut.state == 3'h010)
state_decode = "WAIT";
else if (testbench.uut.state == 3'h100)
state_decode = "START_OVER";
else
state_decode = "UNKNOWN";
You can then either add the state_decode to your waveform and tell the
simulator to display it as ASCII or you can place a $monitor onto the
state_decode and have it display this information to the console. This
should work for both functional and place & route simulation if you
control the state-mapping which is done above by implicitly stating the
mapping and using the synthesis option FSM_ENCODING="USER" (for XST in
this case) which says to the synthesis tool, do not mess with my
state-machine mapping. I have used this technique on a few designs and
do find it useful but you need to make sure that the mapping you choose
for your state-machine is optimal or else you may not get the best
implementation when doing this. This also works best when using a
hierarchical simulation method but is not necessary if you want to
slightly adjust your testbench between behavioral and timing simulation.
-- Brian
Bob Perlman wrote:
> On 21 Nov 2005 18:33:09 -0800, ajeetha@gmail.com wrote:
>
>
>>Bob,
>> I also follow that in old Verilog. Thanks to SV, we have enums.
>>However the OP asked about Post place-and-route sim, hence this trick
>>won't help much. One needs to build equivalent signal names and enum
>>mapping. I believe MTI's virtual bus fits the bill better.
>>
>>Regards
>>Ajeetha
>>www.noveldv.com
>
>
> My mistake--I missed the part about post-place-and-route.
>
> Bob Perlman
> Cambrian Design Works
Article: 92186
On Wed, 23 Nov 2005 14:05:39 -0000, "Fred" <fred@nowhere.com> wrote:
>
><allanherriman@hotmail.com> wrote in message
>news:1132748877.058204.324060@g47g2000cwa.googlegroups.com...
>> Fred wrote:
>>> For simplicity I would like to do the following
>>>
>>> CASE (bit1 & bit2 & bit3) IS
>>> bit1 to 3 are "std_logic". How do I concatenate these "bits" in a CASE
>>> statement without having an intermediate array?
>I've used a temporary variable but it's not so readable. Shame really to
>have to do it.
Probably the nicest way is to declare a subtype - you can do this
locally in the process, so it doesn't pollute the architecture.
Then type-qualify the expression:
process (...)
[other declarations]
subtype SLV3 is std_logic_vector(2 downto 0);
begin
...
CASE SLV3'(bit1 & bit2 & bit3) IS
...
Note the apostrophe between subtype name and
opening parenthesis.
Depending on the application, you may be able to think of
a more apt name for the subtype.
HTH
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 92187Hi I need to use more than 8 global buffer in a virtex II design. I know that VirtexII supports up to 16 Global Buffer divided in more clock regions, but ISE PAR doesn't automatically divide project in two (or more) clock region and it uses only 8 global buffer. How can I use the other global buffer?Article: 92188
Hi I want to correlate my question to Chintan's problem and Alex answer. I usually use the method suggested by Alex to handle a bidirectional bus, but post PAR simulation (using modelsim) shows the signals on the bus delayed of about 12 ns and undefined for the next 5-6 ns before to begin stable. When bus comes back in Z state there's also a period of instability of 5-6 ns. The bus default state is 'Z'. It changes state during writing and readind operation. Microprocessor interface operations use a clock of 80Mhz, but writng operation from FPGA to Micro is asynchornous. I have also noted that this time of instability decreases (to 2-3 ns) when I do PAR whit High Effort Level. Is this a normal situation? or It should be better to investigate for the origin of the instability.Article: 92189
My ultimate goal is to try and investigate how much of an impact adding 1, 2, 4, X amount of peripherals onto the local memory bus has on processor clock impact. I want to be able to allow each coprocessor to have single cycle access, which should in theory impact the clock speed of the Microblaze. Is there a way for me to model and show this impact on the processor clock with the EDK?Article: 92190
Adrian Knoth wrote:
> Andy Peters <Bassman59a@yahoo.com> wrote:
>
> >> chooser : process (clk_i, reset) --, update_input)
> >> variable links,rechts : std_logic_vector (31 downto 0);
> >> begin
> >> if (reset='1') then
> >> input <= (others => '0');
> >> elsif (clk_i'event and clk_i='1') then
> >> if (update_input'event and update_input='1') then
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > I assume you wish to look for the edge of update_input? You can't do
>
> Yes.
>
> > it this way. You'll need to use a delay flip-flop (clocked by clk) and
> > then test the state of both update_input and update_input_delayed. If
> > update_input is true and update_input_delayed is false, then you've got
> > the edge of update_input.
>
> Wouldn't rising_edge (update_input) do the job? Or falling_edge (),
> if I need to know whether a signal was once set and is now off
> (write_A indicates that my processor core has written its result
> and I now can use the value of the output-FFs to write it to
> vga.)
THINK HARDWARE.
How would you implement the rising_edge() function? How does the
hardware "know" when an edge occurs?
Here's a point you must understand: the process statement
myflop : process (clk, rst) is
begin
if (rst = '1') then
q <= '0';
elsif rising_edge(clk) then
q <= d;
end if;
end process myflop;
follows a template that the synthesis tool uses to generate hardware.
The synthesis tool tries to match the code against standard templates
to infer various hardware structures (flip-flops, RAMs, etc). (It also
works to minimize logic, etc.)
The notation above conveniently describes a clearable D flip-flop. On
the rising edge of clk, it looks at the D input and assigns it to the Q
output.
You can't use the rising_edge() function in the way you describe ...
there is no hardware equivalent..
> How do I synchronize these processes in VHDL? I have the output-FFs
> containing the current value and need to bitwise store the content
> in the VGA-RAM every time my write_A indicates that there are new
> data. I currently use a process for this but I don't know if it
> really stops after executing the for-loops, how many clock cycles
> are used for each loop iteration, if every statement in the
> loop-body is executed in one clock cycle and so on:
>
> to_video : process (clk_i, reset)
> variable tmp_vga : std_logic_vector (31 downto 0);
> begin
> if (reset='1') then
> addr_vga <= (others => '0');
> web_i <= '0';
> elsif (falling_edge (write_A)) then
This is another problem. Your sensitivity list includes a clock and a
reset (which is correct), but your code tells us that you want write_A
to be the clock used by the flip-flops. Your synthesis tool should
barf on this.
> tmp_vga := output;
> for j in 3 downto 0 loop
> for i in 6 downto 1 loop
> web_i <= '1';
> dib_i (0 downto 0) <= tmp_vga (j * 8 + i downto j * 8 + i);
> web_i <= '0';
> addr_vga <= addr_vga + 1;
> end loop;
> end loop;
> end if;
> end process to_video;
>
> (web_i enables the vga input, addr_vga should be the bitaddress in
> the VGA RAM)
>
> Let's say write_A goes up for two cycles every 24 clocks (assumption,
> I don't know the real amount of clocks between these two pulses),
> indicating that there is now new information available at the
> output (output is DFF-buffered (but currently optimized away ;)).
>
> Does the process above would poke the selected bits to dib_i or
> do I have to keep track of write_A by something like a state machine?
Assuming write_A is synchronous to your clock, you have a couple of
options. If your data remain valid during the time write_A is
asserted, you can use write_A directly as a clock enable:
myenabledflop : process (clk, rst) is
begin
if (rst = '1') then
q <= '0';
elsif rising_edge(clk) then
if (write_A = '1') then
q <= d;
end if;
end if;
end process myenabledflop;
If you really do need to do your work on the rising edge of write_A,
then you code an edge detector and use that as your clock enable:
myedgedetectflop : process (clk, rst) is
begin
if (rst = '1') then
write_A_d <= '0';
q <= '0';
elsif rising_edge(clk) then
write_A_d <= write_A; -- delay for edge detect
if (write_A = '1' and write_A_d = '0') then
q <= d;
end if;
end if;
end process myedgedetectflop;
Is this clear?
-a
Article: 92191You need to manually instantiate BUFG or BUFGMUX operators. The tools are not going to infer more than 8 because there is only 8 global clock connections. To use more than 8 you have to limit the connections on some of them to one quadrant of the chip. Use the -timing parameter on the mapper to place them or manually locate them yourself -- something you will likely have to do anyway. When you manually instantiate them make sure that some of them are only connected to objects in their quadrant of the chip.Article: 92192
Hi,
I am trying to generate a serial bit clock for a Camera Link interface and I
am having trouble going from 40MHz to 280MHz. I am committing two DCMs for
this task, one using the FX output to go from 40 to 140 MHz (7/2), and
another DCM using 2X output to go from 140 to 280. The FX output locks OK
and the divided output looks OK on the scope. The 2X lock output seems to
lock intermitently, trying to get to high, and the 2X divided output is
"fuzzy".
I probably need some sort of timing restraint or perhaps I don't understand
what Xilinx is doing with this auto_callibration on the dcm_adv wizard. Can
somebody help me out. Here is the code:
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 top is
port(
sys_rst_in : in std_logic;
gpio_exp_hdr2 : in std_logic_vector( 7 downto 6); -- HDR2 diff
gpio : out std_logic_vector(3 downto 0) ); -- LEDs
end top;
architecture Behavioral of top is
signal reset : std_logic;
signal cam1_xclk : std_logic;
signal test_counter_1 : std_logic_vector( 9 downto 0);
signal test_counter_2 : std_logic_vector( 9 downto 0);
signal test_counter_3 : std_logic_vector( 9 downto 0);
signal cam1_clk7xdiv2 : std_logic;
signal cam1_lock7xdiv2 : std_logic;
signal cam1_clk7x : std_logic;
signal cam1_lock7x : std_logic;
component dcmfx2
port(
clkin_n_in : in std_logic;
clkin_p_in : in std_logic;
rst_in : in std_logic;
clkfx_out : out std_logic;
clkin_ibufgds_out : out std_logic;
clk0_out : out std_logic;
locked_out : out std_logic );
end component;
component dcm_140_280
port(
CLKIN_IN : in std_logic;
RST_IN : in std_logic;
CLK0_OUT : out std_logic;
CLK2X_OUT : out std_logic;
LOCKED_OUT : out std_logic );
end component;
begin
cam1_dcmfx2 : dcmfx2
port map(
clkin_n_in => gpio_exp_hdr2(6), -- 40 MHz
clkin_p_in => gpio_exp_hdr2(7), -- Differential pair
rst_in => reset,
clkfx_out => cam1_clk7xdiv2, -- 140MHz
clkin_ibufgds_out => open,
clk0_out => cam1_xclk, -- 40 MHz
locked_out => cam1_lock7xdiv2 );
cam1_dcm_140_280: dcm_140_280
port map(
CLKIN_IN => cam1_clk7xdiv2, -- 140 MHz
RST_IN => reset,
CLK0_OUT => open,
CLK2X_OUT => cam1_clk7x, -- 280 MHz
LOCKED_OUT => cam1_lock7x );
reset <= not sys_rst_in;
led_test_counter_1_process:process(cam1_xclk)
begin
if( cam1_xclk'event and cam1_xclk='1') then
if( reset='1' ) then
test_counter_1 <= (others=>'0');
else
test_counter_1 <= test_counter_1+1;
end if;
end if;
end process;
led_test_counter_2_process:process(cam1_clk7xdiv2)
begin
if( cam1_clk7xdiv2'event and cam1_clk7xdiv2='1') then
if( reset='1' ) then
test_counter_2 <= (others=>'0');
else
test_counter_2 <= test_counter_2+1;
end if;
end if;
end process;
led_test_counter_3_process:process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1') then
if( reset='1' ) then
test_counter_3 <= (others=>'0');
else
test_counter_3 <= test_counter_3+1;
end if;
end if;
end process;
gpio(0) <= test_counter_1(9);
gpio(1) <= test_counter_2(9);
gpio(2) <= test_counter_3(9);
-- gpio(3) <= cam1_lock7xdiv2; -- OK
gpio(3) <= cam1_lock7x; -- FAILS
end Behavioral;
Brad Smallridge
aivision.com
Article: 92193>2. We don't know what is better: to program flash chip and then to >solder it or to solder it and then program. May be ask Xilinx to >program flashes at factory and then solder? Even if you do program the flash chip before you solder it to the board, you probably want to be able to re-program it in case you discover a bug or come up with a new feature. That's one of the great advantages of (some/most) FPGAs. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 92194
"Brad Smallridge" <bradsmallridge@dslextreme.com> schrieb im Newsbeitrag news:11o9f00jpgidsc7@corp.supernews.com... > Hi, > > I am trying to generate a serial bit clock for a Camera Link interface and > I am having trouble going from 40MHz to 280MHz. I am committing two DCMs > for this task, one using the FX output to go from 40 to 140 MHz (7/2), and > another DCM using 2X output to go from 140 to 280. The FX output locks OK > and the divided output looks OK on the scope. The 2X lock output seems to > lock intermitently, trying to get to high, and the 2X divided output is > "fuzzy". > > I probably need some sort of timing restraint or perhaps I don't > understand what Xilinx is doing with this auto_callibration on the dcm_adv > wizard. Can somebody help me out. Here is the code: > > 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 top is > port( > sys_rst_in : in std_logic; > gpio_exp_hdr2 : in std_logic_vector( 7 downto 6); -- HDR2 diff > gpio : out std_logic_vector(3 downto 0) ); -- LEDs > end top; > > architecture Behavioral of top is > > signal reset : std_logic; > signal cam1_xclk : std_logic; > > signal test_counter_1 : std_logic_vector( 9 downto 0); > signal test_counter_2 : std_logic_vector( 9 downto 0); > signal test_counter_3 : std_logic_vector( 9 downto 0); > > signal cam1_clk7xdiv2 : std_logic; > signal cam1_lock7xdiv2 : std_logic; > signal cam1_clk7x : std_logic; > signal cam1_lock7x : std_logic; > > component dcmfx2 > port( > clkin_n_in : in std_logic; > clkin_p_in : in std_logic; > rst_in : in std_logic; > clkfx_out : out std_logic; > clkin_ibufgds_out : out std_logic; > clk0_out : out std_logic; > locked_out : out std_logic ); > end component; > > component dcm_140_280 > port( > CLKIN_IN : in std_logic; > RST_IN : in std_logic; > CLK0_OUT : out std_logic; > CLK2X_OUT : out std_logic; > LOCKED_OUT : out std_logic ); > end component; > > begin > > cam1_dcmfx2 : dcmfx2 > port map( > clkin_n_in => gpio_exp_hdr2(6), -- 40 MHz > clkin_p_in => gpio_exp_hdr2(7), -- Differential pair > rst_in => reset, > clkfx_out => cam1_clk7xdiv2, -- 140MHz > clkin_ibufgds_out => open, > clk0_out => cam1_xclk, -- 40 MHz > locked_out => cam1_lock7xdiv2 ); > > cam1_dcm_140_280: dcm_140_280 > port map( > CLKIN_IN => cam1_clk7xdiv2, -- 140 MHz > RST_IN => reset, > CLK0_OUT => open, > CLK2X_OUT => cam1_clk7x, -- 280 MHz > LOCKED_OUT => cam1_lock7x ); > > reset <= not sys_rst_in; > > led_test_counter_1_process:process(cam1_xclk) > begin > if( cam1_xclk'event and cam1_xclk='1') then > if( reset='1' ) then > test_counter_1 <= (others=>'0'); > else > test_counter_1 <= test_counter_1+1; > end if; > end if; > end process; > > led_test_counter_2_process:process(cam1_clk7xdiv2) > begin > if( cam1_clk7xdiv2'event and cam1_clk7xdiv2='1') then > if( reset='1' ) then > test_counter_2 <= (others=>'0'); > else > test_counter_2 <= test_counter_2+1; > end if; > end if; > end process; > > led_test_counter_3_process:process(cam1_clk7x) > begin > if( cam1_clk7x'event and cam1_clk7x='1') then > if( reset='1' ) then > test_counter_3 <= (others=>'0'); > else > test_counter_3 <= test_counter_3+1; > end if; > end if; > end process; > > gpio(0) <= test_counter_1(9); > gpio(1) <= test_counter_2(9); > gpio(2) <= test_counter_3(9); > -- gpio(3) <= cam1_lock7xdiv2; -- OK > gpio(3) <= cam1_lock7x; -- FAILS > > end Behavioral; > > Brad Smallridge > aivision.com > > Hi Btad, What device are you using? In spartan3 -4 I have seen DCM fail somewhere about at 270MHz, but I think most other devices should actually go up to 280 but for 280 cameralink there is no need for 280 Mhz at all you can implement it all by 140MHz clock using both clock edges AnttiArticle: 92195
johnp wrote:
> I love synthesis, but... It sure would be nice to have any easier way
> to direct it! In any event, it sure beats schematics.
It not only beats them, It draws them for me:
http://home.comcast.net/~mike_treseler/uart.pdf
-- Mike Treseler
Article: 92196I am not familiar with the CLKFX outputs of the DCM, but... When a DCM is locking, it is not guaranteed to generate a stable clock; the output clock is only guaranteed to be stable once the LOCKED output goes high. Since you are cascading two DCMs, the second DCM is trying to attain lock on the output of the first DCM. But, right after reset, the second DCM is seeing an unstable clock. Once a DCM fails to lock properly (due to an unstable input clock), it will not try again until its reset is asserted. Therefore, I think you need to hold the second DCM in reset until the first DCM locks (this is mentioned in several app-notes). In fact, it is a good idea to delay the deassertion of RESET on the second DCM until a few clocks after the first DCM locks (an SRL is useful for doing this. Doing this will probably fix your problem. Avrum "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11o9f00jpgidsc7@corp.supernews.com... > Hi, > > I am trying to generate a serial bit clock for a Camera Link interface and I > am having trouble going from 40MHz to 280MHz. I am committing two DCMs for > this task, one using the FX output to go from 40 to 140 MHz (7/2), and > another DCM using 2X output to go from 140 to 280. The FX output locks OK > and the divided output looks OK on the scope. The 2X lock output seems to > lock intermitently, trying to get to high, and the 2X divided output is > "fuzzy". > > I probably need some sort of timing restraint or perhaps I don't understand > what Xilinx is doing with this auto_callibration on the dcm_adv wizard. Can > somebody help me out. Here is the code: > > 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 top is > port( > sys_rst_in : in std_logic; > gpio_exp_hdr2 : in std_logic_vector( 7 downto 6); -- HDR2 diff > gpio : out std_logic_vector(3 downto 0) ); -- LEDs > end top; > > architecture Behavioral of top is > > signal reset : std_logic; > signal cam1_xclk : std_logic; > > signal test_counter_1 : std_logic_vector( 9 downto 0); > signal test_counter_2 : std_logic_vector( 9 downto 0); > signal test_counter_3 : std_logic_vector( 9 downto 0); > > signal cam1_clk7xdiv2 : std_logic; > signal cam1_lock7xdiv2 : std_logic; > signal cam1_clk7x : std_logic; > signal cam1_lock7x : std_logic; > > component dcmfx2 > port( > clkin_n_in : in std_logic; > clkin_p_in : in std_logic; > rst_in : in std_logic; > clkfx_out : out std_logic; > clkin_ibufgds_out : out std_logic; > clk0_out : out std_logic; > locked_out : out std_logic ); > end component; > > component dcm_140_280 > port( > CLKIN_IN : in std_logic; > RST_IN : in std_logic; > CLK0_OUT : out std_logic; > CLK2X_OUT : out std_logic; > LOCKED_OUT : out std_logic ); > end component; > > begin > > cam1_dcmfx2 : dcmfx2 > port map( > clkin_n_in => gpio_exp_hdr2(6), -- 40 MHz > clkin_p_in => gpio_exp_hdr2(7), -- Differential pair > rst_in => reset, > clkfx_out => cam1_clk7xdiv2, -- 140MHz > clkin_ibufgds_out => open, > clk0_out => cam1_xclk, -- 40 MHz > locked_out => cam1_lock7xdiv2 ); > > cam1_dcm_140_280: dcm_140_280 > port map( > CLKIN_IN => cam1_clk7xdiv2, -- 140 MHz > RST_IN => reset, > CLK0_OUT => open, > CLK2X_OUT => cam1_clk7x, -- 280 MHz > LOCKED_OUT => cam1_lock7x ); > > reset <= not sys_rst_in; > > led_test_counter_1_process:process(cam1_xclk) > begin > if( cam1_xclk'event and cam1_xclk='1') then > if( reset='1' ) then > test_counter_1 <= (others=>'0'); > else > test_counter_1 <= test_counter_1+1; > end if; > end if; > end process; > > led_test_counter_2_process:process(cam1_clk7xdiv2) > begin > if( cam1_clk7xdiv2'event and cam1_clk7xdiv2='1') then > if( reset='1' ) then > test_counter_2 <= (others=>'0'); > else > test_counter_2 <= test_counter_2+1; > end if; > end if; > end process; > > led_test_counter_3_process:process(cam1_clk7x) > begin > if( cam1_clk7x'event and cam1_clk7x='1') then > if( reset='1' ) then > test_counter_3 <= (others=>'0'); > else > test_counter_3 <= test_counter_3+1; > end if; > end if; > end process; > > gpio(0) <= test_counter_1(9); > gpio(1) <= test_counter_2(9); > gpio(2) <= test_counter_3(9); > -- gpio(3) <= cam1_lock7xdiv2; -- OK > gpio(3) <= cam1_lock7x; -- FAILS > > end Behavioral; > > Brad Smallridge > aivision.com > > >Article: 92197
allanherriman@hotmail.com wrote: > allanherri...@hotmail.com wrote: > >>Fred wrote: >>>Unfortunately in the UK you're more employable if you know VHDL. I have >>>written in Verilog and quite like the C type structure. Since I'd like to >>>pay my bills I feel tied to VHDL. >> >>You're even more employable if you have a strong knowedge of both. > > > ... and even more employable if you can spell. Nope, then they think you are over qualifed for the job :) -jgArticle: 92198
Since you haven't posted any details about how you are doing the clock crossing, we can't say if the system is robust or not. Dealing with clock crossing is a tricky issue, not just in terms of dealing with metastability, but also in terms of how to ensure that data is not missed, replicated, or otherwise mangled. 40 hours of testing is relatively short when you are dealing with metastability; all you have demonstrated is that your MTBF is not substantially less than 40hrs; it is certainly possible that you could have a system that works most of the time, but still fails once per day, once per week, once per year... Clock crossing through a FIFO is a mechanism that is well understood, and can be designed to be reliable in spite of metastability issues. Other mechanisms certainly exist, and, depending on the frequencies involved, can be implemented with less logic than a FIFO. However from 125MHz to 166MHz, many of the "easy" robust mechanisms won't work; a FIFO is your best bet. It is understandable that you don't want to "waste" block RAMs for the clock crossing. However, one nice features of the Xilinx architecture is the availability of distributed RAMs. It is relatively "cheap" to use these dual ported RAMs to build 16 word deep FIFOs (in any width), which are enough for most clock crossing applications. Avrum <v_mirgorodsky@yahoo.com> wrote in message news:1132738682.392066.268630@g14g2000cwa.googlegroups.com... > Hello ALL, > > I have a design with two global clocks. I have data I need to transfer > from one clock domain to another. I am aware of existence of FIFO > blocks :), but it seems to be too expensive to spend a block-ram and > other resources for every boundary crossing. To avoid using FIFO blocks > we created a handshake schematic, based on some triggers and small FSM. > This solution is proven to work in hardware error-free for almost 40 > hours. First domain clock frequency is 25MHz or 125MHz (depending on > mode); second domain clock frequency is 166MHz. > > Naturally, some triggers in out design are metastable. Is it possible > to get some intermediate voltage level at the output of trigger in FPGA > if input signal on its Data input violates setup or hold times? In my > design I assume I don't get any intermediate level voltages at the > trigger outputs. What about signal I input into FPGA from outside? Is > it possible to get some intermediate voltage levels on the trigger > outputs by violating setup-hold times and/or IO standard voltage > levels? > > With best regards, > Vladimir S. Mirgorodsky >Article: 92199
Phil Hays wrote:
> Nick <nick@no-domain> wrote:
<snipped>
> use ieee.numeric_std.all;
> entity
> ...
> architecture
> ...
> Signal reset : std_logic := '1';
> Signal count : unsigned(3 downto 0) := "0000";
> begin
> --
> -- This counter is used to hold all statemachines in reset for the
> -- first 8 or so clocks after the end of configuration.
> --
> RESET_STATE: process(clk)
> begin
> if rising_edge(clk) then
> reset <= count(3);
> if count(3) = '1' then
> count <= count + 1;
> end if;
> end if;
> end process;
> (rest of code)
>
>
> Note that not all synthesis tools can correctly handle this. Some of
> the old tools would have problems with this. While I've used similar
> tricks in the past, I have not verified this exact code.
>
> Note that the number of bits in count needs to be large enough to get
> well past the end of asynchronous reset, and not so large as to cause
> startup delays.
>
>
> --
> Phil Hays to reply solve: phil_hays at not(coldmail) dot com
> If not cold then hot
Shouldn't:
if count(3) = '1' then
count <= count + 1;
be:
if count(3) = '0' then
count <= count + 1;
-Dave Pollum
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