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 40675

Article: 40675
Subject: Re: cyphers
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Tue, 12 Mar 2002 15:05:18 -0600
Links: << >>  << T >>  << A >>
Drake,

You can take a look at Xilinx's  high speed DES and Triple DES app note
at http://support.xilinx.com/apps/virtexapp.htm#appnotes
This app. note also comes with both VHDL and Verilog reference designs.
If you are not concerned much about performance refer the following free
IP providers for DES  VHDL source code.
http://www.opencores.org/projects
http://www.free-ip.com/DES/index.html

For Xilinx's PCI core solution, refer http://www.xilinx.com/pci/

Hope this helps !!!


-Vikram




drake wrote:

> i am looking for VHDL to implement cryptographic cyphers in an FPGA,
> and an FPGA with a PCI interface.  does anybody have any ideas?
>
> --drake


Article: 40676
Subject: Re: cyphers
From: Andy Main <andymain@blueyonder.co.uk>
Date: Tue, 12 Mar 2002 21:27:04 GMT
Links: << >>  << T >>  << A >>
drake wrote:

> i am looking for VHDL to implement cryptographic cyphers in an FPGA,
> and an FPGA with a PCI interface.  does anybody have any ideas?
>
> --drake

www.opencores.org


Article: 40677
Subject: Re: Article in March Embedded Systems - "The Death of Hardware
From: Ray Andraka <ray@andraka.com>
Date: Tue, 12 Mar 2002 21:58:30 GMT
Links: << >>  << T >>  << A >>
The block RAMs do add a challenge, but with careful design you can get them to
run quite a bit faster than 115 MHz in a -6.  I have a -7 design where one port
(the write port at that) is running at 240 Mhz.  The -6 should be able to get
pretty close to 200 MHz...if you are really careful with the BRAMs.  AFAIK, the
rijndael algorithm doesn't use carries, so the bottle neck is going to be the
block rams.  Even at the 200 MHz, there are some tricks you can play to keep the
BRAM from being the bottleneck.



Nicholas Weaver wrote:

> In article <MNsj8.27108$af7.22802@rwcrnsc53>,
> Kevin Neilson <kevin_neilson@removethis-yahoo.com> wrote:
> >Yeah, I read this article.  It's pretty weak.  There will come a day when we
> >will write HDL at such a level of abstraction we won't even need to know
> >what a CLB looks like.  That day is a long long way off.  The tragedy is
> >that some managers believe this hype and allocate valuable resources to it,
> >ushering in a wave of weak, bloated, 50-levels-of-logic desgins.
>
> And if they don't need to worry about the bloat and slowdown, there is
> no problem.
>
> My classic example:
>
> An academic implementation of a Rijndael core relies heavily on HDL
> synthesis, and uses an 8 stage pipeline for the single round.  It ran
> at 100 MHz (according to static timing analysis) on a Virtex-6, using
> 2000 slices and 8 BlockRAMS, with expanded subkeys stored in
> Luts-as-ram.  1.2 Gbps throughput on nonfeedback modes, 150 Mbps
> throughput on feedback modes.
>
> My implementation relied heavily on hand placing and understanding the
> target architecture.  It uses a 5 stage pipeline for the single
> round.  It runs at 115 MHz (according to static timining analysis) on
> a Spartan II-5, using 800 slices and 10 BlockRAMs[1], with subkeys
> computed on the fly.  1.3 Gbps throughput on nonfeedback modes, 260
> Mbps throughput on feedback modes.  Ray Andraka probably could have
> added another 5-10% improvement [2].
>
> So, by using a synthesis methodology instead of programming to the
> device, there is an ~10% penalty in throughput on nonfeedback modes, a
> ~70% penalty in throughput on feedback modes, and a ~60% penalty on
> area.
>
> If these costs don't matter, then synthesis worked fine.  If costs
> DOES matter, then synthesis failed hideously, and someone who was
> doing this as part of a product would have to call one of the many
> FPGA expert consultants to have it done right.
>
> [1] The extra 2 BlockRAMs were for the sboxes in the
> subkey-generation.
>
> [2] Based that some of my design decisions were done on gut feel and
> in combination with other bits.  It may be possible to shave off a
> cycle without hurting the clock TOO much, but I doubt it, but it may
> be possible to squeeze a little bit better with some better balancing,
> but it's hard to get much faster when you are hitting the BlockRAMs.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 40678
Subject: Re: cyphers
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 12 Mar 2002 22:06:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <cfd3bf0a.0203121206.14b6425b@posting.google.com>,
drake <drake1337@hotmail.com> wrote:
>i am looking for VHDL to implement cryptographic cyphers in an FPGA,
>and an FPGA with a PCI interface.  does anybody have any ideas?

