Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 89775

Article: 89775
Subject: Re: Xilinx Spartan-3
From: "Brian Davis" <brimdavis@aol.com>
Date: 26 Sep 2005 05:56:30 -0700
Links: << >>  << T >>  << A >>
Alvin,
>
> Normally, you houldn't neeed the divide by 2 and cable stub: just use the
> fact that DCMs align to the rising edge and use their CLK180 to clock your
> data in.

 Without the divide by two to strip the phase modulation, I think the
duty cycle variation might drive the DCM's batty, as it's well outside
the allowed DCM input clock duty cycle and cycle-cycle jitter specs.

Brian


Article: 89776
Subject: Re: Question on Metastability
From: "Gabor" <gabor@alacron.com>
Date: 26 Sep 2005 07:06:33 -0700
Links: << >>  << T >>  << A >>

GPE wrote:
> But - I have an oddball case of a clock.  One always runs at 1Khz.  The
> other *May* run as fast as 100MHz but usually runs slower -- sometimes as
> slow as 100Hz.  If I knew my variable clock was always fater than the 1KHz
> clock, the edge detection would work fine.
>
> Incidently, I already have a circuit similar to what you have in one of my
> other designs which does have a guaranteed fast clock.
>
> Thanks,
> Ed
>
> "Stephan Flock" <sflock@freenet.de> wrote in message
> news:dh354s$gcu$03$1@news.t-online.com...
> > You could run both your 32-bit counter and the other set of registers off
> > a
> > fast (e. g. 100 MHz) clock. Detect the edge of the 1 kHz counter clock
> > signal and make it a clock enable for the counter together with the 100
> > MHz
> > clock.
> >
> > HTH,
> > Stephan
> >
> >

The obvious solution would be to use a third clock of known higher
frequency.  If this isn't avaliable, you could add hardware to detect
which clock is running faster, but that may be more work than it's
worth, especially if your variable rate clock changes frequently.

This would be a good time to add 2 cents worth on the virtues of
having a free-running clock in an FPGA (as were in early Xilinx
parts).  Many newer parts have internal oscillators for configuration
but the clocks aren't available to the routing fabric.  I've seen
some threads here about building oscillators in the FPGA from
internal LUT delays and the like.  I wouldn't like to depend on that
sort of design due to variances in process and temperature.  For
future designs, however I would suggest always having a fixed clock
of sufficient frequency to feed a DLL (unless you can't afford the
crystal which would be unusual in most designs containing an FPGA).

Regards,
Gabor


Article: 89777
Subject: Re: Xilinx PAR -- WARNING:Route - CLK Net may have excessive skew...
From: "Gabor" <gabor@alacron.com>
Date: 26 Sep 2005 07:16:17 -0700
Links: << >>  << T >>  << A >>

Julian Kain wrote:
> Greetings,
>
> I am implementing a design whose system clock is generated by an MGT
> (the TXOUTCLK pin), based on higher frequency differential reference
> clock inputs to that MGT. The frequency generated at TXOUTCLK is
> correct, but the issue is that Xilinx ISE (7.1i, SP4) does not route
> this clock as a CLK Net.
>
> The particular error, generated after PAR, is "WARNING:Route - CLK Net:
> net_name may have excessive skew because xx NON-CLK pins failed to
> route using a CLK template."
>

This error message usually means there are non-clock loads in the
design.  This can happen when the clock signal is used as a gate
(LUT) input.  Normally in a fully synchronous design only clock
or latch gate inputs of the CLB or IOB would connect to the clock
route.

If you have the FPGA editor I would suggest looking at the post
place-and-route design and see how the clock was actually routed.
If it uses global resources for all of the clock loads and only
local resources for gated loads you may actually have lower skew
to the important loads than reported.  If you are actually gating
this clock to deliver to some clocked loads, you should try to
change the design to use clock enables rather than gated clocking.

> This design cannot tolerate the max skew that is reported (about 20% of
> a period), or the resulting max delay of about 40%. How can I force
> this net to use the CLK template I specified in the UCF, or otherwise
> remedy this issue?
> 
> Thanks much,
> Julian Kain


Article: 89778
Subject: Re: C-to-gates experiences
From: "fortiz80@gmail.com" <fortiz80@gmail.com>
Date: 26 Sep 2005 07:28:38 -0700
Links: << >>  << T >>  << A >>
IMHO another big issue with "compiler" approaches is memory management.
 Given the variety and flexibility available in hardware, it is very
