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
On Wed, 09 Aug 2006 17:23:06 -0400, MM wrote: > "Alex Iliev" <iliev@nimbus.dartmouth.edu> wrote in message > news:pan.2006.08.09.20.14.10.432160@nimbus.dartmouth.edu... >> >> Also, the LEDs have a register in front of them. > > In which of the 2 FPGA's? It's not in your code, and you previously said > that the second FPGA is configured to pass the data straight through I got a hold of the second (bridge) FPGA's design, and it turned out that the process (DFF register) driving the LEDs is indeed clocked, and I had not been providing that clock. Now the board said hello, with a counter on the LEDs :) alexArticle: 106301
Frank Buss wrote:
> How can I
> sample this data with rising edge of E_RX_CLK and is block RAM fast enough
> for saving it?
My USB 8 channel logic analyzer arrived yesterday, so I managed to debug it
a bit. With some higher internal clock, generated with a DCM and some
latches I managed to sample the 25 MHz data at 100 Mbit and 2.5 MHz data at
10 Mbit (with the same source code). The program saves it to block RAM
(which is fast enough according to the datasheet) and outputs it to the
RS232 port (as binary data), where I was able to read the MAC address of my
Windows PC, which sends broadcast packages from time to time.
I've tried to implement the RS232 interface as Whishbone components, but
I'm not sure about the signals and timings. Is it true that the master has
to wait for ack=0 before it can signal another stb=1?
Below is the new source. Please comment it, if there are some things which
can be simplified or which can cause timing problems, because this is my
first bigger FPGA project and I'm not always sure how and when signals are
propagated and sampled.
Now I'll try to add the sending part and then some higher layers, like the
DHCP client protocol and maybe finally a simple web server. I'll post this
in the comp.lang.vhdl newsgroup for discussion and bugfixing for adding it
to the Spartan 3E design examples site (
http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm ).
-- rs232 sender with whishbone slave interface
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.MATH_REAL.ALL;
entity rs232_sender is
generic(system_speed, baudrate: integer);
port(
ack_o: out std_logic;
clk_i: in std_logic;
dat_i: in unsigned(7 downto 0);
rst_i: in std_logic;
stb_i: in std_logic;
tx: out std_logic);
end entity rs232_sender;
architecture rtl of rs232_sender is
constant max_counter: natural := system_speed / baudrate;
type state_type is (
wait_for_strobe,
send_start_bit,
send_bits,
send_stop_bit);
signal state: state_type := wait_for_strobe;
signal baudrate_counter: natural range 0 to max_counter := 0;
signal bit_counter: natural range 0 to 7 := 0;
signal shift_register: unsigned(7 downto 0) := (others => '0');
signal data_sending_started: std_logic := '0';
begin
-- acknowledge, when sending process was started
ack_o <= data_sending_started and stb_i;
update: process(clk_i)
begin
if rising_edge(clk_i) then
if rst_i = '1' then
tx <= '1';
data_sending_started <= '0';
state <= wait_for_strobe;
else
case state is
when wait_for_strobe =>
if stb_i = '1' then
state <= send_start_bit;
baudrate_counter <= max_counter - 1;
tx <= '0';
shift_register <= dat_i;
data_sending_started <= '1';
else
tx <= '1';
end if;
when send_start_bit =>
if baudrate_counter = 0 then
state <= send_bits;
baudrate_counter <= max_counter - 1;
tx <= shift_register(0);
bit_counter <= 7;
else
baudrate_counter <= baudrate_counter - 1;
end if;
when send_bits =>
if baudrate_counter = 0 then
if bit_counter = 0 then
state <= send_stop_bit;
tx <= '1';
else
tx <= shift_register(1);
shift_register <= shift_right(shift_register, 1);
bit_counter <= bit_counter - 1;
end if;
baudrate_counter <= max_counter - 1;
else
baudrate_counter <= baudrate_counter - 1;
end if;
when send_stop_bit =>
if baudrate_counter = 0 then
state <= wait_for_strobe;
else
baudrate_counter <= baudrate_counter - 1;
end if;
end case;
-- this resets acknowledge until all bits are sent
if stb_i = '0' and data_sending_started = '1' then
data_sending_started <= '0';
end if;
end if;
end if;
end process;
end architecture rtl;
-- rs232 receiver with whishbone master interface
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.MATH_REAL.ALL;
entity rs232_receiver is
generic(system_speed, baudrate: integer);
port(
ack_i: in std_logic;
clk_i: in std_logic;
dat_o: out unsigned(7 downto 0);
rst_i: in std_logic;
stb_o: out std_logic;
rx: in std_logic);
end entity rs232_receiver;
architecture rtl of rs232_receiver is
constant max_counter: natural := system_speed / baudrate;
type state_type is (
wait_for_rx_start,
wait_half_bit,
receive_bits,
wait_for_stop_bit);
signal state: state_type := wait_for_rx_start;
signal baudrate_counter: natural range 0 to max_counter := 0;
signal bit_counter: natural range 0 to 7 := 0;
signal shift_register: unsigned(7 downto 0) := (others => '0');
begin
update: process(clk_i, ack_i)
begin
if rising_edge(clk_i) then
if rst_i = '1' then
state <= wait_for_rx_start;
dat_o <= (others => '0');
stb_o <= '0';
else
case state is
when wait_for_rx_start =>
if rx = '0' then
-- start bit received, wait for a half bit time
-- to sample bits in the middle of the signal
state <= wait_half_bit;
baudrate_counter <= max_counter / 2 - 1;
end if;
when wait_half_bit =>
if baudrate_counter = 0 then
-- now we are in the middle of the start bit,
-- wait a full bit for the middle of the first bit
state <= receive_bits;
bit_counter <= 7;
baudrate_counter <= max_counter - 1;
else
baudrate_counter <= baudrate_counter - 1;
end if;
when receive_bits =>
-- sample a bit
if baudrate_counter = 0 then
shift_register <= rx & shift_register(7 downto 1);
if bit_counter = 0 then
state <= wait_for_stop_bit;
else
bit_counter <= bit_counter - 1;
end if;
baudrate_counter <= max_counter - 1;
else
baudrate_counter <= baudrate_counter - 1;
end if;
when wait_for_stop_bit =>
-- wait for the middle of the stop bit
if baudrate_counter = 0 then
state <= wait_for_rx_start;
if rx = '1' then
dat_o <= shift_register;
stb_o <= '1';
-- else: missing stop bit, ignore
end if;
else
baudrate_counter <= baudrate_counter - 1;
end if;
end case;
end if;
end if;
-- when acknowledged, reset strobe
if ack_i = '1' then
stb_o <= '0';
end if;
end process;
end architecture rtl;
-- network test
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.MATH_REAL.ALL;
Library UNISIM;
use UNISIM.vcomponents.all;
entity network_test is
port(
clk_50mhz: in std_logic;
rs232_dce_txd: out std_logic;
rs232_dce_rxd: in std_logic;
e_rxd: in unsigned(4 downto 0);
e_rx_clk: in std_logic;
e_rx_dv: in std_logic;
e_txd: buffer std_logic_vector(3 downto 0);
e_tx_en: out std_logic;
e_mdc: out std_logic;
e_mdio: inout std_logic;
led: out unsigned(7 downto 0));
end entity network_test;
architecture rtl of network_test is
constant system_speed: natural := 125e6;
constant baudrate: natural := 115200;
signal clk_250mhz: std_logic := '0';
signal clk_125mhz: std_logic := '0';
signal rs232_receiver_ack: std_logic := '0';
signal rs232_receiver_dat: unsigned(7 downto 0);
signal rs232_receiver_stb: std_logic := '0';
signal rs232_sender_ack: std_logic := '0';
signal rs232_sender_dat: unsigned(7 downto 0) := (others => '0');
signal rs232_sender_stb: std_logic := '0';
signal test: std_logic := '0';
signal counter: natural range 0 to 125000000 := 0;
signal rxd: unsigned(3 downto 0) := (others => '0');
signal rx_dv: std_logic := '0';
signal rx_clk: std_logic := '0';
signal old_rx_clk: std_logic := '0';
type state_type is (
wait_for_start,
wait_for_data,
receive_first_low_nibble,
receive_high_nibble,
receive_low_nibble,
start_send_data,
send_data,
wait_for_data_send_start);
signal state: state_type := wait_for_start;
type command_type is (
wait_for_command,
wait_for_strobe_0);
signal command: command_type := wait_for_command;
signal low_nibble: unsigned(3 downto 0);
signal ethernet_packet_size: natural range 0 to 2047;
signal ethernet_buffer_addr: natural range 0 to 2047;
type ram_t is array(2047 downto 0)
of unsigned(7 downto 0);
-- infers 2048 Kbyte block RAM, if used inside rising_edge
signal ethernet_buffer: ram_t;
begin
-- Spartan 3E stepping 0, speed grade -4 devices:
-- CLKFX frequency in "high" mode: min: 220 MHz, max: 307 MHz
clock250: dcm_sp
generic map(
clkfx_multiply => 5,
clkin_period => 4.0,
dfs_frequency_mode => "HIGH")
port map(
clkfx => clk_250mhz,
clkin => clk_50mhz);
sender: entity rs232_sender
generic map(system_speed, baudrate)
port map(
ack_o => rs232_sender_ack,
clk_i => clk_125mhz,
dat_i => rs232_sender_dat,
rst_i => '0',
stb_i => rs232_sender_stb,
tx => rs232_dce_txd);
receiver: entity rs232_receiver
generic map(system_speed, baudrate)
port map(
ack_i => rs232_receiver_ack,
clk_i => clk_125mhz,
dat_o => rs232_receiver_dat,
rst_i => '0',
stb_o => rs232_receiver_stb,
rx => rs232_dce_rxd);
-- receive commands from rs232 port for debugging
rs232_command: process(clk_125mhz)
begin
if rising_edge(clk_125mhz) then
case command is
when wait_for_command =>
if rs232_receiver_stb = '1' then
case rs232_receiver_dat is
when x"10" =>
led(7) <= '1';
when x"11" =>
led(7) <= '0';
when others =>
led(7) <= '0';
end case;
rs232_receiver_ack <= '1';
command <= wait_for_strobe_0;
end if;
when wait_for_strobe_0 =>
if rs232_receiver_stb <= '0' then
rs232_receiver_ack <= '0';
command <= wait_for_command;
end if;
end case;
end if;
end process;
-- network data is valid after rising edge of rx_clk (see latch process),
-- data is sampled with falling edge of rx_clk, aligned with system clock
-- to allow infering 2048 bytes block RAM for saving a full TCP/IP block
ethernet_dump: process(clk_125mhz)
begin
if rising_edge(clk_125mhz) then
old_rx_clk <= rx_clk;
case state is
-- wait for data valid
when wait_for_start =>
if rx_clk = '0' and old_rx_clk = '1' then
if rx_dv = '1' then
ethernet_buffer_addr <= 0;
ethernet_packet_size <= 0;
state <= wait_for_data;
end if;
end if;
-- wait for "d" nibble, after which the data starts
when wait_for_data =>
if rx_clk = '0' and old_rx_clk = '1' then
if rx_dv = '1' then
if rxd = x"d" then
state <= receive_first_low_nibble;
end if;
else
state <= wait_for_start;
end if;
end if;
-- receive first low nibble, don't increment address pointer
when receive_first_low_nibble =>
if rx_clk = '0' and old_rx_clk = '1' then
low_nibble(3 downto 0) <= rxd;
if rx_dv = '0' then
state <= start_send_data;
else
state <= receive_high_nibble;
end if;
end if;
-- receive high nibble and save to block RAM
when receive_high_nibble =>
if rx_clk = '0' and old_rx_clk = '1' then
ethernet_buffer(ethernet_buffer_addr) <= rxd & low_nibble;
state <= receive_low_nibble;
end if;
-- receive next low nibble and increment block RAM pointer
when receive_low_nibble =>
if rx_clk = '0' and old_rx_clk = '1' then
low_nibble(3 downto 0) <= rxd;
if rx_dv = '0' then
state <= start_send_data;
else
state <= receive_high_nibble;
end if;
ethernet_buffer_addr <= ethernet_buffer_addr + 1;
ethernet_packet_size <= ethernet_packet_size + 1;
end if;
-- dump data to RS232 port for debugging
when start_send_data =>
ethernet_buffer_addr <= 0;
if ethernet_packet_size = 0 then
state <= wait_for_start;
else
state <= send_data;
end if;
when send_data =>
if rs232_sender_ack = '0' then
if ethernet_packet_size = 0 then
state <= wait_for_start;
else
rs232_sender_dat <= ethernet_buffer(ethernet_buffer_addr);
rs232_sender_stb <= '1';
state <= wait_for_data_send_start;
end if;
end if;
when wait_for_data_send_start =>
if rs232_sender_ack = '1' then
rs232_sender_stb <= '0';
state <= send_data;
ethernet_packet_size <= ethernet_packet_size - 1;
ethernet_buffer_addr <= ethernet_buffer_addr + 1;
end if;
end case;
-- "test" should change with 1 Hz @ 100 Mbit
if counter = 0 then
test <= not test;
counter <= 62500000;
else
counter <= counter - 1;
end if;
end if;
end process;
-- latch network signals with 125 MHz system clock
latch: process(clk_125mhz)
begin
if rising_edge(clk_125mhz) then
if e_rx_clk = '1' and rx_clk = '0' then
rxd <= e_rxd(3 downto 0);
rx_dv <= e_rx_dv;
end if;
rx_clk <= e_rx_clk;
end if;
end process;
-- divide 250 MHz to system clock
clock_divide: process(clk_250mhz)
begin
if rising_edge(clk_250mhz) then
clk_125mhz <= not clk_125mhz;
end if;
end process;
e_mdio <= '0';
e_mdc <= '0';
e_txd <= (others => '0');
e_tx_en <= '0';
led(6) <= e_rxd(4);
led(5 downto 4) <= (others => '0');
led(3 downto 1) <= (others => '1');
led(0) <= test;
end architecture rtl;
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 106302Hi, I'm tearing my hair out and I can't find the answer to this in any of the Xilinx solutions!!! ---8<------8<------8<------8<------8<------8<------8<------8<------8<--- NgdBuild:604 - logical block 'pace_inst/U_Game/vram_inst' with type vram' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'vram' is not supported in target 'spartan3'. ---8<------8<------8<------8<------8<------8<------8<------8<------8<--- 'vram' was generated with coregen and is a block memory. I copied the .NGC file to my project directory and associated it with the instance in the source tree. The VHDL file in which it is instantiated has a component entry for vram. I also notice during synthesis I get... WARNING:Xst:766 - line 453: Generating a Black Box for component <vram>. What am I doing wrong??? What have I forgotten? 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: 106303
Mark McDougall wrote: > What am I doing wrong??? What have I forgotten? I guess I should also add that I'm doing all this in the ISE 8.1i Webpack Edition IDE, not the command-line. 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: 106304
Hello.
Newbie here. I am trying to write a very simple program to simulate a
multiplexer. I am using the xilinx version of the modelsim compiler
viz. Modelsim XE version.
heres my code:
library ieee;
use ieee.std_logic_1164.all;
entity mux is
port(a,b:IN std_logic_vector(7 downto 0);
sel:IN std_logic_vector(1 downto 0);
c : OUT std_logic_vector(7 downto 0));
end mux;
architecture example of mux is
begin
process(a,b,sel)
begin
if(sel = "00") then
c <= "00000000";
elsif (sel = "01") then
c <= a;
elsif (sel = "10") then
c <= b;
else
c <= (OTHERS => 'Z');
end if;
end process;
end example;
entity tb_mux is
end entity;
architecture mux of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel1 : std_logic_vector(1 downto 0);
component muxc is
port(a,b : in std_logic_vector(7 downto 0);
sel : in std_logic_vector(1 downto 0);
c : out std_logic_vector(7 downto 0));
end muxc;
for all:muxc use entity mux(example);
begin
M1:muxc port map(a,b,sel,c);
process
begin
a <= X"11" after 1 ns,
X"AF" after 2 ns,
X"BB" after 3 ns,
X"6F" after 4 ns;
b <= X"01" after 1 ns,
X"2F" after 2 ns,
X"3C" after 3 ns,
X"BE" after 4 ns;
sel <= B"00" after 1 ns,
B"01" after 2 ns,
B"10" after 3 ns,
B"11" after 4 ns;
wait;
end process;
end mux;
When I try to compile my program into a file called mux.vhd in the work
library it gives me errors at all lines where I use std_logic_vector
saying that it is an unknown identifier though I have included the
library and the needed package in the code above.Alongwith that it says
that I should always end a component declaration with a "end component
component_name" instead of just "end component_name" which is perfectly
legal I guess isn't it?
After that when I replace the line containing ' c <= (OTHERS => 'Z');
' with ' c <= 'Z'; ' it says that "Enumeration literal 'Z' is not
of type std_logic_vector.". And the error about the ending of the
component part doesn't come in the picture.
Hoping to hear from you,
Aijaz Baig.
Article: 106305
On Fri, 11 Aug 2006 17:25:59 +1000, Mark McDougall <markm@vl.com.au> wrote:
>Hi,
>
>I'm tearing my hair out and I can't find the answer to this in any of
>the Xilinx solutions!!!
>
>---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>NgdBuild:604 - logical block 'pace_inst/U_Game/vram_inst' with type
>vram' could not be resolved. A pin name misspelling can cause this, a
>missing edif or ngc file, or the misspelling of a type name. Symbol
>'vram' is not supported in target 'spartan3'.
>---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>
>'vram' was generated with coregen and is a block memory. I copied the
>.NGC file to my project directory and associated it with the instance in
>the source tree. The VHDL file in which it is instantiated has a
>component entry for vram.
I get this error if I do not import the vram.xco file into the project explicitely by hand.
Even though the core generator asks for the project and should know what is needed.
I think earlier versions than ISE 8.1.? worked without that, but I'm not sure.
(I use virtex4, Ise8.1.current_sp)
>
>I also notice during synthesis I get...
>
>WARNING:Xst:766 - line 453: Generating a Black Box for component <vram>.
You can declare the black box yourself, then you get only 1999 warnings
instead of 2000.
What annoys me more is self critic like "You use dirty and unsave coding tricks
like clock gating" that comes from inside the MicroBlaze and endless lists
of unconnected and removed signals from inside of automatically generated
FIR-filters or multipliers.
Why can't ISE respect it when I explicitely write
....
carry_out => open,
....
It's not that I forgot to connect the pin.
Now use name mangling like
carry_out => carry_out_unused678,
and leave that unconnected. Then the false alarm is obvious at first glance.
regards, Gerhard
Article: 106306
Hi,
different errors, have a close look at the following corrected code:
library ieee;
use ieee.std_logic_1164.all;
entity mux is
port(a,b:IN std_logic_vector(7 downto 0);
sel:IN std_logic_vector(1 downto 0);
c : OUT std_logic_vector(7 downto 0));
end mux;
architecture example of mux is
begin
process(a,b,sel)
begin
if(sel = "00") then
c <= "00000000";
elsif (sel = "01") then
c <= a;
elsif (sel = "10") then
c <= b;
else
c <= (OTHERS => 'Z');
end if;
end process;
end example;
----------------------------------------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity tb_mux is
end entity;
architecture testbench of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel : std_logic_vector(1 downto 0);
component mux is
port(a,b : in std_logic_vector(7 downto 0);
sel : in std_logic_vector(1 downto 0);
c : out std_logic_vector(7 downto 0));
end component;
begin
M1:mux port map(a,b,sel,c);
process
begin
a <= X"11" after 1 ns,
X"AF" after 2 ns,
X"BB" after 3 ns,
X"6F" after 4 ns;
b <= X"01" after 1 ns,
X"2F" after 2 ns,
X"3C" after 3 ns,
X"BE" after 4 ns;
sel <= B"00" after 1 ns,
B"01" after 2 ns,
B"10" after 3 ns,
B"11" after 4 ns;
wait;
end process;
end testbench;
Article: 106307
Hi,
This is regarding synthesis of code on ISE 7.
II have a design that I want to run on spartan 3, 400K gate FPGA. It
has taken 65% of total slices. The synthesis, and PAR options are set
to default, no high effort levels are set.
The issue is every time I do the place and route the Post place and
route simulation results are different. One of the two state machines
hangup. I'm not getting the possible reason for this.
Could you please help me in solving this?
Thanks and Regards,
Srikanth
Article: 106308> > The issue is every time I do the place and route the Post place and > route simulation results are different. One of the two state machines > hangup. I'm not getting the possible reason for this. > Take a look at the timing analysis report that pops out of the place and route. Odds are that you're violating the timing in the simulation in one of two ways: - Clock(s) are running faster in simulation than the place and route report says is acceptable (i.e. sim runs at 50 MHz, but the timing report says that the best it can do is 10 MHz) - Setup times on input pins are being violated. Again the timing report out of place and route will tell you what the setup time for each pin is relative to whatever clock signal it is referenced to. If your simulation model does not adhere to this (i.e. maybe inputs are changing just prior to the rising edge of the clock) than you won't simulate correctly. Bottom line is to do timing analysis first and then make sure that the simulation model that surrounds the design does not violate those timing constraints. KJArticle: 106309
This is an issue with ISE that tries to be too smart about related clocks, i.e. clocks derived from the same source. I'm guessing that your two clocks are related via a DCM? You can add a FROM TO style of timespec calling out the two clocks and give it a sufficiently large value that these cross-clock paths are essentially ignored. something like (in the .ucf file): NET "fx_clk" TNM="FastFlops"; NET "CLK_OSC" TNM="SlowFlops"; TIMESPEC "TS_fastslow"=FROM "SlowFlops" TO "FastFlops" 15 ns; Brandon Jasionowski wrote: > I am having a hard time getting ISE/XST to ignore clock skew between > two clock domains from an asychronous FIFO generated from CoreGen. Why > is the tool not ignoring this automatically? Here is the error after > Map: > > <SNIP> > ================================================================================ > Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB > HIGH 50%; > > 1681 items analyzed, 26 timing errors detected. (26 setup errors, 0 > hold errors) > Minimum period is 3892.500ns. > -------------------------------------------------------------------------------- > Slack: -1.036ns (requirement - (data path - clock path > skew + uncertainty)) > Source: > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF) > Destination: > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF) > Requirement: 0.002ns > Data Path Delay: 1.038ns (Levels of Logic = 0) > Clock Path Skew: 0.000ns > Source Clock: fx_clk rising at 9607.498ns > Destination Clock: CLK_OSC rising at 9607.500ns > Clock Uncertainty: 0.000ns > Timing Improvement Wizard > Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tcko 0.568 > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 > net (fanout=1) e 0.100 > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8> > Tdick 0.370 > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 > ---------------------------- --------------------------- > Total 1.038ns (0.938ns logic, 0.100ns route) > (90.4% logic, 9.6% route) > </SNIP> > > I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns > clock on the read port. I have a TIG setup as follows: > > <SNIP> > NET "CLK1_FB" TNM_NET = "CLK1_FB"; > TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %; > PIN "U0_DCM.CLK0" TNM = "DCM_CLK0"; > PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX"; > TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG; > #Asynch FIFO clock domains > </SNIP> > > CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any > ideas? I'm lost.... > > Thx, > -BrandonArticle: 106310
Be careful with timespec like this, you may include a lot of paths that are important to you. I was never successful in fixing this problem and Xilinx was no help either. On Fri, 11 Aug 2006 06:01:51 -0700, Gabor wrote: > This is an issue with ISE that tries to be too smart about related > clocks, i.e. clocks derived from the same source. I'm guessing that > your two clocks are related via a DCM? > > You can add a FROM TO style of timespec calling out the two > clocks and give it a sufficiently large value that these cross-clock > paths are essentially ignored. > > something like (in the .ucf file): > NET "fx_clk" TNM="FastFlops"; > NET "CLK_OSC" TNM="SlowFlops"; > TIMESPEC "TS_fastslow"=FROM "SlowFlops" TO "FastFlops" 15 ns; > > > Brandon Jasionowski wrote: >> I am having a hard time getting ISE/XST to ignore clock skew between >> two clock domains from an asychronous FIFO generated from CoreGen. Why >> is the tool not ignoring this automatically? Here is the error after >> Map: >> >> <SNIP> >> ================================================================================ >> Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB >> HIGH 50%; >> >> 1681 items analyzed, 26 timing errors detected. (26 setup errors, 0 >> hold errors) >> Minimum period is 3892.500ns. >> -------------------------------------------------------------------------------- >> Slack: -1.036ns (requirement - (data path - clock path >> skew + uncertainty)) >> Source: >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF) >> Destination: >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF) >> Requirement: 0.002ns >> Data Path Delay: 1.038ns (Levels of Logic = 0) >> Clock Path Skew: 0.000ns >> Source Clock: fx_clk rising at 9607.498ns >> Destination Clock: CLK_OSC rising at 9607.500ns >> Clock Uncertainty: 0.000ns >> Timing Improvement Wizard >> Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 >> Delay type Delay(ns) Logical Resource(s) >> ---------------------------- ------------------- >> Tcko 0.568 >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 >> net (fanout=1) e 0.100 >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8> >> Tdick 0.370 >> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 >> ---------------------------- --------------------------- >> Total 1.038ns (0.938ns logic, 0.100ns route) >> (90.4% logic, 9.6% route) >> </SNIP> >> >> I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns >> clock on the read port. I have a TIG setup as follows: >> >> <SNIP> >> NET "CLK1_FB" TNM_NET = "CLK1_FB"; >> TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %; >> PIN "U0_DCM.CLK0" TNM = "DCM_CLK0"; >> PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX"; >> TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG; >> #Asynch FIFO clock domains >> </SNIP> >> >> CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any >> ideas? I'm lost.... >> >> Thx, >> -BrandonArticle: 106311
Hello,
Could someone here explain how to do the above. I have been
regularly using only the Modelsim MXE versions for Xilinx ISE and
invoking the simulation was very easy because it was done through the
GUI.
But my gatelevel simulations run very slow and i want use Cadence
NcSim for that. I am not very friendly with NcSim and therefore would
request some one to guide me how to proceed in a very simple way.
Thanks in advance.
Regards,
Anil
Article: 106312PeterC wrote: > I have two clocks which are relatively synchronous (ie. the frequencies > are exactly the same because the originate from the same master clock), > but one of the clocks is shifted in phase, and this phase shift is > dynamically variable and may be up to one whole period. > > I need to switch between these two clocks, but without losing rising > edges. From my experiments with BUFGMUXs, I appear to be losing a > rising edge (post PAR timing simulation). > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > to be lost. Peter writes "Any clock-switching starts when the > originally selected clock goes Low, and the Output Clock then stays Low > until the newly selected clock has first gone Low and then High again." > > I realize that asynchronous clock multiplexing has been covered many > times in the group, but I simply can't find a good solution to my > specific problem. How "short" a clock period can you tolerate from the clock switching hardware? How long can you wait before a missing clock is stuffed back in?Article: 106313
On Wed, 09 Aug 2006 01:17:04 -0700, vit.matteo wrote: > Peter C. Wallace ha scritto: > >> On Mon, 07 Aug 2006 16:26:36 -0700, fpgakid@gmail.com wrote: >> >> > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux >> > >> > Following cables are supported: >> > >> > Parallel III >> > Digilent USB (on Linux it needs libusb, Win32 needs the original >> > driver from digilent, utilizes full USB transfer speed!) >> > >> > >> Could it support the FTDI-2232? > > If you need support for FTDI-2232 i wrote a porting for Jamplayer. I > think you can use it with Xilinx devices. You can find it here > > http://teoscorner.byethost6.com/?page_id=6 > > Matteo Thanks, I'll give it a try Would you like a proto FTDI2232-JTAG card? (USB --> JTAG + PIO 1.6 to 5V (or 1.2 to 3.3V) JTAG signals EJTAG pinout) Peter WallaceArticle: 106314
homoalteraiensis wrote: > > deriving the SCLK from the LSB of a counter in the FPGA. But this isn't > > working. > > > Did you succed now with the design? Did you try the DDR architecture > (assuming full fpga clock speed is needed here ?) homoalteraiensis, the design is working now. Not sure why. I haven't changed anything major so possibly had to do with incorrect setup. Sorry, I didn't try your suggestion because I'm afraid I didn't quite understand it, but thanks for your advice. KiArticle: 106315
Hi V4FX Linux 2.6 by end of Aug 2006 MB uClinux 2.6 by Dec 6 2006 by http://www.lynuxworks.com both will be pushed to open/GPL linux tree thats the current schedule from Xilinx --- for those who are interested then the new ver 5 MicroBlaze is fully compatible to ver 4 - I have tested with "old" uClinux 2.4.x images they run succesfully in MicroBlaze v5 based systems (in Virtex-4 targets). Official support for Virtex-5 MicroBlaze (ver 5) will be included in EDK 8.2 SP2 Xilant XSIM simulator supporting MicroBlaze (and capable to run different uClinux versions) will shortly be available (Xilinx VP simulator currently does not succesfully boot uclinux). Antti Lukats http://xilant.com PS Our rootserver had to be reformatted. I wish I would know who arranged that. Somebody must have been really angry, the attack was pretty mercyless.Article: 106316
Hello . I made the corrections as suggested. I used the library and the use clauses before each entity declaration and also took care of the component error as mentioned. Now the only error I get is that it says that "Enumeration literal 'Z' is not of type std_logic_vector." and the compiler exits. The 'others' clause assigns each element of the array to Z which is of type std_logic and the array C is indeed an array of std_logic elements. So why is the compiler flagging an error. Hope to hear from you. Best Regards, Aijaz Baig. ALuPin@web.de wrote: > Hi, > > different errors, have a close look at the following corrected code: > > library ieee; > use ieee.std_logic_1164.all; > > > entity mux is > port(a,b:IN std_logic_vector(7 downto 0); > sel:IN std_logic_vector(1 downto 0); > c : OUT std_logic_vector(7 downto 0)); > end mux; > > > architecture example of mux is > begin > process(a,b,sel) > begin > if(sel = "00") then > c <= "00000000"; > elsif (sel = "01") then > c <= a; > elsif (sel = "10") then > c <= b; > else > c <= (OTHERS => 'Z'); > end if; > end process; > end example; > > > > > ---------------------------------------------------------------------------------------------------------------- > > library ieee; > use ieee.std_logic_1164.all; > > entity tb_mux is > end entity; > > > architecture testbench of tb_mux is > signal a,b,c : std_logic_vector(7 downto 0); > signal sel : std_logic_vector(1 downto 0); > component mux is > port(a,b : in std_logic_vector(7 downto 0); > sel : in std_logic_vector(1 downto 0); > c : out std_logic_vector(7 downto 0)); > end component; > > begin > M1:mux port map(a,b,sel,c); > process > begin > a <= X"11" after 1 ns, > X"AF" after 2 ns, > X"BB" after 3 ns, > X"6F" after 4 ns; > > > b <= X"01" after 1 ns, > X"2F" after 2 ns, > X"3C" after 3 ns, > X"BE" after 4 ns; > > > sel <= B"00" after 1 ns, > B"01" after 2 ns, > B"10" after 3 ns, > B"11" after 4 ns; > wait; > end process; > end testbench;Article: 106317
Correct. I'm using the CLK0 and CLKFX outputs from the same DCM. The prior is writing, the latter is reading from the asynch FIFO. Oh well, this is a pain. Maybe I can find something better, or just assume it works. Gabor wrote: > This is an issue with ISE that tries to be too smart about related > clocks, i.e. clocks derived from the same source. I'm guessing that > your two clocks are related via a DCM? > > You can add a FROM TO style of timespec calling out the two > clocks and give it a sufficiently large value that these cross-clock > paths are essentially ignored. > > something like (in the .ucf file): > NET "fx_clk" TNM="FastFlops"; > NET "CLK_OSC" TNM="SlowFlops"; > TIMESPEC "TS_fastslow"=FROM "SlowFlops" TO "FastFlops" 15 ns; > > > Brandon Jasionowski wrote: > > I am having a hard time getting ISE/XST to ignore clock skew between > > two clock domains from an asychronous FIFO generated from CoreGen. Why > > is the tool not ignoring this automatically? Here is the error after > > Map: > > > > <SNIP> > > ================================================================================ > > Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB > > HIGH 50%; > > > > 1681 items analyzed, 26 timing errors detected. (26 setup errors, 0 > > hold errors) > > Minimum period is 3892.500ns. > > -------------------------------------------------------------------------------- > > Slack: -1.036ns (requirement - (data path - clock path > > skew + uncertainty)) > > Source: > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF) > > Destination: > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF) > > Requirement: 0.002ns > > Data Path Delay: 1.038ns (Levels of Logic = 0) > > Clock Path Skew: 0.000ns > > Source Clock: fx_clk rising at 9607.498ns > > Destination Clock: CLK_OSC rising at 9607.500ns > > Clock Uncertainty: 0.000ns > > Timing Improvement Wizard > > Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 > > Delay type Delay(ns) Logical Resource(s) > > ---------------------------- ------------------- > > Tcko 0.568 > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 > > net (fanout=1) e 0.100 > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8> > > Tdick 0.370 > > fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 > > ---------------------------- --------------------------- > > Total 1.038ns (0.938ns logic, 0.100ns route) > > (90.4% logic, 9.6% route) > > </SNIP> > > > > I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns > > clock on the read port. I have a TIG setup as follows: > > > > <SNIP> > > NET "CLK1_FB" TNM_NET = "CLK1_FB"; > > TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %; > > PIN "U0_DCM.CLK0" TNM = "DCM_CLK0"; > > PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX"; > > TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG; > > #Asynch FIFO clock domains > > </SNIP> > > > > CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any > > ideas? I'm lost.... > > > > Thx, > > -BrandonArticle: 106318
John_H wrote: > rickman wrote: > > I don't agree. By ignoring the signal for 2 clock edges, you are > > actually delaying by up to 3 clock edges. You may have just missed > > catching the transition on edge 1, then you wait until edge 2 and 3. > > So the jitter in the measurement will put you (worst case) right at the > > next transition on your input signal and you may just miss that. If > > all clocks were perfect and there was no worry about transition timing > > on the edges, etc, then yes, I would agree you could do it with 3 > > clocks. But in the real world with imperfect clocks and signals you > > can miss an edge when the timing is [borderline]. > > <snip> > While the specific approach about a digital differentiator and looking > at specific samples relative to an input stream ignored by a few cycles > may be confusing, if you don't wait to acquire the signals but analyze > what you got, the concept flows. > _____ > > If you can find a sampling such that you can guarantee at least one > unambiguous sample in any half bit period - including jitter - then you > can recover the data. The worst case for the 3x clock is when one clock > samples midpoint of one half-bit section of the data leasing the front > and back edges of the next half bit perilously close the the edges. > > (view in fixed space font:) > __ _____ __ > __/ \_____/__ > Sample Points ^ ^ ^ ^ I don't agree that this is the worst case. The worst case is when the transition of the signal is at the same time as the clock edge. The signal can be sampled either in the leading or the trailing state. So the edge might be sampled right at the edge or 1/3 of the way into the bit time (2/3 of the first half of the bit). Your decoder has to sample either 0, 1 or 2 clocks after the edge is detected. It then has to wait a defined number of clocks before it recognizes another edge. This is to prevent the detection of the edges that can occur between bit times. If you select 1 clock for the lock out, the worst case is when you detect the mid-bit edge as soon as it happens. Then the lock out is too short. If you wait 2 clocks after detecting the mid-bit edge the worst case is when the edge is just missed by a clock and is not detected until the next clock. Then waiting 2 more clocks puts you at the middle of the next bit and the slightest amount of jitter will cause you to miss the mid-bit edge. So any amout of jitter will cause failures with a 3x clock. You can use a 3.1x clock and will have less margin (0.06 clock periods) at the one extreme and 0.1 clock period margin at the other. But a 3x clock is not workable. > Depending on the jitter it might not work but the sample points are 1/12 > of a full bit period from the data transition. If one of the sample > points is on the hairy edge, the value *will* stabilize through standard > handling of asynchronous signals. The problem is not that the signal becomes metastable, the problem is when *both* the edge detection and the next edge detection are close to metastable. Then you can miss an edge because of even microscopic amounts of jitter. > The minimum sampling frequency for guaranteed operation is determined by > the minimum pulse width (less than half a bit period) degraded by the > jitter of the edges (both leading and trailing) as well as jitter in the > sampling clock. The DCMs may produce a large amount of (calculated) > jitter that would be included in any DCM-based sampling clock analysis. > But for a 100 MB/s data rate, the 5 ns period won't be degraded *that* > much. While 300 MHz should work flawlessly, even a 250 MHz sampling > clock might work if the duty cycle is well controlled. 5 ns half > period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns > apart should hit the meat of the half period. Fractional multipliers > are just such a bother. Your statements are not supported by the facts. > Metastability windows are now sub-picosecond so all that needs to be > worried about is standard synchronization for those one in a million > events that happen once every 5 seconds at 2x 100 MB/s. I agree that the metastability windows are small. But metastability has nothing to do with this analysis. I brought it up to show that the difference between an edge being detected in this clock cycle and the next is a very small amount of time and much smaller than the jitter in a typical clocked system. > Sample everything, let the logic figure it out. Don't they use that logic in the Rangers? > The clock is extracted from the data rather than the data extracted from > the clock. > > There's even a Xilinx app note that describes how to extract data from > wide busses above 600 MB/s without rocket I/O. There's no 1.5x clock > available at those rates! Please tell how they do it! Here are two example bit streams that I collected from my white board. Please decode them for me and explain the algorithm you used. Each one is clocked at 3x the bit rate... 0001101110010000 0000101111010000 An algorithm should be able to correctly decode these streams.Article: 106319
I was posting to the thread on the embedded clock in a Manchester encoded bit stream and realized that the clock is not truely embedded in the data stream. I say this because you still have to know the clock rate in order for it to work. The decoder has to lock out the edge detection for the time between bits to prevent detecting false bits. You have to know the data rate in order to time this lock out period. Of course the timing is much less critical than a typical clock, even an RC clock. But none the less you have to have a clock of a given frequency. Are there any methods of transmitting data and clock on a single wire that do not rely on the decoder having knowlege of the clock rate. This is not entirely academic. I have an interface I am working on where I need to multiplex multiple signals over a single pin. One is a serial bus and the others are discrete pins which require very accurate timing. Idealy the decoder would not have a clock, but rather the data would be self clocking. I would like to use a very low power CPLD that could be powered by either the signal or at least only require a few mA of current from an LDO on the battery connection. Is self clocking on a single pin possible? I am thinking that the extra info has to be presented in some manner that requires either a timing or amplitude measurement.Article: 106320
rickman wrote: > I was posting to the thread on the embedded clock in a Manchester > encoded bit stream and realized that the clock is not truely embedded > in the data stream. I say this because you still have to know the > clock rate in order for it to work. The decoder has to lock out the > edge detection for the time between bits to prevent detecting false > bits. You have to know the data rate in order to time this lock out > period. Of course the timing is much less critical than a typical > clock, even an RC clock. But none the less you have to have a clock of > a given frequency. > > Are there any methods of transmitting data and clock on a single wire > that do not rely on the decoder having knowlege of the clock rate. > This is not entirely academic. I have an interface I am working on > where I need to multiplex multiple signals over a single pin. One is a > serial bus and the others are discrete pins which require very accurate > timing. Idealy the decoder would not have a clock, but rather the data > would be self clocking. I would like to use a very low power CPLD that > could be powered by either the signal or at least only require a few mA > of current from an LDO on the battery connection. > > Is self clocking on a single pin possible? I am thinking that the > extra info has to be presented in some manner that requires either a > timing or amplitude measurement. You do not have to know (except to within a very broad range) the clock rate for a manchester encoded (or many other techniques) to lock up to it. A Manchester encoded stream is guaranteed a transition every bit, and two transitions per bit for a logical 1 (some schemes did this for zero instead). That means the minimum transition rate on the line is clk/2 [zero bits] and for (statistically) 50% of the time, clk * 2 [ 1 bits]. Obviously, that means that *on average*, the transition rate of the line is the clock rate. This requires the loop filter of the PLL/DLL to be appropriately set, but within a pretty wide margin. Self clocking schemes abound, some with inherently wider bandwidths than others, although the issue is more usually the application than the technique. What was the application (clock rate variation in particular)? We may be able to suggest a suitable technique. Cheers PeteSArticle: 106321
PeteS wrote: > rickman wrote: > > I was posting to the thread on the embedded clock in a Manchester > > encoded bit stream and realized that the clock is not truely embedded > > in the data stream. I say this because you still have to know the > > clock rate in order for it to work. The decoder has to lock out the > > edge detection for the time between bits to prevent detecting false > > bits. You have to know the data rate in order to time this lock out > > period. Of course the timing is much less critical than a typical > > clock, even an RC clock. But none the less you have to have a clock of > > a given frequency. > > > > Are there any methods of transmitting data and clock on a single wire > > that do not rely on the decoder having knowlege of the clock rate. > > This is not entirely academic. I have an interface I am working on > > where I need to multiplex multiple signals over a single pin. One is a > > serial bus and the others are discrete pins which require very accurate > > timing. Idealy the decoder would not have a clock, but rather the data > > would be self clocking. I would like to use a very low power CPLD that > > could be powered by either the signal or at least only require a few mA > > of current from an LDO on the battery connection. > > > > Is self clocking on a single pin possible? I am thinking that the > > extra info has to be presented in some manner that requires either a > > timing or amplitude measurement. > > You do not have to know (except to within a very broad range) the clock > rate for a manchester encoded (or many other techniques) to lock up to > it. > > A Manchester encoded stream is guaranteed a transition every bit, and > two transitions per bit for a logical 1 (some schemes did this for zero > instead). > > That means the minimum transition rate on the line is clk/2 [zero bits] > and for (statistically) 50% of the time, clk * 2 [ 1 bits]. Obviously, > that means that *on average*, the transition rate of the line is the > clock rate. This requires the loop filter of the PLL/DLL to be > appropriately set, but within a pretty wide margin. > > Self clocking schemes abound, some with inherently wider bandwidths > than others, although the issue is more usually the application than > the technique. > > What was the application (clock rate variation in particular)? We may > be able to suggest a suitable technique. > > Cheers > > PeteS I'll correct my own mistake: (Blame the cold ;) For 50% of the time in a manchester encoded sheme, the transition rate is clk/2 and for 50% it's clk. By setting the loop filter at 3/4 clock (or even 5/8) we can lock in on the clock quite easily. (Nowadays - when it was first invented, it was quite a breakthrough and not easy at all). Certainly there are schemes that are wider band - 8b/10b encoding comes to mind for instance. Cheers PeteSArticle: 106322
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1155322803.697990.219990@i42g2000cwa.googlegroups.com... > John_H wrote: >> If you can find a sampling such that you can guarantee at least one >> unambiguous sample in any half bit period - including jitter - then you >> can recover the data. The worst case for the 3x clock is when one clock >> samples midpoint of one half-bit section of the data leasing the front >> and back edges of the next half bit perilously close the the edges. >> >> (view in fixed space font:) >> __ _____ __ >> __/ \_____/__ >> Sample Points ^ ^ ^ ^ > > I don't agree that this is the worst case. The worst case is when the > transition of the signal is at the same time as the clock edge. The > signal can be sampled either in the leading or the trailing state. So > the edge might be sampled right at the edge or 1/3 of the way into the > bit time (2/3 of the first half of the bit). Your decoder has to > sample either 0, 1 or 2 clocks after the edge is detected. It then has > to wait a defined number of clocks before it recognizes another edge. > This is to prevent the detection of the edges that can occur between > bit times. If you select 1 clock for the lock out, the worst case is > when you detect the mid-bit edge as soon as it happens. Then the lock > out is too short. If you wait 2 clocks after detecting the mid-bit > edge the worst case is when the edge is just missed by a clock and is > not detected until the next clock. Then waiting 2 more clocks puts you > at the middle of the next bit and the slightest amount of jitter will > cause you to miss the mid-bit edge. Detection of edges that can occur between bit times was not understood (by me) as a necessary condition for manchester decoding. If this is the case, the situation is more difficult. If the requirement did not include glitch filtering (as should be the case for 100 Mbit/s chanchester encoding) then sampling at the edge would leave the samples on either side fully 1/3 into the half bit period; only the edge sample would be ambiguous and would either widen the previous half bit or the next one in the new timing domain. Jitter is not an issue. Glitches are an issue. If the logic levels are well behaved, my suggestions should hold. If the logic levels are not well behaved, it appears that finding and holding on to error-free manchester decoded data is an elusive task. > So any amout of jitter will cause failures with a 3x clock. You can > use a 3.1x clock and will have less margin (0.06 clock periods) at the > one extreme and 0.1 clock period margin at the other. But a 3x clock > is not workable. > > >> Depending on the jitter it might not work but the sample points are 1/12 >> of a full bit period from the data transition. If one of the sample >> points is on the hairy edge, the value *will* stabilize through standard >> handling of asynchronous signals. > > The problem is not that the signal becomes metastable, the problem is > when *both* the edge detection and the next edge detection are close to > metastable. Then you can miss an edge because of even microscopic > amounts of jitter. If you aren't dealing with edge detection but sample the signals and let any metastability settle out first. Edge detection is done on this data. The constraint is that the smallest half period degraded by both the transmit jitter and the receive clock jitter MUST be less than the sampling period, adjusting for the sub-picosecond metastability window (which is less than any jitter consideration). >> The minimum sampling frequency for guaranteed operation is determined by >> the minimum pulse width (less than half a bit period) degraded by the >> jitter of the edges (both leading and trailing) as well as jitter in the >> sampling clock. The DCMs may produce a large amount of (calculated) >> jitter that would be included in any DCM-based sampling clock analysis. >> But for a 100 MB/s data rate, the 5 ns period won't be degraded *that* >> much. While 300 MHz should work flawlessly, even a 250 MHz sampling >> clock might work if the duty cycle is well controlled. 5 ns half >> period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns >> apart should hit the meat of the half period. Fractional multipliers >> are just such a bother. > > Your statements are not supported by the facts. If there are glitches sampled in either half, you are correct that my statements are not supported by facts. If the signal is well behaved though degraded by jitter and duty cycle I stand by my understanding of sampling theory to suggest that I am correct. As long as you can get one unambiguous sample of the half period, you can extract the original data stream. Understanding when two samples are both the same half period versus two half periods from adjoining bits is where a tracking NCO or similar clock extraction is needed. If there is no NCO, just the immediate neighborhood of a few samples, then no - unambiguous decoding is not possible at 2.5x rates. >> Metastability windows are now sub-picosecond so all that needs to be >> worried about is standard synchronization for those one in a million >> events that happen once every 5 seconds at 2x 100 MB/s. > > I agree that the metastability windows are small. But metastability > has nothing to do with this analysis. I brought it up to show that the > difference between an edge being detected in this clock cycle and the > next is a very small amount of time and much smaller than the jitter in > a typical clocked system. The difference of being on one side of the metastability window or the other is having one more sample in one half the bit period or the other. The edge detection is just moved by one sample, not ignored entirely. >> Sample everything, let the logic figure it out. > > Don't they use that logic in the Rangers? > > >> The clock is extracted from the data rather than the data extracted from >> the clock. >> >> There's even a Xilinx app note that describes how to extract data from >> wide busses above 600 MB/s without rocket I/O. There's no 1.5x clock >> available at those rates! > > Please tell how they do it! http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf > Here are two example bit streams that I collected from my white board. > Please decode them for me and explain the algorithm you used. Each one > is clocked at 3x the bit rate... > > 0001101110010000 > 0000101111010000 > > An algorithm should be able to correctly decode these streams. With this small sequence of bits, unambiguous decoding is still available 0001101110010000 10 01 01 10 10 01 1 0 0 1 1 0 0000101111010000 10 01 01 10 10 01 1 0 0 1 1 0 The half bit perios are always identified by a 101 or a 010. The half bit periods from two adjecent bits are always identified by 111 or 000. On average, the bit rate is two half-bit pairs every three clocks. Q.E.D. yet?Article: 106323
"John_H" <newsgroup@johnhandwork.com> wrote in message news:Iu5Dg.7581$Oh1.4082@news01.roc.ny... > 0001101110010000 > 10 01 01 10 10 01 > 1 0 0 1 1 0 > > 0000101111010000 > 10 01 01 10 10 01 > 1 0 0 1 1 0 I may have inverted my single-bit results. It looks like manchester has the logic level in the second half of the bit, not the first like I thought. I checked wikipedia.org and saw my inversion, otherwise the idea still holds. Without knowing the clock rate, Manchester encoding has pulses that are either 1/2 bit period or 1 whole bit period. You should get two tight ranges of count values that correspond to these intervals. In the 3x clock case, those two ranges overlap. It's knowing when the half bit periods are definitely half or whole bit periods that the alignment can be determined and the frequency extracted without ambiguity.Article: 106324
Antti wrote: > Hi > > V4FX Linux 2.6 by end of Aug 2006 > MB uClinux 2.6 by Dec 6 2006 > by > http://www.lynuxworks.com > both will be pushed to open/GPL linux tree > > thats the current schedule from Xilinx > > --- > for those who are interested then the new ver 5 MicroBlaze is fully > compatible to ver 4 - I have tested with "old" uClinux 2.4.x images > they run succesfully in MicroBlaze v5 based systems (in Virtex-4 > targets). > > Official support for Virtex-5 MicroBlaze (ver 5) will be included in > EDK 8.2 SP2 > > Xilant XSIM simulator supporting MicroBlaze (and capable to run > different uClinux versions) will shortly be available (Xilinx VP > simulator currently does not succesfully boot uclinux). Thanks Antti. Any info on what has changed in V5 MB ? ( or is V5 just a tweak to have a compile-time variant that runs better on the V5 silicon ? ) Do you know if WebPACK users will be able to evaluate this, at least on V4 silicon ? [I guess not on V5 silicon, as WebPACK specifically excludes that ?] -jg
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