How much performance do you want?  How much area?  What FPGA?  Why
VHDL and not Verilog or schematic?

And what cipher?

The only symmetric key ciphers you should even consider are
AES/Rijndael and 3DES.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 40679
Subject: Timing Simulations
From: prashantj@usa.net (Prashant)
Date: 12 Mar 2002 14:28:49 -0800
Links: << >>  << T >>  << A >>
hi,

In Quartus II , is the timing simulation after compilation a good
indication of the speeds seen by a design in the actual FPGA ?

If not what would I need to do to get a correct estimate of the timing
?

What about routing delay estimates when the design gets mapped to the
FPGA ? Are they accounted for in any way in the timing estimation
process ?

Thanks,
Prashant

Article: 40680
Subject: Re: DPRAM implementation in altera
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 12 Mar 2002 14:39:56 -0800
Links: << >>  << T >>  << A >>
MegaPowerStar wrote:

> Is there any equivalent verilog LPM/ALTPM function module from altera
> for xillinx dualport ram block RAMB4_S16_S16 module.The currently
> available DPRAM functions from altera(like
> LPM_RAM_DP,ALTSYNCRAM,ALT3PRAM) do not match the above xillinx DPRAM
> module.
> If not how can I implement the DPRAM in altera device.

Altera dpram has one just one read and one write port.
The following code snippet uses the ram this way and will infer a
DPRAM_16_8_256_6_0 for altera, or a
RAM_B4_S16_S16 for xylinx (leo ties off extra read and write controls)

        -- Mike Treseler
-----------------------------------------------------------
. . .

   constant mem_size : natural := 2**add_length; 
   type     mem_type is array (mem_size-1 downto 0) of
                               std_logic_vector (dat_length-1 downto 0);
   subtype  ptr_type is unsigned(add_length-1 downto 0);  -- unsigned wraps
   signal   mem         : mem_type;
   signal   we          : std_ulogic;   -- write signal to block ram   
   signal   rd_head_ptr : ptr_type;     -- both _ptr must init same 
   signal   wr_tail_ptr : ptr_type;     -- each counts up appropriate cycles
                                                         
begin

-------------------------------------------------------------------------------
-- Leo infers ram_dq_da_inclock_out_clock_16_8_256 from this template
-- for Virtex, this makes a RAM_B4_S16_S16 library XCV
-- for Apex, this makes a DPRAM_16_8_256_6_0 interface LPM library OPERATORS
-------------------------------------------------------------------------------
   ram_access : process (clk)
   begin
      if rising_edge(clk) then
         if we = '1' then
            mem(to_integer(wr_tail_ptr)) <= data_i;  -- raw address   
         end if;
            data_q <= mem(to_integer(rd_head_ptr));  -- mem data after pop low
      end if;
   end process ram_access;

. . .

Article: 40681
Subject: Re: Mystery two wire interface, or am I being dense?
From: "Mark A. Odell" <mark@embeddedfw.com>
Date: 12 Mar 2002 22:42:26 GMT
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in news:3C8D8F19.108838BE@yahoo.com:

> I need to implement a two wire interface used on a Cypress CY22393 clock
> chip. The data sheet simply refers to it as "industry-standard
> signaling".  The two signal names are SDAT and SCLK.  They give no info
> on the logic or the timing of the interface.  

When they don't pay Philips for the license they refer indirectly to I2C. 
See the I2C spec. at www.philips.com. It's a pig-simple hardware protocol. 
Well at least if you're doing single master anyhow.

- Mark

Article: 40682
Subject: Re: Timing Simulations
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 12 Mar 2002 14:48:14 -0800
Links: << >>  << T >>  << A >>
Prashant wrote:

> In Quartus II , is the timing simulation after compilation a good
> indication of the speeds seen by a design in the actual FPGA ?