hard to determine the right memory organization and chaching strategy.
Significant performance losses would follow in memory-bound
applications.


Article: 89779
Subject: ALTERA quartus II 5.0sp1 web edition can't program MAXII: error code 84
From: VAX9000@gmail.com
Date: 26 Sep 2005 07:37:20 -0700
Links: << >>  << T >>  << A >>
Hi group,
  I am trying to download the design compiled with quartus II 5.0sp1
web edition into MAX II chip EPM1270T144C5. However, quartus programmer
complained
"Error: Unexpected error in JTAG server -- error code 84"
I used the same MAXII board, cable (JTAG from parallel port) and
computer days ago with quartus II 4.2 web edition and had no problem to
download. Unfortunately I deleted quartus 4.2 web edition. Can anybody
tell me what this error code 84 is? I googled but get no answer. Thank
you!

vax, 9000


Article: 89780
Subject: Re: jbits & reverse engineering
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Sep 2005 08:02:53 -0700
Links: << >>  << T >>  << A >>
Adam,

It was pointed out to me the other day, that Neocad reverse engineered 
bitgen.  They never reverse engineered the bitstream (had no idea what 
controlled what).

Folks are ofthen fond of saying "there is no security in obscurity" but 
then they do not have to search for a needle in a haystack.

Keeping the bitstream secret is still a powerful means of preventing 
reverse engineering.

Lately I asked a well know reverse engineering firm to do their job, and 
tell me what the design was given only the bitstream.

They no bid the job "as we felt it would take to long, and cost too 
much."  That definitely surprised me, as to refuse business for 
something that is understandably long and arduous (read $$$) was a surprise.

But from their point of view, they would much rather go after something 
that was easier (cut, section, etc.) and had immediate payback.

Now it is said that governments would not be so limited (they would 
reverse engineeer a bitstream).

Very few of our customers are worried about a governement stealing their 
designs and intellectual property.  For those that are (other 
governments), we are happy to assure them that the bitstream still 
remains a secret (for what that is worth, which may in fact be a lot).

So far the 'Logic Vault' cards I have sent out to academia have not been 
able to be cracked by DPA (a commonly held belief is that differential 
power attack (DPA) is able to 'crack' 3DES or AES easily).  Seems that 
finding the keys in a smart card may be a junior EE class exercise, but 
going after something a bit more challenging (like the keys held in out 
battery backed RAM) is no easy task.

I'd like to think that it has to do with brilliant engineering, but it 
is more likely that one can not discern the information from the noise 
of all those pesky support transistors that clutter up a FPGA.

Austin

Adam Megacz wrote:

>>Some one already told me "Jbits is dead" but didn't explain why !
> 
> 
> Because http://www.megacz.com/research/bitstream.secrecy.xt
> 
>   - a
> 

Article: 89781
Subject: Xilinx XUP + Linux (firmware loading problem!)
From: "S.T." <st@iss.tu-darmstadt.de>
Date: Mon, 26 Sep 2005 17:21:26 +0200
Links: << >>  << T >>  << A >>
Hi

I have some more insights in the problem connecting a "xilinx xup virtex II
pro" board with linux: I just installed windows and ise71_4i and connected
the board. After *three* times driver installation the board worked. Then i
rebooted into linux and got impact running and identifying the chips in the
jtag chain. After that i powercycled the board loading the firmware via
linux into the board. After that the board stopped working. To double check
i booted into windows (without switching the xup board off) and got the
same problems as under linux. 

So the problem seems to be related to the firmware or the loading of the
firmware. 

It would be really nice to get a firmware which gets the XUP board working.
The revision of the board is 3 (anyone a different rev and got the board
working under linux?)

Thanks
ST

Article: 89782
Subject: Re: downlaoding bit files to Xilinx FPGA
From: "Anuja" <thakkar.anuja@gmail.com>
Date: 26 Sep 2005 08:40:09 -0700
Links: << >>  << T >>  << A >>
Can the downloading of the bit file be done w/out using an embedded
processor or EPROM/PROM as we are just trying to program the device
autonomously. This is not going into production so i dont have to worry
about loosing the configuration data in case of power loss.
Anuja


