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
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
"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.vhdlArticle: 124077
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? JonArticle: 124078
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
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
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
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). -mArticle: 124082
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-3266Article: 124083
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-3266Article: 124084
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. -- glenArticle: 124085
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
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.comArticle: 124087
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 TreselerArticle: 124088
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. -jgArticle: 124089
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 ProvidenzaArticle: 124090
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, 25°C, 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. -jgArticle: 124091
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. EliArticle: 124092
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
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. SylvainArticle: 124094
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). AntonioArticle: 124095
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.comArticle: 124096
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. PaulArticle: 124097
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, 25°C, 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. ;) JonArticle: 124098
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-3266Article: 124099
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:
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