If you mean the static timing analysis and you have
a synchronous design, then yes.

> What about routing delay estimates when the design gets mapped to the
> FPGA ? Are they accounted for in any way in the timing estimation
> process 

Same answer.

 -- Mike Treseler

Article: 40683
Subject: Re: Article in March Embedded Systems - "The Death of Hardware
From: Ray Andraka <ray@andraka.com>
Date: Tue, 12 Mar 2002 22:59:03 GMT
Links: << >>  << T >>  << A >>
Nick brought to my attention that he was referring to the 5v Virtex,  I
instinctively saw the -6 and assumed VirtexE.  Not having the luxury of using the
fastest speed grades, I am not sure of the numbers off hand for the 5v virtex, but
it isn't that far different than the E-6.  The near 200 MHz number assumes you avoid
using the WE and ENA similar to what I have posted here before.

Ray Andraka wrote:

> The block RAMs do add a challenge, but with careful design you can get them to
> run quite a bit faster than 115 MHz in a -6.  I have a -7 design where one port
> (the write port at that) is running at 240 Mhz.  The -6 should be able to get
> pretty close to 200 MHz...if you are really careful with the BRAMs.  AFAIK, the
> rijndael algorithm doesn't use carries, so the bottle neck is going to be the
> block rams.  Even at the 200 MHz, there are some tricks you can play to keep the
> BRAM from being the bottleneck.
>
> Nicholas Weaver wrote:
>
> > In article <MNsj8.27108$af7.22802@rwcrnsc53>,
> > Kevin Neilson <kevin_neilson@removethis-yahoo.com> wrote:
> > >Yeah, I read this article.  It's pretty weak.  There will come a day when we
> > >will write HDL at such a level of abstraction we won't even need to know
> > >what a CLB looks like.  That day is a long long way off.  The tragedy is
> > >that some managers believe this hype and allocate valuable resources to it,
> > >ushering in a wave of weak, bloated, 50-levels-of-logic desgins.
> >
> > And if they don't need to worry about the bloat and slowdown, there is
> > no problem.
> >
> > My classic example:
> >
> > An academic implementation of a Rijndael core relies heavily on HDL
> > synthesis, and uses an 8 stage pipeline for the single round.  It ran
> > at 100 MHz (according to static timing analysis) on a Virtex-6, using
> > 2000 slices and 8 BlockRAMS, with expanded subkeys stored in
> > Luts-as-ram.  1.2 Gbps throughput on nonfeedback modes, 150 Mbps
> > throughput on feedback modes.
> >
> > My implementation relied heavily on hand placing and understanding the
> > target architecture.  It uses a 5 stage pipeline for the single
> > round.  It runs at 115 MHz (according to static timining analysis) on
> > a Spartan II-5, using 800 slices and 10 BlockRAMs[1], with subkeys
> > computed on the fly.  1.3 Gbps throughput on nonfeedback modes, 260
> > Mbps throughput on feedback modes.  Ray Andraka probably could have
> > added another 5-10% improvement [2].
> >
> > So, by using a synthesis methodology instead of programming to the
> > device, there is an ~10% penalty in throughput on nonfeedback modes, a
> > ~70% penalty in throughput on feedback modes, and a ~60% penalty on
> > area.
> >
> > If these costs don't matter, then synthesis worked fine.  If costs
> > DOES matter, then synthesis failed hideously, and someone who was
> > doing this as part of a product would have to call one of the many
> > FPGA expert consultants to have it done right.
> >
> > [1] The extra 2 BlockRAMs were for the sboxes in the
> > subkey-generation.
> >
> > [2] Based that some of my design decisions were done on gut feel and
> > in combination with other bits.  It may be possible to shave off a
> > cycle without hurting the clock TOO much, but I doubt it, but it may
> > be possible to squeeze a little bit better with some better balancing,
> > but it's hard to get much faster when you are hitting the BlockRAMs.
> > --
> > Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 40684
Subject: How do I infer a carry-chain parity generator in XST?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 12 Mar 2002 17:26:29 -0600
Links: << >>  << T >>  << A >>
        I will like to know if there is a way to infer a parity