Article: 89783
Subject: vhdl state maching problem
From: "CMOS" <manusha@millenniumit.com>
Date: 26 Sep 2005 08:47:54 -0700
Links: << >>  << T >>  << A >>

following is a part of the state machine im trying to design. when
start is set to '1' it goes to rw_1. when in that state, i increment
the ram_counter_w and jumps to rw_2 , where the values of ram_counter_w
is checked. if it is "11111111111111110", i jump to rw_3 , otherwise i
come back to rw_1. The problem is i never go to rw_3. i continuously
alternate between rw_1 and rw_2. Since im very new to VHDL and FPGA
development, i cant find the problem. please someone help me.

Thank you
CMOS

---------------------------------------------------------------------


type state_type is (ready, rw_1, rw_2, rw_3);
signal state, next_state : state_type;

signal ram_counter_w	: std_logic_vector(17 downto 0);




begin



process ( state, ram_counter_w)
begin
next_state <= state;

case state is
when ready =>
	if reset = '0' and start = '1' then
		next_state <= rw_1;
	else
		ram_counter_w		<= "000000000000000000";

	end if;

when rw_1 =>
	ram_counter_w <= ram_counter_w + 1;
	next_state <= rw_2;


when rw_2 =>

	if ram_counter_w = "11111111111111110" then
		next_state <= rw_3;
	else
		next_state <=  rw_1;
	end if;

when rw_3 =>

	-- some statements...

when others =>
	-- some statements

end case;

---------------------------------------------------------------------


Article: 89784
Subject: Re: jbits & reverse engineering
From: Adam Megacz <adam@megacz.com>
Date: Mon, 26 Sep 2005 09:27:50 -0700
Links: << >>  << T >>  << A >>

Austin Lesea <austin@xilinx.com> writes:
> It was pointed out to me the other day, that Neocad reverse engineered
> bitgen.  They never reverse engineered the bitstream (had no idea what
> controlled what).

Austin, please cite a source for this.

Xilinx would have sued them halfway to the moon if their product
required "bitgen.dll" (or equivalent) from the Xilinx ISE in order to
function.  That would be clear infringement on Xilinx's copyrights and
any judge would have been more than happy to hand down an injunction
putting them out of business.

  - a



Article: 89785
Subject: Re: vhdl state maching problem
From: pinod01@sympatico.ca
Date: 26 Sep 2005 10:00:18 -0700
Links: << >>  << T >>  << A >>
My first suggestion would be to declare the counter as an integer first
so that the increment ('+') operation is more effective.  Also the you
can not use an IF statement to check a std_logic_vector since you would
need to compare every single bit.  Integer is easier to do so.

I gather this is an asynchronous state machine.  There is no process
for the clock.  In this case you would only change states during each
clock, and not on every time a bit changed as in your above example.


Article: 89786
Subject: Re: Altera_VHDL_support library into Modelsim?
From: pinod01@sympatico.ca
Date: 26 Sep 2005 10:09:18 -0700
Links: << >>  << T >>  << A >>
Just in case, I have done the following to confirm that Modelsim
guarantee's does not find the library file:

1) I inserted the altera_support_vhdl.vhd file into my Modelsim project
2) I compiled the .vhd file which created what I believe to be the
library itself into the default "work" library for my project.

3) Recompiling the SOPC.vhd file produced the same error and it says
that it still doesn't find that library.


Article: 89787
Subject: Spartan3E - problem in creating LVDS DDR pads
From: assaf_sarfati@yahoo.com
Date: 26 Sep 2005 11:48:04 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am trying to create LVDS, bidirectional, DDR I/O pads
in a Spartan-3E chip (xc3s500e).

I've created an I/O pad in VHDL which simply instatiates
and connects Xilinx library components:
 *  IOBUFDS = bidirectional, differential I/O pad,
 *  IDDR2 = S3E input DDR logic,
 *  ODDR2 = S3E output DDR logic,
Tri-State control is not DDR - I've added a simple FF
instance.

The pad matches a subset of the S3E description of the
I/O pad logic.

When I try to implement a chip using these I/O pads, the synthesis
and Translate stages complete without errors, but the Map stage
outputs the following error for each I/O Pad:

ERROR:Pack:1564 - The dual data rate register
   Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1

   failed to join the DIFFSI component as required.  Symbol
   Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1

   is not a kind of symbol that can join a DIFFSI component.

