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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 124075

Article: 124075
Subject: Address sensitive process, Xilinx virtex2pro
From: yoni.lan@gmail.com
Date: Tue, 11 Sep 2007 22:28:39 -0000
Links: << >>  << T >>  << A >>
hi, i'm trying to write a process that is sensitive to a given
address,
i wrote something like this:

my_proc: process (Bus2ip_Clk)
begin
  if (Bus2ip_Addr = X"some address") then
  Bus2ip_Data <= X"FF00FF00";
  end if;
end process;

basicly i what i want is: if i try to read this given address (using
Xio_In32 function) i will read      0xFF00FF00.
The address that i'm comparing Bus2ip_Addr to is well in the address
space that my IP received and not used by any other process (the base
address of my IP is used for software register though but i'm taking a
far enough address).
The problem is that evry time that i read from this address i read 0.

what i'm doing wrong?
Thanks.

ps. writing and reading from the software register works perfectly.


Article: 124076
Subject: Re: Good VHDL reference?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 11 Sep 2007 23:55:34 +0100
Links: << >>  << T >>  << A >>
"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:46e6ec70.1220712902@news.planet.nl...
> It seems I have misplaced my VHDL book a long time ago and I can't
> figure out where I left it. In short: I need a new VHDL book :-(
>
> Can anyone recommend a good generic VHDL reference? I'm not looking
> for a book with a particular bias towards fpga design, asic design, or
> simulation.
>
>
http://groups.google.com/groups/search?q=vhdl+reference+book+group%3Acomp.lang.vhdl 



Article: 124077
Subject: Re: Uses of Gray code in digital design
From: Jonathan Kirwan <jkirwan@easystreet.com>
Date: Tue, 11 Sep 2007 23:42:52 GMT
Links: << >>  << T >>  << A >>
On Tue, 11 Sep 2007 05:26:23 -0700, richard.melikson@gmail.com wrote:

>> >I didn't mean it as a big question. It's quite simple, really - when
>> >was the last time *you* Jonathan (and other readers interested in
>> >sharing) used Gray codes in digital design, either in coding logic or
>> >software ?
>>
>> 2005, for an EEPROM counter.
>
>An internal address counter for access to the EEPROM ? Why did you
>choose Gray encoding in this case ?

Since you seem pretty savvy about things, think about implementing an
incrementing or decrementing counter stored in EEPROM and how to
reduce the wear on some fixed locations you may be using (one could
always use another scheme where things are in constant motion, as
well.)  As I've pointed out earlier, there are quite a number of
possible Gray code sequences available for 16 bits -- in fact, with
just 5 bits instead of 16, we have 187,499,638,240 of them.  I have no
idea what the figure is for 16 bits, but "many" will have to suffice.

In the 2-byte, 16-bit case, residing at a fixed EEPROM address, you
may want to find a particular gray code sequence where it is true
that, on average over successive partial subranges, half the bit
changes will occur in one of the bytes and half of them in the other.

In base 2 binary notation, you already know that the least significant
bit changes on every increment.  So that means the low order byte is
always written on every increment or decrement.  Which means that byte
is your weak link in the chain and will determine the lifetime of your
counter.

But with Gray coding, and the selection of a 'good' sequence (which is
not the usual one, by the way), you can pretty nicely spread out the
updates 50/50 between the two bytes -- over short ranges as well as
over the total count range -- doubling the expected endurance by a
rather modest software change.  By distributing the bits over more
bytes, you can achieve much better.

Does that help?

Jon

Article: 124078
Subject: ML410 Board & 1GB DDR2 DIMM Problem
From: Wren <werneta@gmail.com>
Date: Wed, 12 Sep 2007 00:01:43 -0000
Links: << >>  << T >>  << A >>
Hi -

I'm having problems getting a 1GB DDR2-667 DIMM to work with an ML410
board.  I'm working with the plb_ddr2 IP core in XPS.  The auto-
generated memory test works perfectly with the 256MB DIMM that the
board came with, but once I insert the new DIMM, the test fails every
time.  Per the data sheet, I incremented the address bus width and
changed the memory size.  I've tried setting the parameters to match
the data sheet, leaving them at the defaults (for a more conservative
settings), and innumerable permutations (this is ~week 3 with this
problem).  We tested the DIMM in a computer, so we know it's good.
I've also tried writing to the memory using the debugger, and any data
I write refuses to stick.  I've never worked with a non-supplied DIMM
on a Xilinx board, so I'm probably doing something dumb.  What am I
doing wrong?

Any help is appreciated.


Article: 124079
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 11 Sep 2007 17:02:46 -0700
Links: << >>  << T >>  << A >>
Add this:
> my_proc: process (Bus2ip_Clk)
> begin
  if( Bus2ip_clk'event and Bus2ip_Clk='1') then
>  if (Bus2ip_Addr = X"some address") then
>  Bus2ip_Data <= X"FF00FF00";
>  end if;
end if ;
> end process;
>



Article: 124080
Subject: Re: ML410 Board & 1GB DDR2 DIMM Problem
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 11 Sep 2007 17:04:29 -0700
Links: << >>  << T >>  << A >>
You have the extra address lines specified in the UCF file?

"Wren" <werneta@gmail.com> wrote in message 
news:1189555303.630566.130720@v23g2000prn.googlegroups.com...
> Hi -
>
> I'm having problems getting a 1GB DDR2-667 DIMM to work with an ML410
> board.  I'm working with the plb_ddr2 IP core in XPS.  The auto-
> generated memory test works perfectly with the 256MB DIMM that the
> board came with, but once I insert the new DIMM, the test fails every
> time.  Per the data sheet, I incremented the address bus width and
> changed the memory size.  I've tried setting the parameters to match
> the data sheet, leaving them at the defaults (for a more conservative
> settings), and innumerable permutations (this is ~week 3 with this
> problem).  We tested the DIMM in a computer, so we know it's good.
> I've also tried writing to the memory using the debugger, and any data
> I write refuses to stick.  I've never worked with a non-supplied DIMM
> on a Xilinx board, so I'm probably doing something dumb.  What am I
> doing wrong?
>
> Any help is appreciated.
> 



Article: 124081
Subject: Re: V5 Configuration via SPI
From: Max Baker <maxb@xilinx.com>
Date: Tue, 11 Sep 2007 17:27:51 -0700
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
> I just noticed that it says the internal oscillator runs at about 50MHz,
> that's quite a lot faster than I expected...

Hi Sean,

The 50MHz (nominal) free-running internal oscillator (CFGMCLK) is used 
by the FPGA for House Cleaning during the power up sequence.  See UG191 
(http://www.xilinx.com/bvdocs/userguides/ug191.pdf) PP. 21 "Clear 
Configuration Memory".

A different oscillator is then used during Master mode configurations 
like SPI after INIT goes high. This clock (Master CCLK) starts off at a 
slow frequency in the low MHz and is then bumped up to a user-selected 
frequency.  See bitgen -g option "ConfigRate"
(http://toolbox.xilinx.com/docsan/xilinx92/books/docs/dev/dev.pdf).

-m

Article: 124082
Subject: Re: PCI byte enalbes in read cycles
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 12 Sep 2007 10:29:57 +1000
Links: << >>  << T >>  << A >>
A.D. wrote:

> Specifications are not clear about this
> point, saying that if you perform a burst read, byte
> enable are *usually* all active on all cycles. Even figures
> always show this situation. This hide the real timing or
> behaviour of BEs. I mean: are in general BEs referred
> to the data present on the bus in next clock cycle? (BEs
> signals are asserted one clock in advance during read
> cycles...). Or this happens only on the first data cycle?

From PCI System Architecture, Chapter 8, pg 131...

"PCI permits burst transactions where the byte enables change from one
data phase to the next. Furthermore, the initiator may use any byte enable
setting, consisting of contiguous or non-contiguous byte enables. During a
read transaction, the initiator will typically assert all of the byte
enables during each data phase (because burst reads are typically reading
a stream of dwords or quadwords), but it may use any combination."

As for timing, the BEs must *NOT* change during a data phase. So although
the BEs are asserted before the 1st phase, they don't change until the
start of the 2nd phase (which may be while the phase 1 data is still being
driven, and before the phase 2 data is valid).

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-3266

Article: 124083
Subject: Re: PCI byte enalbes in read cycles
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 12 Sep 2007 10:32:07 +1000
Links: << >>  << T >>  << A >>
Mark McDougall wrote:

> As for timing, the BEs must *NOT* change during a data phase. So although
> the BEs are asserted before the 1st phase, they don't change until the
> start of the 2nd phase (which may be while the phase 1 data is still being
> driven, and before the phase 2 data is valid).

Actually, I correct myself, they're not asserted *BEFORE* the 1st phase,
but during the 1st phase...

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-3266

Article: 124084
Subject: Re: Uses of Gray code in digital design
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 11 Sep 2007 17:12:02 -0800
Links: << >>  << T >>  << A >>
richard.melikson@gmail.com wrote:

>>Binary-coded counter sequences often change multiple bits on one count
>>transition. That can (will) lead to decoding glitches, especially when
>>counter values are compared for identity.

> What do you mean by "compared for identity" - do you mean equality of
> two multi-bit registers ?

> Also, what kind of glitches are you referring to here ? Logic
> hazards ?

In the days when ripple counters were more popular, it was
more of a problem.   In a ripple counter, like the TTL 7490,
each bit changes on the falling edge of the next lower bit.

(snip)
> Why can't the values just be synchronized (double FF) between the
> domains with a handshake and solve the problem of glitches in the
> first place ?

Even with a synchronous counter, the bits don't change at exactly
the same time.  Even if they did, differences in wire length or
propagation velocity would cause them to be different when
they got to the first latch.

>>The "one bit change per transition" advantage occurs only in counters,
>>or under other very restrictive circumstances. I do not see an
>>advantage in general state machines, where sequences are not as
>>predictable.

> So why do all synthesis tools propose "gray code" as one of the
> encodings of state machines ?

Most for FPGAs like one-hot encoding.

-- glen


Article: 124085
Subject: Re: ML410 Board & 1GB DDR2 DIMM Problem
From: Wren <werneta@gmail.com>
Date: Tue, 11 Sep 2007 18:15:59 -0700
Links: << >>  << T >>  << A >>
On Sep 11, 5:04 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> You have the extra address lines specified in the UCF file?

Yup.  I incremented the bus width in the IP configuration, the mhd
file, and added an address in the .UCF file, pointing it to the pin
last pin referred to in the ML410 user's guide.


Article: 124086
Subject: Re: Uses of Gray code in digital design
From: CBFalconer <cbfalconer@yahoo.com>
Date: Tue, 11 Sep 2007 21:54:35 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> richard.melikson@gmail.com wrote:
> 
>> So why do all synthesis tools propose "gray code" as one of the
>> encodings of state machines ?
> 
> I expect that the original author got it wrong and others copied
> the idea. A state is normally decoded synchronously and the the
> coding scheme makes no functional difference.

'synchronously' requires a clock driving everything.  Not avail.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com


Article: 124087
Subject: Re: Uses of Gray code in digital design
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 11 Sep 2007 20:03:33 -0700
Links: << >>  << T >>  << A >>
CBFalconer wrote:

> 'synchronously' requires a clock driving everything.  Not avail.

That depends on the application.
When a clock *is* available, the
state encoding style is irrelevant
to timing or function.

  -- Mike Treseler

Article: 124088
Subject: Re: Uses of Gray code in digital design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 12 Sep 2007 15:28:03 +1200
Links: << >>  << T >>  << A >>
richard.melikson@gmail.com wrote:
> Hi Peter, thanks for replying. My comments below...
>>The "one bit change per transition" advantage occurs only in counters,
>>or under other very restrictive circumstances. I do not see an
>>advantage in general state machines, where sequences are not as
>>predictable.
> 
> 
> So why do all synthesis tools propose "gray code" as one of the
> encodings of state machines ?

Suppose you want to create a Gray counter ? - A Gray encoded state 
machine is one such way, after all, a counter is a simple state machine.

Also, even if you start with a Sync Binary counter, routing
delay deltas can still cause decoder glitches, so if you want
reliable glitch free decodes, then use a Gray counter.

-jg


Article: 124089
Subject: Re: Uses of Gray code in digital design
From: johnp <johnp3+nospam@probo.com>
Date: Tue, 11 Sep 2007 20:58:15 -0700
Links: << >>  << T >>  << A >>
On Sep 11, 8:28 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> richard.melik...@gmail.com wrote:
> > Hi Peter, thanks for replying. My comments below...
> >>The "one bit change per transition" advantage occurs only in counters,
> >>or under other very restrictive circumstances. I do not see an
> >>advantage in general state machines, where sequences are not as
> >>predictable.
>
> > So why do all synthesis tools propose "gray code" as one of the
> > encodings of state machines ?
>
> Suppose you want to create a Gray counter ? - A Gray encoded state
> machine is one such way, after all, a counter is a simple state machine.
>
> Also, even if you start with a Sync Binary counter, routing
> delay deltas can still cause decoder glitches, so if you want
> reliable glitch free decodes, then use a Gray counter.
>
> -jg

So here's one caveat on Gray coding.  Multiple times, Ive seen
designers take the output of
a binary counter, feed it into a combinatrorial Gray encoder, then
treat the output as if
only one bit will change at a time.  Yes, after a settling time, the
final output will be a Gray
code, but this arrangement still has decoding glitches.

John Providenza


Article: 124090
Subject: Re: Uses of Gray code in digital design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 12 Sep 2007 16:21:54 +1200
Links: << >>  << T >>  << A >>
Jonathan Kirwan wrote:
<snip>
> In base 2 binary notation, you already know that the least significant
> bit changes on every increment.  So that means the low order byte is
> always written on every increment or decrement.  Which means that byte
> is your weak link in the chain and will determine the lifetime of your
> counter.
> 
> But with Gray coding, and the selection of a 'good' sequence (which is
> not the usual one, by the way), you can pretty nicely spread out the
> updates 50/50 between the two bytes -- over short ranges as well as
> over the total count range -- doubling the expected endurance by a
> rather modest software change.  

That's true, if you assume they BYTE write, and not PAGE write anyway :)

I see the Atmel Serial EE's only spec
Endurance 5.0V, 25C, Page Mode >1M

which suggests everything is page mode, and even if only one byte
is loaded, the device reads/erase/repgms a whole page set.

-jg


Article: 124091
Subject: Re: Good VHDL reference?
From: Eli Bendersky <eliben@gmail.com>
Date: Wed, 12 Sep 2007 05:19:46 -0000
Links: << >>  << T >>  << A >>
On Sep 11, 9:33 pm, n...@puntnl.niks (Nico Coesel) wrote:
> It seems I have misplaced my VHDL book a long time ago and I can't
> figure out where I left it. In short: I need a new VHDL book :-(
>
> Can anyone recommend a good generic VHDL reference? I'm not looking
> for a book with a particular bias towards fpga design, asic design, or
> simulation.
>

I've waded through my share of VHDL books, and Ashenden's (Designer's
Guide) is by far the best of the pack.

Eli


Article: 124092
Subject: Re: Question about Virtex-4 DCM
From: ghelbig@lycos.com
Date: Wed, 12 Sep 2007 05:41:55 -0000
Links: << >>  << T >>  << A >>
On Sep 10, 11:27 pm, austin <aus...@xilinx.com> wrote:
> Gary,
>
> There is the BUFGMUX, which will allow you to switch from a clock, to
> another.
>
> Set it for asynchronous operation (allows a switch to a dead clock),
> ,and then just switch over to a BUFG which has no clock on it (connected
> to a '0' or a '1').
>
> I believe that RESET will also work, but as you say, there will be
> transitions that may occur, and if you just want everything to cease,
> the BUFGMUX may be a better test.
>
> Austin (at RADECS 2007, in Deauville, Fr)
>
> Austin

Thanks.


Article: 124093
Subject: Re: ML410 Board & 1GB DDR2 DIMM Problem
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Wed, 12 Sep 2007 06:09:49 -0000
Links: << >>  << T >>  << A >>
On Sep 12, 3:15 am, Wren <wern...@gmail.com> wrote:
> On Sep 11, 5:04 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
>
> > You have the extra address lines specified in the UCF file?
>
> Yup.  I incremented the bus width in the IP configuration, the mhd
> file, and added an address in the .UCF file, pointing it to the pin
> last pin referred to in the ML410 user's guide.

The 1 GB DIMM might be a dual bank one. Which means you basically have
two 512 Mo DIMM sharing the same lines except clk,  cs_n & odt . Not
all controller can handle that ...
So either you only 512 Mo of it.
Or you buy a 2 Go DIMM to use only 1 Go of it.

   Sylvain


Article: 124094
Subject: Re: PCI byte enalbes in read cycles
From: "A.D." <isd_mod@libero.ix>
Date: Wed, 12 Sep 2007 06:21:33 GMT
Links: << >>  << T >>  << A >>
Mark McDougall <markm@vl.com.au> wrote in message
46e73310$0$14156$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> As for timing, the BEs must *NOT* change during a data phase.
> So although the BEs are asserted before the 1st phase, they
> don't change until the start of the 2nd phase (which may be
> while the phase 1 data is still being driven, and before the
> phase 2 data is valid).

Ok, so will new BEs for the second data phase be put on the
bus starting from clock 3? (I'm considering figure 3.5 of PCI
2.2 specs, that is commonly used and reproduced to show
the read cycle).

Antonio




Article: 124095
Subject: Re: Uses of Gray code in digital design
From: CBFalconer <cbfalconer@yahoo.com>
Date: Wed, 12 Sep 2007 02:31:33 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> CBFalconer wrote:
> 
>> 'synchronously' requires a clock driving everything.  Not avail.
> 
> That depends on the application.  When a clock *is* available, the
> state encoding style is irrelevant to timing or function.

You didn't leave much of a quote.  Assuming this has to do with
Gray codes, there is no reason to assume the source can be clocked,
in fact this is relatively rare.  In general source values change
when they are in the appropriate mood.  Now deal with the result.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com


Article: 124096
Subject: Re: Uses of Gray code in digital design
From: Paul Keinanen <keinanen@sci.fi>
Date: Wed, 12 Sep 2007 09:40:21 +0300
Links: << >>  << T >>  << A >>
On Tue, 11 Sep 2007 20:03:33 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

>CBFalconer wrote:
>
>> 'synchronously' requires a clock driving everything.  Not avail.
>
>That depends on the application.
>When a clock *is* available, the
>state encoding style is irrelevant
>to timing or function.

If you have a counter, you usually feed it with a clock :-)

A ripple counter (7490 style) is more or less useless for decoding
states at high speeds, since the decoding can be done only after the
sum of the flip-flop propagation delays. 

In synchronous counter (such as 74196), each flip-flop "knows" in
advance, if it should change state at the next count pulse, thus the
delay is only as large as the propagation delay of a single FF. Some
gating is required to decide, if the FF should change state at the
next count pulse or not.

Since gating is required anyway for the counting, I don't see the
point of using a Gray sequence instead of a simple 1-2-4-8 weighting.

For short sequences, the Johnston counter would be ideal, if you need
to decode all states.

Paul


Article: 124097
Subject: Re: Uses of Gray code in digital design
From: Jonathan Kirwan <jkirwan@easystreet.com>
Date: Wed, 12 Sep 2007 06:58:58 GMT
Links: << >>  << T >>  << A >>
On Wed, 12 Sep 2007 16:21:54 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>Jonathan Kirwan wrote:
><snip>
>> In base 2 binary notation, you already know that the least significant
>> bit changes on every increment.  So that means the low order byte is
>> always written on every increment or decrement.  Which means that byte
>> is your weak link in the chain and will determine the lifetime of your
>> counter.
>> 
>> But with Gray coding, and the selection of a 'good' sequence (which is
>> not the usual one, by the way), you can pretty nicely spread out the
>> updates 50/50 between the two bytes -- over short ranges as well as
>> over the total count range -- doubling the expected endurance by a
>> rather modest software change.  
>
>That's true, if you assume they BYTE write, and not PAGE write anyway :)
>
>I see the Atmel Serial EE's only spec
>Endurance 5.0V, 25C, Page Mode >1M
>
>which suggests everything is page mode, and even if only one byte
>is loaded, the device reads/erase/repgms a whole page set.

Page mode would be a problem.  ;)

Jon

Article: 124098
Subject: Re: PCI byte enalbes in read cycles
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 12 Sep 2007 17:18:13 +1000
Links: << >>  << T >>  << A >>
A.D. wrote:

> Ok, so will new BEs for the second data phase be put on the
> bus starting from clock 3? (I'm considering figure 3.5 of PCI
> 2.2 specs, that is commonly used and reproduced to show
> the read cycle).

No! They must not changed until the data has been transferred for the
current phase.

From section 3.3.1...

"The C/BE# lines contain the byte enable information for data phase N+1 on
the clock following the completion of data phase N."

Since phase 1 ends on clock 4, the BE for phase 2 is valid on clock 5.

Also see fig 3-6...

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-3266

Article: 124099
Subject: Re: What is called carry chain structure in FPGA is called in IC?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 11 Sep 2007 23:19:08 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

(snip on carry generation in FPGAs)

> The physical implementation can vary a lot, using different
> compromises between speed and complexity (and perhaps power
> consumption). There is ripple carry, carry look-ahead, carry
> anticipate, and even more exotic methods. 

I thought the XC4000 series was a specialized form of carry
select using pass transistors.   I haven't looked at the
newer series, I don't believe that they are documented as well
as the older ones.  I used to do work on designs that used the
properties of the XC4000 carry chain.  Since the carry logic
was separate from the CLB logic, one could use it, for example,
to compare two values without computing the difference.

-- glen




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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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