generator that uses Virtex's carry-chains rather than LUTs?
The reason I am asking this question is because when I synthesize a
parity generator, XST uses LUTs rather than carry-chains even if "XOR
Collapsing" option is checked (enabled).
I will like to conserve valuable LUTs, and use carry-chains because
carry-chains are rarely used in my design.
Will I have to use Virtex specific primitives to do so, or is there a
way to do so without using Virtex specific primitives?
IF I have to use Virtex specific primitives, how do I do it?
Or is this problem XST's fault, and do other synthesis tools handle XOR
stuff differently than XST?
The parity generator here I am talking about is a one that generates the
parity of 36-inputs for PCI bus.



Thanks,



Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)

Article: 40685
Subject: Re: Mystery two wire interface, or am I being dense?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 13 Mar 2002 00:01:45 +0000
Links: << >>  << T >>  << A >>


Keith Brafford wrote:

> "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3C8D8F19.108838BE@yahoo.com...
> > I need to implement a two wire interface used on a Cypress CY22393 clock
> > chip. The data sheet simply refers to it as "industry-standard
> > signaling".  The two signal names are SDAT and SCLK.  They give no info
> > on the logic or the timing of the interface.
>
> From their datasheet:
>
> The serial port uses industry-standard signaling in both stan-dard
>
> and fast modes. This section describes the unique fea-tures
>
> of the serial interface in this family of devices.
>
> The device address is a 7-bit value that is configured during
>
> Field Programming. By programming different device address-es,
>
> two or more parts can be connected to the serial interface
>
> and be independently controlled. The device address is com-bined
>
> with a read/write bit as the LSB and is sent after each
>
> start bit.
>
> This family of devices supports 1-byte memory addressing.
>
> The memory address is always sent after each Device Ad-dress/
>
> Write bit combination. It describes the memory location
>
> within the device to be accessed. The memory address is in-cremented
>
> after each acknowledge, allowing sequential mem-ory
>
> access.
>
> To read a memory location, a write operation must be per-formed
>
> with the memory address to be read, and zero data
>
> bytes. This is followed by a repeated start bit and the Device
>
> Address/Read byte, after which the desired memory location
>
> is available for reading.
>
> --------------
>
> That sounds like I2C.
>
> > The ATmega devices include an interface they call, TWI, for two wire
> > interface.  The signal names are SDA and SCL.  Is this the same
> > interface?  Why can I not find info (in a Yahoo search anyway) on any of
> > these names other than at Atmel or Cypress?  Is this interface a real
> > orphan?
>
> That definitely sounds like I2C.  It's all over the place.
>
> --Keith Brafford

Most likely I2C except the description above left out the ACK/NACK stuff that's the most
awkward bit to implement. One good place to see a simple description of basic I2C operation
is an SDRAM DIMM data sheet. The `serial presence detect' EEPROM is an I2C device.



Article: 40686
Subject: Re: Mystery two wire interface, or am I being dense?
From: "michael brown" <n5qmg@nospam.earthlink.net>
Date: Wed, 13 Mar 2002 00:02:39 GMT
Links: << >>  << T >>  << A >>
> One of the reasons that "two wire" interfaces that are nominally IIC
> are given a different name is that they aren't fully compatible with
> the spec, even though they interwork in every practical way.
>
> Regards,
> Allan.

That may be partially true, but the primary reason that other manufacturers
don't call their parts IIC compatible is that Philips would make them pay
royalties to do so.  Pretty much whenever you hear about two-wire
interfaces, it's probably IIC compatible (more or less).

michael brown


Article: 40687
Subject: Re: Mystery two wire interface, or am I being dense?
From: "Keith Brafford" <kbrafford@nc.rr.com>
Date: Wed, 13 Mar 2002 00:08:06 GMT
Links: << >>  << T >>  << A >>
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3C8E96E9.FA47D408@algor.co.uk...
>
> Most likely I2C except the description above left out the ACK/NACK stuff that's the most
> awkward bit to implement. One good place to see a simple description of basic I2C operation
> is an SDRAM DIMM data sheet. The `serial presence detect' EEPROM is an I2C device.

Yeah...I think that the Cypress people were going out of their way to say "I2C" without
having to say it...I guess you're supposed to get the idea that it's I2C then go
look elsewhere for documentation.