>From what I've been able to find, the DIFFSI is the "negative"
pin of the I/O pad - the I/O logic is placed at the "positive"
pad, but borrows resources from the negative pad, which can't
be used for anything else.

The error is connected to having bidirectional pads; when I used
separate input and output pads, there were no errors.

There is no difference in the errors when I place LOC constraints
on the positive, negative, both or none of the I/O pads.

The IDDR2 and ODDR2 have Generic options to control clock
alignment, some of which borrow FFs from the negative pad;
changing these Generics make no difference in the errors.

I am using ISE7.1i, SP4 (problem appeared in SP3 as well).
The Xilinx knowledge base doesn't have anything about this error.

Anyone knows what is the problem and if there is any way to
fix it? please help, I am getting pretty desperate (need to
start board layout).

        Thanks in Advance


Article: 89788
Subject: Re: vhdl state maching problem
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Mon, 26 Sep 2005 13:11:27 -0700
Links: << >>  << T >>  << A >>
Hello Manusha,

I looked over your code and ran a simulation
using the waveform tool in the Xilinx Webpack.

Some things:

1) You have no clock which is something I have
never tried. Usually, VHDL is synchronous and
you will see:

your_name : process(clk)
 begin
 if( clk'event and clk='1') then

starting most of your work.

2) You need a reset in your sensitivity list
and an end process at the end of your process.

3) After simulating your code, your process never
comes out of the the RESET state. Perhaps this
is because next_state is not in your sensitivity
list. You can try to put next_state in your sensitivity
list, instead of state, but I don't know if that will
solve your issues.

Good luck,

Brad Smallridge

P.S. Here is the code I ran:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity top is
  port(
   reset : in std_logic;
   start : in std_logic;
   state3 : out std_logic );
end top;

architecture Behavioral of top is

type state_type is (ready, rw_1, rw_2, rw_3);
signal state, next_state : state_type;

signal ram_counter_w : std_logic_vector(17 downto 0);

begin

process (reset, state, ram_counter_w)
begin
next_state <= state;
 state3<='0';

case state is
 when ready =>
  if reset = '0' and start = '1' then
   next_state <= rw_1;
  else
   ram_counter_w <= "000000000000000000";
  end if;

 when rw_1 =>
  ram_counter_w <= ram_counter_w + 1;
  next_state <= rw_2;

 when rw_2 =>
  if ram_counter_w = "11111111111111110" then
   next_state <= rw_3;
  else
   next_state <=  rw_1;
  end if;

 when rw_3 =>
  state3 <= '1';

  -- some statements...

 when others =>
  -- some statements

end case;
end process;


end Behavioral;



Article: 89789
Subject: Re: External dpram similar to blockram of Xilinx device
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 26 Sep 2005 13:15:10 -0700
Links: << >>  << T >>  << A >>
codejk wrote:

> I tried to find some external dpram chips
> for several days, but I couldn't.
> 
> The spec. of dpram which I need is:
> port a addr 10bit
> port a data 8bit
> port a we
> port a clk
> port b addr 10bit
> port b data 8bit
> port b clk
> 
> That's all.
> Could you please recommend one?

Consider using a standard RAM
and designing your own dual port
controller on the fpga.

         -- Mike Treseler

Article: 89790
Subject: Re: jbits & reverse engineering
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Sep 2005 13:38:15 -0700
Links: << >>  << T >>  << A >>
Adam,

The things you learn after you buy a company.

Personally, I think it was for the best that we purchased Neocad...

Austin

Adam Megacz wrote:

> Austin Lesea <austin@xilinx.com> writes:
> 
>>It was pointed out to me the other day, that Neocad reverse engineered
>>bitgen.  They never reverse engineered the bitstream (had no idea what
>>controlled what).
> 
> 
> Austin, please cite a source for this.
> 
> Xilinx would have sued them halfway to the moon if their product
> required "bitgen.dll" (or equivalent) from the Xilinx ISE in order to
> function.  That would be clear infringement on Xilinx's copyrights and
> any judge would have been more than happy to hand down an injunction
> putting them out of business.
> 
>   - a
> 
> 

Article: 89791
Subject: Re: Question on Metastability
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 27 Sep 2005 09:49:27 +1200
Links: << >>  << T >>  << A >>
Gabor wrote:
<snip> This would be a good time to add 2 cents worth on the virtues of
> having a free-running clock in an FPGA (as were in early Xilinx
> parts).  Many newer parts have internal oscillators for configuration
> but the clocks aren't available to the routing fabric.  I've seen
> some threads here about building oscillators in the FPGA from
> internal LUT delays and the like.  I wouldn't like to depend on that
> sort of design due to variances in process and temperature.  

However, those variances actually self-track, so a Logic Element + 
Routing  derived clock can be self-margining.

Lattice have added a usable clock to their MachXO, so this might
catch on....

> For future designs, however I would suggest always having a fixed clock
> of sufficient frequency to feed a DLL (unless you can't afford the
> crystal which would be unusual in most designs containing an FPGA).

There is another class of Osc, called the Calibrated On Chip -
these are now common in small Microcontrollers, and achieve
in the regions of 1-2-3% stability over Vcc and Temp.

Ideal would be both; The first type would be easy for the FPGA
vendors to offer as simple IP blocks, but the CalOsc is
needs special HW, and a mindset change in the FPGA sector, so
is less likely.....

-jg


Article: 89792
Subject: chipscope pro
From: "Nitesh" <nitesh.guinde@gmail.com>
Date: 26 Sep 2005 15:15:25 -0700
Links: << >>  << T >>  << A >>
I have a working design where I can see the ouput on the leds .I am
using a ML310 board .
The design doesnt seem to work when I try to load it through chipscope
pro.
When I use a ILA core into my design and try to load the design on to
the system it always says that "Waiting for Core to be armed, slow or
stopped clock":
I saw the chipscope pro answer record which says that this is due to
clock.But I am giving system clock in the core inserter  module.
Instead of system clock if I give JTAg clock as the clock in the
inserter module then the chipscope output remains static with all
constant waveforms.
Did anyone have a similar problem?
Nitesh


Article: 89793
Subject: Re: Altera_VHDL_support library into Modelsim?
From: pinod01@sympatico.ca
Date: 26 Sep 2005 16:02:52 -0700
Links: << >>  << T >>  << A >>
To all,

    I did a bit of poking around in Modelsim, and I figured it out.
Just so you know what I did to figure this out, here's the steps:

1) I copied the altera_vhdl_support.vhd file into my Modelsim directory
2) I clicked on the library tab
3) I right-clicked and selected New Library, and created a new library
called: "altera_vhdl_support"
4) In the project window I added the VHDL file for the
altera_vhdl_support and right-clicked this file, to go to the compile
properties, where I forced the compiled library into the
"altera_vhdl_support" instead of the default work directory.

Once I did this, and re-compiled the SOPC builder VHDL file, it
compiled.   I haven't tested it yet, but at least it compiled.

Cheers....


Article: 89794
Subject: Re: Question on Metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 26 Sep 2005 18:14:17 -0700
Links: << >>  << T >>  << A >>
The original question has been answeed: I still stand behind my
suggestion in #2 in this thread.
A self-contained stable oscillator is a difficult (if not impossible)
proposition. All transistor parameters have unacceptable variation over
temp, voltage, and processing. Metal resistivity and capacitance are
fairly stable, but how do you make an oscillator out of that?
Peter Alfke


Article: 89795
Subject: Re: downlaoding bit files to Xilinx FPGA
From: "Stephen Craven" <scraven@vt.edu>
Date: 26 Sep 2005 18:37:54 -0700
Links: << >>  << T >>  << A >>
If this is a Virtex part you can try using the ICAP (Internal
Configuration) Port.  This allows you to have the device configure
itself.  It does not need an embedded processor, but you have to be
careful about your bitstreams in that the new bitstream with which you
are programming the device must have the same ICAP logic in the same
location as the previous bitstream, else your configuration logic will
change mid-stream and stop reconfiguration.  You could also use partial
bitstreams to avoid overwriting the ICAP control logic.


Article: 89796
Subject: Re: Question on Metastability
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 27 Sep 2005 14:26:20 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> The original question has been answeed: I still stand behind my
> suggestion in #2 in this thread.
> A self-contained stable oscillator is a difficult (if not impossible)
> proposition. All transistor parameters have unacceptable variation over
> temp, voltage, and processing. Metal resistivity and capacitance are
> fairly stable, but how do you make an oscillator out of that?
> Peter Alfke