I found that the Micronas 3507 and ST STA013 MP3 chips both had
good descriptions of I2C operation, too...

--Keith Brafford



Article: 40688
Subject: Re: How do I infer a carry-chain parity generator in XST?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Mar 2002 00:55:22 GMT
Links: << >>  << T >>  << A >>
Synthesis tools will generally not infer a carry chain unless it is
expressed as an add, subtract, increment or decrement.  Unless you can
reduce your function to one of these, then you'll probably have to resort to
instantiating the carry chain components.  I'm not sure how much performance
a carry chain parity will buy you, since it will require you to pull the
carry out at each bit and feed it back into the di input of the muxcy
(perhaps I missed something more elegant here).

Kevin Brace wrote:

>         I will like to know if there is a way to infer a parity
> generator that uses Virtex's carry-chains rather than LUTs?
> The reason I am asking this question is because when I synthesize a
> parity generator, XST uses LUTs rather than carry-chains even if "XOR
> Collapsing" option is checked (enabled).
> I will like to conserve valuable LUTs, and use carry-chains because
> carry-chains are rarely used in my design.
> Will I have to use Virtex specific primitives to do so, or is there a
> way to do so without using Virtex specific primitives?
> IF I have to use Virtex specific primitives, how do I do it?
> Or is this problem XST's fault, and do other synthesis tools handle XOR
> stuff differently than XST?
> The parity generator here I am talking about is a one that generates the
> parity of 36-inputs for PCI bus.
>
> Thanks,
>
> Kevin Brace (Don't respond to me directly, respond within the
> newsgroup.)


Article: 40689
Subject: Re: Mystery two wire interface, or am I being dense?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Mar 2002 00:57:23 GMT
Links: << >>  << T >>  << A >>
'More or less' is the key phrase here.  I have seen at least a half dozen
different dialects of I2C over the years.

michael brown wrote:

> > One of the reasons that "two wire" interfaces that are nominally IIC
> > are given a different name is that they aren't fully compatible with
> > the spec, even though they interwork in every practical way.
> >
> > Regards,
> > Allan.
>
> That may be partially true, but the primary reason that other manufacturers
> don't call their parts IIC compatible is that Philips would make them pay
> royalties to do so.  Pretty much whenever you hear about two-wire
> interfaces, it's probably IIC compatible (more or less).
>
> michael brown


Article: 40690
Subject: How would I know somebody has copied my files in Unix?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Wed, 13 Mar 2002 09:44:56 +0800
Links: << >>  << T >>  << A >>
Hi,

How would I know somebody has copied my files in Unix?

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg



Article: 40691
Subject: Re: Mystery two wire interface, or am I being dense?
From: "michael brown" <n5qmg@nospam.earthlink.net>
Date: Wed, 13 Mar 2002 01:53:27 GMT
Links: << >>  << T >>  << A >>
>I have seen at least a half dozen different dialects of I2C over the years.

Can there really be that many (6) variations?  ;-)  The protocol is pretty
simplistic for a proprietary protocol.  I can understand others not
implementing some of the more esoteric features, but don't see allot of room
for much variation in the scheme.

Now, the Dallas 1-wire, there's a bitch of a protocol.  ;-D  I don't see too
many variations of that floating around.  Most people don't have a clue on
how to interrogate the bus and deal with multiple devices dynamically (not
that the datasheets make it crystal clear).  If it wasn't for the skip-rom
command, nobody would use 1-wire parts.  ;-D   No wonder though, it's a real
PITA and there's really only one way to do it (AFAIK)

michael brown


Article: 40692
Subject: Re: How do I infer a carry-chain parity generator in XST?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 12 Mar 2002 20:53:09 -0600
Links: << >>  << T >>  << A >>
Okay, if synthesis tools cannot infer a carry-chain parity generator
automatically, I guess I will have to use Virtex specific primitives.
I personally want synthesis tool vendors to give users an option to
select a carry-chain or LUT for implementing an XOR gate.
        If I have to use Virtex specific primitives to build a parity
generator, should I use XORCY_L or XORCY_D?
Can I use XORCY_L only, and still be able to connect other carry-chains
located vertically without going out to the general routing resources?
Also, do I have to instantiate 35 or 36 of XORCY_L or XORCY_D to
complete the parity generator? (Trying to build a 36-bit parity
generator for PCI here.)
I guess using "generate" statement of VHDL might save time, but that is
not available in the current version of Verilog.