Depends on what you mean by stable and acceptable.

Certainly to RS232 standards is achievable today.

For some background reading, look at the Philips LPC9xx family,
and the Atmel AVR series. They have impressive On-Chip osc
performances.

Also look here (even more precise) :
http://www.maxim-ic.com/products/timers/econoscillator.cfm

they show Silicon Oscillators, spec'd to ~1%. and targeting
ceramic resonator applications.
They also have Spread spectrum Silicon oscillators.

More esoteric are the still experimental 'machined silicon' oscillators 
-  more special process handling, but precisions getting close to
low end quartz crystals.

There are many apps, where even 2% is more than precise enough,
and others where +/-20% would be fine.

-jg





Article: 89797
Subject: Re: Question on Metastability
From: "GPE" <See_my_website_for_email@cox.net>
Date: Mon, 26 Sep 2005 21:26:47 -0500
Links: << >>  << T >>  << A >>

This worked quite well.
I left my 32-bit binary counter alone (hey, I'm lazy!) -- added a binary to 
gray code converter on the output.  Registered that using a higher clock 
that was used to derive the 1KHz clock - so I get a nice, registered gray 
code.

With the higher frequency clock, I register the gray code at the required 
time interval.  Perform a gray code to binary conversion to get back to my 
original value.   Luckily, I have several clock periods worth of time to 
bring back the original binary value as this piece of the puzzle isn't real 
fast.
Now all I have left is a 1-bit ambiguity - which is quite reasonable.

Thanks,
Ed



"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1127539632.607707.192720@g44g2000cwa.googlegroups.com...
> If I understand you right, you need to copy the 32-bit counter ontent
> (which changes very slowly) into a fast-changing (fast-clocked)
> register at asynchronous times.
> I am sure that your problem is not metastability, but rather timing
> uncertainty between the 32 register bits. My suggestion is to run the
> 32-bit counter as a Gray counter. Since only one bit changes at any
> time, a not-totally-synchronous transfer never results in a serious
> error. Afterwards, you can convertthe gray code back to binary.
> Binary-to-Gray conversion uses one XOR per bit, and is very fast.
> Gray-to-binary involves a ripple chain, and may be more challenging at
> 100 MHz, but I suppose you can do it off-line. Or you pipeline the
> operation.
>
> As is often the case,,mtastabilty gets blamed here for a completely
> different (and more solvable) problem.
> Peter Alfke, Xilinx Applications
> 



Article: 89798
Subject: Re: Synchronizer Flip Flop / Metastability
From: "rhnlogic@yahoo.com" <rhnlogic@yahoo.com>
Date: 26 Sep 2005 21:11:12 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> metastability is a problem that cannot be "solved", we can only
> reduce the probability of errors due to metastability.

This certainly depends on what you mean by "solved".  Even
machines intended to be completely deterministic are built
of components which have various wear and statistical failure
mechanisms.  However, engineers usually consider the problem
solved if the MTBF of the conglomeration of gears, relays, tubes,
CMOS transistors, etc. is longer than the expected operational
life of the widget by sufficient orders of magnitude.  In that
sense, one could easily consider the metastability problem
solved when the probability of the register train not resolving
is far less than that of the device getting vaporized in a
direct meteor strike.  In which case even a CMOS NAND gate would
no longer produce the correct voltage result.

> In many cases you will find that the mean-time-betwen-failure is
> millions or billions of years.

Which means the power supply, if not electromigration, background
radiation, bonding wires, or even a meteor strike, etc., would far
more likely cause any instance of the "solved" FPGA solution to
fail even earlier.

IMHO. YMMV.
-- 
Ron
rhn A.T nicholson d.O.t C-o-M


Article: 89799
Subject: Re: "Free" core and license
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Tue, 27 Sep 2005 11:16:17 +0700
Links: << >>  << T >>  << A >>
Marco wrote:

> Hallo,
> I have used one core downloded from "opecores.org" into a project which
> will be a commercial microcotroller.
> 
> Which are the commercial conditions about selling it into the complete
> system?
> 
> Many Thanks
> Marco


Marko,

you should direct this question to the OpenCores mailing list.
Every developer is free to chose the license of his/her liking.
Try asking the developer directly.

Best Regards, 
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
****** Certified USB 2.0 HS OTG and HS Device IP Cores ******



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search