Thanks,



Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)



Ray Andraka wrote:
> 
> Synthesis tools will generally not infer a carry chain unless it is
> expressed as an add, subtract, increment or decrement.  Unless you can
> reduce your function to one of these, then you'll probably have to resort to
> instantiating the carry chain components.  I'm not sure how much performance
> a carry chain parity will buy you, since it will require you to pull the
> carry out at each bit and feed it back into the di input of the muxcy
> (perhaps I missed something more elegant here).
>

Article: 40693
Subject: IBIS simulation (was Re: max frequency of obuf_lvdci_dv2_18)
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 12 Mar 2002 19:49:57 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> writes:
> Run an IBIS simulation.

Is there any not-too-insanely-expensive software that
can be used for this?

Article: 40694
Subject: Re: Mutual Clock Synchronization
From: kindalin2002@yahoo.com (showbiz)
Date: 12 Mar 2002 22:39:35 -0800
Links: << >>  << T >>  << A >>
allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote in message news:<3c870132.9726435@netnews.agilent.com>...
> On Wed, 06 Mar 2002 18:19:46 -0500, Greg Neff <gregeneff@yahoo.com>
> wrote:
> 
> >On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com>
> >wrote:
> >
> >I have not looked at the CEPT standard.  We are using E1 physical
> >layer stuff for a non-telecom application.  Does the CEPT standard
> >talk about mutual clock synchronization?  If so, I would appreciate a
> >pointer to this standard.  I though that E1/T1 systems were typically
> >clocked in a master/slave arrangement, or lived with slips.
> >
> > With regard to stability, I was thinking about the stability of the
> >democratic clock, due to multiple feedback paths to the multiple phase
> >error detectors on each PLL.
> >
> >>The references for stability...  shouldn't they be contained in the
> >>ITU-T specifications regarding E1 reference timing?  The clock
> >>distribution schemes, switchover conditions on signal loss, acceptable
> >>jitter transfer and tolerance are all part of the CEPT standard.  Very
> >>constrained.
> >(snip)
> 
> As the other posters have mentioned, a "democratic" approach to timing
> is unusual, and (to me) doesn't make sense.
> 
> Regarding the ITU-T specifications, I think you should look at the
> SONET/SDH specs instead of the E1 ones.
> Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing).
> Also GR-253 (SONET).
> 
> Even the Network Time Protocol (RFC1305) that is used to synchronise
> time of day clocks on computers has a hierarchy of timing sources.
> But it might give you some ideas that will help you with your problem.
> http://www.ietf.org/rfc/rfc1305.txt
> 
> Oh, you should probably look at the datasheets for chips that are
> designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401
> http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127
> or maybe this one from Semtech:
> http://www.semtech.com/products/sets.html
> 
> Regards,
> Allan.

I have two questions related to the timing soloutions you have
mentioned:

1)I've found a similar chip from Agere systems which is TSWC01622. But
there is nothing more than a product brief on their website.
http://www.agere.com/netcom/docs/PB00144.pdf
I'll be grateful if someone provide me with more information (like a
complete datasheet)about it.
 
2)According to MT90401 datasheet the two input references should have
the same frequency. In my application I want to switch between two
different clock rates so I can't feed both of them to the chip. After
any failure of references MT90401 enters a holdover mode(suppose the
failed clock frequency X). I WANNA KNOW if returning from holdover
mode to a diffrent clock rate Y is safe and slip free. I know the
manufacture can answer the question best but I thought you may know
the structure of such devices.

Best regards,

MP

Article: 40695
Subject: How can I program into the EEPROM?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Wed, 13 Mar 2002 15:13:18 +0800
Links: << >>  << T >>  << A >>
Hi:

I am programming with a Vertex board. I found that
under JTAG mode I can only see the Spartan-II chip,
but not the SST 39SF020A EEPROM, can anybody
advice what has happened?

Thanks.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg



Article: 40696
Subject: Re: IBIS simulation (was Re: max frequency of obuf_lvdci_dv2_18)
From: bobsrefusebin@hotmail.com (Bob Perlman)
Date: 12 Mar 2002 23:31:48 -0800
Links: << >>  << T >>  << A >>
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:<qhvgc13z4q.fsf_-_@ruckus.brouhaha.com>...
> Austin Lesea <austin.lesea@xilinx.com> writes:
> > Run an IBIS simulation.
> 
> Is there any not-too-insanely-expensive software that
> can be used for this?

Try Hyperlynx.  It's inexpensive, relatively speaking.    

Bob Perlman
----------
Cambrian Design Works
http://www.cambriandesign.com

Article: 40697
Subject: Re: high active and low active reset signal mixed in a design
From: "H.L" <alphaboran@yahoo.com>
Date: Wed, 13 Mar 2002 09:41:23 +0200
Links: << >>  << T >>  << A >>
Hi ,
I have read in xilinx Answer Record #6713 that the recommend way is to
asynchronously reset FFs in Virtex designs. Also says that reset signal will
be routed in lines with minimal skews, is this process automatic or I must
declare something in my code?

Best Regards,
Harris

"Jay" <kayrock66@yahoo.com> wrote in message
news:d049f91b.0203111736.2b606c03@posting.google.com...
> In an ASIC, no, it shouldn't cause a problem, but in an FPGA where one
> group of flops is being reset at time zero, and the other is being
> reset 20nS later it could.  The FPGA has special routing for the reset
> net, if you put logic in there, you may be off into the general
> purpose routing which is MUCH slower and higher skew.  Since its
> arbitrary, why don't you just make them the same (positive or
> negative)?  It's common to use a `define for the register always @(...
> clause so you can change this stuff late in the game easily.
>
> Regards
>
> shengyu_shen@hotmail.com (ssy) wrote in message
news:<f4a5f64f.0203062312.420d9e9@posting.google.com>...
> > Hi everyone
> >
> > in my design, some module use high active reset, and other use low
> > active reset, and the global reset is low active, so all high active
> > reset is generate by pass global reset through an inverter, if this
> > will cause any problem?



Article: 40698
Subject: Re: How to Align 7x DDR Data Input to a XC2V6000-5?
From: Mark <mark@pac.net>
Date: Wed, 13 Mar 2002 08:00:21 GMT
Links: << >>  << T >>  << A >>
I think that with the toggling signals, they have a period of twice the clock period.
It seems when using clk35x_p and clk35x_n, toggle35x_p and toggle35x_n can only resolve
down to one clk35x resolution.  The 90 degree phase shift sounds like one way to find a
difference.  I believe that I once saw an appnote that described using 90 deg phases to
lock(?) onto an input signal.

Now that you mention it, I do remember reading messages about clock skew and jitter in
FPGAs.  Also, several weeks ago, I looked into the Virtex-II skew/jitter when
multiplying up the clock by 7x to the rate of 420 MHz.

John_H wrote:

> To avoid sampling the clock, you could do something a little different:
> Have a toggle flip-flop clocked by clk10x.
> Use the positive and negative edges of the clk35x to sample the toggle output.  When
> the sampled toggle value are different in the two time domains, you're at an edge of
> the clk10x.  Which edge of the clk35x you use to sample the difference determines
> which edge you're on.
>
> In the past Ray Andraka's pointed out the troubles with using a DLL recovered clock
> to sample signals in the reference clock's domain - clock skew and jitter can
> sometimes make same-edge sampling unreliable.  Depending on the allowable skew in
> your data sampling, you might be able to add a small phase shift in the DCM on the
> "safe" side.   You might also figure out how to use the 90 degree version of the
> clk10x to give you the timing margin you need but detect a specific middle timeslot.
>
> Mark wrote:
>
> > I did consider the approach you mentioned.  I've been rather spoiled, having
> > done nearly all synchronous designs.  I don't have any real, meaning internal to
> > FPGA chips, experience with "sampling" one clock with another.


Article: 40699
Subject: Pointer Processor for OC192
From: "Zak smith" <zakhama@sympatico.ca>
Date: Wed, 13 Mar 2002 00:21:21 -0800
Links: << >>  << T >>  << A >>
Do you have any data how many gates it take to implement the pointer
processor in FPGA ?
Do you have data about this design ?

Thanks





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